Historical analysis and current scope
Cryptographic Governance Evidence for MCP Security
A signed decision can contribute to a security review. The surrounding identity, isolation, policy and collection controls still need their own evidence.
Attested Intelligence · Originally published March 28, 2026 · Web overview revised October 3, 2026
RecordHistorical CoSAI analysis PDF: published March 2026. The original document is preserved. Its proposals and descriptions may differ from the published implementation. For current capabilities and limits, see Trust and scope.
Revision history and source version
The March analysis mapped proposed AGA mechanisms to CoSAI threat categories. September 28 scope notes corrected several implementation claims. On October 3, this web overview replaced the transcription with explicit evidence boundaries. Claims of complete capture, uniform parser verdicts and coverage of every threat category were removed. The original analysis PDF, publication date and URL are retained.
The upstream paper has also changed. The CoSAI snapshot reviewed on October 3 identifies itself as version 2.0, updated August 12, 2026. It includes security assurance profiles and guidance on integrity, isolation and logging. It is separate from the source available when our March analysis was written.
Start with a specific review question.
For a supplied export, a reviewer can check which tool decisions were recorded, which policy reference their signed fields commit to, and whether the bundle verifies against an expected signing key. The current case supplies the policy, request fixture, bundle and manifest needed to inspect that task.
That evidence does not establish which unrecorded actions occurred, which tool actually ran, or whether the deployment prevented a bypass. The analysis of a threat category must identify the control and observation that support each of those claims.
Keep the evidence boundary visible.
- Identity and authorization
- A matching expected key identifies the signing key. Attribution to an agent, user or operator requires an established identity relationship. The published proxy binds its JSON policy hash into receipts; this is distinct from a sealed Policy Artifact.
- Injected instructions and tool decisions
- The proxy evaluates covered tool requests against its configured policy. This does not detect prompt injection or make an inadequate policy sufficient. Its default permissive profile denies nothing on policy grounds, and some refusal paths produce no receipt. See the capture limitation.
- Network and key boundaries
- A configured upstream and a separate process do not establish the only possible call path or protect a key from an agent with shared permissions. Qualify actual identities, credential access and bypass routes in the intended deployment. A signed denial alone is not an independent observation of the protected tool.
- Confidentiality
- The signed arguments_hash is a commitment, not a general redaction guarantee. Guessable inputs and disclosure through other fields remain concerns. Inspect the entire receipt, including denial reasons, against the recipient's data-handling requirements.
- Collection and retained history
- Signatures, receipt links, Merkle proofs and the signed checkpoint support checks on the supplied record. They do not prove complete capture, freshness or the absence of another history signed by the same key. Signed logs, protected retention and independent collectors may also meet the review requirement.
- Interpretation across verifiers
- A passing corpus does not establish identical acceptance of every input file. Published verifiers have documented byte-level differences. Retain the original bytes, verifier version and result.
Proposed mechanisms need separate qualification.
The historical analysis discusses continuous binary measurement, repeated attestation, sealed upstream identity, synthetic responses and infrastructure integrations. Those descriptions do not establish that the published decision-record path implements them. The current implementation scope and control mappings identify published, partial and proposed work.
A mapping to a threat taxonomy is a review aid. It does not establish mitigation coverage, certification, interoperability or endorsement by CoSAI. Use the original source and test the actual deployment controls before making those claims.