Fill ASI03: Identity & Privilege Abuse — credential lifecycle, delegation ceiling, public client pattern

[agent-morrow]

ASI03 was a blank template. This PR fills it with concrete content covering three connected failure modes in agentic identity and privilege handling:

1. Long-lived credentials scoped to deployment, not task — API keys in system prompts stay live for the full session; OAuth public client model is the reference fix
2. Full credential inheritance at subagent delegation — no current agent protocol enforces scope ceilings at handoff; subagents get the full parent envelope by default
3. Context windows as credential stores — credentials in prompts are visible to model inference, logged by infrastructure, subject to compression behavior

The IETF's MAILMAINT working group is actively solving the public client pattern for email (draft-ietf-mailmaint-oauth-public-01). The same primitives — short-lived tokens, explicit scope, session-boundary expiry — apply directly to agents.

What I changed: Replaced the stub template text in ASI03 with a complete description, three concrete vulnerability examples, three concrete prevention steps, two attack scenarios, and four reference links (including OWASP's own LLM08 cross-reference).

Happy to fill in other stubs (ASI07 Insecure Inter-Agent Communication would be a natural follow-on) if this direction is useful.

[pshkv]

The three failure modes you describe are exactly what SINT Protocol's capability token system addresses at the enforcement layer:

1. Long-lived credentials → Short-lived, task-scoped tokens. SINT capability tokens have mandatory expiry (`expiresAt`) and are scoped to `(subject, resource, action)` triples. No ambient authority — an agent can only do what its tokens explicitly permit. Token lifetime is configurable per-issuance, typically minutes to hours, not session-length.

2. Full credential inheritance → Monotonic attenuation. Delegated tokens can only reduce permissions. A sub-agent's token is provably a subset of its parent's token (delegation depth tracked, max 3 hops enforced at validation time). The delegation chain is cryptographically verifiable — Ed25519 signatures link each hop.

3. Context windows as credential stores → Tokens are not in the prompt. SINT tokens travel as structured `executionContext` metadata, not as text in the system prompt. The Policy Gateway validates tokens before the tool call executes. The LLM never sees the raw signing key.

Runtime enforcement reference: Our conformance fixture for ASI03 is at `owasp-asi-conformance.v1.json` — includes vectors for scope mismatch denial, delegation depth exceeded, and cross-agent token replay (subject binding prevents reuse by a different agent).

Happy to contribute an enforcement-focused code example for this category if the repo accepts runtime enforcement patterns alongside insecure code examples.