An agent with private data, untrusted content, and external service access can turn ordinary tickets into destructive production actions.
2
Standing API keys and broad grants hide which user or agent acted and give the agent more authority than a single task requires.
3
Token exchange, task-scoped policy, and short-lived delegated credentials can preserve useful agent actions while blocking unauthorized database, server, and data access.
Summary
Kim Maida demonstrates an on-call triage agent that can read tickets, query customer data, renew certificates, delete a billing database, restart production, and scale a service. The agent uses standing API keys and an administrator database credential, so it can take actions that individual tickets do not justify. Maida calls the combination of private data, untrusted content, and external communication the lethal trifecta. Removing any capability would reduce the agent's usefulness, so she proposes controlling access at runtime. Her design passes the user's identity through the agent and MCP server, sends a subject token to a security token service, and requests short-lived credentials for each tool call. A second demo blocks customer data and database deletion, permits certificate renewal, and refuses a server restart even after approval because the user lacks the required role. Scaling succeeds because the user's role allows it. Maida also discusses intent-based authorization as Keycard's proposal, separate from the task-based policy demo.
A broad on-call agent can turn routine tickets into destructive production actions
The demo agent reads incident tickets and can call a cloud hosting API, a customer data warehouse, and a billing database. It sends customer rows and personally identifiable information to the morning team, renews a TLS certificate, drops and restores a billing database with an admin password, restarts a production server, and scales a service from four pods to 40. Scaling adds a charge of $420 per hour. The agent cannot directly verify whether the database recovery worked, so it tells the morning team to check it.
Private data, untrusted content, and external tools create the lethal trifecta
Maida describes three capabilities that make agents useful and dangerous together. The agent can access private data such as a customer warehouse and billing database. It reads untrusted material, including user-submitted tickets, reports from other agents, and documented processes. It can communicate externally through third-party APIs and SaaS services. Since agents try to complete their tasks with the powers they have, a malicious or misleading ticket can influence actions across those boundaries.
Human approval does not fix an overprivileged credential
Maida says incidents happen because humans give agents more access than they need. A human-in-the-loop approval can shift access control to a user who is tired or making a mistake, and autonomous agents may have no person available to approve anything. OAuth grants access before a particular task exists, so a broad grant creates standing access while a narrow grant makes the agent less capable. MCP gateways enforce policy per request but can still hold standing credentials, and sandboxes limit processes without deciding what the process is authorized to do outside them.
Token exchange carries the user's identity into the agent execution path
Token exchange extends OAuth 2 and lets an authorization server issue tokens that identify the user and a subset of the user's permissions. The authenticated user submits a prompt to the runtime, which calls the model. Proposed tool calls travel through the MCP client and MCP server before reaching downstream resources. The user's token becomes a subject token, identifying who the agent acts for. This gives the system both the user's identity and the access the user delegated.
The security token service evaluates each requested tool call
The runtime authenticates with a security token service using app credentials or workload identity. It sends the subject token and asks for access to the MCP server for one tool call. Policy evaluates the requested resource, the agent identity, and the user's identity. The MCP server can exchange that token again for a downstream resource token. Each token keeps the user subject and extends the delegation chain, so logs can show who acted, which agent performed the exchange, and what resource was called.
Intent-based authorization narrows a mission before the agent acts
Maida presents intent-based authorization as Keycard's proposal rather than a finalized standard. The agent proposes a mission with a goal, allowed actions, and limits. For example, triaging incident 2294 can allow reading that ticket and summarizing or escalating it, while blocking other tickets and services. A request to remediate a usage spike can allow one scale action and no other tools. The user may review and approve the mission, after which tool calls carry a mission ID that the gateway checks against the security token service policy.
Ephemeral credentials make delegation visible across the request chain
After policy approves a request, the security token service issues an access token for the MCP server and includes both the user subject and the agent that performed the exchange. The token should expire within minutes and should never be stored. If the MCP server needs a downstream resource, it requests another token scoped to that tool call. The resource validates the token and authorizes the request. The MCP server discards the token after the call, and the delegation chain remains visible in the audit trail.
Task-based policy blocks actions that approval alone cannot authorize
In the second demo, the agent can read the billing anomaly but cannot receive a credential for customer data because customer PII does not belong in the agent or incident ticket context. Certificate renewal is allowed. Database deletion is denied because policy forbids an agent from dropping a production database. The agent asks for approval before restarting the main server, but the security token service still refuses because Maida's user role cannot authorize that action. Scaling succeeds after approval because her role has the required authority.
