Agent identity in mecatl tracker

[jhrozek]

Index and open questions for the agent-identity work. Not an epic — the questions below are deliberately not distributed into the epics, because a question spread across seven issues is a question nobody answers.

The set

All of them are linked as sub-issues of this one, so GitHub tracks the progress bar.

Sequencing: #367 is the only unblocked one and everything waits on its owner field. #371 branches off #367 without needing #368. #370 needs #368 and #369 both. #375 runs before any work in which mecatl signs something.

	Behaviour	Waits on
#367	A caller has an identity, and objects have owners	—
#368	One caller cannot reach another's work	#367
#369	Sensitivity is a label that survives delegation	#367
#370	Work can be shared deliberately	#368, #369
#371	An agent cannot widen its own authority	#367
#372	The harness acts for a user against an external system	#375, and ToolHive (see below)
#373	A scheduled run acts with bounded, consented authority	#367, #372
#374	Store hardening — auth, TLS, snapshot integrity	—
#375	Spike: can a model-spawned shell reach the key?	—

Removed from this table: #385 (event-log integrity) closed as not planned — it depended on a snapshot MAC from #374 that was never actually implemented (#374 shipped only Redis auth/TLS). #376 (the escalation proof) closed and moved under #478 ("mecatl as its own SPIFFE issuer") rather than tracked standalone here — its remaining blocker (toolhive#6204, scope intersection) is SPIFFE/identity plumbing #478 already owns.

Decided

1. SPIFFE client authentication: JWT-SVID assertion. Familiar, least new machinery, and vMCP already handles JWTs. X.509-SVID would need work in both repos; WIT-SVID is overkill for now. Update: Embedded auth server should accept SPIFFE SVIDs as client credentials toolhive#6199 commits ToolHive to both spiffe_jwt and spiffe_x509, resolving to one authenticated principal with one client association and one authorization outcome, with WIT-SVID explicitly out of scope. So the "X.509 needs work in both repos" half of the rationale no longer holds on the ToolHive side; spiffe_jwt remains our pick on mecatl-side cost, and the choice is now reversible rather than constrained.
2. External authorization is definition-based. Instance is useful for auditing, not for authorization. Reinforced since: no IETF draft ties consent or authorization to a running instance, so instance-based external authz has no counterparty specification today.
3. The driver protocol is declared trusted now, with generic enforcement middleware in the mid term. The half owed immediately is the written deployment requirement, on One caller cannot reach another's work #368.
4. The access token is a profiled JWT, offline-verified. The claims contract is the sticky part; the carrier is reversible, so introspection stays available later as an additive check.
5. Per-agent consent is a requirement, and the consent model is spike work. The authorization half is definition-keyed and AS-mediated, buildable on the two-leg shape now. The record — who holds it, who signs it, what it is keyed on — needs a proper design pass and is deliberately left open on A scheduled run acts with bounded, consented authority #373. What is established is that no IETF draft ties consent to a running instance and every draft that scopes it puts a signed artifact keyed on the definition, so the gate does not require mecatl to sign anything.
6. The escalation proof runs in e2e, and the cost is accepted.

Still open

• How the gateway gets the AS's signing keys — JWKS endpoint or static key file. Created by decision 4, not answered by it. Day-one item on The harness acts for a user against an external system #372.
• Bundle distribution or a static key for the FS grant verifier. The grant issuer is in-process with the harness but the FS service is a separate process, so one in-house verifier exists. A static public key satisfies it until you want rotation without redeploying verifiers, or a second consumer.
• The cadence for the escalation proof — nightly, pre-release, or on merge. A spend decision; it now lives on mecatl as its own SPIFFE issuer: trust domain, signing path, bundle publication #478, where the escalation proof (formerly The escalation proof: an injected agent cannot act as a write-capable definition #376) was moved.
• The consent model on A scheduled run acts with bounded, consented authority #373: who holds the record, who signs it, what it is keyed on, where consent is captured for unattended work, and whether it must verify with the authorization server unreachable. Spike first, deliberately unsettled.
• The per-spawn round trip. The design's call 2 (per-spawn narrowing) carries no caching note, so every subagent spawn depends on the authorization server being reachable, including a child that only reads files. Cache it, move narrowing to the internal issuer, or accept it. On The harness acts for a user against an external system #372.

Sequenced, no longer deferred

• No prescribed naming scheme; the flag validates and the docs recommend. Since the boundary is per-deployment, the name is a config value, and mecatl is deployed by other people — prescribing a shape for someone else's org domain is presumptuous. --identity-domain is required when identity is enabled, and validated against the spec grammar: lowercase, [a-z0-9.\-_], at most 255 bytes, no userinfo or port, no percent-encoding. The docs recommend a domain you own, because names are nominally self-registered with no global uniqueness guarantee and a collision means being unable to federate. Never derive the name from a bundle-endpoint hostname; the federation spec gives a concrete subdomain-squatting attack for that. Accepted cost: deployments will not look alike.
• The trust-domain boundary is one domain per deployment. Tenants are expected to get their own deployment and probably their own cluster, so this yields per-tenant separation for free in the cmd/mecak8s shape without paying for many name-to-bundle mappings up front. What the boundary buys: a compromised deployment's signing key can never forge another deployment's identities, and that holds even if the issuing server's authorization logic is fully broken. Path prefixes inside one shared domain cannot give that, because the same key signs both and separation rests entirely on the registration logic being correct.
• mecatl as its own SPIFFE issuer. Un-deferred, because the filesystem grant service is on the roadmap and it is the consumer the original deferral named: the grants are over mecatl's own workspace resources on a hot path, and the holder requesting attenuation is a goroutine no external attestor can see. Two amendments to how it lands. Scope the first slice to the shared infrastructure — trust domain, signing path, bundle publication — and let the claim vocabulary land with the FS service, per the doc's own split ("the signing infrastructure, the bundle endpoint and the trust domain are shared, and only the claim set differs"). And sequence it behind Spike: can a model-spawned shell reach the key? #375, because the issuer's day-one payoff is that a verifier can check a narrowing happened rather than trusting the harness, and if the signing key stays reachable from a shell the model drives then verifying against it is trusting the harness again.
  • Not for the vMCP hop. Nothing in hops 3 through 7 consumes anything only an mecatl-run domain could supply; call 1 needs mecatl to be a SPIFFE workload, which any SPIRE deployment gives it.
  • Not for consent. See decision 5.
  • Own domain rather than an intermediate inside an existing one is the current position, not a ratified decision: a delegated intermediate is a full member of that domain's chain with no sub-domain fencing, so chaining in would put a shell-reachable key inside another domain's trust base. The counter-argument, stated for fairness, is that own-domain bounds only the external blast radius — a compromised pod still impersonates every session inside mecatl's own domain, which is where most damage sits in a single-deployment world.

Deferred, with triggers

A deferral with no stated trigger is a decision nobody revisits.

• Per-entry access control inside a session. Deferred because the memory entry type carries no owner and one project store is shared across every session, so a check can only be all-or-nothing per scope. Trigger: the entry type gains an owner, which is Sensitivity is a label that survives delegation #369's territory.

• Resource-level authority — structured resource fields so the gate tests containment over the resolved target rather than a scope string. Trigger: one agent must be confined to a subset of a backend another may reach in full, which a scope string like cap:github.write cannot express.

  The deliverable before then is a short spike doc defining the containment predicate, so the trigger cannot arrive with the algorithm still undefined. Scope for it:

  • MCP resolved targets are the primary case, not the filesystem grant service. The motivation is that ToolHive's gate cannot test containment over a resolved target today, and "the resolved target as a value only admission can construct" is one of the three unfiled ToolHive enforcement pieces below. The FS grant service is a second consumer of the same predicate over a different resource vocabulary — a path subtree instead of a repository — not the first.
  • One predicate, defined once. Given a parent's authorization_details and a child's request, is the child contained? Canonicalized resource prefixes plus an operations set, whichever vocabulary the resource comes from. The spike should say what happens on an unrecognized field, and whether operations are a flat set or a lattice.
  • Both refusal obligations named. mecatl must refuse to request a widening at the spawn seam, because it is the only party that knows the parent's authority. ToolHive must refuse to honour one at the gate, because it cannot assume mecatl did. Neither is sufficient alone: mecatl-only means a compromised harness widens freely, gate-only means the harness cannot tell a child what it may ask for. Same "one decision function, two enforcement points" discipline as the driver protocol on One caller cannot reach another's work #368.
  • Check AuthZEN's COAZ draft before inventing a vocabulary. It maps MCP tool calls into a Subject-Action-Resource-Context model for per-call PDP authorization, which is the same mapping this predicate needs, and it is an adopted OIDF working-group draft rather than an individual one. Borrow it if it fits.

• Sender-constrained token binding. Deferred, with narrow aud plus short exp as the floor — which is what the design already has, and what the JWT-SVID spec treats as the replay defence for a keyless bearer token rather than a supplement to one. A cnf binding only stops an attacker holding the token but not the connection, and an injected in-pod model has both if the loop makes the gateway call, so binding's value is contingent on the broker becoming a data-path proxy while its deployment cost (the gateway terminates TLS itself and requires client certificates, so no TLS-terminating ingress in front) is paid always. Triggers: the broker becomes a proxy for another reason, or a leak makes off-pod replay demonstrated rather than modelled. If built, the method is mTLS (RFC 8705) rather than DPoP, on cost. Note this also parks the unstated question of who makes the gateway call — see The harness acts for a user against an external system #372's hazards.

• Cryptographic per-instance attribution. Definition granularity is settled for external authorization, but the cost is real and stated in the outbound doc: attribution is downgraded from verifiable to operational, and X-Correlation-Id is unsigned, so an instance can only be named by a party that already trusts mecatl's log. No relying party's specification currently knows what to do with an instance-named credential.

  Two triggers, because they fire for different reasons and one of them is ours.

  • A subagent stops being a goroutine. This is the checkable one, and it collapses every objection at once: a separate process is visible to an external attestor, can hold its own key, and can therefore do proof of possession, at which point "no party outside the pod can address, present or revoke it" stops being true. Everything decided here about keyless bearer children and X.509 being structurally unavailable turns over on that single fact. Anyone proposing out-of-process subagents for an unrelated reason — sandboxing, resource limits, language isolation — should land on this row.
  • A downstream service needs to name a specific run in a claim its own authorization server can act on. Phrased as a state rather than an event, because "an auditor asks" is not something anyone can check on a Tuesday. This one is sufficient but the structural trigger is not necessary for it: the requirement could land while children are still goroutines, and that is the expensive version — instance credentials for in-process principals with every caveat above still intact.

  What it would need either way is a published JWKS, not federation-grade machinery. Worth carrying with the row so the trigger does not drag the whole issuer-operator load in behind it.

ToolHive dependencies

Checked against every open and closed issue in stacklok/toolhive. Covered: token exchange (stacklok/toolhive#5194), act nesting (stacklok/toolhive#6113), Cedar (stacklok/toolhive#6081, stacklok/toolhive#6053, stacklok/toolhive#6049, stacklok/toolhive#6048, stacklok/toolhive#5845, stacklok/toolhive#5582), and SPIFFE client authentication with its per-identity scope association (stacklok/toolhive#6199, sub-issues stacklok/toolhive#6200–6206 — which also carries the client_credentials grant and the provisionable confidential client, option D of stacklok/toolhive#6082).

Prerequisites of the two-leg shape we picked, both confirmed against the code:

• Support explicit actor_token and id_token subject type in token exchange toolhive#5815, explicit actor_token support. Call 3 sends actor_token and the server rejects it outright today (pkg/authserver/server/tokenexchange/handler.go:296-301, "not yet supported").
• Consent model for external OIDC subject tokens in multi-issuer token exchange toolhive#5989, a consent model for external OIDC subject tokens. This is how call 3 accepts a real IdP token at all; its MultiIssuerTokenValidator implements SubjectTokenValidator, so it sits on the subject token presented into the AS's own exchange endpoint.

Neither is the seam a single-mint design would need, which is a gateway accepting an externally minted token as the terminal credential. Nothing is filed for that, and single-mint is not the chosen path.

Of the three enforcement pieces, one is now filed, one is deliberately deferred, and one is genuinely missing. Intersection, binding and an unforgeable target are what separate delegation that constrains from attribution that describes; without them the chain is a log field.

• Requested scope intersected against the subject token — filed, on Integrate SPIFFE principals with OAuth grants and discovery toolhive#6204: "Constrain requested scopes and resources by both workload policy and source-token authority, whichever is narrower." Since the scope shrinking between two token payloads is the intersection, the escalation proof (now tracked on mecatl as its own SPIFFE issuer: trust domain, signing path, bundle publication #478) is no longer blocked on an unfiled item — it waits on #6204 landing. The per-identity ceiling the intersection narrows against is Define the SPIFFE client identity, association, and configuration model toolhive#6200, which requires per-identity narrowing rather than deferring it (the spiffee-authserver prototype gave every auto-registered client every supported scope, and #6200 names that as a weakness not to lift).
• Tokens sender-constrained end to end — nothing filed, and we are deliberately not asking for it yet; see the deferral above. The method, if it is ever wanted, is mTLS binding rather than DPoP.
• The resolved target as a value only admission can construct — the one still genuinely missing, though the admission seam itself shipped. Note Integrate SPIFFE principals with OAuth grants and discovery toolhive#6204 does carry "require and authorize the target MCP resource", which is the RFC 8707 half; the internal value admission alone can construct is the part with no owner.

One half-covered: the credential read happening behind the gate (only the store and refresh halves exist). The other former half — registration saying which definitions a client may act as — is absorbed: with act.sub being the workload by design on #6204, a definition is expressed as a scope (agent:code-reviewer), so #6200's per-association scope configuration is the allowlist. Two things to confirm are anticipated there: that a scope namespace enumerated per association is in scope (one mecatl deployment is a single SPIFFE ID carrying several agent:* entries), and that matching is exact-element rather than prefix — agent:deploy must not admit agent:deployer.

Two of their open issues are worth reading regardless: stacklok/toolhive#5293, the proxy forwarding upstream credential tokens in tool result bodies unchanged — into bodies the model reads; and stacklok/toolhive#6081, Cedar taking its principal from an unverified id_token, which is the premise of the whole gate.

Reasoning

• docs/agent-identity-model.md — inbound.
• docs/agent-identity-outbound.md — the outbound boundary.

[JAORMX]

Open questions:

Which SPIFFE client-authentication method — JWT-SVID assertion, X.509-SVID over mTLS, or WIT-SVID. Blocks the outbound work.

I'm thinking we can start with JWT-SVID assertion. It's something we already handle in other places like vmcp, easy to reason about and it gets us a long way. X.509-SVID would require a bunch fo work in multiple places (both here and in toolhive) and... Probably WIT-SVID is overkill?

Definition-based or instance-based external authorization. The registration design assumes definition-based; if that is wrong it changes shape.

I think the design assumes the right auth format, definition based is the way to go. Instance is useful for auditing but not for authorization.

Whether the driver protocol enforces or is declared trusted.

I'd say the answer here is "somewhere in between". In practical terms we can "declare it trusted". The identity information is carried as headers in the transport, and it would trickle into the request and handlers via an identity interface that is persisted via context.Context. In an initial iteration we can claim it's trusted infra, but in the mid-term we should provide service authors means and middleware to enforce this in a general way. This is what we were talking about yesterday with lifting the auth pieces off vmcp. That could be a general mechanism. wdyt?

Whether the access token is a profiled JWT or opaque plus introspection.

Right now I'm leaning towards a profiled JWT instead of opaque mostly because it's faster, easier and allows us to move forward.

Whether per-agent consent is a product requirement, and who holds the record.

With the risk of scope creep, I'm going to say that per-agent consent is going to be a requirement for this. However, I'm not yet sure "who holds the record". This is something to figure out.

Where the escalation proof runs.

e2e. It doesn't matter if it costs money. We can do lightweight integration tests, and this is fine, but ultimatelyt we are going to need e2e.

Deferrals:

mecatl as its own SPIFFE issuer

I'm not sure we should really defer this. We probably should instead try to downscope and come up with the minimal implementation that makes things work. My thinking is that this is going to make "per-agent consent" possible and it's something we can't really get around from.

Per-entry access control inside a session.

I agree. Here be dragons.

Resource-level authority

It would be ideal we have an idea of how this will work, but it's fine if we defer this for now.

[JAORMX]

(mecatl comment, posted on Juan's behalf — adding color to his answers above, from the mecatl side of the design docs.)

Q1 (client-auth method) — JWT-SVID assertion works here only because the cnf holder-binding lives on a different connection: tokens are bound to the broker's key checked against the mTLS connection to the gateway, not the AS. The answer is fine as long as mTLS-to-the-gateway stays; if that leg ever loses mTLS, holder binding falls back to DPoP. The doc lists these as separate open questions precisely because they land on different connections — worth not conflating them.

Q2 (definition-based) — agreed, with one keep-the-door-cheap note. Instance IDs still ride the token path structure and the correlation value, so a future dynamic/session-scoped rule needs no re-minting: it would be template rules over signed per-session facts (kill-switch by jti, resource containment from authorization_details), never static per-session policy. "Definition for policy, instance for audit" is the right frame; just keep the instance data flowing so the option costs nothing later.

Q3 (driver protocol) — three refinements to "somewhere in between":

1. "Declare trusted" only counts if written as an explicit deployment requirement now: the driver endpoint speaks only to mecatl pods and must never be tenant-reachable. That statement is the difference between "declared" and "silence" — it's the actual deliverable of the question, independent of any mid-term middleware.
2. The header carries a principal claim only — never authority or scopes. The moment it carries "what the caller may do," the driver becomes a policy engine and we've rebuilt the enforcement option by accident.
3. On context.Context: fine at the gRPC boundary (metadata → interceptor → handler ctx, idiomatic), but below the adapter keep the principal explicit — constructor-injected on the client (like the bearer token today), typed values in composition. ctx-everywhere makes a missing principal a nil at the store instead of a failure at the gate. Also note: the owner label sits inside the opaque sessnap payload, invisible to the driver — if the driver ever needs to key/filter on owner (e.g. per-principal List), that needs a top-level proto field, not just a header.

Q4 (profiled JWT) — agreed; two additions. The carrier is the reversible part; the claims contract is the sticky one (it survives a later JWT↔opaque flip; changing claims later touches both repos + operator policies). And JWT moves one item onto the day-one checklist: the gateway needs the AS's signing keys (JWKS endpoint or static key file). Introspection stays available as an additive liveness/policy check later — worth saying so "profiled JWT" isn't read as "introspection forever rejected."

Q5 (per-agent consent) — the split that makes "requirement" actionable: (a) the authorization is definition-keyed and AS-mediated, buildable on the outbound work now; (b) the integrity — signed proof of who consented and which instance acted — needs mecatl's own signing identity. "Going to be a requirement" is cheap for (a) and is exactly what pulls (b) forward. For "who holds the record": the leading candidate is wherever the schedule grant lives — it's the one consent artifact the design already makes forgery-resistant (signed envelope, verified before every fire, confirmation flow the model can't author). And the shape problem should be named in the answer: unattended runs can't consent at fire time, so consent is either captured at creation or admin-pre-authorized — someone signs that trade-off explicitly.

Q6 (escalation proof in e2e) — one practical amendment: the concern was that an ungated proof rots. If it lives in e2e (not task test), state the cadence it runs on — nightly, pre-release, whatever — so "it's e2e" doesn't become "it hasn't run in three months."

SPIFFE-issuer deferral — support un-deferring, scoped. Amend the deferral to split it: minimal-issuer spike now (record the trust-domain name, the claim vocabulary, a signing path on the go-spiffe/go-jose/sigstore-KMS stack, a bundle endpoint), sequenced ahead of the FS spike — FS is its first consumer, and per-agent consent's integrity half is its second. Production issuer-operator load (rotation ceremonies, federation, HA intermediates, JWKS SLO) stays deferred until a production consumer exists. Two conditions from the original deferral stand: the outbound hop's vocabulary stays AS-shaped (two-leg remains the bridge), and the ToolHive issues that make the paths converge — #5989 (multi-issuer validator) + #5815 (cnf binding) — get pulled into the plan explicitly, because single-mint at vMCP is what makes GitHub and FS the same mechanism rather than two wearing one diagram.

Resource-level authority — for "an idea of how this will work": the model doc already sketches the shape (RFC 9396 authorization_details, containment over an operations set, canonicalized resource prefixes, posture/depth ranks) and names the genuinely unclaimed ground — the subset computation plus who is obliged to refuse a widening. Suggest the "idea" deliverable be a short spike doc defining exactly that containment algorithm, so the deferral's trigger doesn't arrive with the algorithm still undefined.

[jhrozek]

Recording what the six answers changed, what they left open, and three things that came out of chasing the issuer deferral. Body updated to match.

The answers, and what each left behind

Q1, client auth: JWT-SVID assertion. Settled. It does not settle holder binding, which lives on a different connection: tokens are cnf-bound to the broker's key, checked against the mTLS leg to the gateway, not to the AS. Fine while that leg keeps mTLS; if it ever doesn't, holder binding falls to DPoP. Kept as a separate open row.

Q2, definition-based. Settled, and it got stronger from an unexpected direction. 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. Instance-based external authorization has no counterparty specification today, so choosing it would mean minting credentials no relying party knows how to act on.

Q3, driver protocol: declared trusted now, generic middleware later. Accepted. The half owed now is the sentence itself, and it is on #368: the driver endpoint speaks only to mecatl pods and is never tenant-reachable. Two constraints ride with it. The future header carries a principal claim only, never authority, or the driver becomes a policy engine and we have rebuilt the enforcement option by accident. And the decision function gets shaped so a later driver-side check calls the same function rather than growing a second one.

Worth adding: SPIFFE mTLS would turn that declaration into enforcement, and unlike the in-process delegation work it fits cleanly, because both sides are real OS processes and attestation applies without the goroutine problem. That needs a SPIFFE deployment, not mecatl's own trust domain, so it is separable from everything below.

Q4, profiled JWT. Accepted. The claims contract is the sticky part; the carrier is reversible, so introspection stays available later as an additive check. It creates one day-one item that was not there before: the gateway needs the AS's signing keys, JWKS endpoint or static file. Now on #372.

Q5, per-agent consent is a requirement. Accepted, and the "who holds the record" half is now answerable. Every IETF draft that scopes consent puts an AS-signed artifact keyed on the agent definition. Liu et al. (draft-liu-ai-agent-authorization-integration-00) has the most developed form, an authorization_evidence object inside RFC 9396 authorization_details carrying displayed_content, user_action and a timestamp. So consent does not need mecatl to sign anything, which matters for the deferral below. Details on #372 and #373.

Q6, e2e. Accepted. The cadence is still open and it is a spend decision, so it sits on #376 rather than here.

The issuer deferral: un-deferred, with a different consumer

Agreed it should not be deferred. But the reason changes, and the change is load-bearing.

Consent turned out not to need mecatl to sign. Neither does the vMCP hop, on a closer look: nothing in hops 3 through 7 consumes anything only an mecatl-run trust domain could supply. Call 1 needs mecatl to be a SPIFFE workload, which any SPIRE deployment provides. The internal agent/<def>/inst/<sid>/child/<cid> vocabulary never crosses that boundary; it rides as scope strings mecatl asks for.

What does need it is the filesystem grant service, which is on the roadmap: the grants are over mecatl's own workspace resources on a hot path, and the holder requesting attenuation is a goroutine no external attestor can see. That is exactly the consumer the original deferral named. So the trigger has effectively fired.

Two amendments to how it lands:

Scope the first slice to the shared infrastructure, not the claim vocabulary. The doc's own warning holds — two token designs sharing one issuer, and building for the wrong consumer surfaces the mismatch late. Its escape hatch is the split to use: "the signing infrastructure, the bundle endpoint and the trust domain are shared, and only the claim set differs." So build the domain, the signing path and bundle publication now; let the claim set land with the FS service.

Sequence it behind #375, not ahead of it. The issuer's day-one payoff is that a verifier can check a narrowing actually happened rather than trusting the harness's word. But the signing key sits in the agent-loop process, reachable from a shell the model drives, and not only through memory — a flag lands in /proc/<pid>/cmdline, an env var is readable at the parent's /proc/<harness-pid>/environ, and a mounted Secret file is a fixed path cat reaches under a read-only-by-verb classification. So verifying against that key may just be trusting the harness again. That circularity question is now part of #375's scope, and it decides whether the payoff exists.

Also: the trust-domain name changes character. It was a hedge on a deferral ("pick it now, mint nothing"); with the issuer sequenced it is an ordinary first deliverable. And it is downstream of a question we had not separated — the boundary. Reserving a name avoids redoing work; it does not avoid redoing a wrong boundary, and a boundary correction costs the same re-registration and re-issuance either way. One domain per deployment or one per tenant is the decision that matters, since two domains give key-material separation that survives a registration-policy compromise while path prefixes inside one domain do not.

The ToolHive dependency list needs correcting

The amendment asked to pull toolhive#5989 and toolhive#5815 in as the pieces that make single-mint reachable and the two paths converge. Checked the code, and that is not what they do — but they matter more than that framing suggests, because both are prerequisites of the path we actually picked.

• toolhive#5815, "Support explicit actor_token and id_token subject type in token exchange," is a hard prerequisite for two-leg. Call 3 sends actor_token, and the server rejects it outright today: pkg/authserver/server/tokenexchange/handler.go:296-301, "The 'actor_token' and 'actor_token_type' parameters are not yet supported."
• toolhive#5989, "Consent model for external OIDC subject tokens in multi-issuer token exchange," is how call 3 accepts a real IdP token at all. Its MultiIssuerTokenValidator implements SubjectTokenValidator, so it sits on the subject token presented into the AS's own exchange endpoint.

Neither is the seam single-mint would need, which is a gateway accepting an externally minted token as the terminal credential. No issue was found for that. Since single-mint is not the chosen path, the fix is to move both into the two-leg prerequisite list rather than the convergence list.

Resource-level authority

For the "would be ideal to have an idea how this works" note: proposing the deliverable be a short spike doc defining the containment algorithm and naming who is obliged to refuse a widening. The model doc already sketches the shape (RFC 9396 authorization_details, containment over an operations set, canonicalized resource prefixes, posture and depth ranks); the subset computation and the refusal obligation are the unclaimed parts. The point is that the trigger must not arrive with the algorithm still undefined.

New, from a security pass on #374

The snapshot MAC's scope is too narrow in three ways and its key custody is an instance of #375. The workspace field matters more than the owner label, since a stored "workspace":"/" roots a session's file tools at the filesystem root; the event log is a second authority path that can make the harness learn a permission the user never granted; and a payload MAC does not survive the grpcdriver round trip. All on #374 with file and line.