Agent identity L1–L4: forge runtime work to complete the capability (platform side shipped)

[initializ-mk]

Context

The platform side of the agent-identity program (agent-identity-plan L1–L4) has merged. It is deliberately inert end-to-end until forge presents/propagates the identity at runtime — the framework-aware half lives here. This issue tracks the forge deliverables and the exact contracts they must match.

Merged platform PRs (contracts):

• L1 workload identity — agent-builder#187: per-agent k8s ServiceAccount + a projected, audience-bound, rotated SA token at deploy (gated WORKLOAD_IDENTITY_MODE=k8s_sa); the k8s_sa TokenReview validator; the §19.13 per-agent entitlement check wired shadow-mode (WORKLOAD_ENTITLEMENT_ENFORCE). agent-builder#186: PrincipalSub on grants.
• Schema — security-next#41: chain_id, chain_hop, mandate_id, grant_ref, principal_sub, principal_iss, delegation_mode, actor_agent_id, actor_workload_id, attestation_level promoted onto audit events + the PDP caller. api-next#36: RFC 8725 token typ media types.
• L2 delegation — security-next#42 (delegation vocab + PDP delegation-mode/bind-strength floors + phantom-principal guard), docs: sync documentation for Phase 2 fixes and UI improvements #43 (mandate object).
• L4 governance — security-next#45 (Okta SET revocation seam → PDP denies revoked principals), feat: env/egress injection, LLM loop fixes, Dockerfile and GHCR release #46 (policy change control), Restructure docs for useforge.ai sync pipeline #47 (hash-chained evidence export + agent-vs-human & foreign-agent reports).

All of the above read fields forge does not yet populate, so today they see nulls.

---

Forge deliverables

1. Present the per-agent workload token (unblocks §19.13 enforcement — smallest, highest value)

On calls to the platform token endpoint (POST /api/v1/mcp/token) and other platform-authenticated calls, send header X-Workload-Token = the projected SA token, read per request from INITIALIZ_WORKLOAD_TOKEN_PATH (default /var/run/secrets/initializ.ai/workload/token) — do not cache it (kubelet rotates the file in place; caching is the no_token failure class). Token audience is initializ:platform-token-endpoint.

• Once forge sends it, agent-builder flips WORKLOAD_ENTITLEMENT_ENFORCE on: an agent bound to svc-runbooks can no longer fetch svc-security's token.
• Active only when the agent is deployed with WORKLOAD_IDENTITY_MODE=k8s_sa (agent-builder provisions the per-agent SA + projects the token).

2. Populate the agentic-identity fields on PDP requests + audit events (lights up L2/L4)

• POST /pdp/decide caller: principal_sub, principal_iss, delegation_mode, actor_agent_id, actor_workload_id, attestation_level, mandate_id, grant_ref + chain_id, chain_hop on the request.
• Emitted audit events: the same promoted columns (security-next#41).
• Without this, the Phase-3 delegation-mode / bind-strength floors, the phantom-principal guard, mandate evaluation, and the Phase-4 actor-breakdown + foreign-agent reports all evaluate on nulls.
• del enum must match security-next exactly: chained | connected_account:user | connected_account:workspace | mandate | agent_own | none.

3. L3 chain tokens — native ChainContext (Phase 2, framework-aware)

• ChainContext helpers mirroring WorkflowContext: FromHTTPHeaders / WithContext / ApplyToHTTPHeaders over header X-Agent-Chain-Token (compact JWS).
• Verify every hop (verified, not trusted-by-position); separate allow-list from workflow_propagation.allowed_hosts.
• Re-mint per hop (RFC 8693 semantics): sub and the outermost act fixed once at ingress; per-hop agentic_ctx replaced.
• Claim shape: sub, act.wl = workload_identity_ref, agentic_ctx{chain_id, hop, org_id, workspace_id, entity_type, del, grant, purpose}, attestation_level, TTL ~60s, jti, typ = application/vnd.initializ.chain-token+jwt.
• Stamp chain_id/chain_hop on emitted audit events (feeds the org_chain index + the foreign-agent detector, which flags actions lacking a gateway chain token).

4. Egress-proxy chain propagation for non-Forge frameworks (§20)

The egress proxy reads the incoming chain token, re-mints for the hop, and stamps it outbound — so Strands / Claude Agent SDK / BYO get an unbroken chain without an SDK helper. Build this alongside the native path; the chain must be unbroken regardless of framework.

5. Token typ discipline (RFC 8725)

Validate typ at every forge verification point — a chain token must be rejected where an access token is expected. Media types: application/vnd.initializ.{platform-bearer,chain-token,workload-credential,mandate}+jwt.

6. SPIRE mode (attested:workload) — when SPIRE ships (Phase 1.3/1.4)

• Consume the X.509-SVID via the Workload API / CSI (the initializ-sdk already refuses cluster mode without a real INITIALIZ_SPIFFE_ID/SVID).
• cnf/x5t#S256-bind the chain token to the X.509-SVID → bind strength attested:workload.
• In k8s_sa mode the chain token stays an unbound bearer (attestation_level = attested:placement), replay-mitigated by actor_workload_id claim checks + the ~60s TTL, and gated per-tool by the PDP bind-strength floor already merged (security-next#42, Decision Add LLM fallback chains, multi-LLM init wizard, and OpenAI OAuth #7). No global switch — forge just stamps attestation_level accurately.

7. Release + rebuild

Cut a forge release including the above so agents bake it (AGENT_FORGE_VERSION); the merged platform features stay inert until deployed agents carry the runtime hooks.

---

Open decision

TTS placement (Decision #3, resolved as cluster-local): does forge mint/re-mint chain tokens in-process, or call a cluster-local token-exchange service? Settle before Phase-2 build.

Related existing issues (cross-link, not duplicates)

• [ASI07] Inbound SPIFFE auth provider — JWT-SVID + X.509-SVID mTLS, validate against SPIRE trust bundle, authorize by SPIFFE ID (K8s) #240 [ASI07] inbound SPIFFE auth — this issue is the outbound propagation + workload-token presentation + PDP/audit field population side.
• [ASI03] Task-scoped short-lived tokens per invocation — close ASI03 #1 #232 [ASI03] task-scoped short-lived tokens — overlaps the per-hop chain-token TTL.
• R10 (governance): delegated identity / on-behalf-of downstream authorization (AARM) #319 / MCP delegated identity: platform-side ID-JAG broker (Forge-side collapses to assertion-forward) #318 delegated identity / ID-JAG broker — L2 delegation vocabulary alignment.

Suggested order

1 (present workload token → flip §19.13 enforce) → 2 (populate PDP/audit fields) → 5 (typ) → 3 (native ChainContext) → 4 (egress-proxy path) → 6 (SPIRE) → 7 (release). Items 1–2 deliver most of the value and are small.

[initializ-mk]

Item 1 (present the per-agent workload token) — implemented in #445.

Forge now sends X-Workload-Token on all five platform-authenticated callouts (MCP platform-token + authorize resolvers, remote session store, admission, PDP), read fresh per-request from INITIALIZ_WORKLOAD_TOKEN_PATH and never cached, gated on WORKLOAD_IDENTITY_MODE=k8s_sa, omitted (not empty) when inactive. This unblocks flipping WORKLOAD_ENTITLEMENT_ENFORCE on. Docs: tenancy.md + environment-variables.md.

Remaining, in the suggested order: 2 (PDP/audit identity fields) → 5 (typ discipline) → 3 (native ChainContext over X-Agent-Chain-Token) → 4 (egress-proxy chain propagation) → 6 (SPIRE attested:workload) → 7 (release). Note on item 2: without item 3's ChainContext most of the new PDP/audit fields (principal_sub, delegation_mode, chain_id/hop, …) would still populate as null — so 2 is best landed either together with 3 or explicitly as 'plumb the columns now, populate as sources land'.

[initializ-mk]

Item 2 (populate agentic-identity fields on PDP + audit) — implemented in #446 (stacked on #445).

Populated now (guard-safe, process-static): actor_agent_id, attestation_level (attested:placement in k8s_sa), delegation_mode = agent_own (forge's real posture — the agent decides tool calls as its own principal). Plumbed but intentionally unpopulated until their sources land: principal_sub/principal_iss (coupled to a delegated mode — leaving them empty under agent_own avoids tripping the phantom-principal guard), actor_workload_id, mandate_id/grant_ref (L2), chain_id/chain_hop (item 3). The del enum + attestation constants match security-next exactly.

One thing for whoever has security-next visibility to confirm on #446: I put the identity fields under caller and chain_id/chain_hop at the PDP request root (per this issue's phrasing) — worth a check against agent_policy_model.go.

Remaining: 5 (typ discipline) → 3 (native ChainContext — also unlocks real population of principal_sub/delegation_mode/chain_id) → 4 (egress-proxy chain) → 6 (SPIRE) → 7 (release).

[initializ-mk]

Item 5 (RFC 8725 typ discipline) — implemented in #447 (independent; off main).

The auth middleware now rejects an inbound bearer whose JWT typ declares a non-access initializ media type (chain-token / workload-credential / mandate) with 401 before the provider chain runs — a single choke point that covers all inbound access-token paths (incl. the delegating http_verifier and opaque static_token, which a per-provider check couldn't). Denylist design: platform-bearer, absent/unknown typ, and non-JWT bearers pass through untouched. Distinct wrong_token_type audit reason + span attribute.

Remaining: 3 (native ChainContext over X-Agent-Chain-Token — also lights up the deferred item-2 fields + adds the positive typ==chain-token verification) → 4 (egress-proxy chain propagation) → 6 (SPIRE) → 7 (release).

Note: items are landing as independent PRs off main (not stacked) — #445 (item 1, merged), #446 (item 2), #447 (item 5).

[initializ-mk]

Cross-repo drift tracking (item 5 / #447). forge's inbound token-typ denylist (forge-core/auth/token_type.go rejectedInboundTokenTypes) must stay in sync with the platform's own ingress guard in api-next helper/tokentype.go (ourNonPlatformTypes / RejectForeignTokenClass). They match today ({chain-token, workload-credential, mandate}, exact-match). There is no shared source of truth across repos, so if api-next adds a fourth non-access media type, forge's denylist must gain it in lockstep — otherwise forge silently keeps accepting that class as an access token. Flagging here as the enforcement-epic tracking home.

[initializ-mk]

Item 3 (native ChainContext) — BLOCKED, paused. Investigated forge-side; the verify + re-mint halves depend on external contracts that don't exist in forge:

1. No chain-token verification contract in forge — no issuer / JWKS / signing key / claim-validation rules to Verify every hop against. (grep for chain-token / X-Agent-Chain / agentic_ctx / RFC 8693 finds only item 5's MediaTypeChainToken constant + unrelated OAuth/MCP token exchange.)
2. Forge never mints a JWT (holds no signing keys — only AWS SigV4 request signing + build-artifact signing exist). So re-mint per hop cannot be in-process; it must call the cluster-local TTS — whose API is this epic's own unsettled open decision (Decision Add Tavily web search integration and Telegram typing indicator #3) and is absent from forge.
3. Depends on item 2 (feat(identity): populate agentic-identity fields on PDP + audit (#444 item 2) #446, open) for the chain_id/chain_hop audit + PDP fields it must populate.

The buildable primitives to mirror exist (WorkflowContext, WorkflowPropagationConfig.AllowedHosts), but a WorkflowContext-style pass-through would violate the spec's verified, not trusted-by-position requirement — so a transport-only scaffold would look like the feature without being the security control.

To unblock: settle Decision #3 (the cluster-local TTS mint/re-mint API) and publish the chain-token verification contract (issuer/JWKS/claim rules), then item 3 can be built against real shapes. Items 4 (egress-proxy chain propagation) and 6 (SPIRE) share the same chain-token dependency and are likewise blocked until then.