Agents with broad API keys can act on decisions without clear user or agent identity, including destructive actions such as dropping a production database.
2
OAuth token exchange can mint a short-lived credential for one specific tool call, after policy checks the user, agent, resource, and requested access.
3
Human approval does not override authorization policy, so an operator without the required role cannot approve a restricted agent action.
Summary
Kim Maida shows how an incident-management agent can misuse a kitchen-sink API key while handling routine night-shift tickets. In the demo, the agent drops a production Postgres database because a runbook says to delete it and restore from backup, then escalates the incident without checking whether a backup exists. Maida traces the agentic execution path from user prompt to model, runtime, MCP client, MCP server, and resource API. Her proposed control uses OAuth 2.0 token exchange, defined in RFC 8693. The user first delegates a subset of access to the agent. Before each tool call, the runtime asks a security token service for a narrowly scoped, short-lived token. Policy evaluates the request before the token is minted. The demo then blocks the database drop before any credential exists, and rejects a human approval because the operator lacks the required role. The approach is presented for CLIs, custom agents, MCP servers, gateways, and OAuth identity providers.
A broad API key lets a night-shift agent make destructive decisions
Maida's incident agent reads incoming tickets and uses API keys to inspect systems and take action. It handles a failed backup power supply by escalating it, renews an expiring TLS certificate, and then reaches the dangerous ticket: the billing database is broken and payments are failing. The documented recovery says to delete the database and restore it from backup. The agent has a Postgres connection string, so it drops the database and escalates the ticket without checking whether a backup ran. The same broad credential can also take production offline and scale infrastructure, including actions that incur spend.
Unrestricted agent access creates problems even when a person is watching
Maida calls these agents overprivileged because they can act freely on their own decisions. An agent can begin writing changes after being asked only to read a project, even under supervision. Unsupervised operation makes the risk greater because agents try to complete the task with every permission available to them. Human approval alone does not solve this. Operators can be tired or affected by consent fatigue, and some agents run autonomously. Access control therefore has to be applied inside the agent's execution path rather than added as a blanket approval step.
The execution path provides several places to enforce access control
The path starts with a user submitting a prompt to a runtime. The runtime calls the model, which proposes tool calls. An MCP client dispatches those calls to an MCP server, and the server calls the resource API. Results travel back through the MCP client and runtime until the model returns an answer. Maida says the runtime can be a CLI such as Claude Code, an SDK such as AI SDK or provider agent SDKs, or an application such as Cursor or Codex. A security control can sit between these components and inspect the requested action before a downstream resource receives a credential.
Token exchange creates an identity chain and narrows delegated access
Maida uses OAuth 2.0 token exchange from RFC 8693. The user signs in through an authorization server, then consents to delegate only a subset of their permissions to the agent. The resulting subject token identifies the user and carries the user's access level. An OAuth client, such as an MCP gateway, custom agent app, or CLI wrapper, passes that subject token to a security token service along with the requested tool action. The service can identify the agent, the user on whose behalf it acts, and the user's delegated access before deciding whether to issue a downstream token.
Each tool call receives a short-lived credential for its target
When the model proposes a tool call, the runtime authenticates to the security token service with app credentials or workload identity. It requests access to the MCP server for that one call. Governance policy evaluates who is asking, which resource is involved, and what access is requested. If approved, the service issues a token whose audience names the target MCP server. Maida says the token should be short-lived, often expiring within a few minutes, and ephemeral, so it is never stored. The MCP server validates it, calls the resource, and discards the token after the call.
Policy can prevent a credential from existing at all
In the second demo, the agent signs in and the audit log shows the user, agent, MCP server, and downstream resource. Certificate renewal requests only the scope needed to renew the certificate. When the agent reaches the billing database ticket, policy sees that agents are not allowed to drop databases. The security token service evaluates the request before minting the credential, so the prohibited database-drop token never exists. Maida explains that this leaves nothing to leak, replay, or steal. The control blocks the requested capability at the point where the agent asks for it, rather than trying to revoke a broad credential afterward.
Human approval remains subject to the same authorization policy
Some actions can require a human decision. In the demo, the agent asks Maida to approve taking production offline. She approves, but another policy requires the human operator to have a specific role, and she does not have it. The action is rejected despite her approval. This prevents an operator from repeatedly clicking through prompts because of fatigue. A scaling action follows a different path: Maida has permission to perform it, so her approval and the policy check both succeed. The design gives human approval a real access boundary instead of treating any click as sufficient authorization.
The approach is intended to work across existing agent and OAuth systems
Maida says token exchange can support off-the-shelf and custom agents, CLI tools, third-party and proprietary MCP servers, MCP gateways, and agent-to-agent systems. It can work with any OAuth identity provider. She presents open standards as a way to connect current systems with technologies that appear later, rather than requiring a separate security design for every agent framework. In the question period, she also says token exchange is not a new protocol. Teams can begin with scopes already defined by their resource server, then add or pass through additional scopes for tool calls in a custom MCP server.
"So, this one was the one where it wants to restart prod. So there are things that agents should probably be allowed to do and things that maybe they shouldn't be allowed to do and then there's some kind of you know something in between, right?"14:20
Who should watch
You are giving coding or operations agents API keys and need to understand what those credentials allow during unattended runs.
Your agent uses MCP servers or downstream APIs, but your audit logs cannot identify the user, agent, and requested action behind each call.
You rely on human approval prompts and want authorization policy to constrain approvals when operators are tired or lack the required role.
