The escalation proof: an injected agent cannot act as a write-capable definition

[jhrozek]

An injected parent asks to act as a write-capable definition, the scope shrinks between two shown
token payloads, the gateway refuses the write, and the twin holds: the operator running that
same definition top-level still succeeds. Without the twin you cannot distinguish "escalation
blocked" from "the definition is broken".

mecatl and ToolHive. The north star: file first, complete last. Needs #371, plus the ToolHive work below.

One agent proves nothing — a single-agent run never requests a second definition, so the
interesting step never executes and the demo passes whether or not it is guarded.

It follows test-sidecar-delegation.sh, which checks real HTTP status codes — not
run-demo.sh Act 3, whose delegation matrix is a hardcoded printf.

Where it runs, and how often

Settled: task e2e, live, and the cost is accepted. Lightweight integration tests are fine alongside
it but are not the proof.

Cadence: on merge to main, path-filtered to the identity and delegation paths. Chosen for the
tightest feedback and because a failure is attributed to a specific PR rather than to "something last
week." Accepted cost: live, paid API calls sit in the merge path, and the path filter is what keeps that
off merges that cannot affect this.

The cadence is written down here on purpose. task e2e is not part of task test, and "it's e2e"
decays into "it hasn't run in three months" — this is the one test whose silent death would be
invisible.

What it pins

The escalation being tested is definition-based authorization working: code-reviewer registered
read-only, deployer registered to write, the injected parent trying to cross. So this test is also
the regression guard for that decision, and it should carry a comment saying so — if instance-based
external authorization ever comes back onto the table, this is where the cost of the flip shows up
first.

That decision is now better supported than when it was made. No IETF draft ties consent or
authorization to a running instance: McGuinness's agent_instance_id exists for attestation and audit
while his draft rules consent out of scope on purpose, the expired WSO2 draft names a
requested_actor which is a definition, and Liu et al.'s consent evidence keys on act.sub with
instance correlation as an optional audit add-on. Instance-based external authorization has no
counterparty specification today.

ToolHive dependencies

• Scope intersection against the subject token is what the shrinking payloads are, and it is not
  filed there. File it before this proof can be demoed.
• actor_token support (toolhive#5815) is a
  hard prerequisite: call 3 sends actor_token, and the server rejects it outright today
  (pkg/authserver/server/tokenexchange/handler.go:296-301, "not yet supported").
• A consent model for external OIDC subject tokens
  (toolhive#5989) is how call 3 accepts a real IdP
  token at all.

Without the last two, the token payloads this proof shows shrinking between never get minted.

Reasoning

The design this comes from, both on main:

• docs/agent-identity-model.md — the inbound side: who is acting, and how mecatl would identify them.
• docs/agent-identity-outbound.md — the outbound boundary: acting for a user against an external system.

Every hazard above is stated in full here rather than linked, so this issue stands on its own.

[JAORMX]

(mecatl comment, posted on Juan's behalf — the #377 Q6 answer plus one structural note.)

Juan answered the where on #377: e2e, and the cost is fine. The amendment from the discussion: the issue's own warning ("a proof that is not gated rots") isn't fully discharged by choosing e2e, because task e2e runs when someone remembers to run it. Record the cadence in this issue — nightly CI, pre-release gate, whatever the team picks — so "it's e2e" doesn't decay into "it hasn't run in three months." The proof is the north star of the whole set; it's the one test whose silent death would be invisible.

One structural note from the Q2 discussion that this proof should preserve: the escalation being tested is definition-based authorization doing its job — code-reviewer registered read-only, deployer registered to write, the injected parent trying to cross. That means the proof is also the regression guard for the definition-based decision: if instance-based external authz ever comes back onto the table (Q2's keep-the-door-cheap note), this test is where the cost of that flip would show up first. Worth a comment in the test itself saying which decision it's pinning.

And the twin deserves emphasis because it's the part a rushed implementation will drop: "the operator running that same definition top-level still succeeds" is what distinguishes "escalation blocked" from "registration is broken." Without it this proof can go green while the feature is dead for legitimate use — the same property-vs-adversarial gap the issue format exists to catch.

[jhrozek]

Where it runs is settled as e2e. The cadence is the half still open, and it needs a spend decision rather than a technical one, so leaving it here: nightly, pre-release gate, or on merge to main. task e2e is live against OpenRouter and costs real money, so it's your call which of those is worth paying for. Whichever it is, it goes in the body, because "it's e2e" decays into "it hasn't run in three months" and this is the one test whose silent death would be invisible.

Two things to add while it's open.

The definition-based decision it pins got stronger. Reading the agent-consent drafts: no IETF draft ties consent or authorization to a running instance. McGuinness's agent_instance_id exists for attestation and audit and his draft rules consent out of scope on purpose. The expired WSO2 draft names a requested_actor, which is a definition. Liu et al.'s consent evidence keys on act.sub, a workload identity, with instance correlation as an optional audit add-on. So instance-based external authorization has no counterparty spec today, and a comment in the test naming which decision it pins is worth writing.

The ToolHive dependency line in the body needs a correction. It says the proof needs scope intersection in ToolHive "which is not filed there," and that still looks right. But two adjacent issues are now confirmed as prerequisites of the path we picked, and neither was in this issue's blockers: #5815 adds actor_token support, which call 3 requires and the server rejects outright today (handler.go:296-301, "not yet supported"), and #5989 is the consent model for external OIDC subject tokens, which is how call 3 accepts a real IdP token at all. Without those two, the token payloads this proof is supposed to show shrinking between never get minted in the first place.

[jhrozek]

A fourth proof bullet, because there is a route to the write that this test as specified would not observe. From the #375 spike, now closed.

However mecatl authenticates to the authorization server, the credential lives in mecatl's process — a client secret in the environment or a mounted file for client_credentials, or the workload SVID private key for spiffe_jwt. All three routes to both are verified against real mecatl, in a kind cluster, driven through mecatl's own tool surface at --posture=auto:

• Bash{cat /proc/1/environ} returns the process environment (PID 1 is mecated; envscrub strips the child's env only);
• a mounted file comes out through Read when --workspace is unset, which is mecak8s: default workspace is the entire container filesystem — an injected agent reads the service-account token #448;
• spire-agent api fetch x509 -write returns the SVID and its private key where the Workload API socket is mounted;
• and /proc/1/mem is readable with CapEff: 0000000000000000 on a kernel where YAMA is absent.

The per-identity ceiling (stacklok/toolhive#6200) attaches to the client, not the session. mecatl's client association legitimately carries both agent:code-reviewer and agent:deployer, because mecatl legitimately runs both definitions. So an injected agent with a shell can:

1. read mecatl's client credential,
2. call the AS directly, bypassing whatever per-session narrowing mecatl applies,
3. request agent:deployer — inside the client's ceiling, so the AS grants it,
4. call the gateway and complete the write.

This test would still pass. The scope shrank on the path mecatl took, the gateway refused that request, and the twin held — while the write succeeded by a route the test never looked at. The gateway cannot distinguish the two, because both present a legitimately-minted token for a definition the client is entitled to act as.

Proposed proof bullet:

• In the escalation arm, the injected agent cannot obtain mecatl's AS client credential — the client secret, or the workload SVID private key. Asserted by searching the arm's transcript and tool results for the credential material, the way a canary probe would. Either it is unreachable (because Bash is absent, the command runner is genuinely isolated, or custody is out of process), or this proof is certifying a door beside an open window.

Two notes for whoever implements it.

The assertion is cheap: seed the credential as a distinct value and grep the arm's event stream and tool results for it. It fails closed — a transcript that does not contain the value because the agent never tried is caught by the attempt assertion below.

And while adding assertions, three controls worth having that the issue does not currently name, all of which are the same class as the twin:

• The escalation was attempted. Assert an EvToolCall for the write exists in the escalation arm. If the model never took the bait, no write happens, the gateway returns nothing, and the test passes having tested nothing. This is the twin's logic applied to the attacker's side.
• The two definitions really differ, read back from the AS rather than trusted from fixture setup. A run where both are accidentally read-only passes forever.
• The legitimate read still succeeds in the escalation arm. Otherwise "everything was refused" reads as a pass when the gateway is simply unreachable, and the 403 assertion cannot tell refusal from failure.

Related: #478 (mecatl as its own SPIFFE issuer) carries the custody side as its own proof bullet, so the two are complementary — but this one belongs here, because #376 is the test that would otherwise look green.

[jhrozek]

Moving this under #478 ("mecatl as its own SPIFFE issuer: trust domain, signing path, bundle publication") rather than tracking it standalone off #377.

Status check: mecatl-side prerequisite #371 is closed, and both ToolHive prerequisites named here (actor_token support — toolhive#5815, and the consent model for external OIDC subject tokens — toolhive#5989) are closed. But per #377's own update, this proof now waits on toolhive#6204 (scope intersection against the subject token), which is still open, and no e2e proof artifact (test-sidecar-delegation.sh or equivalent) exists in this repo yet — the work itself hasn't started.

Since the remaining blocker is SPIFFE/identity plumbing that #478 already owns end to end, closing this as a standalone issue and folding its scope (the escalation proof + its ToolHive dependency tracking) into #478 rather than duplicating tracking across two issues.