]>

bondar.roman@gmail.com

Security AI agents data provenance attestation certificate authority epistemic warrant supply chain Large Language Model (LLM)-based agent systems increasingly invoke external tools and data sources, yet the epistemic provenance of consumed data remains architecturally unregulated. Data crossing tool-call boundaries acquires the apparent trustworthiness of the interface rather than reflecting the institutional standing of its actual source -- a phenomenon termed "semantic laundering." This document specifies the Warrant Certificate Authority (WCA): an end-to-end cryptographic attestation infrastructure that certifies data sources, not data content. WCA introduces a provenance layer satisfying reference monitor properties (complete mediation, tamperproofness, verifiability) for all agent-to-tool interactions. The architecture draws on the PKI trust model, OS provenance paradigms (IMA, CamFlow, LPM), and supply-chain security frameworks (SLSA, in-toto). This document defines data structures for tool-call attestation, warrant certificates, and a trust hierarchy of certificate authorities. It specifies the provenance-layer protocol and introduces Warrant Attestation Levels (WAL-0 through WAL-3) as a graduated adoption framework analogous to SLSA build levels.

Introduction The rapid deployment of Large Language Model (LLM)-based agent architectures has created a category of data provenance risk that existing security frameworks do not address. When AI agents invoke external tools -- APIs, databases, web scrapers, knowledge graphs -- they implicitly trust the data returned. A response from a trusted API may have originated from a retracted study passed through several interpretive layers, yet the agent treats all tool outputs uniformly as "tool output," conflating the channel's trustworthiness with the content's actual provenance. This problem is structurally analogous to the blockchain oracle problem , where smart contracts must rely on external data feeds without the ability to verify their correctness on-chain. However, AI-agent systems face an additional dimension: not merely data accuracy, but preservation of epistemic justification across architectural boundaries. Prior work formalized two phenomena: Warrant Erosion: the inevitable degradation of epistemic justification through interpretive processing. Semantic Laundering: the acquisition of unwarranted credibility by data crossing trusted tool boundaries, constituting a channel-to-content trust conflation. The same authors demonstrated that human oversight undergoes a phase transition from genuine evaluation to ritualized approval at sufficient throughput, establishing that content-evaluating mediators cannot scale. This document specifies the Warrant Certificate Authority (WCA), an infrastructure that certifies data sources rather than data content. The key insight is architectural: just as PKI Certificate Authorities certify server identity without evaluating web page content, WCA certifies the institutional standing of data sources without judging the truth of individual responses. This design is structurally analogous to provenance layers in operating systems: IMA (Integrity Measurement Architecture) tracks what code ran on a system via kernel-level measurement and TPM anchoring. CamFlow tracks all information flows as a provenance monitor satisfying the reference monitor concept. LPM (Linux Provenance Modules) provides 170 provenance hooks parallel to LSM security hooks with 2.7% overhead. PASS introduced provenance-aware storage at the filesystem level. None of these systems evaluate the correctness or meaning of the data they track. They provide complete, tamperproof, verifiable records of what happened. WCA provides the same for AI agent tool calls: not judgment, but attestation. This document makes the following contributions: Specification of data structures for tool-call attestation, warrant certificates, and a hierarchical trust model for certificate authorities. A provenance-layer protocol satisfying reference monitor properties (complete mediation, tamperproofness, verifiability) for AI agent tool calls. Warrant Attestation Levels (WAL-0 through WAL-3): a graduated adoption framework analogous to SLSA build levels, providing practical deployment milestones. Non-interference requirements and mitigation strategies for mediated self-licensing risks. Security analysis covering response substitution, self-licensing, replay attacks, source impersonation, and attestation log tampering.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document:

Agent:

An LLM-based system that invokes external tools and data sources to accomplish tasks.

Attestation:

A cryptographically signed record binding a specific query to a specific response from an identified source at a specific time.

Attestation Log:

An append-only, hash-chained sequence of attestation records maintained by the provenance layer.

Channel-to-Content Trust Conflation:

The error of treating a communication channel's trustworthiness as evidence for the trustworthiness of specific data transmitted through that channel.

Domain WCA:

An intermediate certificate authority covering a specific epistemic domain, subordinate to a Root WCA.

Epistemic Domain:

A bounded field of knowledge within which a source's institutional authority applies (e.g., "pharmacology", "legal-records").

Epistemic Warrant:

The structured justification backing a proposition, comprising observations, inference rules, and institutional attestations. WCA operationalizes only the institutional attestation component.

Institutional Anchor:

The organizational basis for a source's authority within its epistemic domain.

Non-Interference:

The condition that an agent is purely a consumer of registered source data, with no pathway to modify or influence what registered sources store or return.

Provenance Layer:

The mandatory intermediary component that mediates all tool calls between agent and external sources.

Root WCA:

The top-level certificate authority in a WCA hierarchy.

Semantic Laundering:

The phenomenon whereby weakly warranted data acquires unwarranted epistemic status by crossing a trusted tool-call boundary.

Self-Licensing:

The condition where an agent generates a proposition and subsequently treats it as externally warranted.

Source:

An external system that provides data to agents via tool calls.

Trusted Source Registry:

A registry maintained by WCA operators containing registered sources with their public keys, epistemic domains, and institutional anchors.

Warrant Certificate (WC):

A compound data structure comprising a tool-call attestation, the source's certificate, and a chain proof to a trusted Root WCA.

Warrant Attestation Level (WAL):

One of four graduated levels (WAL-0 through WAL-3) specifying increasing provenance guarantees for agent systems.

W_institutional(s, D):

The institutional warrant of source s in domain D.

Problem Statement

Warrant Erosion Epistemic warrant is a structured object, not a scalar:

where: O = {observations grounding p} I = {admissible inference rules deriving p from O} S = {signed attestations from institutional sources} ]]>

For any interpretive process f:

Interpretation can only lose observations and inference rules, never gain them. This is the Warrant Erosion Principle .

Semantic Laundering Semantic laundering occurs when:

= W_min) ]]>

Data without institutional attestation gains "warranted" status solely by crossing a trusted tool-call interface. This constitutes channel-to-content trust conflation.

Insufficiency of Content-Evaluating Mediators For any mediator M that evaluates content:

The argument proceeds in four steps: (a) M must identify proposition boundaries (semantic judgment), (b) M must define canonical representations (representational assumptions), (c) M must assign warrant status (ritualizes under throughput ), (d) M's "certified" label becomes a new laundering channel. This result motivates WCA's design: certify sources, not content.

Architecture Overview

Design Principle WCA certifies sources, not content. This distinction avoids the mediator vulnerability. Evaluating content requires semantic judgment that scales poorly; certifying provenance requires only identity verification and institutional audit -- operations performed at registration time, not per-query.

System Components A WCA deployment consists of: Root WCA: Top-level certificate authority. Domain WCAs: Intermediate CAs for specific epistemic domains. Trusted Source Registry (R): Authorized data sources with keys and domain assignments. Provenance Layer: Enforcement component mediating all tool calls. Attestation Log (L): Append-only, hash-chained transaction log. Registered Sources: Data providers implementing WCA signing.

Data Structures

Trusted Source Registry Entry

", "public_key": "", "domain": "urn:wca:domain:", "anchor": { "organization": "...", "basis": "..." }, "valid_from": "", "valid_until": "", "issuer_wca": "urn:wca:authority:", "revocation": { "crl_uri": "...", "ocsp_uri": "..." } } ]]>

source_id:

Globally unique URI using the "urn:wca:source:" prefix.

public_key:

MUST be ECDSA P-256 or Ed25519 .

domain:

MUST be from the WCA Epistemic Domain Registry ().

anchor:

Institutional basis for authority, populated during registration audit.

valid_from / valid_until:

Validity period. Source certificates SHOULD have a maximum validity of one year. Renewal requires re-audit.

Tool-Call Attestation For query q from agent a to source s returning response r:

where Sign() is ECDSA-P256-SHA256 or Ed25519 , H() is SHA-256 , and || denotes concatenation of canonical byte encodings. Each field MUST be prefixed with a 4-byte big-endian length followed by the field bytes. The source MUST sign the binding of all five components. Nonce inclusion prevents replay; agent_id inclusion prevents cross-agent substitution. Protocol: Agent generates query q and cryptographically random nonce n (>= 16 bytes). Provenance layer forwards (q, agent_id, n) to source s. Source computes response r. Source obtains timestamp tau from a trusted time source. Source computes signature. Source returns (r, tau, signature). Provenance layer verifies using K_pub_s from R.

Warrant Certificate

", "source_certificate": "", "chain_proof": [""] } ]]>

The SourceCertificate issuer_signature is:

WCA Certificate

", "public_key": "", "domain_scope": ["urn:wca:domain:", "..."], "trust_anchor": { "organization": "...", "basis": "..." }, "parent_wca": "urn:wca:authority:" or null, "valid_from": "", "valid_until": "", "parent_signature": "" or null } ]]>

Root WCA certificates are self-signed. Domain WCA certificates MUST be signed by their parent WCA. WCA key pairs MUST be generated and stored in HSMs. Root WCA key generation MUST use multi-party key ceremony procedures.

Attestation Log Entry

", "source_id": "urn:wca:source:", "response": "", "signature": "", "timestamp": "", "warrant_cert": "", "previous_hash": "", "entry_hash": "" } ]]>

entry_hash is computed over all preceding fields. previous_hash links to the predecessor. The log MUST be append-only. Implementations SHOULD periodically commit the chain head to an external transparency log.

WCA Trust Hierarchy

Root WCA MUST store private key in HSM with multi-party access controls. MUST use offline key storage. MUST maintain Certificate Transparency log of issued Domain WCA certificates. SHOULD be operated by a consortium or standards body.

Domain WCA MUST have certificate signed by Root or parent Domain WCA. MUST specify domain_scope. MUST perform institutional audit before issuing source certificates. MUST maintain CRL or operate OCSP responder. Example hierarchy:

Source Certificates Issuance requires: (1) institutional audit, (2) key verification, (3) domain validation. Certificates SHOULD have maximum one-year validity. Renewal MUST include re-audit.

Certificate Lifecycle Issuance -> Active -> Renewal (with re-audit) or Revocation. Revocation triggers: key compromise, institutional standing change, misrepresentation of data sourcing, WCA operator determination. Provenance layer MUST check revocation before accepting signatures. Implementations SHOULD cache revocation status (max 24 hours).

Provenance Layer Protocol

Protocol Flow

Step 1 - Query Registration:

Agent submits query q with fresh nonce n. Provenance layer records (q, agent_id, n, timestamp_local).

Step 2 - Source Lookup:

Consult R; verify source is registered and certificate is valid. If invalid, MUST reject and log rejection with reason code.

Step 3 - Query Routing:

Forward (q, agent_id, n) to source over authenticated channel. SHOULD use mTLS.

Step 4 - Response Receipt:

Source computes r, obtains tau, signs binding, returns (r, tau, signature).

Step 5 - Signature Verification:

Verify using K_pub_s from Cert_s. On failure, MUST reject, MUST log failure, MUST NOT deliver to agent.

Step 6 - Warrant Certificate Construction:

Assemble WC = (Att(q,s,r), Cert_s, ChainProof).

Step 7 - Attestation Log Append:

Append e_i = (seq_i, q, s_id, r, signature, tau, WC, H(e_{i-1})).

Step 8 - Delivery or Rejection:

Deliver (r, WC) or rejection notice. Rejected data MUST NOT enter agent reasoning context.

Warrant assignment upon delivery:

Reference Monitor Properties The provenance layer MUST satisfy three properties per and :

RM1 - Complete Mediation:

Every external data access by the agent MUST pass through the provenance layer. The agent MUST NOT have direct network access to external sources. SHOULD be enforced via network isolation.

RM2 - Tamperproofness:

Attestation log MUST be append-only and hash-chained.

RM3 - Verifiability:

Any party with log access and public keys MUST be able to independently verify every entry.

Attestation Log The log MUST be append-only and hash-chained. Implementations SHOULD replicate to external audit services. SHOULD define retention policy per regulatory context. SHOULD periodically commit chain head to external transparency log.

Warrant Attestation Levels

WAL-0: No Provenance Baseline state. No guarantees. Default for current agent systems.

WAL-1: Provenance Exists Source identification recorded; cryptographic verification MAY be absent. Provenance layer MUST log source identity and responses. Post-hoc attribution possible but not cryptographically verified. Adoption cost: minimal (middleware only).

WAL-2: Signed Provenance Sources MUST sign responses per . Source keys MUST be certified by Domain WCA. Provenance layer MUST verify signatures. Guarantees: query-response binding, source authenticity, anti-laundering bound. Adoption cost: moderate.

WAL-3: Full Verification Provenance layer MUST satisfy RM1-RM3. All tool calls MUST be logged in hash-chained attestation log. Agents MUST generate signed queries with nonces. Non-interference MUST be enforced or M2 MUST be implemented (). Guarantees: all five security properties (). Adoption cost: highest. Use Case Min WAL Rationale Exploratory research WAL-0 Low stakes General info retrieval WAL-1 Post-hoc review Business intelligence WAL-2 Source verify Medical decision support WAL-3 Safety-critical Legal research WAL-3 Regulatory Financial trading WAL-3 Fiduciary duty

Migration Path Phase 1 (WAL-0 to WAL-1): Deploy logging middleware. Phase 2 (WAL-1 to WAL-2): Source signing + Domain WCA setup. Phase 3 (WAL-2 to WAL-3): Full RM1-RM3 + attestation log.

Non-Interference Requirements

Definition Agent a satisfies non-interference w.r.t. registry R iff:

NI-1:

a has no write access to any registered source s in R.

NI-2:

a does not control or operate any registered source s in R.

NI-3:

a cannot influence the stored state of any upstream system feeding s in R.

WAL-3 deployments MUST enforce non-interference or implement an equivalent mitigation.

Mediated Self-Licensing Risk When NI-1 is violated, the following loop is possible: Agent generates content. Agent writes content to registered source. Agent queries that source. Source returns content with valid signature. Provenance layer issues WC. Agent's own content carries institutional warrant. TLA+ model checking confirms: with non-interference, 286 states explored, no self-licensing. Without: counterexample in 3 transitions.

Mitigation Strategies WAL-3 deployments MUST enforce at least one:

M1 - Non-Interference at Deployment:

Read-only access to registered sources. Strongest mitigation.

M2 - Origin-Aware Warrant Assignment:

If data in source was written by agent a, queries from a receive W = 0.

M3 - Institutional Transformation Gate:

Agent-written data undergoes institutional process (peer review, QA) before becoming queryable with warrant.

Integration Considerations

Agent Framework Integration

LangChain/LangGraph:

Provenance layer as BaseTool.invoke() wrapper.

AutoGen/AG2:

Shared provenance layer at tool execution boundary.

Model Context Protocol (MCP):

MCP servers implement signing; MCP clients verify via provenance layer.

OpenAI Function Calling / Anthropic Tool Use:

Provenance layer wraps function execution step.

Source-Side Requirements Sources at WAL-2+ MUST: generate key pair (ECDSA P-256 or Ed25519), implement signing endpoint, undergo institutional audit, implement certificate renewal and key rotation. Sources SHOULD: use HSMs, implement rate limiting, monitor for anomalous signing.

Performance Considerations Per-query overhead: sub-millisecond for cryptographic operations. Ed25519 signs at ~70K ops/sec, verifies at ~30K ops/sec. SHA-256 >1 GB/s. Dominated by network latency. LPM demonstrated 2.7% overhead for whole-system kernel provenance; WCA at tool-call granularity is expected negligible.

Security Considerations

Threat Model Attacker can: MITM traffic, operate malicious sources, inject unattested data, replay responses, impersonate sources, tamper with log. Trust assumptions: Root WCA key security (HSM), sound crypto primitives, correct RM1-RM3 enforcement, institutional audit at registration. Out of scope: registered source providing incorrect data (source quality, not provenance).

Response Substitution Defense: signature covers H(q || r || tau || nonce || agent_id). Modification detected. Residual: key compromise (standard PKI mitigations).

Agent Self-Licensing Defense: non-interference prevents registration and indirect pathways. W = 0 for agent-generated propositions. Residual: NI violation enables mediated self-licensing ().

Replay Attacks Defense: nonce in signature binding. Timestamp enables freshness. Implementations MUST use >= 16 byte random nonces.

Source Impersonation Defense: certificate chain to Root WCA. Residual: WCA compromise.

WCA Compromise Defense: HSMs, multi-party ceremonies, CT logs, CRLs/OCSP, short-lived certificates.

Attestation Log Tampering Defense: hash chain; modification cascades. External transparency log anchoring for additional assurance.

Limitations WCA does NOT defend against: source inaccuracy, domain mismatch, agent reasoning errors, WCA-source collusion, interpretive warrant erosion (but preserves originals in log for audit).

IANA Considerations

WCA URN Namespace This document requests registration of formal URN namespace "wca" per . Syntax: urn:wca:<entity-type>:<entity-name> Entity types: "authority", "source", "domain".

WAL Level Registry New IANA registry "Warrant Attestation Levels": Level Name Reference 0 No Provenance This document 1 Provenance Exists This document 2 Signed Provenance This document 3 Full Verification This document New levels require Standards Action .

WCA Epistemic Domain Registry New IANA registry "WCA Epistemic Domains" with initial entries: Domain Description pharmacology Drug data, interactions medical-records Clinical records medical-lit Peer-reviewed medical literature legal-records Court records, filings legal-lit Legal scholarship meteorology Weather, climate genomics Genomic sequences financial-reg Regulatory filings financial-market Market data geospatial Geographic, satellite data New domains require Specification Required .

WCA Media Types

application/wca-warrant-certificate+json:

JSON serialization of Warrant Certificates.

application/wca-attestation-log+json:

JSON serialization of Attestation Log entries.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Federal Information Processing Standard, FIPS This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Linux IMA OpenSSF in-toto Project SPIFFE Project

Formal Security Properties All properties assume RM1-RM3 and EUF-CMA signature security.

Property 1: No Channel-Based Semantic Laundering For all p received by agent a: W(p) <= W_institutional(source(p)). Data cannot gain warrant above source's institutional standing.

Property 2: Self-Licensing Prevention under Non-Interference For all p generated by agent a: if NonInterference(a, R) then W(p) = 0.

Property 3: Provenance Completeness For all data d in agent context: either d has attestation log entry with valid WC, or W(d) = 0.

Property 4: Query-Response Binding Valid signature implies r is exactly what source s returned to query q at time tau. Substitution detectable.

Property 5: Warrant Erosion Auditability Agent interpretation may degrade warrant, but original data and attestation are always recoverable from log L.

Composability Multi-hop chains: W(final) = min_i(W_institutional(source_i)). No laundering through composition.

TLA+ Model Summary Model verified with TLC: WCA_Strict.cfg (non-interference): PASS, 286 states. WCA_MediatedLoop.cfg (NI violated): FAIL, counterexample in 3 transitions (agent generates, writes to source, queries back with warrant > 0).

Comparison with Related Systems Dimension Covered By WCA Agent identity BAID, DIDs+VCs, SPIFFE -- Execution environment Omega, TEEs -- Action audit trails PROV-AGENT, VFA, MAIF -- Access control CaMeL -- Prompt/context integrity Auth. Prompts, CIV -- Output signing RAG Sign -- Data source warrant NONE YES Anti-channel-laundering NONE YES Self-licensing prevention NONE YES End-to-end attestation NONE YES

JSON Serialization Examples

Warrant Certificate

Acknowledgments The foundational concepts of warrant erosion and semantic laundering were developed jointly with Oleg Romanchuk in and .