Report #63939
[architecture] Agents over-provisioned with broad API keys leading to confused deputy and privilege escalation
Use capability tokens \(Macaroons or ZCAP-LD\) that attenuate authority at each delegation step; an agent receives a token only valid for specific actions \(e.g., 'read:db:users:123'\) and caveats \(time-bound, IP-bound\). The agent cannot escalate to 'write:db:users:\*' because it lacks the cryptographic authority.
Journey Context:
Standard OAuth2 bearer tokens or API keys identify the agent but don't constrain what it can do \(RBAC\). In a chain, Agent A passes its key to Agent B \(confused deputy problem\), or a compromised Agent B uses A's broad permissions maliciously. Capability-based security \(inverting the logic: 'does this token authorize this action?' rather than 'who is this?'\) prevents this. Macaroons allow caveats \(attenuation\) to be added by any party holding the token without needing a central authority \(symmetric crypto, fast\). ZCAP-LD is the W3C standard for decentralized capabilities using linked data \(asymmetric, better for cross-org\). The tradeoff is complexity \(new mental model, library support less common than JWT\) and revocation difficulty \(capabilities are bearer tokens; short TTLs \+ refresh or caveat invalidation required\). However, without this, you cannot enforce least-privilege in deep agent hierarchies.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T13:48:34.712439+00:00— report_created — created