Agent identity and access
Agents are not users, and giving them a service account is how this goes wrong.
Agent identity and access governance is the problem of giving autonomous systems their own identities, scoped permissions, auditable action trails and a revocation path, rather than running them on a shared service account with standing broad privileges. It has moved rapidly up the CISO agenda, because agents that call tools and take actions are non-human identities with real authority, and in most organisations the definition of a privileged user still means a person.
This is our approach, not a programme we have already run.
This is how we would approach it, grounded in how we actually run pilots and in delivery inside regulated environments, not a write-up of an enterprise non-human-identity programme we have delivered. Our own practice is to run pilots locally against mocked services, or in a dedicated hosted environment with synthetic data rather than real customer records, with the CISO involved from design concept and agreeing the scope up front. Where deep identity engineering is required we would expect to work alongside your IAM function or a specialist.
The demand signal
The population this belongs to is already enormous and already ungoverned, before a single agent is added to it. A survey of 2,930 IT and security leaders, published as the 2026 Identity Security Landscape, puts the ratio at 109 machine identities for every human and reports that 96% of human users hold access beyond what their role requires. Agents are the newest entrants to that population and the first that decide for themselves what to do with the access they hold.
Why it stalls
4 failure modes we keep meeting
The agent inherits a person's credentials
The fastest way to ship a pilot is to run the agent as the developer or as a shared service account. It works immediately, it is invisible in the logs, and it means every action the agent takes is attributed to a human who did not take it. Unpicking this after the fact is far more expensive than designing it in.
Permissions are scoped to the agent, not to the task
An agent that needs to read one system for one workflow is given broad standing access because that is simpler. The blast radius of a prompt injection or a reasoning error then equals the entire permission set rather than the task at hand. One agent like this is survivable. It is also the thing that quietly stops organisations scaling AI agents across the enterprise: at thirty agents nobody can answer what any of them is permitted to do, and the security function's only remaining lever is to slow the whole programme down.
Retrieval quietly bypasses source permissions
The most common serious failure in enterprise retrieval. Documents are indexed with the ingestion account's privileges, so the assistant will answer any user from any document it indexed. Permissions must propagate through to query time, and vendor quick-starts rarely do this.
There is no revocation story
Nobody can answer what happens when an agent misbehaves at three in the morning. If the answer involves finding the person who deployed it, you do not have a control, and that will be the finding.
How we approach it
7 moves, in order
- 01
Do not use real customer data to prove the concept
Our default is to run pilots locally against mocked services, or in a dedicated hosted environment, using synthetic data built to exercise the real use cases. It removes the hardest approval from the fastest-moving phase of the work, and it means the identity and access design can be got right before anything sensitive is in scope. It also tends to be why our CISO conversations are short.
- 02
Bring the CISO in at design concept, not at review
In our engagements the security function is involved from the design concept and agrees the limited scope up front. That is the difference between security being a co-author and security being the last gate before a date, and it is almost entirely a sequencing choice rather than a cost.
- 03
Give every agent its own identity from day one
Distinct, enumerable identities per agent, never shared with a human and never a general-purpose service account. This is cheap at design time and expensive to retrofit once actions have accumulated against the wrong principal.
- 04
Scope permissions to the task, and make them expire
Least privilege applied at the granularity of the workflow rather than the agent, with time-boxed credentials. The design question is what this agent needs for this task for this long, which is also the question that makes the blast radius calculable.
- 05
Propagate source permissions through to query time
Retrieval respects the permissions of the asking user against the source system, not the privileges of whatever indexed the corpus. We treat this as a design requirement rather than a hardening step, because retrofitting it usually means rebuilding the index.
- 06
Log actions against the agent, and link them to the human
Every action attributable to a specific agent identity, and traceable to the human accountable for that agent under the operating model. This is where identity design and accountability mapping meet, and where governance evidence comes from without a separate exercise.
- 07
Design the kill switch before you need it
A named person, a documented mechanism and a tested path to revoke an agent's access immediately. Untested revocation is not a control, and this is the question we would expect a CISO to ask first.
A named person, a documented mechanism and a tested path to revoke an agent's access immediately.
Provider divergence is real here
Unlike most patterns, identity is genuinely different across the hyperscalers: the agent identity primitives, how they federate with an existing enterprise directory, and how far permission propagation is supported natively rather than built. The design principles above are provider-independent; the implementation is not, and we would expect to work alongside your existing IAM function rather than around it.
Prefer to talk it through? Ask us on a discovery call →
Sources
Every source below was opened and read before it was attached. Where nothing survived that check, the claim on this page was softened rather than given a plausible-looking link.
2026 Identity Security Landscape, Idira by Palo Alto Networks, May 2026Source of the 109 to 1 ratio and the 96% figure, from a survey of 2,930 IT and security leaders published May 2026. A vendor-commissioned study, which is worth knowing when you read it. It supersedes CyberArk's 2025 edition, whose press release now redirects here and no longer carries the earlier 82 to 1, 42% and 88% figures; those were removed from this guide rather than left pointing at a page that does not hold them.OWASP Top 10 for Large Language Model Applications (2025)LLM06 Excessive Agency and LLM08 Vector and Embedding Weaknesses are the entries behind the scoping and retrieval-permission arguments above.Microsoft, security filter pattern for Azure AI SearchA worked example of propagating source permissions to query time: an identity field on every indexed document, filtered against the caller's group membership at search time. Named as one provider's documented pattern, not as a recommendation of that provider.Questions this guide answers
Should AI agents have their own identities?
Yes, and from the first pilot rather than at production. Running an agent under a developer's credentials or a shared service account attributes its actions to a human who did not take them, makes agent activity invisible in logs, and is materially more expensive to unpick later than to design correctly at the start.
How do you stop AI retrieval leaking documents to the wrong users?
By propagating source-system permissions through to query time, so retrieval respects the permissions of the asking user rather than those of the account that indexed the corpus. This is the most common serious failure in enterprise retrieval, and because it is usually discovered after indexing it often means rebuilding the index. It belongs in the design, not in hardening.
What breaks when you go from one agent to thirty?
Everything that was a shortcut becomes a control failure. Shared credentials stop being a tidiness issue and start meaning that no log can attribute an action to a specific agent. Standing permissions granted for convenience add up to a combined blast radius nobody has calculated. Retrieval indexes built with an ingestion account's privileges multiply into a leak surface across every corpus. And revocation, which was one person and a console, becomes a question of who is on call at three in the morning for thirty systems. The organisations that scale AI agents across the enterprise are the ones that made identity, permission propagation, action logging and revocation a shared platform concern before the second agent, rather than solving it per agent thirty times.
What is non-human identity governance?
Managing the identities, credentials, permissions and lifecycle of things that are not people (service accounts, workloads and now AI agents) with the same rigour applied to human identity. It has risen sharply up the security agenda because agents that call tools take consequential actions with real authority, and because the population was already unmanaged before agents arrived: a 2026 survey of 2,930 IT and security leaders put machine identities at 109 for every human, and found that 96% of human users already hold access beyond what their role requires.
How do you run an AI pilot without exposing customer data?
Run it locally against mocked services, or in a dedicated hosted environment, on synthetic data built to exercise the real use cases rather than on production records. That removes the hardest approval from the fastest-moving phase of the work and lets the identity and access design be settled before anything sensitive is in scope. Combined with static analysis, dependency and secrets scanning in the pipeline and a model-led security review roughly every fifth prompt during the build, proofs of concept produced this way are frequently more compliant than the legacy systems they sit next to.
When should the security team get involved in an agentic project?
At design concept, agreeing the scope, rather than at review. It is a sequencing choice that costs almost nothing and changes the entire dynamic: the security function becomes a co-author of the control design instead of the last gate before a committed date, where its only available lever is to block.
What is the first thing a CISO should ask about an agent deployment?
How do we revoke it, who is authorised to do that, and when was it last tested. If the answer involves locating the person who deployed the agent, there is no control, and untested revocation is not a control either. The second question is what the blast radius is if this agent is manipulated, which is answerable only if permissions are scoped to the task rather than to the agent.
The closest guides to this one
Nearest first, then the rest. Each one carries the same label: written from delivery, or the method we would bring. All 13 are on the hub.
Agent evaluation and assurance
Why AI pilots never reach production, and what it takes to get one through the gate.
Our approachAI governance and regulatory evidence
Building the evidence as a by-product of the work, rather than assembling it under deadline.
DeliveredDocument intelligence to business intelligence
Getting information out of PDFs and into something the business can decide with.
DeliveredAI-native SDLC and product delivery lifecycle
Changing how software gets specified, built and shipped once AI is in the room.
DeliveredTarget operating model for an AI-native organisation
What changes in structure, roles and decision rights once agents do a share of the work.
DeliveredVoice agents and conversation intelligence
Turning conversations into structured intelligence, and holding conversations that take real actions.
Talk to us about agent identity and access.
A 30-minute call with James Rooney. We'll tell you honestly which parts of this we have done before and which we would be doing for the first time, and you'll leave with a rough scope either way.
most start with a fixed-price AI Readiness Audit · £30k–£90k · 6–8 weeks
Calendar not loading? Open it on cal.com or email hello@tenhaw.com.