What a signature does not prove

A developer building evidence layers for AI agents argues that digital signatures are insufficient for proving security, citing three cases: the Open Secure AI Alliance's incident-reporting draft lacks integrity requirements, CVE-2026-33697 in CoCoS allows a valid attestation to be relayed, and a spec limitation. The developer concludes that security questions are about relationships, not just objects.

I spend most of my time building evidence layers for AI agents. The reflex in that work is to reach for a signature. Something happened, sign the record, hand it to the auditor, done. Three things from the last five months say that reflex is wrong, or at least badly incomplete. One is a governance draft that never asks for a signature at all. One is a CVE where the signature verified correctly and the client still ended up talking to an attacker. One is a limit in a spec I wrote myself. Read together they point at the same thing. A signature is a statement about an object. Almost every security question you actually care about is a statement about a relationship. The Open Secure AI Alliance published its Shared AI Findings Exchange draft on GitHub on August 3. It is an incident-reporting compact for AI agents. Members agree to report when an agent they operate accesses or disrupts a third-party system without authorization, and to do it on a clock: notify the affected organisation as soon as possible, notify customers with credible exposure within 72 hours, file a confidential report within four business days. The clock is well specified. So is the evidence. Members must preserve and provide affected organisations with "prompts, traces, tool calls, logs, configurations, model and safeguard versions and third-party dependencies", plus agent and workload identities, permissions and credentials available during the run, human approval events, and a complete incident timeline. That is a good list. It is close to the one I would have written. Now search the draft for signing. It appears exactly once, in a list of example recommendations that incident reviews might produce: "signed evaluation manifests". The draft also asks, in its review framework, whether "data boundaries were independently verified". Both of those are about keeping an agent inside its box. Neither applies to the record of what happened when it got out. The evidence list carries no integrity requirement at all. No signature, no hash, no attestation, nothing tamper-evident. So the operator produces the trace, holds it, and decides what to send. Every artefact on that list is a mutable file on infrastructure controlled by the party with the most to lose from the report. To be fair to the draft, one of its own principles is "Learning is separate from enforcement", and I am not asking a disclosure framework to prevent anything. But evidence is neither learning nor enforcement. An evidence layer has one job, which is to be believable by someone who does not trust you. This is the easy case. Nobody has claimed anything false. A requirement is simply missing, and the comment period is open. The hard case is CVE-2026-33697, published on March 26, against CoCoS, a confidential computing system for AI from Ultraviolet. Attested TLS is the mechanism that is supposed to close the last gap in confidential computing. You do not just want an encrypted channel, you want proof that the other end is a genuine enclave running the code you expect. So you bind hardware attestation evidence into the TLS handshake. The client checks the evidence, sees a real TEE with the right measurements, and proceeds. In CoCoS versions v0.4.0 through v0.8.2, on both AMD SEV-SNP and Intel TDX, that check could pass while the client talked to an attacker. From the advisory: Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. Read that twice. The attestation report is real. It came from a genuine enclave. It is correctly signed by hardware and it validates. The client is not fooled about the existence of a real TEE. It is fooled about which endpoint it is speaking to, because nothing tied the signed evidence to the channel carrying it. Two details make this worth more than a routine advisory. The first is that the attestation subsystem was fully redesigned in v0.7.0 and the flaw survived the rewrite. It was not an implementation bug. Getting the code right does not help when the design binds the wrong two things together. The second is that this is not one vendor's mistake. Muhammad Usama Sardar and co-authors formally analysed attested TLS in ProVerif and found diversion attacks against two candidate standardisation protocols, Intel's Interoperable RA-TLS and the intra-handshake draft-fossati-tls-attestation . In their published property table, server identity, server authentication, compound authentication and agreement of all parameters evaluate to false for both. A follow-on paper extended this to seven distinct intra-handshake binding designs. All seven fail to stop a relay attack. The work went to the IETF, and CoCoS fixed its instance in v0.9.0 with post-handshake binding, one day after the CVE went out. There is a small coda that I enjoy more than I should. The CVE record still reads "As of time of publication, there is no patch available." The fix shipped the following day. NVD last touched the record in June and never updated it. The authoritative record of the vulnerability has been wrong for five months, in the direction of overstating the risk. The two scorers also disagree about how bad it is, and the disagreement is instructive. GitHub scored it 7.5 with Scope: Changed. NVD scored it 6.3 with Scope: Unchanged. That single metric is a judgement about whether relaying an attested session escapes the security boundary the attestation was supposed to establish. The people scoring the bug do not agree on what the attestation covered. Worth stating plainly: exploitation requires first extracting the ephemeral TLS private key, through physical access to the hardware, transient execution attacks, or side channels. That is a real bar. It is also exactly the threat model confidential computing exists to address, which is why the finding matters more than the score suggests. TRACE is a trust-record format I maintain. A gateway emits a signed record for each agent tool call, and an auditor can verify that a record was not altered after the fact. That part works, and there is a conformance suite full of forged-signature and broken-chain vectors to prove it. It has two limits, and they are the same shape as case two. The record set is not provably complete. TRACE captures what is observable at the gateway boundary. If a call routes around the gateway, there is no record, and a missing record looks identical to an action that never happened. Signing fixes forgery. It does nothing about omission. A signed set of records is a signed claim about the records that exist, not about the ones that should. And verification runs against the issuer's own key. The self-hosted verifier confirms cryptographic validity against the key of the party that produced the record. That is fine for detecting later tampering by a third party. It is much weaker than it sounds if the question is whether the issuer was honest at write time, because the issuer holds the key. Independent verification needs an anchor outside the issuer, and that is a separate mechanism, not a property of the signature. So a signature from my gateway is not something your incident responder can independently check. I would rather say that than have someone discover it. In all three cases the signature is not the interesting part. SAFE never asks for one, so the evidence is whatever the reporting party says it is. CoCoS had a perfectly valid signature over a genuine attestation report, bound to an ephemeral key rather than to the channel. The signature was true and the conclusion the client drew from it was false. TRACE signs each record correctly and cannot speak to the completeness of the set or to its own issuer's honesty. Signing is the easy part. It is a well-understood operation with good libraries. The hard part is binding: tying the signed thing to the other thing you actually care about. This record to the complete set. This evidence to this channel. This signer to a trust root you did not choose. Every one of these failures is a missing binding, not a missing signature. And bindings are where formal analysis earns its money, because a missing binding is invisible in code review and obvious in ProVerif. Seven designs, all reviewed by competent people, all failing the same property. The concrete version, since a criticism you cannot file is just a complaint. SAFE's Evidence Preservation section should say roughly this: Evidence must be integrity-protected at the point of capture, not at the point of reporting. Each preserved artefact carries a digest recorded when it is written, and the digest set is signed by the runtime that emitted it rather than by the process that files the report four business days later. A gap in the record must be distinguishable from an absence of activity, so the record needs a sequence that reveals holes. And the receiving party must be able to verify all of it without trusting the sender, which means an anchor the reporting operator does not control. I do not have a complete answer to that last requirement, and neither does my own spec. Someone has already filed the adjacent half in the repo: issue 6 proposes a pre-connection attestation for the thing an agent connects to, and correctly notes that the draft gestures at signed artefacts without specifying their representation. The integrity of the preserved evidence itself is still open. If you build agent infrastructure, the question to sit with is not whether you sign your logs. It is what your signature is bound to, and whether the party who has to believe you can check that binding without taking your word for it.