Skip to content
Pyrana
For AI and data leaders
Agent identity
Agent sprawl

Twelve agents, twelve permission models

Agent sprawl is an identity problem before it is a coordination problem. Every vertical tool arrives with its own identity model, permission semantics, and audit format. Here is what governed agent identity looks like, and an inventory exercise for this quarter.

Eric Tarnowski
September 9, 2026
6 min read

Your company runs about a dozen agents. I can say that without knowing your company, because Salesforce surveyed 1,050 IT leaders and got an average of 12 (Salesforce, 2026 Connectivity Benchmark, February 2026). One came bundled with the CRM. One came with the service desk. Two were built by finance in a low-code tool. A few came out of a platform pilot. Each has its own answer to the question "who are you, and what are you allowed to touch?"

Agent sprawl gets discussed as a coordination problem: agents that do not share context or hand off work. I think it is an identity problem first, and the coordination problem follows from it.

What every new agent brings with it

When a vertical tool arrives with an agent inside, the agent comes with four things you did not order.

It brings its own identity model. Maybe it acts as a service account. Maybe it impersonates whoever clicked. Maybe it has a vendor-side identity that maps to nothing in your directory.

It brings its own permission semantics. "Reviewer" in one tool means read-only. In another it means approve. In a third the concept does not exist, and the agent can do whatever the connector's API key can do.

It brings its own audit format. Some log to their own console. Some emit events you can export. Some record the prompt and the answer and nothing about what was called in between.

And it brings its own storage: memory, transcripts, retrieved documents, cached copies of your data, held wherever the vendor holds them.

Multiply by twelve. Half of those agents "operate in isolated silos," according to the same Salesforce report, and only 54 percent of organizations have a centralized governance framework over any of it. Isolation is the natural result of twelve identity models that cannot talk to each other. You cannot hand work from an agent that thinks in service accounts to one that thinks in delegated user tokens without someone writing glue, and the glue is governed by neither.

How the access gets out of hand

The security numbers are worse than the coordination numbers, and I think they follow directly.

Okta asked 306 CISOs and security executives about their agents. Forty-seven percent said they could identify every AI agent in their environment. Forty-six percent could control what those agents access. Forty-five percent could say what an individual agent is permitted to do. Twenty-one percent rely on shared credentials or broad-permission service accounts for agent access (Okta, Global CISO Insights 2026, July 2026).

Teleport surveyed 205 infrastructure and security leaders and found that 70 percent say AI systems have more access than a human in the same role. Organizations with over-privileged AI reported a 76 percent incident rate. Those enforcing least privilege reported 17 percent (Teleport, The 2026 State of AI in Enterprise Infrastructure Security, February 2026).

Nobody decides to give an agent more access than a person. It happens the way it happens with contractors. The agent has to work for the demo on Thursday. Scoping a least-privilege identity takes a week and a ticket to the identity team. The service account already exists and already has the permissions. So the agent gets the service account, the demo works, and the audit trail from that day forward says svc-integration-02 did it. It cannot say which person asked.

IBM's June study found that 70 percent of technology executives say teams across the business are deploying faster than IT can track (IBM Institute for Business Value, June 2026). At that rate the borrowed service account is never revisited. It becomes the permanent design.

What the good version looks like

Forrester's advice is the right starting point: "Treat every agent as a governed identity. Give it unique credentials, least privilege, full logging, and a named owner who manages its lifecycle" (Forrester, June 3, 2026). I would add five requirements that turn that sentence into an architecture, whichever vendor you use.

One admission path. Every way into an application (a screen, a chat, an API, a tool call from another agent, a schedule) goes through the same check before anything runs. If the API has one check and the chat has another, they will drift.

One permission model shared with people. The agent's grant is expressed in the same terms as the controller's grant. If it is not, you cannot answer "can this agent do anything Maria cannot?"

Per-agent credentials, scoped per system. An agent that reads one SharePoint site gets a credential for that site. A different agent for a different site gets a different credential. Neither gets the tenant-wide app registration.

Child calls never exceed the parent. When an agent delegates to a subagent or calls a tool, the callee's authority is a subset of the caller's. A policy change after the parent started can still deny a later child.

Non-disclosure. When a caller is not allowed to see something, it is absent from the results. A "permission denied" on a named resource tells the caller the resource exists.

How we handle it

At Pyrana every Agentic App has five doors: the App UI, chat, the API, MCP for other agents, and schedules or events. Every door passes one admission check: who is calling, under what authority, on which data, with what approval. It fails closed. The audit record is written before anything runs. This is built and merged. Making App admission the sole authoritative path is a per-installation cutover step, so I describe it as what the platform does rather than as the default everywhere.

Identity survives the door. A person arrives via SSO (Entra ID or OAuth). A service arrives via OAuth client credentials. An agent acting for a person carries a delegated token that names both. A workflow runs as its own principal. Nothing in the chain is flattened into a shared account.

Agents hold their own identity and credentials, inside the platform and in the systems they touch. One agent has a credential for SharePoint site A. Another has a credential for site B. The agent that reconciles vendor invoices does not hold the credential that reads the board packet.

Permission is one correlated grant. An access profile ties what a caller may do to which slice of data. "Reviewer in Business Unit A" is one grant, rather than a role from one place and a scope from another that happen to combine. Enforcement is layered: tenant isolation with row-level security in Postgres, OpenFGA relationship checks, App profiles and scopes, operation policy, resource authorization, approval policy, and narrowed short-lived tokens for client extensions. Unauthorized things are absent from results. These are live.

Here is what it looks like on a project board one of our clients runs. Three callers act on the same operation, project.stage.transition, in one day. At 9:14 a.m. a manager drags a card from "In review" to "Done" in the App UI. At 11:02 a.m. a colleague types "move Atlas to Done" into chat, and the agent proposes the same operation under a token that names the colleague and the agent. At 2:00 a.m. the next morning a nightly workflow promotes projects that have sat in "In review" for more than 14 days, running as its own principal. All three pass the same admission, hit the same domain transaction inside the client's extension, and produce three AppExecution records with the same operation and the same policy. The actor field differs: a person, a person via an agent, a workflow. Nobody borrowed anyone's authority, and the record can prove it.

An inventory exercise for this quarter

You cannot govern twelve identity models. You can inventory them, and the inventory usually makes the next decision for you. For every agent in production, fill in one row.

  • Which identity does it run as, in your directory? A named agent identity, a person's delegated token, a shared service account, or "unknown."
  • Which credentials does it hold, in which systems, and who rotated them last?
  • Can you write down what it is permitted to do in the same terms you use for a person's role?
  • What did it do last Tuesday, and does the record name the person who asked?
  • Who owns it, and would that person know if it stopped?

Count the rows with "shared service account" or "unknown" in the first column. That number is your agent sprawl. Then pick the one process where two of those agents need to hand work to each other, and rebuild it once, on one admission path, with real identities in the record. The second process is cheaper than the first.

Sources

Continue the Conversation

Building production-grade agentic AI requires context, orchestration, and human-in-the-loop design. We'd love to show you how Pyrana delivers it end to end.

Request a Demo