Tool declarations have no integrity binding, so a same-version redefinition is invisible to Inspect-Dynamic

[Mayur021]

The gap

steps/toolCallRequest carries tool: {name, version, provider}, an abstract capability string, and arguments. Nothing in that payload binds the call to the tool declaration the Guardian vetted.

The AgBOM tool component requires name, version, provider, and tool_fields.capability. That is the whole record for a tool.

So a server that edits a tool's description, parameter schema, or protocol-level annotations without bumping version produces a changed diff whose before and after are identical. There is nothing for agbom/changed to report. ACS-Inspect-Dynamic does not miss this case, it cannot express it.

Over MCP

protocols/MCP/tools/call is wrapped. tools/list and notifications/tools/list_changed are not. The strings annotation, readOnlyHint and destructiveHint do not appear in the specification or the docs.

A Guardian sitting on the MCP wrapping therefore sees every call and never sees the declaration move underneath it. Wrapping the MCP notification would help, but it relies on the server choosing to send it, which is the same trust problem the spec already rejects for skillLoad.digest_verified.

The spec already accepts this argument, for skills

skill_fields.definition.digest is required, over the complete loadable artifact. steps/skillLoad carries the digest again so the Guardian can bind the activation to an approved registration, with (skill_id, digest) as the durable correlation key across sessions. From skill-load.json:

Without this binding the lifecycle gate is bypassable

Carrying the digest here, rather than only a digest_verified boolean, lets the Guardian verify the binding itself instead of trusting the framework

Both sentences transfer to tools unchanged. A skill gets a digest because its definition is the surface attackers poison. A tool declaration is the same surface, reached by more deployments, and it is the one with published measurements behind it.

Measured, not hypothetical

Across 35 crawl observations of the public MCP registry between 2026-06-09 and 2026-08-01, covering 44,172 tools on reachable servers, the declared-versus-verified binding gap is 24.46 percentage points, and the corpus contains 17 permissive destructiveHint flips, true to false. The deposit states the strength of those plainly, and it is worth carrying rather than rounding up: each flip was confirmed between 17 and 33 times, but confirmations are repeated crawls by a single crawler, and independent-observer corroboration applies to the receipt network rather than this baseline series. (Bharti, MCP Declared-Effect Coverage and Contract Binding v1, CC BY 4.0, https://doi.org/10.5281/zenodo.21778282)

A separate registry-wide measurement over 88.6 days finds that a prior declaration change lifts next-period change probability 4.8x, but only 5.0% of the population carries any prior change, so re-auditing by drift ranking exhausts its signal pool almost immediately. (https://doi.org/10.5281/zenodo.21751498) A digest reaches every entry. A ranking reaches only the entries that have already moved.

Proposed direction

1. Add an OPTIONAL declaration_digest to the AgBOM tool component, computed over the canonical form of the tool's full declaration: name, description, parameter schema, and any protocol-level annotations. Same scope discipline as skill_fields.definition.digest, same {algorithm, value} shape. The canonical form should be whatever canonicalization Audit chain trust depends on a single Guardian, no cross-Guardian verification protocol #18 lands rather than a second one defined here, since two conformant verifiers disagreeing about a declaration's bytes becomes a spurious deny under item 4. If Feature Proposal: Add Data Sensitivity and Trust Boundary Metadata to ToolDefinition to Prevent "Lethal Trifecta" Architectures #8's security_context lands this scope covers it, and a required_controls entry that disappears at unchanged version is the same measured class as the destructiveHint flips: a control switched off by the field that reads it.
2. Carry it on steps/toolCallRequest, so a Guardian can bind the call to the declaration it vetted, exactly as steps/skillLoad binds to registration. The durable correlation key becomes the tool component id plus its declaration_digest.
3. Make a digest change at unchanged version a reportable mutation, so agbom/changed with reason: configuration_changed has something to carry.
4. Under ACS-Inspect-Dynamic, a call whose declaration digest does not match the approved one is unverifiable and SHOULD be denied, mirroring the skillLoad rule.
5. Wrap protocols/MCP/tools/list, so the Guardian computes the digest from the declaration bytes it observed rather than comparing a framework-computed value against a framework-registered one. That second shape is the digest_verified problem one level up, which the spec already rejects. tools/list is client-initiated, so wrapping it does not depend on the server volunteering anything, which is what makes this avoidable for MCP tools where it is not avoidable for skills. extend_mcp.md currently mentions tools/call twenty times and tools/list zero.

Item 5, the #18 canonicalization dependency and the correction to the flip wording all come from @avp9-nexus's review below.

Optional rather than mandatory keeps ACS-Core unchanged. A harness that cannot compute the digest stays conformant, and a deployment that needs the binding declares Inspect-Dynamic.

If this lands, the negative vector for it is small and I am happy to write it alongside the work in #29 and #30.

References

• specification/v0.1.0/hooks/tool-call-request.json
• specification/v0.1.0/agbom/component.json, tool_fields against skill_fields
• specification/v0.1.0/hooks/skill-load.json, skill-register.json
• specification/v0.1.0/hooks/agbom-changed.json
• docs/spec/instrument/extend_mcp.md
• Related: Feature Proposal: Add Data Sensitivity and Trust Boundary Metadata to ToolDefinition to Prevent "Lethal Trifecta" Architectures #8 (tool security metadata), Proposal: negative conformance vectors for the enforcement layer (valid-but-unauthorized, replayed, and malformed agent actions) #29 and Add conformance/negative/: vectors, failure codes, and runner (closes the suite gap for the enforcement layer) #30 (conformance vectors)

[Mayur021]

Following up on the version point, because it is sharper than I put it above.

MCP tools have no version. In the 2025-06-18 schema, Tool extends BaseMetadata, which is name plus an optional title, and adds description, inputSchema, an optional outputSchema, optional annotations and _meta. There is no version field on a tool anywhere in that schema. The only versioned thing is Implementation, which is the server.

The AgBOM tool component requires version. For an MCP-sourced tool that field cannot come from the tool. The natural filler is the server's version, which moves for reasons unrelated to any single tool's declaration, and does not move when a declaration is edited in place.

Two consequences for the gap above.

reason: component_upgraded cannot fire from a tool's own declaration changing, because the declaration has nothing to bump. When it does fire it reports a server-level change and does not say which tool moved.

annotations is where readOnlyHint, destructiveHint, idempotentHint and openWorldHint live. It is optional, freely mutable at every tools/list, and it is the field with measured flips behind it. ACS has no surface that carries it and no event that fires when it changes.

So a declaration digest is not just the tidier option here. For MCP-sourced tools it is the only thing that can carry the signal, because the version field ACS leans on is not describing the tool in the first place.

[avp9-nexus]

Ran your numbers against the deposit before writing, since the proposal leans on them: binding_gap_pp: 24.46 is in results.json exactly, and flips_v1.csv carries exactly 17 rows matching destructiveHint,true,false,permissive, each with decl_confirm_count between 17 and 33. The figures hold as stated.

One word in the write-up deserves the bound the dataset itself declares. results.json carries corroboration_caveat: "confirmations are repeated crawls by one crawler; independent-observer corroboration applies to the receipt network, not this baseline series". So "17 corroborated flips" is stronger than the deposit claims for this series - "confirmed (single-crawler, repeated)" is the accurate strength. In a thread whose subject is precisely the distance between self-reported and independently observed, the word should carry its own caveat. The 17 flips lose nothing by it; they were confirmed 17 to 33 times each.

On the mechanism, one addition that I think your proposal needs to be enforceable rather than declarative.

The digest needs an observation channel, or it is the boolean one level up. Item 2 carries declaration_digest on steps/toolCallRequest - computed by whom? If the harness computes it from the declaration it fetched, the Guardian ends up comparing a framework-computed value against a framework-registered value. That is the same trust shape the spec rejects for digest_verified, in the sentence you quote. For skills this is hard to avoid, since the Guardian may never hold the artifact. For MCP tools it is avoidable: tools/list is a client-initiated request/response, so wrapping it does not depend on the server volunteering anything - which was your (correct) objection to relying on list_changed. Today extend_mcp.md mentions tools/call twenty times and tools/list zero. Add a fifth item: wrap tools/list, and let the Guardian compute the digest from the declaration bytes it observed. Then the deny rule in item 4 binds to something the Guardian saw rather than something it was told - which would make the tool binding stronger than the skill precedent, not merely parallel to it.

The canonical form needs #18, and your references skip it. Item 1 computes the digest "over the canonical form" of the declaration. On #36, ossumpossum stated the portability condition that applies here unchanged: a corpus "is only portable if #18 pins a defined signing scope (exactly which bytes are inside each signature) and a canonical serialization... Otherwise two conformant verifiers can disagree" on the same record. Two conformant implementations disagreeing on a declaration's digest means false mutations, and under item 4, spurious denies. If the digest definition references whatever canonicalization #18 lands, the two land as one decision instead of two half-decisions.

The #8 cross-reference raises the stakes in the same direction: if security_context lands, trust boundaries and required_controls become one more unversioned declaration surface - and a required_controls entry that silently disappears at unchanged version is the same measured class as the destructiveHint flips, a control switched off by the very field it reads. The digest scope in your item 1 ("any protocol-level annotations") would cover it as written; worth saying so there, since #8 is where that surface gets added.

One note on the cross-reference to OWASP/www-project-agentic-skills-top-10#63: the invocation-time re-evaluation proposed there (now Mitigation 7 in OWASP/www-project-agentic-skills-top-10#74) needs a recorded state to compare against, and your own thread there observes that for MCP tools nothing publishes a digest of record. A Guardian-computed declaration_digest over a wrapped tools/list is exactly that missing comparand - so the two proposals are not just the same gap at two layers, one is the mechanism the other's comparison step presupposes.

On your closing offer: the negative vector for this pairs naturally with the #30 suite shape - a same-version redefinition vector where the declaration mutates, version does not, and the expected verdict is deny-as-unverifiable. Happy to write it alongside yours whenever the direction is settled.

[Mayur021]

All four land, and the first is a correction I should carry further than this thread.

You are right about "corroborated". results.json says it plainly: confirmations are repeated crawls by one crawler, and independent-observer corroboration applies to the receipt network rather than this baseline series. The accurate form is 17 confirmed permissive destructiveHint flips, true to false, each confirmed 17 to 33 times by repeated crawls from a single crawler. I have used the stronger word in three other places including my own FIXTURES.md, which does not carry the caveat at all. Fixing the body here and the repo. The point about a thread on declared-versus-observed being the wrong place to overstate a strength is well made.

The tools/list wrapping is better than what I proposed. A framework-computed digest compared against a framework-registered one is the digest_verified shape one level up, which is exactly what I quoted the spec rejecting. tools/list being client-initiated is what makes this avoidable for MCP where it is not avoidable for skills, and a Guardian computing the digest from bytes it observed makes the tool binding stronger than the skill precedent rather than parallel to it. extend_mcp.md mentioning tools/call twenty times and tools/list zero is the gap in one line. Adding it as item 5.

On #18, agreed, and I should have referenced it. A digest over an undefined canonical form is two conformant verifiers disagreeing about whether a declaration mutated, and under item 4 that is a spurious deny rather than a missed one. Item 1 will depend on whatever canonicalization #18 lands rather than restate one.

On #8, worth stating in item 1 explicitly: a required_controls entry that disappears at unchanged version is the same measured class as the destructiveHint flips, a control switched off by the field that reads it.

Your reading of the AST07 relationship is sharper than mine. I had them as the same gap at two layers. One being the comparand the other's comparison step presupposes is the more useful statement, and it changes what Mitigation 7 can claim without it.

On the vector, yes, and it is yours to shape since #30 is your suite.

[avp9-nexus]

Taken, then. Shaped now, so it is concrete before it is code.

First a measurement: none of the 19 vectors in the #30 branch touches the declaration surface - the suite judges an action against state, authorization and evidence, never a tool's own definition against what was vetted. So this is a new family, not a variant of an existing one. It lands as category 7, declaration integrity, in the suite's existing conventions: state carries what was bound at vetting time, input carries what the call presents, and the family ships with its positive control.

• neg-cat7-001 - observed declaration digest diverges from the bound one at unchanged version: REJECT, DECLARATION_MISMATCH, reason must mention the digest. The measured flip made executable - a declaration that moved with nothing for agbom/changed to carry.
• neg-cat7-002 - the deployment declares the binding but nothing was read about what the declaration currently says: UNMEASURABLE, DECLARATION_UNOBSERVED. The suite already refuses to convert absence of measurement into a verdict (cat 5's oracle rule); this is the same rule pointed at the declaration.
• pos-cat7-001 - observed digest equals the bound one at the same version: MUST pass. The check is on divergence, not on the field's presence.

The three are drafted against vector.schema.json and fail the current schema on exactly two points, both by construction: category is capped at 6, and the code enum is closed. Both are one-line edits when the family lands.

They stay out of the #30 branch until two things settle, deliberately: item 1's field shape landing in the spec, and #18's canonical form - a vector that encoded its own canonicalization would smuggle in exactly what item 1 now defers. Once those land, only input keys move if the field name changes.

And M6 is the right way to carry a correction: recorded where the next reader works, not fixed in place.

[Mayur021]

Holding them until item 1's field shape and #18 land is the right call, and worth saying rather than just agreeing with: a vector carrying its own canonicalization would fix by example the thing item 1 deliberately defers, and that is very hard to unpick once it is in a suite people run.

One thing from the other side that may be worth carrying into the family.

The C9 suite hit the same shape and settled on three states in the record against two outcomes at the gate: BOUND, STALE and UNOBSERVED, where STALE means the contract moved under an unchanged declaration and UNOBSERVED means nothing attested either way. Both make the declaration unusable, so the gate does the same thing for both, but they stay separate in the record, because the coverage measure, declared minus verified, cannot be computed from a binary.

Your category 7 has those same two shapes. neg-001 is we looked and it diverged. neg-002 is we never looked. In a deployment that fails closed both may resolve to the same action, and if they do, the verdicts converge and the records should not. A fleet carrying a hundred cat7-001s has a different problem from one carrying a hundred cat7-002s, and the second is the one that looks fine on a dashboard.

So the split you have drawn between REJECT and UNMEASURABLE is the part I would protect if anyone later argues they should collapse.

On M6, that is generous. It was written that way partly because the alternative was quietly changing a word in a file whose whole subject is records that stop describing what they record.

[dodogeny]

The same-version redefinition case is the one that's hard to argue away, agbom/changed producing a diff whose before and after are byte-identical because the version field didn't move. And your point that drift-ranking exhausts its signal pool almost immediately, 5% of the population carrying any prior change, matches what I see. Re-auditing by "what moved recently" misses everything that's about to move for the first time.

I work on Apitella (https://apitella.com/?utm_source=github&utm_medium=comment&utm_campaign=outreach-8), which does roughly the content-hash-over-canonical-declaration thing you describe in item 1: it snapshots MCP servers and reports digest changes at unchanged version, including destructiveHint and readOnlyHint flips specifically. Your 17 confirmed destructiveHint true-to-false flips line up with the kind of thing it surfaces. Would genuinely like to compare notes on the canonicalization piece, that's where it gets messy fast.

[avp9-nexus]

Taking the three-state record, and the reason you give for it is stronger than the one I had.

I was holding REJECT and UNMEASURABLE apart on honesty grounds - nothing to compare is not nothing wrong, and a verdict should not be manufactured out of an absent measurement. Yours asks nobody to be scrupulous: declared minus verified is not computable from a binary, so collapsing the states destroys the measure whether or not anyone intended it. That argument holds in front of a team that does not share the discipline. Mine does not.

Checked what the suite already does rather than assume it. runner.py compares the failure code unconditionally, on every vector including positive controls, not only where the verdict is REJECT - and that is not foresight, it came from astrogilda's review on #30 in August, which caught a positive control's code field going uncompared. So an adapter returning UNMEASURABLE with DECLARATION_MISMATCH where DECLARATION_UNOBSERVED is expected fails the vector today. The separation you would protect is enforced, by a path independent of the argument for it.

Where a vector's reach ends is worth stating, since it bears on your fleet point. The suite constrains the gate, not the record - it can require that a conformant implementation produce two distinct codes for the two shapes, and it cannot require that anything downstream keep them apart. But that is the useful half: a deployment that fails closed on both still has to emit different codes to pass, so the information the coverage measure needs exists at the boundary even where the action is identical. Anything past that is the consumer's problem, and no vector can reach it.

Your argument is already doing work elsewhere on this repo. On #16 today I reviewed a reconciliation design whose output specifies coverage_status as an overall state plus per-capability states - and an overall state is the collapse you describe, one level up: the record has to stay per-rule, and the overall value has to be derived by a stated precedence or two implementations will disagree on the same findings. The comment is #16 (comment), section 3, if the application is useful to you; the reasoning there is yours.

One observation from the other side, in case the shape is useful beyond declarations. I have hit the same collapse where nobody designed one: a test harness whose output showed a failure while its exit status stayed zero, and an aggregator that read only the exit status. The distinction was present in the record and absent from the thing counting - so the aggregate reported health that the underlying record contradicted. Different domain, same failure: the state that looks fine is the one that is not being read, rather than the one that is not being separated.

Avp9.