@chopmob-cloud thank you for your contribution. I updated the SEP and the paper to reflect that.

Strong framing in the new "Composition with Runtime Drift Monitoring" section — the who / what split is a clean way to scope the admission edge against everything downstream of it.

One axis that composition map doesn't yet name sits alongside the drift layer rather than under it: caller-side governance. ATSA answers which server the host admits; the drift layer answers whether the admitted server's surface changed; neither addresses which calling identity, under what declared purpose and scope, may invoke an admitted tool — the demand-side counterpart to your supply-side admission. Such a layer would compose the way your section describes: bind to the verified id/signerKeyId anchor, enforce before dispatch, on the opposite end of the connection. (I maintain a working reference implementation of one (notboatanchor/gif) — an Apache-2.0 MCP enforcement server, identity- and session-scoped, with an append-only audit trail, exercised against its own conformance scenarios — so this is grounded in a built implementation, not theory.)

That points at the one guarantee currently left undefined on both ends. Your Audit rule is a SHOULD for a "tamper-evident record," and the downstream-layer expectations leave audit to the monitor; the Interceptors SEP (#2624) likewise states "organizations MUST ensure audit trails are tamper-proof" without defining or checking it. So across admission, drift, and caller-governance, tamper-proof audit is named everywhere and specified nowhere — re-punted to deployment policy at each seam. Per SEP-2484 that's precisely the shape of thing that needs a vector + a traceability file to be more than a SHOULD.

Would you see reconciling the audit guarantee across these layers living inside ATSA's clearance/auth-profile reconciliation (already in your Open Questions), or as its own effort that the admission, drift, and governance layers each reference?

Strong framing in the new "Composition with Runtime Drift Monitoring" section — the who / what split is a clean way to scope the admission edge against everything downstream of it.

One axis that composition map doesn't yet name sits alongside the drift layer rather than under it: caller-side governance. ATSA answers which server the host admits; the drift layer answers whether the admitted server's surface changed; neither addresses which calling identity, under what declared purpose and scope, may invoke an admitted tool — the demand-side counterpart to your supply-side admission. Such a layer would compose the way your section describes: bind to the verified id/signerKeyId anchor, enforce before dispatch, on the opposite end of the connection. (I maintain a working reference implementation of one (notboatanchor/gif) — an Apache-2.0 MCP enforcement server, identity- and session-scoped, with an append-only audit trail, exercised against its own conformance scenarios — so this is grounded in a built implementation, not theory.)

That points at the one guarantee currently left undefined on both ends. Your Audit rule is a SHOULD for a "tamper-evident record," and the downstream-layer expectations leave audit to the monitor; the Interceptors SEP (#2624) likewise states "organizations MUST ensure audit trails are tamper-proof" without defining or checking it. So across admission, drift, and caller-governance, tamper-proof audit is named everywhere and specified nowhere — re-punted to deployment policy at each seam. Per SEP-2484 that's precisely the shape of thing that needs a vector + a traceability file to be more than a SHOULD.

Would you see reconciling the audit guarantee across these layers living inside ATSA's clearance/auth-profile reconciliation (already in your Open Questions), or as its own effort that the admission, drift, and governance layers each reference?

The audit-tamper-evident observation is the cross-cutting one. ATSA, drift, Interceptors #2624 each name it; none specify it. Three SHOULDs, zero vectors — won't clear Final under
SEP-2484.

The reconciliation belongs in its own SEP, not ATSA's Open Questions. Same composition discipline that kept drift out of ATSA's wire format: the shape of a tamper-evident record
(fields, canonicalization, hash-chained vs. Merkle, verifier algorithm) is orthogonal to which layer writes to it. Folding it into ATSA inherits an "audit primitive owned by
admission" — wrong factoring for something three layers consume.

Bootstrapping isn't a blocker. ATSA v1 ships with the current SHOULD plus a forward reference; each seam upgrades to MUST against the audit SEP's vector when it lands. RFC 9449 /
6749 is the pattern.

A built Apache-2.0 caller-governance server with conformance vectors is exactly the third consumer that makes the audit SEP worth landing standalone. Happy to cross-reference both
once SEP numbers are assigned.

The audit-tamper-evident observation is the cross-cutting one. ATSA, drift, Interceptors #2624 each name it; none specify it. Three SHOULDs, zero vectors — won't clear Final under SEP-2484.

The reconciliation belongs in its own SEP, not ATSA's Open Questions. Same composition discipline that kept drift out of ATSA's wire format: the shape of a tamper-evident record (fields, canonicalization, hash-chained vs. Merkle, verifier algorithm) is orthogonal to which layer writes to it. Folding it into ATSA inherits an "audit primitive owned by admission" — wrong factoring for something three layers consume.

Bootstrapping isn't a blocker. ATSA v1 ships with the current SHOULD plus a forward reference; each seam upgrades to MUST against the audit SEP's vector when it lands. RFC 9449 / 6749 is the pattern.

A built Apache-2.0 caller-governance server with conformance vectors is exactly the third consumer that makes the audit SEP worth landing standalone. Happy to cross-reference both once SEP numbers are assigned.

I read the paper end to end — the canonicalization discipline (one canonical body, Definition 1, reused on the signing and verification paths) and the deny-by-default flavor gating are clean, and the bootstrapping path you describe is the right way through: ship the SHOULD with a forward reference now, upgrade to a MUST against the audit SEP's vector once it lands. Agreed too that the record shape is orthogonal to which layer writes it — ATSA's audit is admission-scoped (the mcp.connect.* / mcp.tool.deny decision events), the Interceptors thread (#2624) names the same tamper-proof-audit obligation at the per-operation layer, and gif's record is caller-scoped (per invocation). Three layers reaching for one guarantee from three angles is exactly the case for landing it once, standalone, that you're making.

On gif being a consumer — that's fair, though it may be able to contribute a bit more than consume. The append-only audit in notboatanchor/gif is already a concrete instance of the contract this SEP would define: a per-call record bound to a caller identity and a declared purpose, written append-only at the database-permission level (UPDATE/DELETE revoked, no row-level policy permits them — not append-only by convention). The dispatch fields — caller, session, event type, tool, outcome — are carried over a deterministic preimage that is SHA-256 hash-chained entry-to-entry; the declared-purpose field is recorded on the row but currently sits outside that chain, which is itself one of the field-set questions this SEP would settle. The record format and the chain construction are defined and exercised by the test suite. It's a working reference implementation tested against its own scenarios — not a production-deployment claim — but it does mean the decisions you flagged as orthogonal (field set, canonicalization, hash-chain vs. Merkle, verification procedure) already have one fully worked, test-backed answer to argue from, rather than a blank page.

One thing the two implementations seem to already agree on, which might help scope the SEP: the tamper-evidence itself isn't wire-observable, so neither side puts it in the wire-checkable conformance surface — ATSA keeps audit a SHOULD, and gif keeps the hash chain in the storage layer, outside its wire-conformance scenarios. That suggests the audit SEP's machine-checkable vectors realistically cover the observable record — its schema, the emission events, scope-gated read — while the integrity construction is specified and referenced but attested rather than gated. Worth pinning down early, since it shapes what "conforming" can even mean.

I'd be glad to put gif's record format on the table as a starting point and to do real drafting work on the contract itself, not just reference it from the side. Two things that would help me calibrate: which venue you see this homed in — one of the existing IGs (#security-ig / #auth-ig) or its own effort — and whether finding a sponsor is the gating step. And yes to cross-referencing once numbers are assigned.

The audit-tamper-evident observation is the cross-cutting one. ATSA, drift, Interceptors #2624 each name it; none specify it. Three SHOULDs, zero vectors — won't clear Final under SEP-2484.
The reconciliation belongs in its own SEP, not ATSA's Open Questions. Same composition discipline that kept drift out of ATSA's wire format: the shape of a tamper-evident record (fields, canonicalization, hash-chained vs. Merkle, verifier algorithm) is orthogonal to which layer writes to it. Folding it into ATSA inherits an "audit primitive owned by admission" — wrong factoring for something three layers consume.
Bootstrapping isn't a blocker. ATSA v1 ships with the current SHOULD plus a forward reference; each seam upgrades to MUST against the audit SEP's vector when it lands. RFC 9449 / 6749 is the pattern.
A built Apache-2.0 caller-governance server with conformance vectors is exactly the third consumer that makes the audit SEP worth landing standalone. Happy to cross-reference both once SEP numbers are assigned.

I read the paper end to end — the canonicalization discipline (one canonical body, Definition 1, reused on the signing and verification paths) and the deny-by-default flavor gating are clean, and the bootstrapping path you describe is the right way through: ship the SHOULD with a forward reference now, upgrade to a MUST against the audit SEP's vector once it lands. Agreed too that the record shape is orthogonal to which layer writes it — ATSA's audit is admission-scoped (the mcp.connect.* / mcp.tool.deny decision events), the Interceptors thread (#2624) names the same tamper-proof-audit obligation at the per-operation layer, and gif's record is caller-scoped (per invocation). Three layers reaching for one guarantee from three angles is exactly the case for landing it once, standalone, that you're making.

On gif being a consumer — that's fair, though it may be able to contribute a bit more than consume. The append-only audit in notboatanchor/gif is already a concrete instance of the contract this SEP would define: a per-call record bound to a caller identity and a declared purpose, written append-only at the database-permission level (UPDATE/DELETE revoked, no row-level policy permits them — not append-only by convention). The dispatch fields — caller, session, event type, tool, outcome — are carried over a deterministic preimage that is SHA-256 hash-chained entry-to-entry; the declared-purpose field is recorded on the row but currently sits outside that chain, which is itself one of the field-set questions this SEP would settle. The record format and the chain construction are defined and exercised by the test suite. It's a working reference implementation tested against its own scenarios — not a production-deployment claim — but it does mean the decisions you flagged as orthogonal (field set, canonicalization, hash-chain vs. Merkle, verification procedure) already have one fully worked, test-backed answer to argue from, rather than a blank page.

One thing the two implementations seem to already agree on, which might help scope the SEP: the tamper-evidence itself isn't wire-observable, so neither side puts it in the wire-checkable conformance surface — ATSA keeps audit a SHOULD, and gif keeps the hash chain in the storage layer, outside its wire-conformance scenarios. That suggests the audit SEP's machine-checkable vectors realistically cover the observable record — its schema, the emission events, scope-gated read — while the integrity construction is specified and referenced but attested rather than gated. Worth pinning down early, since it shapes what "conforming" can even mean.

I'd be glad to put gif's record format on the table as a starting point and to do real drafting work on the contract itself, not just reference it from the side. Two things that would help me calibrate: which venue you see this homed in — one of the existing IGs (#security-ig / #auth-ig) or its own effort — and whether finding a sponsor is the gating step. And yes to cross-referencing once numbers are assigned.

Hi Scott,

To answer your initial question directly: No, I will not be adding the explicit definition of the audit-tamper-evident observation to this ATSA PR.

Your comment perfectly articulates why: folding it in here inherits an "audit primitive owned by admission," which is the wrong factoring. Since ATSA, Interceptors (#2624), and gif all consume this exact same guarantee, it belongs in its own standalone SEP rather than burying it in ATSA's Open Questions.

I completely agree with the bootstrapping path you outlined. I will keep the current SHOULD in this PR along with a forward reference to the future audit SEP. That keeps the wire-conformance surface clean and ensures this PR clears SEP-2484 without getting stalled by orthogonal architectural dependencies.

To your points on moving the standalone effort forward:

Venue & Sponsorship: This belongs in #security-ig. We need to secure the sponsor for the standalone audit SEP so we aren't gated.

The Draft: I welcome your drafting help. Let’s use notboatanchor/gif's record format, canonicalization discipline, and SHA-256 hash-chain mechanics as the baseline draft so we start with a worked, test-backed reference implementation.

Conformance Boundary: Agree completely that the machine-checkable vectors should cover the observable record (schema, emission, scope-gated read) while the integrity construction is specified and attested.

I’ll update this PR with the forward reference text shortly. Let's move the deeper audit definition discussion to a new issue under #security-ig—tag me when you put the gif format on the table and we’ll cross-reference the numbers.