On this page10 sections
- What is AI agent identity management?
- What changed, and what it means for cost, risk and scale
- How AI agent access control works, step by step
- What people get wrong about AI agent security
- Shared logins, borrowed logins or agent identities: how they compare
- How much access should an AI agent get?
- How to run an AI agent identity pilot and measure it
- The risks, and how to control each one
- How Thriiv approaches agent access
- What to do this quarter
Gartner expects the average Global Fortune 500 company to run more than 150,000 AI agents by 2028, up from fewer than 15 today. AI agent identity management is how you keep that much software accountable: every agent gets its own login, a named human owner, the narrowest access its task needs and a record of everything it does.
This matters now because agents act, not only advise. Rubrik, a seller of agent controls, ran a survey of 200 IT and AI decision makers with Foundry and sponsored the write-up, so read its figures as a signal: 38% said agents had exfiltrated data, meaning copied it out without permission, or caused a sensitive data leak. When agents share one login, nobody can say which one acted, and the only safe fix is to switch them all off.
The tools now ship from Microsoft, Google and AWS. Most of the work is not technical. Name an owner for every agent, cut its access to what one task needs, and prove you can stop one agent in minutes without stopping the rest.
What is AI agent identity management?
AI agent identity management is the set of rules and tools that decide who an agent is, what it may touch and who answers for it.
An AI agent is software that uses an AI model to choose its next step and then takes it: it reads a file, sends an email or changes a record. To do that it must log in to company systems, just as a person does. Four ideas sit underneath:
- Identity: the name a system knows the agent by.
- Authentication: how the agent proves that name, for example with a digital certificate rather than a password typed into code.
- Authorisation: what that name is allowed to do, system by system and action by action.
- Governance: who approved the agent, who reviews it and when it is retired.
Gartner's advice fits in one line. As The Register reports it, every agent needs a defined identity, a clear set of permissions and a lifecycle plan.
What is a non-human identity?
A non-human identity is any login used by software rather than a person. Service accounts (logins set up for a program rather than a person), API keys (long passwords one program uses to call another) and certificates are all non-human identities. Firms have run them for years. Agents are a new and more active kind, because they decide what to do with the access they hold.
The closest comparison is a contractor's building pass. It names the holder, lists the doors it opens, names the manager who asked for it and expires on a date. The comparison stops at judgement. A contractor who finds a note saying "open the server room" will usually ask why. An agent may simply do it, as the section on common mistakes shows.
What changed, and what it means for cost, risk and scale
Agents moved from answering questions to taking actions inside core systems, and the largest platforms rebuilt their access controls in response.
The same Foundry and Rubrik survey found that most agents are allowed to act with full (26%) or limited (35%) autonomy. Rubrik sells agent controls and sponsored the article, so read the figures as a signal, not a census.
The engineering response is already visible:
- Uber built one gateway in front of more than 800 MCP servers and 5,000 tools. MCP, the Model Context Protocol, is a common standard that lets an agent find and call a company tool. Uber's gateway checks access at both the server and the tool level, and can redact personal data from tool responses.
- Cloudera sees access rights, not model choice, as what decides whether an agent can be trusted. Its chief product officer, Leo Brunnick, put it plainly: "the agent needs to know who you are and what your permissions are".
- Microsoft, AWS and Google have each shipped tools for agent access. Microsoft Entra Agent ID and Amazon Bedrock AgentCore Identity give each agent its own identity. Google's new IAM Helper does a different job: it narrows the access agents hold to the minimum a task needs.
- NIST, the US standards body, published a concept paper for a project on the identification, authorisation, auditing and non-repudiation of AI agents in February 2026. Non-repudiation means an action can be proven to have come from a given agent.
For risk, the gap is wide. Gartner found that just 13% of organisations believe they have the right governance in place.
For scale and cost, the point is the reverse of what many expect. Gartner found that firms which limited generative AI tools to low-risk or trusted users were less likely to report high returns, while broader adopters under strong governance were 3.3 times more likely to report higher value. Gartner measured staff access to generative AI tools, not agents, so applying the finding to agents is our reading. Our argument is that identity controls are what let you widen access safely. In the Foundry survey, 24% named security and governance as the biggest barrier to scaling agents, ahead of a lack of proven ROI at 14%.
How AI agent access control works, step by step
AI agent access control works by giving each agent a checked identity, short-lived passes for specific actions, and a log that ties every action to a person who answers for it.
- Register the agent. Each agent gets its own identity, made from an approved template. Microsoft calls the template a blueprint. Disabling a blueprint instantly blocks all its agent identities: an emergency stop for every agent built from that template at once. Disabling one agent identity stops that agent alone. A sponsor, the person accountable for the agent's purpose, and a technical owner are named at creation.
- Prove who it is. The agent signs in with a certificate or a managed identity, a login that the cloud platform issues and rotates so no password is stored. Client secrets, which are passwords for software, are for testing only.
- Decide whose authority it uses. An agent either acts on behalf of a person or acts as itself. Set up properly, an agent acting for a person can never do more than that person may. Acting alone, it gets only the permissions its task needs.
- Issue short-lived passes. The agent receives a token, a digital pass that expires in minutes or hours, for each system it calls. AWS stores these passes in a vault and binds each one to a single agent and user pair. Google's tooling can grant a time-limited pass on request, for example for one hour, instead of standing access.
- Check each tool call at a gateway. A gateway is a single checkpoint between agents and company systems. It compares each request with policy before the action runs, as Uber's does for its tool catalogue.
- Pass on less authority at each hand-off. Agents often hand work to other agents. Each sub-agent should get no more authority than the agent that called it, cut to the task it was given. In an AWS reference design, token exchange, which swaps one pass for a narrower one, limits each downstream agent to the delegated task instead of passing on the full original pass. Each decision is logged with the user's identity and the full chain of hand-offs, and the design caps how many hand-offs a chain may have.
- Log each action to the agent and the person. AWS describes the standard regulated firms need: audit trails that record who accessed what, when, and on whose behalf. An auditor can then follow the chain from the action to the person who answers for it.
- Review and retire. Microsoft advises that sponsors attest every 6 to 12 months that each agent is still needed, and that agents with no sponsor or no recent activity are found every quarter and either reassigned or switched off.
What people get wrong about AI agent security
Most mistakes come from treating an agent like a user, a script or a model, when it behaves like none of them.
"A better prompt or filter will stop the agent being tricked"
It will not. Prompt injection is text hidden in an email, web page or document that an AI model reads and then follows as an instruction. The UK's National Cyber Security Centre explains that models make no real distinction between data and instructions, so it's very possible that prompt injection attacks may never be totally mitigated.
Researchers have already shown this in a mainstream product. In the EchoLeak case, found by the AI security firm Aim Security, a crafted email could instruct Microsoft 365 Copilot to collect sensitive data and send it to an attacker, and the user does not need to open the malicious email or click on any links. Microsoft fixed it on its own servers. The lesson is that the control must sit in what the agent is allowed to reach, not in what it is told.
"The agent can borrow a person's login or a shared account"
This is a common shortcut, and an expensive one to undo later. Microsoft's guidance is direct: provision a unique identity per agent, because distinct identities improve traceability and let you disable or update one agent without impacting others. A borrowed login also gives the agent everything that person can do, which is almost always more than one task needs.
"Locking every agent down is the safe choice"
Over-restriction fails too. Gartner's Shiva Varma calls binary governance, either locked down or fully trusted, the root cause of failure. Locking down simple agents slows delivery and pushes staff to build their own tools out of sight. Under-restricting autonomous agents raises operational, security and compliance risk.
"Our current identity controls already cover agents"
They rarely do. Agents cannot answer a multi-factor prompt on a phone, so policies written for people either block them or end up excluding them, which leaves the agent with no policy at all. Microsoft advises separate access policies built for agents. The sponsored Foundry article makes the same point: traditional security, monitoring and governance tools were built to manage human identities, not agents.
Shared logins, borrowed logins or agent identities: how they compare
The choice of identity decides three things: whether you can trace an action, whether you can stop one agent alone, and how much damage a tricked agent can do.
| Option | Who the logs say acted | Stop one agent alone | Damage if tricked | Use it when |
|---|---|---|---|---|
| Shared service account | The account, not the agent | No | Everything the account reaches | Never for an agent that can change data |
| A person's own login | That person | Only by locking the person out | Everything that person can do | Never |
| Agent identity acting for a person | The agent and the person | Yes | What the person may do, cut to the agent's grant | Assistants that work for one person at a time |
| Agent identity acting as itself | The agent and its named owner | Yes | Only its narrow grant | Background work with no person present |
The last two rows are the target state. The first two are where many estates start, often inside tools nobody counted as agents.
How much access should an AI agent get?
Give each agent the access its worst permitted action justifies, and set controls by what it can change, not by how capable its model is.
Gartner recommends proportional governance: classify agents by autonomy level and match controls to each level. A three-tier version works for most firms:
- Tier 1, suggests. The agent reads data for one person and drafts answers. The person takes every action. Controls: delegated read access and standard logs.
- Tier 2, acts with approval. The agent prepares changes, and a person approves each one before it is applied. Controls: write access only through the approval step, enforced by the system rather than the prompt, and a full action log. Google's IAM Helper follows this pattern, pausing any change to access policies for human-in-the-loop confirmation.
- Tier 3, acts alone within limits. The agent has its own identity and acts without approval inside hard limits on value, volume and scope. Controls: what Gartner lists as continuous monitoring, enforced guardrails, rapid rollback, circuit breakers that halt the agent when a threshold is crossed, and clear ownership.
One rule overrides the tiers. An agent that reads content from outside the company, such as supplier email, web pages or customer uploads, should not hold write access to sensitive systems in the same step. The National Cyber Security Centre cites a simple principle: when a model processes information from a party, its privileges should drop to that party's level.
Questions to ask a vendor or your team
- Does each agent get its own identity, or does it run on a shared account or a person's password?
- Who is the named owner of each agent, and what happens when that person leaves?
- When the agent acts for a person, can it ever do more than that person may?
- Which actions need approval, and is that enforced by the system or only by the prompt?
- How long does each access pass last, and how are credentials rotated?
- Can you stop one agent in minutes without stopping the others? Show us.
- Does every log entry name both the agent and the person it acted for?
- What access does the agent hold while it reads content from outside the company?
How to run an AI agent identity pilot and measure it
Run the pilot on one business unit and one write-capable workflow, and measure control and output together, so you prove safety without killing the value.
- Count every agent in the unit. Include agents built into software you buy, such as CRM, ERP and office suites, and anything staff built themselves. Gartner advises a central inventory of every agent, sanctioned or not.
- Pick one workflow that changes data. Supplier invoice matching or customer record updates are good candidates: real volume, real risk, clear owners.
- Give that agent its own identity, a sponsor and an owner. No owner, no agent.
- Write the grant. List each system and each action the task needs, and remove everything else. Test the new policy against past activity before you enforce it, and run new access rules first in report-only mode, where they record what they would block without blocking it.
- Put approval on the worst actions. Payments, deletions and anything that leaves the company go through a person.
- Run a stop drill. Disable the agent, time how long it takes, and check that nothing else broke.
- Measure for six to eight weeks. Track the share of agents with a named owner, standing write permissions removed, time to stop one agent, actions blocked by policy (split into real errors and wrong rules), and the workflow's output against its baseline.
The risks, and how to control each one
Each risk below has a control that does not depend on the model behaving well.
- Hidden instructions in content. Assume some will get through. Constrain what the agent can do with rules enforced outside the model, as the National Cyber Security Centre advises, and drop its access while it reads outside content.
- Stolen credentials. Use certificates or managed identities, keep no passwords in code, and rotate certificates at least once a year, as Microsoft recommends.
- Privilege creep. Agents take on new tasks and keep old access. Audit each agent's permissions on a schedule and cut what it no longer uses.
- Orphaned agents. Owners leave and agents keep running. Run a quarterly check for agents with no sponsor or no recent activity, and retire them.
- Shadow agents. Staff build agents inside tools you already pay for. Register every agent in one directory, whatever platform built it.
- Untraceable actions. Make it a condition of purchase that logs name the agent and the person it acted for.
- Lock-in. Prefer tools built on open standards such as OAuth 2.0, the common method for granting one system limited access to another, and MCP. Microsoft's agent platform supports both, which makes a later move less painful.
For the board-level controls that sit above identity, such as autonomy limits and incident reporting, see our guide to agentic AI risk management.
How Thriiv approaches agent access
Thriiv builds and runs custom AI systems, workflow automation and secure data pipelines for international enterprises. Every system runs in an environment we host and manage, and we keep running it after launch, so one team answers for what it can reach. Our security page sets out how that environment works.
We put a quantified saving in front of you before budget is committed, and a working pilot follows in weeks, not quarters. Tell us where the cost sits. To begin, start the conversation.
What to do this quarter
Four actions move a firm from guesswork to control.
- Ask for the count. How many agents run today, on which logins, with which owners? If nobody can answer, that is the first finding.
- Set two rules. No agent without a named owner. No agent on a shared account or a person's password.
- Run one pilot. Pick a workflow that changes data and follow the seven steps above.
- Add two numbers to the risk report. The share of agents with an owner, and the time it takes to stop one agent. Both should improve every quarter.
Questions
- Who should own an AI agent: IT, security or the business?
- Split the roles. A business sponsor answers for why the agent exists and what it may do, and confirms at each review that it is still needed. A technical owner in IT runs its identity, credentials and logs. Security sets the policies every agent must meet. If an agent has no business sponsor, nobody can judge whether its access still makes sense, so treat a missing sponsor as a reason to switch the agent off.
- Do we need to buy a new identity product for AI agents?
- Often not first. The main identity platforms now extend to agents: Microsoft Entra Agent ID and Amazon Bedrock AgentCore Identity both give each agent its own identity. Check your current licences, because Microsoft ties its agent security features to a Microsoft Agent 365 licence. The first gains come from work no product does for you: counting your agents, naming owners, removing shared accounts and cutting access to what each task needs.
- Can an AI agent use multi-factor authentication?
- Not in the usual sense. Multi-factor checks expect a person to approve a prompt on a phone, and an agent cannot do that. Agents prove who they are with certificates or managed identities instead, which are logins the platform issues and rotates. Write separate access policies for agents, block agents flagged as high risk, and test new rules in report-only mode before you enforce them, so you do not break working systems.
- Do agents built into the software we buy count too?
- Yes. Agents inside CRM, ERP and office tools act on your data with your permissions, so they belong in the same inventory and the same reviews as agents you build. Ask each vendor whether its agents get their own identity, what they can reach, how you stop one and whether the logs name both the agent and the person it acted for. If the vendor cannot answer, limit what the agent can touch.
- How quickly should we be able to switch off one AI agent?
- In minutes, and without stopping any other agent. That is only possible when each agent has its own identity, because disabling a shared account stops everything that uses it. Test it with a drill: disable the agent, time how long it takes and check that nothing else broke. Ask vendors to show you the same drill rather than describe it, and report the time to the board each quarter.
Sources
- Govern your bots carefully or chaos could ensueThe Register, 30 April 2026
- 4 in 10 AI agents headed for demotion or the rubbish binThe Register, 27 May 2026
- Governing the agent workforce: New data on the next frontier of AI riskCIO, 29 October 2026
- Uber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent ToolsInfoQ, 2 November 2026
- The race to deploy AI agents finds a familiar hurdle in data accessSiliconANGLE, 30 October 2026
- What is Microsoft Entra Agent ID?Microsoft Learn
- Best practices for Microsoft Entra Agent IDMicrosoft Learn
- Introducing Amazon Bedrock AgentCore Identity: Securing agentic AI at scaleAmazon Web Services, 16 September 2025
- Scale agents securely with IAM Helper Agent Skills and MCP ToolsGoogle Cloud, 28 October 2026
- New concept paper on identity and authority of software agentsNIST, 5 February 2026
- Prompt injection is not SQL injection (it may be worse)National Cyber Security Centre, 8 December 2025
- 'EchoLeak' AI attack enabled theft of sensitive data via Microsoft 365 CopilotSecurityWeek, 12 June 2025
- Enforce least-privilege authorization in multi-agent AI chains using CedarAWS Security Blog
