Who Is Your AI Agent Logged In As? The Agent Identity Gap

Your invoice-processing agent has your controller's credentials. It can do everything she can do — approve payments, edit vendor records, export the ledger — at 3am, four hundred times an hour. And the audit log says she did it.

That's not a hypothetical failure mode. It's the default configuration in most companies running AI agents in production right now. Not because anyone decided it was a good idea, but because it was the fastest path to a working agent, and nobody revisited it when the second, fifth, and thirteenth agent showed up.

This is the agent identity problem, and it moved from "something to think about" to "something in your next budget cycle" over the past few weeks.

The borrowed-credential default

Here's how it happens. A team builds an agent to handle a real workflow — reconciling invoices, triaging support tickets, updating CRM records after calls. To do the job, the agent needs access to systems. The fastest way to grant that access is to reuse something that already works: a staff member's API key, a shared service account, an OAuth token minted during a one-time integration.

At agent number one, this is a defensible shortcut. The agent does a narrow task, a human watches it closely, and the scope of what could go wrong is small enough to hold in your head.

The problem is that the shortcut has no natural stopping point. Nobody schedules a meeting to decide that agent #6 will also borrow a human's login. It just inherits the pattern.

What breaks at thirteen agents

Salesforce's Agentic Enterprise Index — built on production activity at 400 businesses plus a survey of roughly 5,000 people — found that the average number of agents per organization nearly tripled, from 5 in early 2025 to 13 by April 2026. That's the hinge. Thirteen agents sharing human credentials is a materially different system than one, and four specific things break.

1. Blast radius stops being containable

An agent with a human's credentials has a human's full permission set — not the subset it needs. A ticket-triage agent that inherits an admin token can delete records it was never meant to see. Multiply that across thirteen agents and you no longer have a permission model; you have a collection of over-privileged processes running unattended.

2. Non-repudiation collapses

If an agent acts as a person, your logs record a person acting. You cannot distinguish a decision your controller made from an action her borrowed token executed autonomously. That's not just an audit inconvenience — it destroys your ability to answer the most basic incident question: who or what did this, and who authorized it?

3. Audits become guesswork

Access reviews assume identities map to accountable parties. When agents hide behind human accounts, the review tells you nothing useful about actual system access. Auditors increasingly know to ask, and "it's under Sarah's account" is not an answer that survives follow-up.

4. There's no clean revocation path

Rotate the credential and you break the agent along with the human's access. Disable the agent and you may break unrelated integrations sharing the same token. You've coupled things that should be independently killable — which is exactly the wrong property to have during an incident.

Three forces converged in the last two weeks

What makes this urgent isn't that the architecture is sloppy. It's that three independent tracks — platforms, standards, and law — all landed on agent identity in the same window.

Platform guidance. On August 24, 2026, Google Cloud published agent-security guidance tied to its State of AI Infrastructure report, framing agent security as the top blocker to scaling autonomous workflows. Its recommendations: platform-level governance, task-level provenance, and human-in-the-loop checkpoints. Note what that means — a major infrastructure vendor is saying the constraint on agentic AI is no longer model capability. It's governance.

Protocols and standards. A Fortune analysis republished August 24, 2026 tied together three developments: Google's Agent Payments Protocol (AP2), NIST concept work on agent identity and permissioning, and the AI AGENT Act (S.5051) in Congress. A payments protocol, a standards body, and a piece of legislation independently arriving at the same conclusion — agents need their own credentials — is the pattern that precedes a requirement rather than a recommendation.

Live regulation. EU AI Act Annex III high-risk obligations became enforceable on August 2, 2026, alongside transparency duties requiring disclosure when users interact with AI and machine-readable marking of generative output. If any of your agents touch the EU, you're already inside a live compliance regime — one that assumes you can explain what your systems did and why.

Buyers have moved with it. Enterprise procurement teams are now asking for audit logs, explicit permission boundaries, kill switches, and documented human review before agents touch production systems. If you sell to enterprises, this shows up in your security questionnaire before it shows up in your risk register.

What a real agent authorization layer looks like

The fix isn't a policy document. It's architecture. Seven components, roughly in order of how much they buy you:

• A distinct machine identity per agent. Every agent gets its own credential, tied to its own record, never shared with a human or another agent. This is the foundation; nothing else works without it.
• Scoped, least-privilege permissions. Grant each agent exactly the operations it needs on exactly the resources it touches. Not a role. Not a copy of a person's access.
• Delegated authority with expiry. When an agent acts on a human's behalf, that authority should be explicit, narrow, and time-bounded — a delegation, not an impersonation.
• Task-level provenance. Every action traces back through the task that triggered it to the human who authorized the workflow. This is what turns "the agent did it" into a defensible chain of accountability.
• Spend and rate caps. Hard ceilings on transaction value, call volume, and record modifications. Agents fail fast and at machine speed; the limit needs to be enforced by infrastructure, not by hope.
• A kill switch per agent. One action, taking seconds, that stops a single agent without touching anything else.
• An immutable audit log. Append-only, agent-attributed, queryable by a person who wasn't involved in building the system.

One design constraint matters above all: keep the permission layer independent of the model layer. BenchLM logged 24 confirmed model releases from 18 providers in August 2026 alone. The reasoning engine under your agents will change repeatedly; your identity and permission boundaries shouldn't have to be rebuilt each time. That's a core principle in how we architect agentic AI systems — the authorization layer is infrastructure, not a feature of whichever model is currently best.

Why off-the-shelf agents can't get you there

SaaS agent products run inside the vendor's identity model and log to the vendor's system. That creates three problems you can't engineer around from the outside.

First, you inherit their blast radius. Their permission granularity is your permission granularity, and it was designed for the average customer, not your risk profile. Second, their permissions rarely map cleanly onto your existing IAM and SSO, so you end up maintaining a parallel access model that no one reviews. Third, and most consequential: when a regulator or an enterprise customer asks which human authorized a specific action, you're dependent on whatever your vendor chose to record.

You can't extend an identity model you don't own. For agents that touch money, customer data, or regulated processes, that's the argument for building — and it's a large part of why companies come to us for custom AI software rather than assembling agents from vendor toolkits.

A seven-question audit for the agents you already run

Take these to your engineering lead this week:

• Can you produce a complete list of every agent currently running against production systems?
• Does each one have its own credential, or are any of them sharing?
• For each agent, can you state the exact permissions it holds — and justify every one?
• Can you disable a single agent in under 60 seconds without affecting anything else?
• For any action an agent took last month, can you prove which human authorized the workflow?
• Are there enforced hard caps on spend, volume, and record changes per agent?
• If your model provider changed tomorrow, would your permission boundaries still hold unchanged?

Most organizations fail four or more. That's not a sign of negligence — it's a sign that agent deployment outpaced the identity infrastructure, which is what happens when capability arrives faster than governance. The fix is tractable, but only if you start before the audit, the enterprise deal, or the incident forces it.

Talk to Levels AI

We offer a scoped Agent Identity & Permissions Audit: we map every agent you have running, the credentials each one uses, the real blast radius of each, and a prioritized plan to move to per-agent identity with provable provenance. If you already have agents in production, this is the fastest way to find out how exposed you are.

Levels AI is an Inc. 5000 custom AI development company in Tucson, Arizona, with 100+ AI specialists and 61+ delivered projects. Talk to our team about auditing your agents — or about building the authorization layer before your next thirteen go live.