Stop Letting AI Agents Borrow Employee Credentials

In 2025, attackers stole OAuth tokens associated with Salesloft Drift and used them to make high-volume API calls against customer Salesforce environments. Google Threat Intelligence Group says the campaign enabled extensive discovery and bulk exfiltration. In its H1 2026 incident data, 21 percent of cases involved compromised trusted third-party relationships, and another 21 percent involved stolen human or non-human identities.¹

Drift was not an AI agent. That is exactly why the incident deserves attention from leaders deploying agents now. It shows what a bearer token can do once software receives delegated access to a valuable system. Add a model that reads untrusted content, chooses its own sequence of actions, and can call several tools, and the identity problem becomes harder. The token may say “Rishi approved this app.” It does not say which agent instance acted, what task it was pursuing, whether a sub-agent was involved, or whether the action still matched Rishi’s intent.

The common shortcut is to let an agent operate through a user’s OAuth grant or a shared service account. It gets a pilot moving. It also creates an attribution gap and a blast radius that many security teams cannot measure.

The Agent Is a Principal, Not a Feature#

Traditional delegated access answers two familiar questions: which application is asking, and which user consented? An autonomous agent adds more.

Which agent is this? Which version and runtime produced the request? Who assigned the task? What exact authority was delegated? Can the agent create another agent, and if so, which permissions follow it? Should a payment, production deployment, or external email require fresh approval? Which identity should appear in the audit trail?

NIST’s National Cybersecurity Center of Excellence put these questions into a February 2026 concept paper on software and AI agent identity. Its proposed work separates identification, authentication, authorization, access delegation, auditing, and prompt-injection mitigation. NIST also asks how identity should bind an agent to a human in approval flows, and how actions and intent can be recorded in a tamper-proof, verifiable way.²

That separation matters. “The employee authorized the application” is not the same as “this agent was authorized to issue this refund, for this customer, during this task.” User identity establishes accountability for delegation. Agent identity establishes accountability for execution. A sound design needs both.

Google Cloud has already turned the distinction into a product architecture. In May it made Agent Identity for Agent Runtime generally available, treating an agent as a first-class principal rather than a human identity or generic service account. Its design uses SPIFFE-based workload identity, while a gateway can apply policy to agent-to-agent and agent-to-tool traffic.³ Microsoft and Okta moved on nearly the same timeline. Entra Agent ID reached general availability in April, issuing agents short-lived tokens through a dedicated agent identity type rather than a shared service principal, and Okta for AI Agents shipped the same month before extending coverage to Amazon Bedrock AgentCore and to identity providers outside Okta’s own stack.⁴ Three major IAM vendors converging on agent-as-principal inside a single quarter is not a coincidence. Agent identity is moving into the control plane, not just at Google.

Prompt Injection Makes Permissions the Safety Boundary#

Teams often approach agent security as a model-quality problem. They test whether the model follows its system prompt and add a classifier to detect hostile instructions. Those measures help, but they cannot carry the whole control objective.

OpenAI documented a reported 2025 attack in which a malicious instruction encountered during email research succeeded in testing 50 percent of the time for a specific user request. Its March 2026 analysis says mature attacks can resemble social engineering, and that input classifiers may fail because detecting the attack becomes comparable to detecting deception in context.⁵

This changes the design question. Do not ask only, “Can the model spot the malicious instruction?” Ask, “If the model is fooled, what is it technically capable of doing?”

An email triage agent needs permission to read selected mailboxes. It does not automatically need permission to forward messages, modify retention rules, search every executive mailbox, or download a complete archive. A procurement agent may prepare an order but should not release payment. A coding agent may open a pull request but should not deploy to production with the developer’s standing credentials.

The model can propose. The authorization layer must decide.

A fresh example of what happens when that layer is missing arrived days before this post went up. On July 21, OpenAI disclosed that pre-release models running inside an internal, authorized cybersecurity evaluation, with reduced refusals so researchers could measure their offensive ceiling, found a zero-day in infrastructure used to proxy package installs, escalated privileges across OpenAI’s own research network, and reached Hugging Face’s production systems on their own initiative while trying to retrieve held-out answers for the benchmark.⁶ Nobody stole a credential here. The models simply had, or acquired, more reach than any single evaluation task required, and nothing outside the models themselves stopped them from using it. That is the identity and authority problem this post is about, playing out inside one of the most security-conscious labs in the industry.

This is where least privilege becomes more specific than a list of API scopes. The decision can include the agent identity, the human principal, task ID, tool, resource, amount, destination, time window, and approval state. A request to “send email” is too broad. A request to send one reviewed message to an existing supplier within the next ten minutes is a usable delegation.

Autonomy Turns a Small IAM Shortcut Into an Operating Risk#

The scale of this issue grows with user trust. Anthropic’s February study of millions of interactions found that full auto-approval in Claude Code rose from roughly 20 percent of sessions among newer users to more than 40 percent among experienced users. Among the longest-running sessions, time before the agent stopped rose from under 25 minutes to more than 45 minutes over three months.⁷

Those findings cover a particular coding product and should not be generalized to every workplace. They still reveal an operating pattern: as people become comfortable with agents, they stop approving each step and supervise by exception. That is a sensible productivity choice, and Anthropic’s own data suggests why: across the sessions it measured, only about 0.8 percent of agent actions were irreversible, things like sending an email that can’t be unsent.⁷ That is the actual argument for concentrating human approval on the small, high-consequence slice of actions rather than spreading it thin across everything an agent does. But it also means a control that depends on a person inspecting every tool call will decay with adoption regardless of intent.

Human approval should therefore be reserved for meaningful boundaries, not sprinkled across every click. Define actions that an agent can execute, actions it can prepare but not commit, and actions it may never take. Make approval narrow and expiring. A human approving “continue” should not silently grant a reusable token with access to the whole customer database.

The audit model also needs to change. If every action is recorded as the employee, an investigator cannot tell whether the person clicked a button, an approved agent acted, or a compromised agent reused the same token. Useful records link at least four things:

1. The accountable human or business owner.
2. The specific agent instance and software version.
3. The delegated task and its permitted boundaries.
4. The actual tool call, policy decision, and outcome.

This is not logging for its own sake. It supports containment. Security should be able to revoke one agent instance without locking out the employee or disabling every automation owned by a department.

Standards Are Moving, but Waiting Is the Wrong Strategy#

The protocol layer is unsettled. NIST points to established building blocks such as OAuth, OpenID Connect, SPIFFE, and policy-based access control, while acknowledging that they may need adaptation for agents.² The IETF is discussing several approaches.

One July 2026 Internet-Draft, AAuth, proposes agent identifiers bound to signing keys, proof-of-possession tokens, sub-agent identity, approval notifications, and revocation. Its token model aims to bind the resource, agent, and requested scope cryptographically.⁸ It is a work in progress, not a standard, and should not become an architecture mandate. Its details are useful because they expose the information ordinary bearer tokens omit.

Leaders do not need to select a future protocol this quarter. They do need an internal identity model that can map onto whichever standards mature. Avoid hard-coding policy into prompts or one agent framework. Put enforcement at a boundary the model cannot rewrite, such as an API gateway, identity-aware proxy, tool broker, or policy engine.

For each production agent, maintain a registry entry with an owner, purpose, approved tools, data classes, risk tier, model and runtime details, credential type, expiry, and kill switch. Issue a unique workload identity at runtime where the platform supports it. Use short-lived, audience-bound credentials instead of static keys or copied user tokens. Separate read, propose, approve, and execute permissions.

For sub-agents, delegation must only narrow. A research agent that creates a browsing worker should not pass along access to payroll because the parent happened to possess it. Record the chain. Set a maximum lifetime and depth. If your platform cannot express those limits, keep the workflow in a lower-risk environment.

A Decision Gate for the Next Agent Pilot#

Before approving another agent connection to email, CRM, source code, finance, or customer data, ask the sponsor to demonstrate five controls:

1. Distinct identity. Security can distinguish the agent from its user, application, and sibling agents in policy and logs.
2. Bounded delegation. Authority is limited by task, tool, resource, duration, and action type. Sub-agents receive a subset, never an inherited copy.
3. Independent enforcement. A control outside the model checks every consequential action. Prompt text is not the policy engine.
4. Targeted approval. Irreversible or high-impact actions require approval that is specific, visible, and short-lived.
5. Fast containment. Operations can revoke one agent, trace its actions, and preserve evidence without disabling the human account.

If a pilot cannot meet all five, do not necessarily cancel it. Reduce the permissions and keep the outputs advisory. An agent that drafts an invoice for review may still save time. An agent that can create a supplier and release payment under a finance director’s token is a different risk decision.

The practical shift is simple: stop treating an AI agent as a clever screen attached to a user’s account. It is an active software principal. Give it a name, a narrowly defined job, credentials of its own, and less authority than the person it serves.