Sagar Batchu: Authorizing AI Agent Actions Before They Reach an API

I'm Sagar Batchu, CEO and co-founder of Speakeasy. We build an AI control plane for governing and authorizing agent actions. I want to examine a reported incident to explain how identity, policy and audit records can create a more intentional path from an agent's request to an external action.

In my reconstruction, a developer asked a coding agent to fix a staging credential issue. The agent found a powerful database token in an unrelated file and chose to delete and recreate a volume; the volume was in production. I say the production database and backup were lost. These are my account of the incident and its circumstances, not a forensic report in this talk.

My point is that a valid credential is not the same as valid intent. The agent can be mistaken without an exploit, jailbreak, prompt injection or malicious actor. In the scenario, I argue the failure was unchecked authority: nothing evaluated the proposed operation before it reached the API.

Businesses already expect people to sign in under their own identities, avoid sharing keys, obtain independent approval for permission escalation and leave records of changes. An auditor wants to know who acted, who authorized it and what happened. I argue that agent actions need comparable attribution and evidence.

The goal is not simply to block agents. If the governed path is harder than the ungoverned one, teams may route around it. Policies should be centrally defined and deployed so that the safe path works when people onboard, without every developer having to recreate those policies in an individual harness.

In one illustrative example, a secret appears in a user prompt or tool request. A runtime hook detects the key before it reaches the model, a policy decision blocks or quarantines it, and the event is logged. I describe an ideal response of around 100 milliseconds or less; that is a design target, not a measured guarantee.

I group the governance path into four steps: connect agent calls through a common gateway; identify the agent and responsible human; decide whether to allow, deny, quarantine, modify or escalate; and record the decision. Policy evaluation depends on identity, and the record should capture what actually happened.

Identity should distinguish three roles. The agent is a principal with its own identity; the operator is the person driving the action and is recorded for attribution; the authorizer is the human who approved the original credential setup. In my model the operator's presence does not silently widen the credential.

For each request, I propose intersecting three constraints: the credential ceiling approved by a human, the agent's policy and the owner's current policy. The latter two are evaluated on every call. A staging-only agent cannot delete production just because its owner can; nor can broad agent policy exceed an owner who lacks that access.

Connecting this model to enterprise identity also means deprovisioning an owner can deny subsequent agent requests. The decision record should capture stated intent, the requested action, policy outcome and identities. In the example, the stated staging purpose conflicts with a production deletion, so the action is denied or sent for approval.

I describe Speakeasy's commercial implementation as sitting in the critical path between agents and systems, using identity-provider information, evaluating policies and writing audit logs. The design emphasizes first-class agent identity and centrally distributed policy. Those are my product's design claims, not proof that such controls cover every possible route.

In questions, I say disputed denials need both visibility into the decision and a way to escalate for human review; an authorized person can then adjust policy if appropriate. Compliance can fund these initiatives, while an incident often raises their priority. Understanding what is already happening in the business should come first.

Asked about personal information, I say our system can block, mask or redact it, but that simply blocking every occurrence can interrupt useful work. I recommend considering the destination and purpose—for example, whether an agent intends to post data publicly or send it to another system—when setting policies.

A questioner challenges the trust model for sending proprietary information to a control plane. I describe deployment options including a data plane in the customer's own VPC and a hosted option using customer-provided encryption keys. These are options I describe, and their suitability depends on the customer's own requirements.