Composition boundary: attenu-guard delegation and VATE admission

[Poke-nushi]

Hi Rafael — I read the current Python A2A and evidence paths at 3606464. GuardedAgentExecutor runs wire.load, asks deployment-supplied authority_for(agent_id, task) for required authority, derives a served guard no wider than the verified leaf, then calls inner.execute. complete() runs in finally and adds done; export_bundle carries the guard ledger plus its signed head anchor.

The VATE AL2 profile specifies a protocol-neutral relying-party decision on one concrete request from heterogeneous evidence: allow, attenuate, or deny. An attenuation records original/effective request bases; later post-execution evidence is checked against the specific admission and admitted effective request.

That suggests a composition boundary: attenu-guard establishes and enforces delegated authority at the receiving hop, while VATE specifies concrete-request admission and admission-to-outcome evidence linkage. Could you confirm or correct this reading at two points?

• authority_for is deployment-local input, so even a chain that passes wire.load may still be narrowed or refused before the inner executor runs.
• A served task’s bundle is authorization/lifecycle evidence only; it does not claim successful execution or bind result, output, or side effects.

A correction would help us document the seam and choose a useful negative composition case. I’m asking about the boundary, not for adoption or implementation work.

[rafaelasor]

Both readings are right.

On authority_for. Yes. It is deployment-local, and what it returns only goes into a meet, so the
served guard cannot come out wider than the verified leaf. The adapter builds the continuation root
from the verified leaf itself, then calls delegate, and delegate only narrows.

Three things can stop the hop between wire.load and inner.execute:

1. revocation_check=, an optional deployment seam. If it returns a reason the hop is refused,
   disposition OUT_OF_AUTHORITY.
2. authority_for returns None. Refused as no_authority, disposition UNRESOLVED.
3. authority_for returns an authority that cannot be met from the leaf. AuthorityError,
   disposition OUT_OF_AUTHORITY.

So a chain can verify and still be narrowed, or refused, before the inner executor runs.

On the bundle. Correct. It is authorization and lifecycle evidence. It records that a call was
authorized and that the guard completed. It doesn't say the tool ran, and it binds nothing about the
result or the side effects. That gap is open on our side. A reviewer on crewAIInc/crewAI#5888 raised
the same point and I have not closed it.

One correction on the commit you read. 3606464 didn't remove the claim, it narrowed it: "every
decision remains verifiable offline" became "every decision the guard makes remains verifiable
offline". The old wording could be read as completeness. A hash chain doesn't give you completeness,
and if a call path skips the interception point the log is silent and still verifies.

Two more things before you write the seam down.

The client's bundle proves the caller's side. The server's bundle proves the receiving side. Neither
one alone proves the hop. verify_hop(tokens, signer, client_bundle=…, server_bundle=…) checks all
three parts from those inputs, with no service in the path. That sentence is only in a module
docstring today, which is my fault. It should be in the docs.

And one that matters if you ever verify our bundles from something other than Python. Our
canonicalization is sorted-key compact json.dumps, not RFC 8785 JCS, and the draft doesn't say so.
Two implementers caught it this week. So the hashes in a bundle today are reproducible by a Python
verifier and not reliably by anything else. We are moving to JCS across the token, the ledger and the
evidence anchor. If you are building against the bundle, build against JCS and not against what we
emit right now. I'll post the version here when it lands.

A negative composition case you can use: cross-process revocation. wire.load does not check a Token
Status List, so a token revoked in the caller's process after it was minted still verifies at the
receiving hop until it expires. With revocation_check= unwired, admission succeeds on evidence that
is already stale. Your post-execution check against a specific admission would catch that. The
offline verifier can't.

Your boundary reads right to me. Tell me if you want the revocation case as a runnable test and I'll
write it.

[rafaelasor]

It landed. attenu-guard 0.7.1 on PyPI, and attenu-guard-ts 0.2.1 on npm with the same
canonicalization.

RFC 8785 JCS now, on all four surfaces, so bundle hashes are reproducible from any language and not
only from Python. That is the thing I told you not to build against this morning.

If you were reading tokens at 3606464: the verifier now re-canonicalizes and compares bytes.
Anything whose bytes are JCS verifies, anything else is rejected. Tokens and bundles carry a
c14n: "JCS" field, but it is a label only. Verification never reads it. The composition boundary
you described does not change.

[Poke-nushi]

Thank you for the fast follow-through. I see that the JCS transition has now landed in attenu-guard 0.7.1 and attenu-guard-ts 0.2.1.

For any future attenu-guard bundle evaluation, I will use the new JCS release line rather than 3606464, while keeping attenu-guard’s source canonicalization distinct from VATE’s own current fixture digest basis. Treating c14n: "JCS" as informational and enforcing the canonical bytes rather than trusting the label is an important distinction.

The authority and outcome boundary is now clear as well. I will record the client and server bundles as authorization and lifecycle evidence, with verify_hop required to evaluate the complete hop, and not treat either bundle as outcome evidence or a completeness proof.

One precision on the proposed revocation case: VATE’s post-execution linkage alone would not discover the revocation. VATE can deny at admission when current or bounded-freshness status or revocation evidence makes the stale authority observable. A later verifier may also re-evaluate that evidence when accepting the artifact set, but the current v0.3 runner does not continuously monitor later status changes.

So I would frame the composition boundary as follows: attenu-guard accepts the receiving hop because no cross-process revocation source is wired, while a VATE admission profile supplied with current status evidence must deny the request before handoff. Post-execution linkage then determines whether later evidence belongs to that specific admission and admitted effective request; it is not itself a revocation-discovery mechanism.

Yes, the runnable revocation test would be very valuable. Keeping it native to attenu-guard would be ideal. A minimal sequence showing:

1. token minting;
2. revocation in the caller process;
3. verification in a separate receiving process with revocation_check unwired;
4. wire.load succeeding and the inner executor being reached;

would be enough. Once it lands, I can pin the exact commit and map it independently into a VATE composition case without changing its source semantics.

Thank you for offering to write it, and for documenting these boundaries so precisely.

[rafaelasor]

Your precision on the revocation case is right and I'll use your framing. Post-execution linkage
does not discover a revocation. Attenu accepts the receiving hop because no cross-process
revocation source is wired. A VATE admission profile holding current status evidence denies
before the handoff. Linkage then binds later evidence to that admission, nothing more.

The cross-process case is in tests/test_cross_process_revocation.py at 48cd64f.
The receiving side is a real second interpreter, not a thread, so nothing from the caller's
memory crosses the line. With no revocation source, the real wire.load succeeds and a sentinel
inner body prints REACHED. With the same tokens and current status evidence supplied through
the modeled revocation_check contract, the receiver prints DENIED:revoked.

Within attenu-guard's A2A receiver, revocation_check is applied to the verified leaf payload
before the inner executor, and any non-empty reason refuses the hop. The shipped executor path
has separate integration coverage.
A composition layer can instead enforce current revocation evidence earlier at admission, as
you described. CI is green on the pinned commit.

[Poke-nushi]

Thank you. I independently reproduced both cases from a fresh checkout at 48cd64f382e0fe006c9d2899430e2ba87308a6d8, without modifying the test:

• unwired receiver: REACHED
• current status through the modeled revocation_check contract: DENIED:revoked

Both tests passed, and the pinned CI run is green.

I will preserve this as attenu-guard-native composition evidence, keeping the real second-interpreter wire boundary distinct from the modeled status seam and the separately covered A2A executor path.

I will now prepare the VATE-side mapping locally. I am not treating this as a VATE external-SUT result yet. If that mapping produces a small exact-byte packet that needs an attenu-owned bridge, I will return with the concrete pinned inputs and expected output contract rather than asking for additional implementation work now.

Thank you again for turning the boundary discussion into a runnable artifact so quickly.

[rafaelasor]

The outcome-evidence gap you recorded now has a reviewed proposal: https://github.com/orgs/attenu-io/discussions/8 . For the VATE mapping the relevant parts are section 5, a missing or contradicting record becomes a named verification failure instead of an audit line, and section 3, the vocabulary is observations, not judgments, so your admission-side denial composes with it rather than overlapping it.

[Poke-nushi]

Thanks for the pointer. I read the revised proposal, especially sections 3 and
5 and the clarifications added after review.

The separation between admission-side decisions and producer-side outcome
observations is clear, and the named missing or contradictory states plus
separate parameter-binding coverage look like a sound composition boundary.

I’ll keep the VATE mapping local for now and revisit it when the proposed
schema and vectors land in a released implementation. No action is needed from
you in the meantime.

[rafaelasor]

It landed. attenu-guard 0.9.0 on PyPI, attenu-guard-ts 0.4.0 on npm, same contract in both.

What you would pin for the VATE mapping: schema version 2, opt-in per chain (schema_version=2 on Guard.issue; v1 chains and bundles are unchanged). The pieces from our exchange are all in it: call_id allocated before the call runs, the body_state observation vocabulary, the verifier's named failures with execution_binding reported as observation × lifecycle × aggregate plus params_coverage, and verify_bundle(expected_anchor=…/expected_head=…) for an independently retained anchor. The revocation test we built for you is unchanged and still passes against this release.