Counterfactual Receipts: A Framework for Cryptographic Negative Attestation in Autonomous Agent Systems
By Harris Abbaali | NotaryOS | March 2026
---
## Abstract
As autonomous AI agents proliferate across domains—executing financial transactions, managing infrastructure, negotiating contracts, and coordinating with other agents—the question of accountability shifts from what did the agent do? to an equally critical but largely unaddressed counterpart: what did the agent NOT do?
This paper introduces the concept of the counterfactual receipt—a cryptographically verifiable attestation that an autonomous agent did not take a specific action, did not exceed a defined boundary, or did not pursue an available decision path. We provide a formal definition encompassing three modes of negative attestation—proofs of inaction, proofs of constraint adherence, and proofs of non-selected represented paths—and establish the theoretical foundations, security properties, and threat model for such receipts.
We further present NotaryOS as, to the best of the author's knowledge, the first public production system explicitly implementing scoped counterfactual receipts for AI-agent decision workflows, demonstrating that these constructions are not merely theoretical but deployable at the latencies required by real-time agent workflows. We argue that counterfactual receipts represent a necessary and previously missing primitive in the AI accountability stack, and that their absence constitutes a fundamental gap in current approaches to agent governance, compliance, and trust.
---
## 1. Introduction
The rapid deployment of autonomous AI agents into consequential decision-making contexts—financial trading, healthcare triage, legal analysis, supply chain optimization—has generated substantial academic and regulatory interest in agent accountability. Existing approaches overwhelmingly focus on positive attestation: the creation of logs, audit trails, and cryptographic proofs that record what an agent did. This paper identifies and addresses a fundamental asymmetry in the current accountability landscape: the near-total absence of formal mechanisms for attesting to what an agent did not do.
Consider an AI agent authorized to trade equities on behalf of a portfolio. Current audit systems can verify that the agent executed a particular trade at a particular time. But equally important questions remain unaddressable: Did the agent refrain from insider trading when it had access to material nonpublic information? Did it avoid exceeding position limits during a volatile period? Were there alternative trades it considered and rejected, and if so, on what basis? These are counterfactual questions, and they demand counterfactual evidence.
We introduce the counterfactual receipt as the formal primitive that fills this gap. A counterfactual receipt is a cryptographically verifiable attestation that an autonomous agent either (a) did not perform a specific action it was capable of performing, (b) did not violate a specific constraint or boundary condition, or (c) did not select a specific represented decision path that was available and sealed within its observation boundary. This tripartite definition captures the full scope of negative attestation required for comprehensive agent accountability.
The contributions of this paper are as follows:
1. We provide the first formal definition of counterfactual receipts, establishing a rigorous taxonomy of three modes: proofs of inaction, proofs of constraint adherence, and proofs of non-selected represented paths.
2. We establish the cryptographic and information-theoretic properties required for counterfactual receipts to be sound, complete, and non-forgeable, and articulate the threat model under which these properties hold.
3. We situate counterfactual receipts within the broader landscape of AI accountability, demonstrating their necessity as a complement to existing positive attestation mechanisms.
4. We present NotaryOS as, to the best of the author's knowledge, the first public production system explicitly implementing scoped counterfactual receipts for AI-agent decision workflows, establishing a proof of concept that moves these constructions from theory to deployment.
5. We identify applications spanning regulatory compliance, multi-agent coordination, insurance, and enterprise governance, and discuss implications for the emerging field of AI agent trust infrastructure.
---
## 2. Background and Motivation
### 2.1 The Accountability Asymmetry
Current AI accountability frameworks exhibit a pronounced structural asymmetry. Virtually all existing mechanisms—from simple logging to sophisticated cryptographic audit trails—are designed to record positive events: actions taken, decisions made, outputs produced. This asymmetry reflects the historical trajectory of accountability systems designed for human actors, where the default assumption is that inaction requires no documentation.
For autonomous agents, this assumption fails. An agent's decision space at any moment may contain thousands of possible actions, of which it executes one (or a small number). The overwhelming majority of its behavior at any given timestep consists of actions not taken. In many regulatory and contractual contexts, the non-occurrence of specific actions is as important as—or more important than—the actions that were taken.
### 2.2 The Counterfactual Gap in Existing Systems
We identify three categories of existing accountability mechanisms and demonstrate the counterfactual gap in each:
Audit Logs. Traditional logging records events that occur. The absence of a log entry is not evidence of inaction—it may indicate a logging failure, a gap in coverage, or a deliberate omission. Logs are structurally incapable of providing affirmative proof that something did not happen.
Blockchain and Distributed Ledger Systems. Blockchain-based approaches provide immutable records of transactions that were executed. While the absence of a transaction on a ledger is suggestive, it does not constitute cryptographic proof of non-occurrence, particularly when the agent may have access to multiple ledgers or off-chain execution paths.
Formal Verification. Model checking and formal verification can prove that a system satisfies certain properties across all possible execution paths. However, these approaches operate at design time, not runtime. They prove that a system cannot violate a property, not that a running instance did not violate it during a specific execution window.
### 2.3 Why Counterfactual Evidence Matters
Regulatory Compliance. Financial regulators require not merely evidence of lawful trades but evidence that unlawful trades were not made. Healthcare compliance demands proof that patient data was not accessed without authorization. In each case, the regulatory question is inherently counterfactual.
Multi-Agent Coordination. When agents from different organizations interact, each party needs assurance not only about what the counterparty's agent did, but about what it did not do—particularly regarding information handling, scope of authority, and side effects.
Insurance and Liability. As AI agents assume greater operational responsibility, insurers and legal frameworks require evidence of due diligence—proof that an agent did not act negligently and did not exceed its authorized scope.
Trust Calibration. Positive attestation tells you what the agent did right; counterfactual attestation tells you what it resisted doing wrong. Both are necessary for informed trust.
---
## 3. Formal Framework
### 3.1 Preliminaries
Let A denote an autonomous agent operating within an environment E. At each discrete timestep t, the agent occupies a state s_t ∈ S and has available an action space Α(s_t) ⊆ Α, where Α is the universe of all possible actions. The agent selects and executes an action a_t ∈ Α(s_t) according to its policy π. We define the complement set Ā(s_t) = Α(s_t) \ {a_t} as the set of actions available but not taken at timestep t.
Let C = {c_1, c_2, ..., c_n} denote a set of constraints governing the agent's behavior, where each constraint c_i is a predicate over the agent's state and action history. Let Π(s_t) denote the set of all feasible decision paths available to the agent at state s_t.
### 3.2 Definition of Counterfactual Receipts
Definition (Counterfactual Receipt). A counterfactual receipt R_cf is a tuple (M, σ, t, τ, B, V) where M is a machine-readable claim asserting the non-occurrence of a specified event, condition, or decision path; σ is a cryptographic signature binding M to a specific agent identity and execution context; t is a timestamp or temporal interval over which the claim holds; τ is the type of counterfactual attestation (one of: INACTION, CONSTRAINT, or PATH); B is the declared observation boundary—the interfaces, tools, agents, model outputs, witnesses, timestamps, data sources, execution environment, and workflow stages over which the claim is valid (a counterfactual receipt makes no claim about events outside B); and V is a verification procedure that allows any party holding the receipt to independently confirm its validity within B.
Definition (Proof of Inaction — Type I). A counterfactual receipt of type τ = INACTION attests that for a specified action a* ∈ Α(s_t), the agent did not execute a* during a temporal interval [t_start, t_end], despite a* being available in its action space throughout that interval. Formally: ∀t ∈ [t_start, t_end]: a* ∈ Α(s_t) ∧ a_t ≠ a*.
Definition (Proof of Constraint Adherence — Type II). A counterfactual receipt of type τ = CONSTRAINT attests that for a specified constraint c_i ∈ C, the agent's actions satisfied c_i throughout a temporal interval [t_start, t_end]. Formally: ∀t ∈ [t_start, t_end]: c_i(s_t, a_t) = true. This is equivalent to attesting that no constraint violation occurred.
Definition (Proof of Non-Selected Represented Path — Type III). A counterfactual receipt of type τ = PATH attests that a specified externally represented candidate path, model output, reasoning artifact, branch, or decision alternative was generated or made available within observation boundary B, cryptographically sealed at the time of generation, and not selected or executed as the final path. This receipt establishes that the alternative existed and was observable within B, but was not chosen—enabling audit of what decision options were present and which were rejected.
### 3.3 Security Properties
Scoped Soundness. If a counterfactual receipt is verified as valid, then—under the stated witness, instrumentation, key-management, and observation-boundary assumptions—the attested event did not occur within boundary B during interval t, except with negligible probability. Soundness is scoped to B: no claim is made about events outside the declared observation boundary.
Completeness. Completeness is relative to the declared boundary B: within the covered interfaces and operational witness assumptions, any covered non-event within B can be represented as a valid receipt. The system makes no claim about events outside B.
Non-Forgeability. No party—including the agent itself, its operator, or any external adversary—can produce a valid counterfactual receipt for a non-event that did in fact occur. This property must hold even if the agent is compromised or adversarially controlled.
Temporal Binding. A counterfactual receipt is bound to a specific temporal interval and cannot be retroactively extended to cover periods outside its original scope.
Independence. The validity of a counterfactual receipt must not depend solely on the attestation of the agent being audited. At minimum, one independent observer or cryptographic mechanism must corroborate the non-occurrence.
---
## 4. Construction
### 4.1 Architectural Requirements
Producing sound counterfactual receipts requires an architecture fundamentally different from positive attestation systems. Where positive attestation records events that occur (an inherently reactive process), counterfactual attestation must actively monitor for the non-occurrence of events (an inherently proactive process).
Continuous Observation. The attestation system must maintain continuous observation of the agent's action space, not merely its executed actions. A gap in observation renders counterfactual claims unsound for the unobserved interval.
Action Space Enumeration. For Type I receipts, the system must be able to enumerate or bound the agent's available action space at each timestep. This does not require exhaustive enumeration of all possible actions—only that the specific action being attested as not-taken was demonstrably available.
Independent Witness. The Independence property requires that counterfactual attestation involve at least one entity beyond the agent itself. This can be an external observer, a trusted execution environment, a cryptographic commitment scheme, or a combination thereof.
### 4.2 The Witness-Observer Model
We propose a general construction based on a Witness-Observer model. A trusted witness W maintains an independent view of the agent A's execution environment. At each attestation interval, W performs the following:
1. Captures or receives the agent's current state s_t and available action space Α(s_t).
2. Observes the agent's executed action a_t.
3. For each counterfactual claim M to be attested, verifies that the non-event described by M is consistent with the observed execution.
4. Produces a signed receipt R_cf = (M, σ_W, t, τ, B, V) binding the claim to the witness's identity, the observation timestamp, and the declared observation boundary.
The witness need not be a single entity. In a distributed setting, the witness function can be implemented by a quorum of observers, a trusted execution environment (TEE), or a combination of hardware and software attestation mechanisms.
### 4.3 Provenance DAGs for Counterfactual Chains
Individual counterfactual receipts can be composed into directed acyclic graphs (DAGs) that represent the full counterfactual history of an agent's execution. Each node in the DAG is a receipt, and edges represent temporal or causal dependencies. This structure enables complex queries such as: "Over the past 30 days, produce all intervals during which the agent had access to dataset D but did not query it."
Provenance DAGs also enable counterfactual chaining: the derivation of higher-order counterfactual claims from compositions of lower-order receipts. For example, a Type II constraint adherence receipt over a complex policy may be decomposed into a chain of Type I inaction receipts for each atomic action that would have violated the policy.
---
## 5. NotaryOS: A Reference Implementation
To demonstrate that counterfactual receipts are not merely a theoretical construct, we present NotaryOS (NotaryOS.org) as, to the best of the author's knowledge, the first public production system explicitly implementing scoped counterfactual receipts for AI-agent decision workflows. NotaryOS is a platform providing cryptographic receipts and attestations for AI agent actions, with counterfactual receipts as a core and distinguishing capability.
### 5.1 Architecture Overview
NotaryOS implements the Witness-Observer model through a multi-plane architecture consisting of an Action Plane, an Attestation Plane, and a Verification Plane. The Action Plane captures agent state and executed actions in real time. The Attestation Plane, operating asynchronously on dedicated processing resources, generates both positive and counterfactual receipts. The Verification Plane exposes an API through which any authorized party can verify any receipt—positive or counterfactual—against the underlying attestation chain.
### 5.2 The Reasoning Forge: Counterfactual Receipts in Practice
The Reasoning Forge (accessible at notaryos.org/forge) is the primary demonstration of counterfactual receipt generation in a live, interactive system. The Forge implements comparative counterfactual attestation: a user submits a single prompt to multiple AI models simultaneously—drawing from a pool that includes models from OpenAI, Anthropic, Google, xAI, and Moonshot—and each model's externally represented analysis artifact is cryptographically sealed as an independent receipt at the moment it enters the NotaryOS workflow.
The critical insight is that the Forge transforms an activity users already want to perform—comparing AI model outputs—into an automatic counterfactual receipt generation process. When a user selects one model's output as the basis for a decision, each non-selected sealed artifact becomes a Type III (Proof of Non-Selected Represented Path) receipt: proof that the alternative was represented within B, sealed at the moment it entered the NotaryOS workflow, available to the selection procedure, and not selected as the final path.
This construction achieves a property essential for practical adoption: the cryptographic attestation layer imposes zero additional cognitive or procedural burden on the user. The user's natural workflow—querying, comparing, and selecting—produces the evidentiary artifacts as a byproduct rather than as an overhead.
### 5.3 DAG Agent: Independent Witness Architecture
A second architectural element of NotaryOS is the DAG Agent—a specialized trust witness that observes other agents in workflows and creates independent attestations. The DAG Agent operates as a passive observer rather than an active participant, which satisfies the Independence requirement established in Section 3.3 and sidesteps legal liability concerns that would arise if the witness were a co-participant in the agent's actions.
### 5.4 Implementation Status and Verifiability
At the time of writing, NotaryOS is deployed and operational at NotaryOS.org, with the Reasoning Forge accessible at NotaryOS.org/forge, representing—to the best of the author's knowledge—the first public production system explicitly implementing scoped counterfactual receipts for AI-agent decision workflows. Any reader of this paper can independently verify the system's operation by submitting a prompt through the Reasoning Forge and observing the cryptographic sealing of each model's analysis artifact in real time.
---
## 6. Applications
### 6.1 Regulatory Compliance
Financial regulators increasingly require evidence of what automated systems did not do. A counterfactual receipt system can provide cryptographic proof that a trading agent did not execute trades based on material nonpublic information, did not exceed position limits, and did not engage in market manipulation strategies—all as verifiable attestations rather than mere log entries. Similar applications exist in healthcare, environmental regulation, and data privacy.
### 6.2 Multi-Agent Trust
When autonomous agents from different organizations interact, each party needs assurance about the counterparty agent's behavior boundaries. Counterfactual receipts enable verifiable proof that a counterparty's agent did not share proprietary information, did not pursue exploitative strategies, and did not exceed its negotiation mandate.
### 6.3 Insurance and Liability
As AI agents assume operational responsibilities, counterfactual receipts provide the evidentiary basis for liability determinations: proof that an agent did or did not have access to relevant information, did or did not consider available alternatives, and did or did not operate within its authorized scope.
### 6.4 Trust Calibration Over Time
An agent that consistently produces counterfactual receipts demonstrating adherence to policies, resistance to adversarial prompts, and avoidance of unauthorized actions builds a verifiable track record of trustworthiness that no amount of positive attestation alone can provide.
---
## 7. Related Work
Cryptographic Audit and Transparency Logs. Certificate Transparency, Key Transparency, and related systems provide append-only logs of positive events. These systems establish that certain events occurred but are structurally silent on non-events. Counterfactual receipts complement transparency logs by providing the negative attestation counterpart.
Zero-Knowledge Proofs. ZKPs enable proving properties of data without revealing the data itself. While ZKPs could be used as a building block within counterfactual receipt constructions, the concept of counterfactual receipts is orthogonal to the specific proof system employed. A counterfactual receipt defines what is being attested; ZKPs address how the attestation is constructed.
AI Alignment and Safety. The AI alignment community has extensively studied ensuring that AI systems behave as intended. Counterfactual receipts address the complementary problem of providing verifiable evidence that an agent behaved as intended after the fact. While alignment seeks to prevent misalignment ex ante, counterfactual receipts provide evidence of non-misalignment ex post.
Explainable AI (XAI). XAI methods provide post-hoc explanations of why an AI system made a particular decision. Counterfactual receipts provide something different: verifiable proof of what the system did not decide. XAI addresses the question "why this action?" while counterfactual receipts address "why not that action?"—and do so with cryptographic rather than interpretive evidence.
Trusted Execution Environments (TEEs). TEEs such as Intel SGX and ARM TrustZone provide hardware-based attestation of code execution. TEEs can serve as a building block for counterfactual receipt systems but do not inherently provide the semantic framework for negative attestation that counterfactual receipts define.
---
## 8. Discussion
### 8.1 The Epistemology of Non-Events
Proving that something did not happen is, in general, a harder epistemological problem than proving that something did happen. Counterfactual receipts do not resolve this philosophical challenge in the general case; rather, they provide a formal framework for a tractable subset: proving non-occurrence within a defined observation scope, with respect to a specific agent, over a bounded temporal interval, attested by an independent witness. The scoping is what makes the problem tractable, and the formal framework is what makes the solution rigorous.
### 8.2 Limitations and Open Problems
Several important limitations merit acknowledgment. First, the observation scope of any counterfactual receipt system is necessarily bounded. A receipt attests to non-occurrence within the system's observation domain; events outside that domain are not covered. Second, the quality of counterfactual receipts is bounded by the fidelity of action space enumeration. Third, when an agent's action space is continuous or implicitly defined—as is common in large language model deployments—the boundary between Type I (Inaction) and Type III (Non-Selected Represented Path) receipts can become fuzzy, requiring further formalization. Fourth, composing counterfactual receipts across organizational boundaries introduces trust aggregation challenges that require further investigation.
### 8.3 Toward a Complete Accountability Stack
A complete AI accountability stack requires both positive and negative attestation as co-equal primitives. Positive attestation answers "what happened?" Negative attestation—via counterfactual receipts—answers "what did not happen?" Together, they provide a comprehensive account of an agent's behavior that is far more informative than either alone. The introduction of counterfactual receipts as a formal construct is, to the best of our knowledge, the first attempt to establish this symmetry in the accountability literature.
---
## 9. Conclusion
This paper has introduced the counterfactual receipt as a new cryptographic primitive for AI agent accountability: a verifiable attestation of non-occurrence, non-violation, and non-pursuit. We have provided a formal definition encompassing three types of negative attestation—proofs of inaction, proofs of constraint adherence, and proofs of non-selected represented paths—and established the security properties and architectural requirements for their sound construction.
We have presented NotaryOS as, to the best of the author's knowledge, the first public production implementation of scoped counterfactual receipts, demonstrating the practical viability of these constructions. We have identified applications across regulatory compliance, multi-agent coordination, insurance, and trust calibration, and have situated counterfactual receipts within the broader landscape of AI accountability.
The central claim of this paper is that the absence of negative attestation represents a fundamental gap in current AI accountability infrastructure—a gap that will become increasingly consequential as autonomous agents assume greater operational scope and authority. Counterfactual receipts are the primitive that fills this gap. Their formalization and implementation mark a necessary step toward accountability systems that can answer not only what AI agents do, but what they refrain from doing—and prove it.
---
## Appendix A: Sample Counterfactual Receipt — JSON Schema and Verification
This appendix presents a representative counterfactual receipt in the NotaryOS wire format. Identifiers, hashes, and signature values are illustrative; field names, structure, and semantics correspond directly to the formal tuple R_cf = (M, σ, t, τ, B, V) defined in Section 3.2. A live verifiable receipt can be obtained by submitting a prompt through the Reasoning Forge at notaryos.org/forge.
### A.1 Sample Raw Receipt — Type III (Non-Selected Represented Path)
```
{
"receipt_id": "rcpt_01HX9K2MNPQR7STUVWXY3Z4AB5",
"version": "2.0",
"type": "COUNTERFACTUAL",
"tau": "PATH",
"issued_at": "2026-03-14T18:42:07.391Z",
"interval": {
"start": "2026-03-14T18:41:55.002Z",
"end": "2026-03-14T18:42:07.391Z"
},
"observation_boundary": {
"workflow": "reasoning_forge",
"session_id": "sess_7FGHJ9K2LMNP",
"models_observed": [
"gpt-4o",
"claude-sonnet-4-20250514",
"gemini-2.0-pro"
],
"witness": "notaryos-attestation-service-v2",
"scope": "externally_represented_artifacts_only"
},
"claim": {
"description": "Model output sealed and not selected as final decision path",
"non_selected_model": "gemini-2.0-pro",
"selected_model": "claude-sonnet-4-20250514",
"prompt_hash": "sha256:a3f8c2d1e4b709...",
"artifact_hash": "sha256:9b8c7d6e5f4a3b...",
"capability_confirmed": true,
"counterfactual": true,
"would_have": {
"action": "select_as_final_output",
"model": "gemini-2.0-pro",
"artifact_sealed": true
}
},
"payload_hash": "sha256:1a2b3c4d5e6f7a...",
"previous_receipt_hash": "sha256:0f1e2d3c4b5a69...",
"signature": {
"algorithm": "Ed25519",
"key_id": "notaryos-signing-key-2026-03",
"value": "base64:3yXk9mNpQrStUvWx..."
},
"verification": {
"jwks_endpoint": "https://notaryos.org/.well-known/jwks.json",
"verify_endpoint": "https://notaryos.org/v1/receipts/verify",
"chain_endpoint": "https://notaryos.org/v1/receipts/chain"
}
}
```
### A.2 Field Semantics
tau. Receipt type: INACTION (Type I), CONSTRAINT (Type II), or PATH (Type III). This example is PATH — a Proof of Non-Selected Represented Path.
observation_boundary (B). The declared scope of the attestation. Claims extend only to externally represented artifacts entering the NotaryOS workflow, not to internal model activations.
claim.artifact_hash. SHA-256 hash of the sealed model output artifact at the moment it entered the NotaryOS workflow. Any modification to the sealed output invalidates the receipt.
claim.capability_confirmed. Confirms that the non-selected model output was genuinely available and observable within boundary B. This distinguishes a counterfactual receipt (the alternative existed and was not chosen) from a simple absence (the alternative was never generated).
claim.counterfactual. Explicitly marks this as a counterfactual receipt — a proof of non-selection rather than a proof of execution.
claim.would_have. Structured record of the action that would have occurred had this path been selected.
previous_receipt_hash. Hash of the immediately preceding receipt in the chain, forming the tamper-evident hash chain. Any modification to a prior receipt invalidates all subsequent receipts.
signature. Ed25519 signature over the canonical serialization of the receipt payload, produced by the NotaryOS attestation service.
### A.3 Verification Procedure
Any party holding a counterfactual receipt can independently verify it using the following five steps:
1. Fetch the signing key. Retrieve the Ed25519 public key corresponding to signature.key_id from the JWKS endpoint at https://notaryos.org/.well-known/jwks.json.
2. Reconstruct the payload hash. Canonically serialize the receipt object (excluding the signature field) and compute its SHA-256 hash. Confirm it matches payload_hash.
3. Verify the signature. Verify signature.value against payload_hash using the Ed25519 public key. A valid signature confirms the receipt was produced by the NotaryOS attestation service and has not been modified since issuance.
4. Verify the hash chain. Retrieve the receipt identified by previous_receipt_hash and confirm that its payload_hash matches the value recorded in this receipt.
5. Confirm the observation boundary. Confirm that the attested non-event falls within the declared observation boundary B. Claims about events outside B are not covered by this receipt.
### A.4 Sample Verification Response
```
{
"receipt_id": "rcpt_01HX9K2MNPQR7STUVWXY3Z4AB5",
"valid": true,
"signature_verified": true,
"chain_intact": true,
"observation_boundary_confirmed": true,
"tau": "PATH",
"claim_summary": "gemini-2.0-pro output sealed and not selected",
"verified_at": "2026-05-21T09:15:33.002Z",
"key_id_used": "notaryos-signing-key-2026-03",
"chain_depth": 14
}
```
---
## References
Amodei, D., Olah, C., Steinhardt, J., Christiano, P., Schulman, J., & Mané, D. (2016). Concrete problems in AI safety. arXiv preprint arXiv:1606.06565.
Ben-Sasson, E., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., & Virza, M. (2014). Zerocash: Decentralized anonymous payments from Bitcoin. Proceedings of the 2014 IEEE Symposium on Security and Privacy, 459–474.
Costan, V., & Devadas, S. (2016). Intel SGX explained. IACR Cryptology ePrint Archive, Report 2016/086.
Goldwasser, S., Micali, S., & Rackoff, C. (1989). The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18(1), 186–208.
Laurie, B., Langley, A., & Kasper, E. (2013). Certificate Transparency. RFC 6962. Internet Engineering Task Force.
Lundberg, S. M., & Lee, S.-I. (2017). A unified approach to interpreting model predictions. Advances in Neural Information Processing Systems, 30, 4765–4774.
McKeen, F., et al. (2013). Innovative instructions and software model for isolated execution. Proceedings of HASP 2013.
Melara, M. S., Blankstein, A., Bonneau, J., Felten, E. W., & Freedman, M. J. (2015). CONIKS: Bringing key transparency to end users. Proceedings of the 24th USENIX Security Symposium, 383–398.
Pearl, J. (2009). Causality: Models, reasoning, and inference (2nd ed.). Cambridge University Press.
Ribeiro, M. T., Singh, S., & Guestrin, C. (2016). "Why should I trust you?": Explaining the predictions of any classifier. Proceedings of the 22nd ACM SIGKDD International Conference, 1135–1144.
Russell, S. (2019). Human compatible: Artificial intelligence and the problem of control. Viking.
Shoham, Y., & Leyton-Brown, K. (2008). Multiagent systems: Algorithmic, game-theoretic, and logical foundations. Cambridge University Press.
Wooldridge, M. (2009). An introduction to multiagent systems (2nd ed.). Wiley.