A Valid Key Let an AI Agent Delete Production - Sagar Batchu, Speakeasy

A developer asked a coding agent to fix a credential problem in staging. The agent read through the workspace and found an infrastructure token in an unrelated file. It had full access. The agent decided to delete the database volume and recreate it. The volume it could reach belonged to production.

In Batchu’s reconstruction of the April incident, the database and its backup lived inside the same network boundary. Both were gone in about ten seconds. The API accepted the token, and nothing checked whether the target of the delete matched the environment the developer had asked the agent to repair. The call had no named actor, approval, or usable record of how the decision was made.

There was no jailbreak, prompt injection, exploit, or malicious participant to detect. The agent made a bad inference during an ordinary task. What turned that inference into an outage was the authority of a key the agent happened to find.

Batchu cited figures putting agent adoption at 82% of organizations and AI governance policy adoption at 32%. He also cited an estimated average cost of about $5 million for a breach involving shadow AI. The figures describe different things. Simply having a governance policy, for example, says little about whether anything checks a specific API call.

For employees, the operating rules are familiar. People sign in as themselves, keep credentials separate, and need someone else to approve an increase in their permissions. Systems keep a history of changes. An auditor investigating an agent’s actions needs to answer the same questions an employee’s actions would raise. Who acted? Who allowed it? Where is the record?

Batchu illustrated enforcement with a policy covering secrets in user prompts and tool requests. In his example, the company writes the policy centrally and distributes it to the developer’s laptop at onboarding. The developer can start using an agent without having to recreate the rule in each harness. Batchu wants that governed route to be the easiest one to use, since a cumbersome block gives teams a reason to work around it.

Suppose a developer pastes an AWS key into a prompt, or another agent supplies it. A hook in the harness runtime intercepts the prompt before it reaches the model. A detector matches the key, the control layer evaluates the policy, and the prescribed response is to block or quarantine. In the illustrated case, the runtime blocks the prompt and logs the interception. The secret stays on the machine, and the developer can try again.

Batchu’s target for interception and decision was 100 milliseconds or less. He presented that as a design goal for keeping a check in the normal flow of work, rather than a measured latency result.

For external tool calls, Batchu organizes the control layer around four steps. Connect through a common entry point, such as an MCP gateway. Inspect the request and resolve the identity behind it. Decide whether to allow it, deny it, quarantine it, or escalate it to a human. Record that decision before the action proceeds. Depending on the policy, a warning or a modification to the request can also be appropriate.

Identity resolution has to distinguish three roles that a shared login collapses. The agent is a principal with its own identity. The operator is the person interacting with it on this request. Recording the operator establishes attribution and grants no extra access. The authorizer is the human who approved the original credential setup, an association that stays fixed for the credential’s lifetime. Batchu contrasted that record with a background job running under an anonymous system role or a Slack assistant borrowing a user’s login. He said Speakeasy itself had relied on borrowed identities until earlier that year.

The effective permission is the intersection of three sets. R is the ceiling the human set when issuing the credential. A is the agent’s own policy, which excludes admin privileges and human-only scopes. O is the live policy of the owner accountable for the agent. The request must fit inside all three. The control layer reads A and O on every call, so removing a permission takes effect on the next request.

Consider the production delete again. An owner with production rights can run a staging-only agent, and the agent’s policy will stop the delete. Give the agent a broader policy and the owner’s lack of production rights will still stop it. If the owner leaves and the enterprise identity provider deprovisions the account, subsequent requests from that owner’s agents are denied.

In the governed replay, the agent states that it intends to act on staging, while the requested operation targets production. For a non-read action, Batchu’s design evaluates both the stated intent and the actual request. A denial now leaves evidence of the discrepancy, the actor, and the policy decision. Batchu described cryptographically binding the record to the agent’s identity so an auditor can verify its attribution.

Speakeasy puts its control plane between agents and the systems they access. An enterprise identity provider such as Okta supplies the identity baseline. The control plane evaluates policy and writes the audit log for calls that pass through it, including denials. Its position in the request path matters because it can record the call it actually intercepted, independently of the agent’s account of what it did. Speakeasy uses mobile device management to distribute the controls so they are present when a developer first opens an agent.

What happens when someone disagrees with a denial? Batchu starts with the decision record. Even the reverse dispute, where someone suspects an agent was wrongly allowed into a CRM, is difficult to resolve without evidence of the access decision. With a record, a user can escalate the case to a human who can decide whether to let the request through. If the rule itself is wrong, the company can update it. Batchu said compliance often supplies the budget for these controls and an incident raises their priority, but companies first need visibility into what agents already do.

That visibility creates its own design problem. Batchu said Speakeasy supports blocking, masking, and redacting personally identifiable information (PII). In his experience, businesses discover so much PII in ordinary agent traffic that blanket blocking could bring work to a halt. A more selective policy considers where the information is going. Posting it in a public Slack channel, sending it by email, and passing it to another system in a tool call are distinct decisions.

An audience member pressed on who gets custody of the data an investigator might later need. Batchu described a data plane that runs in the customer’s own virtual private cloud so the data stays there. He said the more common choice among Speakeasy customers is to bring their own encryption keys. Customers can also review findings about detected PII without viewing the underlying sensitive values.