# Signed Security Receipts for AI Agents *A signed security receipt turns an agent safety check into portable evidence: subject hash, policy hash, decision, findings, evidence hash, issuer, and verifier identity.* Published 2026-05-19 · 10 min read · receipts, audit, verification ## The missing artifact in agent security Most agent systems can tell you what happened if an engineer queries logs quickly enough. Fewer can hand a customer, auditor, or security reviewer a compact artifact that proves a check happened before an action was allowed. That artifact is a signed security receipt. It is not a screenshot and not a free-form log line. It is a structured object containing the subject, policy, decision, risk score, finding counts, evidence hash, issuer, scanner version, timestamp, and signature. For AI agents, receipts are important because the buyer, the agent, the tool provider, and the verifier may all be different parties. Evidence needs to move across organizational boundaries without becoming ambiguous. ## What a security receipt proves A security receipt proves that a named issuer ran a named check over a named subject under a named policy at a specific time and signed the resulting decision. The subject can be an agent config, MCP manifest, x402 endpoint, permission request, tool chain, Ergo note, or Accord receipt bundle. The most important fields are config_hash, policy_hash, evidence_hash, scanner_version, decision, risk_score, critical_findings, high_findings, issued_at, issuer, and signature. Together, they make the check replayable enough for audit and stable enough for machine verification. A receipt also lets downstream systems make policy decisions without reading all raw evidence. A marketplace, registry, CI job, or agent client can verify the signature and inspect the decision, while the evidence bundle remains stored under retention rules. ## What it does not prove A receipt does not prove that an agent is safe forever. It does not prove the tool will behave correctly tomorrow. It does not replace an external audit, legal review, or production incident response. It does not prove semantic correctness of every answer. It proves a narrower but valuable thing: this preflight check happened, this policy was applied, this evidence was hashed, this decision was issued, and this issuer signed it. In security operations, that narrower proof is often exactly what the organization needs. The honesty matters. Overclaiming receipt meaning creates false confidence. Precise receipt semantics create useful trust. ## Receipt fields that matter A good receipt starts with a receipt_type such as hekate.security_preflight.v1 or agentsec.security_preflight.v1. Versioned types allow clients to validate schemas as the product evolves. The subject block should identify the object checked and include a stable hash. The policy_hash should bind the decision to the rules in force at the time. The scanner_version should make implementation changes visible. The evidence_hash should bind the receipt to raw findings, request metadata, and verifier outputs without forcing every consumer to fetch the full bundle. The signature should be produced by an isolated receipt service, not by the LLM path. The public verification key should be discoverable through a JWKS or registry endpoint. Verification should fail closed if the signature, schema, issuer, or evidence hash is wrong. ## Evidence hashes and retention Evidence can be large, sensitive, or tenant-specific. That is why receipts should contain hashes and references rather than dumping raw data into every artifact. The receipt stays portable; the evidence bundle stays controlled. A useful evidence bundle may include the MCP manifest, tool list, permission graph, x402 challenge, payment proof, endpoint metadata, policy file, findings, verifier output, and audit events. The hash gives integrity. The retention policy gives operational control. This design also supports selective disclosure. A customer can verify that a check happened and request deeper evidence only when needed, while the operator avoids leaking secrets or customer data inside public receipts. ## How receipts connect to Accord Accord-style flows separate what was agreed, how completion was verified, and how settlement was recorded. Hekate receipts fit naturally into that model because a security scan can itself be treated as verifiable work. An agreement can say that Hekate will run preflight against an agent config and policy. A verification receipt can say that the scan completed with scanner version X, evidence hash Y, and decision Z. A settlement receipt can say that payment for the scan completed. For paid-agent workflows, the stack becomes composable: x402 verifies payment, Accord verifies completion, Hekate verifies security preflight, and the receipt bundle makes the full chain auditable. ## Why buyers and agents both need receipts Human buyers need receipts because security and finance teams need audit evidence. They need to know why an agent was allowed into production, why a payment was approved, why a tool chain was blocked, and what policy existed at the time. Agents need receipts because agentic systems increasingly call other agentic systems. A buying agent may need to verify a provider's receipt before paying. A registry may need to display the last signed preflight. A CI job may need to block a deployment if a receipt is missing or stale. Signed receipts are the bridge between autonomous action and accountable governance. They turn a security check from a temporary API response into durable evidence that can travel with the workflow. ## Hekate next steps - [View sample receipt](/receipts/sample): Inspect a Hekate-style security receipt and the fields verifiers care about. - [Review Hekate Registry](/registry): See how public trust status and mainnet claim boundaries are surfaced. - [Read about audit ledger](/glossary/audit-ledger): Why hash-linked events matter for receipt evidence. - [Join private beta](/beta): Bring a workflow that needs signed preflight evidence. ## FAQ ### What does a signed security receipt prove? It proves that an issuer ran a specific check over a specific subject under a specific policy, produced a decision, hashed the evidence, and signed the result. ### Is a Hekate receipt a production certification? No. A receipt is evidence that a check happened under a policy. It is not a guarantee of safety or a replacement for external audit, legal review, or production ownership. ### Why use evidence hashes instead of raw evidence in every receipt? Evidence hashes keep receipts portable while allowing sensitive raw evidence to stay under retention, access control, and tenant-specific disclosure rules.