Your Agent Is a Lethal Trifecta (and What to Do About It)#

Kim Maida (Keycard, Founding GTM Engineer)

• Why: A working, standards-based answer to the overprivileged-agent problem, demonstrated before/after on the same incident queue — the OAuth token-exchange machinery will be familiar territory for anyone who has built delegated access in cloud platforms.
• What: The demo: an on-call agent with static API keys and an admin connection string resolves six tickets by copying customer PII into reports, dropping and restoring a production database, restarting a server (production offline), and scaling 4→40 pods at a demonstrated $420/hour. The fix is not human-in-the-loop (consent-fatigued users just approve) and not narrower grants (OAuth grants issued before any task exists become standing access). Instead: RFC 8693 OAuth token exchange at every call — the user's token is the subject token, the runtime authenticates to a security token service, and the STS evaluates user + agent + resource + requested permission together before minting a minutes-lived, call-scoped token, discarded after use, with the delegation chain preserved for audit.
• How: The re-run shows the mechanism working with the same imperfect agent behavior: the warehouse query is refused (PII doesn't belong in the incident workflow) and the agent escalates instead; the DB drop is refused outright; a human approval of a server restart still fails because her user lacks the role — approval cannot amplify permission; scaling succeeds after approval because her role authorizes it. Also previews intent-based authorization (a proposed mission stating goal, allowed actions, and limits, checked per tool call — explicitly an evolving proposal, not a finalized standard).
• Where applicable: Token exchange is an open 2020 standard interoperating with existing identity providers, gateways, and MCP servers — broadly applicable, not vendor-locked (though the demo is Keycard's product). The demo uses task-based policy governance; IBA is future work.