Zero-Knowledge Proofs (ZKPs)

If a statement is true, an honest prover who knows the secret witness can convince an honest verifier of this fact. This property ensures the protocol works correctly when all parties follow the rules.

• Formal Guarantee: For any valid input (the secret witness), the probability that the verifier accepts the proof approaches 1.
• Example: In a ZKP for proving knowledge of a password's hash pre-image, if the prover actually knows the correct password, the protocol will always succeed in convincing the verifier.
• Engineering Implication: This is a baseline correctness property; a protocol lacking completeness is fundamentally broken for its intended purpose.

If a statement is false, no dishonest prover (even one with unlimited computational power) can convince an honest verifier that it is true, except with a negligibly small probability. This protects the verifier from being fooled.

• Statistical vs. Computational: Soundness can be statistical (holds against any prover) or computational (holds only against provers limited to probabilistic polynomial-time algorithms, assuming certain problems are hard).
• Example: In a ZKP for a transaction's validity, a malicious prover cannot create a proof for an invalid, double-spending transaction.
• Security Parameter: The negligible probability of cheating is tuned by a security parameter (e.g., 128-bit security), making successful deception cryptographically infeasible.

The proof reveals nothing beyond the veracity of the statement itself. The verifier learns no information about the prover's secret witness. This is the defining property that enables privacy.

• Simulation Paradigm: Formally, anything the verifier can compute after seeing the proof, it could have computed on its own using a simulator that only knows the statement is true (not the secret). The proof and the simulated proof are computationally indistinguishable.
• Types: Perfect zero-knowledge (distributions are identical), Statistical zero-knowledge (distributions are statistically close), or Computational zero-knowledge (distributions are indistinguishable to efficient algorithms).
• Example: A ZKP of age ("I am over 21") conveys only that boolean truth, not the exact birth date, address, or name.

A specialized property for zk-SNARKs (Succinct Non-interactive Arguments of Knowledge). The proof is extremely small and fast to verify, independent of the computational complexity of the original statement.

• Verification Time: Scales with the size of the statement, not the witness. Often constant or logarithmic.
• Proof Size: Typically a few hundred bytes, regardless of whether the proven computation involved millions of steps.
• Critical for Scalability: This enables blockchain applications where verifying a proof on-chain is cheap, even if the off-chain computation (e.g., a batch of transactions) was massive. It is not a core requirement for all ZKPs but is essential for modern, efficient applications.

The prover sends a single message to the verifier, who can verify it without further back-and-forth communication. This is achieved via a trusted setup (zk-SNARKs) or public randomness (zk-STARKs).

• Trusted Setup (zk-SNARKs): Requires a one-time, ceremony-dependent generation of public parameters (Common Reference String). If the ceremony is compromised, soundness can fail.
• Transparent Setup (zk-STARKs): Uses publicly verifiable randomness, eliminating the trusted setup requirement but often resulting in larger proof sizes.
• Application Benefit: Non-interactive proofs can be posted to a blockchain or included in a message, enabling asynchronous verification, which is crucial for decentralized systems.

In agentic memory systems, ZKPs enable privacy-preserving queries and state proofs. An agent can prove properties about its private memory or actions without revealing the underlying data.

• Proven State Transitions: An agent can prove it updated its internal state correctly according to its rules, without exposing the state's contents.
• Access Control Proofs: An agent can prove it has the correct credentials or role (RBAC/ABAC attributes) to perform an action, without revealing its full identity or other attributes.
• Integrity without Disclosure: Combines with immutable logs and audit trails to prove log consistency or the occurrence of an event, while keeping event details private. This aligns with privacy by design and supports compliance with regulations like GDPR by minimizing data exposure.

Agents can prove they possess the correct credentials or that a piece of data meets certain criteria without revealing the query or the data itself. This is critical for accessing sensitive context from a shared memory store.

• Example: An agent proves it is authorized to retrieve a customer's financial records without disclosing which customer or what specific records were accessed.
• Mechanism: Uses zk-SNARKs or zk-STARKs to generate a succinct proof that a hidden input satisfies a public verification function.

ZKPs can cryptographically attest that an agent's action or a memory update was performed correctly according to a predefined protocol, creating a tamper-evident audit trail.

• Ensures that context written to long-term memory is valid and authorized.
• Prevents unauthorized or malformed state changes by malicious or faulty agents.
• Enables verifiable computation where the proof is small and quick to verify, unlike re-executing the entire agent logic.

When multiple agents operate on shared state or memory, ZKPs allow them to prove the correctness of their local computations before committing to a global state, ensuring consistency without full disclosure.

• Prevents agents from submitting invalid partial results to a shared ledger or knowledge graph.
• Enables Byzantine Fault Tolerance in decentralized agent networks, as proofs can be verified independently by any participant.
• Use Case: Coordinating a supply chain where agents prove inventory changes are valid without revealing proprietary business logic.

An agent can hold a rich, private context (e.g., a user's full profile) and generate proofs about specific attributes on-demand, adhering to the principle of least privilege.

• Example: Proving a user is over 21 years old from a private ID, or proving an account balance exceeds a threshold without revealing the exact amount.
• Contrasts with Data Masking or Tokenization by providing cryptographic certainty of the statement's truth, not just a sanitized copy.

ZKP circuits can encode complex security and governance policies. An agent's execution trace can be proven to have adhered to these policies, providing algorithmic compliance.

• Links to: Formal Verification by providing executable, verifiable proofs of policy adherence.
• Audit Trail: Creates an immutable, cryptographically verifiable log that specific RBAC or ABAC rules were followed.
• Essential for regulated industries where agent actions must be demonstrably compliant.

ZKPs enable agents operating in different security domains or trust boundaries to collaborate by proving statements about their internal state without a trusted intermediary.

• Enables interoperability between agents owned by different organizations without sharing raw data.
• Foundation for privacy-preserving machine learning in agentic systems, where one agent can prove it trained a model on valid data without exposing the dataset.
• Contrasts with Trusted Execution Environments (TEEs) by providing cryptographic guarantees instead of hardware-based isolation.

A cryptographic protocol that allows multiple parties to jointly compute a function over their private inputs while keeping those inputs concealed from each other. Unlike ZKPs, which prove a statement about secret data, SMPC enables collaborative computation on that secret data.

• Key Distinction: SMPC reveals the output of a computation, while ZKPs reveal only the validity of a statement.
• Example: Two hospitals could use SMPC to compute the average patient treatment cost without sharing individual patient records.
• Use Case in Memory: Enables agents with private datasets to collaboratively train a model or query a shared knowledge base without exposing their raw, sensitive context.

A rigorous mathematical framework that quantifies and bounds the privacy loss incurred when an individual's data is included in a statistical analysis or dataset. It adds calibrated noise to query results or training data.

• Core Mechanism: Guarantees that the inclusion or exclusion of any single data point does not significantly change the output distribution.
• vs. ZKPs: Provides statistical privacy for aggregate insights; ZKPs provide cryptographic certainty for specific statements.
• Use Case in Memory: Applied when releasing aggregated statistics from an agent's memory log or when fine-tuning a model on user interactions, ensuring no single interaction can be inferred.

A form of encryption that allows computations to be performed directly on ciphertext, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext.

• Functional Property: Enables Encrypt(A) ⊗ Encrypt(B) = Encrypt(A ⊕ B), where ⊗ and ⊕ are operations.
• Comparison to ZKPs: Focuses on private computation on encrypted data, whereas ZKPs focus on private verification of a claim.
• Use Case in Memory: Allows an agent to store its memory in an encrypted vector database. A retrieval service can perform similarity searches on the encrypted embeddings without ever decrypting the sensitive memory contents.

A secure, isolated area within a main processor (e.g., Intel SGX, AMD SEV) that guarantees the confidentiality and integrity of code and data loaded inside it, even from a compromised operating system or hypervisor.

• Hardware Root of Trust: Relies on hardware-enforced isolation, unlike the cryptographic guarantees of ZKPs.
• Trust Model: Requires trust in the hardware manufacturer and the TEE's attestation, whereas ZKPs are trustless.
• Use Case in Memory: Can host an agent's memory and inference engine, ensuring that sensitive context and model weights are never exposed in plaintext to the underlying infrastructure.

A security model that grants or denies access to resources based on a set of attributes (user, resource, action, environment) and policies, enabling fine-grained, dynamic authorization.

• Policy-Driven: Access decisions are made by evaluating policies against attributes (e.g., user.role == 'analyst' AND resource.sensitivity == 'low').
• Integration with ZKPs: A user can prove they possess certain credentials or attributes (e.g., over age 21, holds a valid license) via a ZKP to satisfy an ABAC policy without revealing their full identity.
• Use Case in Memory: Governs access to specific memory segments or context windows within an agentic system. ZKPs can provide the privacy-preserving credentials for such access checks.

The process of using mathematical reasoning and logic to prove or disprove the correctness of a system's algorithms, protocols, or hardware designs against a formal specification.

• Mathematical Rigor: Aims for exhaustive proof of properties like safety, liveness, or security.
• Application to ZKPs: Critical for verifying the soundness and completeness of ZKP circuit constructions (e.g., arithmetic circuits for zk-SNARKs) to ensure there are no logical flaws that could break the proof's guarantees.
• Use Case in Memory: Used to verify that the privacy-preserving access logic for an agent's memory (which may use ZKPs) adheres to its security policy under all possible execution paths.