Who owns your AI agents? How to find them, give each one a sponsor and stop their access creeping

AI agents now open tickets, read mailboxes, call each other and change records in production, and in most companies nobody can say who answers for each one. Before you add more agents, give every one a named business owner, find the ones nobody registered and put their permissions under continuous watch. This guide covers the six gaps we look for first, from ownership to the identity graphdefinitionA single map of who owns which agent, what each one runs as and what it can reach. Without it you're stitching exports together by hand..

If you haven't set up per-agent identities yet, start with giving each agent its own login and capping what it can do. The governance below assumes each agent already has an identity you can point to.

Agent trouble rarely starts with a dramatic breach. Usually it's slow drift. Someone in finance builds an agent in a low-code tool and gives it a connector to the ERP. Then the builder moves teams. A year later it's still running and nobody's watching. When an auditor asks who approved its access, people shrug.

The standards bodies have noticed. OWASP now keeps a separate top 10 for agentic applications, and identity and privilege abuse sits third on it. NIST's National Cybersecurity Center of Excellence put out a concept paper asking how agents should be identified, authorized and audited. Neither tells you to stop building agents. Both expect you to know which ones you have and what they can do.

For engineers, the hard part is that every step uses a legitimate feature. Dynamic tool lists, step-up scopes and agent-to-agent calls are all in the specs. Governance has to watch how those features get used over time, because nothing in the protocol will stop an agent from collecting access.

Start here, because everything else depends on it. An access review needs a reviewer, a leaver process needs someone to hand over to, and an incident needs someone who can say whether the agent's behavior was expected. If an agent has no accountable human, every one of those processes quietly skips it.

We like Microsoft's split even for teams that don't run Entra. Owners are the technical admins, and they look after credentials and configuration. Sponsors are business people who answer for the agent's purpose. Entra requires one when an agent identity or blueprint is created. If a user creates it and names nobody, Entra makes that user the sponsordefinitionWhoever in the business answers for an agent. If it misbehaves, they're the one you call, and they decide whether it keeps running. Technical settings stay with the owner.. Managers sit in the org chart and can ask for access on an agent's behalf.

The detail that matters most is succession. A sponsor who leaves is the classic orphaning moment. Entra's Lifecycle Workflows can move sponsorship to the leaving sponsor's manager automatically once you set up the sponsor tasks, and SailPoint's agent docs describe an automated succession plan for agent owners. Whatever platform you use, test the leaver path with a real agent before you trust it.

Watch the defaults too. In Copilot Studio, Microsoft records whoever created the agent as its sponsor. That's a reasonable start for a prototype. For an agent that a whole department relies on, the sponsor should be someone who can actually decide whether it's still needed, so change it when the agent goes into real use.

Usually, yes. Shadow IT used to mean a team buying a SaaS app with a credit card. Agents are easier to start than that. Anyone with a low-code license, a cloud console or an API key can make one, and it runs under whatever credential they gave it. The identity team only sees it if it signs in through a path they already monitor.

Even one vendor's own tools can disagree about what exists. Microsoft says the Entra admin center shows agents that have an Entra agent identity, while the full inventory, including agents without one, lives in the Agent 365 registry in the Microsoft 365 admin center. Its docs also warn that some agent identity blueprints created earlier may not appear in that registry until someone registers them. If you count agents from one console, check it against the other.

Discovery has to look in more than one place. Okta's agent product starts with discovering agents in managed and unmanaged apps, including agents employees connect to company apps. SailPoint aggregates agents from connected sources and correlates the machine accounts they use. Pick the sources that match where your agents actually get built, then run discovery on a schedule. A one-off sweep goes stale the week after.

• Identity provider logs: sign-ins and token grants from app registrations, service principals and OAuth clients nobody can name
• Agent platforms. Low-code studios, cloud agent services and model gateways each keep their own list, and they rarely match
• Secrets and vaults. Look for API keys and tokens issued to automation that nobody ever tied to an owner
• MCP servers and gateways. Their logs show who connects and what they call, which is often the first sign of an agent nobody listed
• Cloud bills and egress: model API spend on cost centers that never asked for an agent

When you find one nobody claims, treat it the way you'd treat an orphaned service account. Look at what it calls, ask the teams whose systems it touches, and if nobody steps up, disable it in a change window and see who complains. Don't delete it on day one. You'll want its logs if it turns out to matter.

IGA was built around people who join, move and leave on HR dates, and around applications that stay put for years. Quarterly certifications work when access changes slowly. Agents break both assumptions. Microsoft's own docs say an agent might exist for minutes, or be created and destroyed thousands of times a day in an automated workflow.

There's a second gap. An agent either works on its own grants or, when it acts for a person, on the rights that person delegated to it. A quarterly review of the agent's entitlements alone misses half of it. You need to know who it was acting for, at the moment it acted.

None of this throws IGA away. Certification campaigns still matter for the standing grants on agent templates and blueprints, and for the humans who can call agents. SailPoint, for instance, describes campaigns where certifiers review human access to agents and the tools agents can reach. The change is adding a continuous layer underneath for everything that moves faster than a quarter.

Once agents call agents, zero trust gets harder. NIST's zero trust architecture says no implicit trust comes from network location alone, and authentication and authorization happen before each session. That's easy to state for a user hitting an app. It's much harder for a planner agent that hands a task to a research agent, which calls a tool through an MCP server, which calls a SaaS API.

The protocols help, but only partly. A2A is at version 1.0.0 and treats an agent like any other enterprise app. You publish an Agent Card at /.well-known/agent-card.json saying how callers sign in, and they get credentials out of band. Your server checks each request against its own policies. A2A also warns that hitting the auth-required state doesn't grant anything by itself, which is easy to get wrong in a quick build.

MCP covers the agent-to-tool hop. Its authorization spec makes the MCP server an OAuth resource server, requires the client to name the target server in a resource parameter, and requires the server to check that each token was issued for it. The server must not pass a client's token on to an upstream API. It gets its own token for that hop, and the confused deputy problem is the reason why.

What's usually missing is identity that survives the whole chain. OAuth Token ExchangedefinitionOAuth's way (RFC 8693) to swap one token for another. Under delegation the new token names both the user and the agent acting for them. (RFC 8693) lets an agent swap the token it got for a new one under delegation. The agent keeps its own identity, and the act claim names it. Nested act claims keep a record of earlier callers, so the service at the end can see the research agent working for the planner, which works for a buyer in procurement. Those earlier callers are there for the audit trail. RFC 8693 says not to use them in access decisions, so authorize on the current actor. Inside one trust domain, the Transaction Tokens draft goes a step further and carries the user, the workload and the authorization context down the call chain.

sub:   user:buyer-114@procurement
aud:   https://mcp.example.com/erp
scope: po:read
act:   { sub: agent:research-7 }
         act: { sub: agent:planner-2 }

For the agent's own credential, workload identity is the safer base. SPIFFE gives each workload an ID in the form spiffe://trust-domain/path and issues short-lived X.509 or JWT documents through its Workload API, rotated automatically. SPIFFE prefers the X.509 form, since JWTs can be replayed. Agents running as workloads can use the same plumbing your services do, so nobody pastes long-lived API keys into a config file.

The OpenID Foundation's paper on agent identity is honest about the gap. Today's frameworks give a solid foundation for agents that stay inside one organization, and they weren't designed for recursive chains of agents spawning sub-agents. A commenter on Hacker News put the practical side bluntly: most of it can be solved by composing existing standards, but in practice almost nobody does. On Okta's developer forum, a team running only an MCP gateway with no user interface asked how Cross App Access works when there's nowhere for a user to sign in. Plan for those headless cases early.

Agents rarely edit their own role assignments. They don't need to. The specs let access grow at runtime in quieter ways, and each one is legitimate on its own. Governance means watching for the pattern.

MCP's own security guidance lists the mistakes to look for: publishing every possible scope, wildcard scopes like full-access, bundling unrelated privileges to avoid future prompts, and silent changes to what a scope means without versioning. Those are exactly the things a drift check should flag. The same guidance says servers should log elevation events with the scope requested, the subset granted and a correlation ID.

OWASP's excessive agency entry blames too much functionality, permission or autonomy. One of its key mitigations is complete mediation. The downstream system checks every action, and the model never gets to decide whether something is allowed. NIST's concept paper is still asking whether authorization policies can update when an agent's context changes, for instance when it picks up new tools. Nobody has a settled answer, so plan for it yourself.

In practice, drift detection is a diff. Take a baseline of each agent's scopes, tools, credentials and policy assignments. Compare it daily against what the identity provider, the MCP gateway and the vault report. Anything new either has an approval behind it or goes to the sponsor. MCP also says clients must treat tool annotations as untrusted unless they come from trusted servers, so read what a new tool does before you believe its label.

Ask most companies to show every path from one agent to their customer database and you'll get four exports and a spreadsheet. The agent lives in an agent platform, its credential in a vault, its workload in a cloud account, its delegated user in the identity provider, and its tools behind an MCP gateway. Each console is right about its own piece.

A graph joins those pieces. Nodes are humans, agents, NHIs, credentials, workloads, tools and resources. Edges say owns, sponsors, runs as, acts for, holds, can call and can reach. NIST's concept paper names NGAC (Next Generation Access Control), an attribute-based standard that models policy as a graph of users, objects, attributes and policy classes, as one option it's considering. You don't need NGAC to start. You need the edges in one place so you can ask a question across them.

Some vendors are starting to put pieces of this graph inside their own products. SailPoint's agent report lists identities that are overpermissioned by agents, and Okta's agent product covers access reviews and ownership for agents as resources. Those help inside each tool. If your agents span several platforms, you'll still need a layer that reads from all of them.

• Which agents can reach payment or customer data? Who signs for each one, and do those people know they're on the hook?
• Which agents run on a credential that nobody owns, or on a key older than your rotation policy?
• Which people can start an agent that has more access than they do? If someone can, they can borrow privilege they were never given
• Which agents call other agents? On each hop, check the token was issued for the one receiving it. If it was just passed along, you've found a forwarding problem.
• If a sponsor resigned today, which agents would be left with nobody to answer for them, and who'd find out?

Most of these risks already have a name. OWASP has written them up across three separate top 10 lists, and NIST's AI RMF asks for an inventory, named accountability and a working way to switch a system off. The table lines each risk up with the control most teams lean on today, then shows where that control stops working for agents.

We'd build it in this order. Each step gives you something an auditor can check, and each one makes the next step cheaper. Don't try to buy the whole thing at once. Most of the early work is lists, owners and logs you mostly already have.

Analysts group these products into categories, and the names come in handy when you're writing a budget line. Gartner's term for the AI side is AI TRiSM, short for AI trust, risk and security management. It covers keeping AI systems trustworthy and compliant through ongoing monitoring and enforcement, and the identity tools you'd use for agents sit underneath it.

We don't rank vendors. Each category below maps to a step of the six-step program, and the examples are listed alphabetically. A capability only made it into the tables if the vendor's own documentation describes it, and we kept the vendor's status label where it has one.

Read "not documented" literally. We couldn't find it in the vendor's public docs, and it might exist under another name or behind a login. Saviynt's technical documentation sits behind a customer sign-in, so we left it out of the tables rather than quote its marketing pages. Check licensing too. Microsoft says ID Protection for agents will need an Agent 365 license, and Conditional Access for agents needs Microsoft 365 E7, or Agent 365 with at least Entra P1 or Microsoft 365 E3.

If Microsoft Entra Permissions Management ran your drift checks, they need a new home. Microsoft retired the product on November 1, 2025 and partnered with Delinea on an alternative. AWS shops can switch on IAM Access Analyzer's unused access findings, which catch roles, keys and permissions nobody touched in the window you set. Those are billed separately.

Our platform pages go deeper on each tool: Microsoft Entra ID, Okta, SailPoint, Saviynt, CyberArk, HashiCorp Vault and Delinea. Start with the tool you already pay for, and only add a category when a step of the program has no owner.

These are measures we'd track, not industry benchmarks, and we won't give you a target number. Take a baseline in the first month and watch the trend after that. Each one comes from logs you can already collect, as long as someone turns the export on.

Send it all to one place. Entra's diagnostic settings push sign-in and audit logs to a Log Analytics workspace or an event hub, and Okta streams its System Log to Amazon EventBridge or Splunk Cloud. Entra doesn't keep a separate sign-in log for agents. Their sign-ins land in the existing sign-in logs, so you'll filter on agent type.

Two things catch people out with Vault. Its audit log stores most string values as HMACs, so you can match one secret's use across entries but you can't read the secret. And if every audit device goes down, Vault stops serving requests, so run more than one.

Part 2 of this series goes deeper on that first hour: how to stop a rogue agent, and what OAuth and runtime enforcement can and can't do. It covers revocation platform by platform, the containment steps in order and how to join your logs so you can prove what the agent did.

We'd start by sitting down with your team to build a spreadsheet: one row per agent, with its sponsor and what it signs in with. Then we wire reviews and drift checks into the identity tools you already run. Our non-human identity discovery and governance and AI agent identity pages explain how we work.

We'd usually do the platform work on Microsoft Entra ID, Okta, SailPoint or Saviynt. CyberArk or HashiCorp Vault can hold the agent credentials. You can bring in identity engineers for the build, or start with an assessment and see what you actually have first.