When you give an AI agent access to your company’s tools — your email, your CRM, your file system, your APIs — you’re making an identity and access decision. But most teams making that decision are working with mental models built for human users or static service accounts. Those models don’t quite fit agents, and the gaps matter.
Why Agents Aren’t Like Service Accounts
The instinct is to create a service account, hand it credentials, and let the agent run. This works for a background process that does one predictable thing on a schedule. It works less well for an agent that’s making autonomous decisions, calling different tools in different sequences, and taking actions that weren’t explicitly predicted at setup time.
Service accounts have fixed, predictable behaviour. You can audit what they’ll do because you’ve written the code. An LLM-based agent’s behaviour is contextual — what it does depends on the instructions it receives, the data it sees, and the tools available to it. If someone injects malicious instructions into a document the agent processes, the “service account” suddenly starts doing things its original permissions were designed to allow but the operator never intended.
The second problem is scope creep through inheritance. An agent that can send email inherits all the trust a human sender gets. An agent with access to your knowledge base has read access to everything in it. Unless you’ve thought carefully about scoping, you’ve probably granted much broader access than the agent actually needs for its tasks.
The Three Things to Get Right
Minimal scope at creation time. Before you wire up a new agent, write down exactly which tools it needs and for what purpose. If it’s a customer support agent, it needs to read tickets and post replies. It probably doesn’t need to read your internal HR documents or access billing systems, even if those are technically available on the platform. Resist the temptation to grant broad access “just in case” — add specific access when you actually need it.
Action-level audit trails. You need to know not just that the agent ran, but what it did. Which tools it called, what parameters it passed, what outputs it returned. This is partly for security (spotting compromised behaviour) and partly for compliance — under UK GDPR and in regulated sectors, you may need to demonstrate that automated decision-making is auditable. Platforms like Langfuse, Langsmith, and Arize Phoenix can capture agent traces, but make sure you’re capturing the tool calls, not just the model outputs.
Human checkpoints for irreversible actions. The most important access control question for any tool is: can an agent take an action that can’t be undone? Sending an external email, deleting a record, posting to a public channel, making a payment — these all need either explicit human confirmation or very tight constraints on when the agent can invoke them. The pattern isn’t “never let agents do irreversible things”, it’s “require human approval for the ones where a mistake is expensive”.
Practical Patterns
Scoped tokens over shared credentials. Where possible, create purpose-specific API tokens rather than sharing master credentials with your agent. A read-only token for a knowledge base, a write-only token for a ticketing system that can only create tickets (not delete them). Most modern SaaS platforms support fine-grained token scoping and it’s worth using it.
SPIFFE/SPIRE for service-to-service identity. If you’re running agents as microservices in a Kubernetes or containerised environment, SPIFFE (Secure Production Identity Framework For Everyone) gives each workload a cryptographic identity that can be used for authentication between services. This is more robust than shared secrets and gives you workload-level audit trails. SPIRE is the reference implementation and integrates with common cloud environments.
Time-bounded credentials. Long-lived credentials sitting in environment variables are a common source of breach. Agents don’t need indefinite access — they need access for the duration of a task. Short-lived tokens issued at task start and revoked on completion significantly reduce your blast radius if credentials are compromised.
Separate identities for separate capabilities. If you have an agent that handles customer queries and separately an agent that handles internal data analysis, give them separate identities even if they run on the same infrastructure. This isn’t bureaucratic overhead — it’s what lets you answer “what could this agent possibly have accessed?” if something goes wrong.
The Emerging Standards Gap
There’s no widely adopted identity standard specifically designed for AI agents yet. The OAuth 2.0 ecosystem handles service accounts reasonably well, and efforts like the Identity Provider for AI Agents (IPAAI) community group are starting to define what agent-specific OAuth extensions might look like. Microsoft’s Entra ID has begun adding agent-specific identity concepts in its 2026 updates. None of this is mature yet.
In the meantime, the practical approach is to use existing IAM primitives thoughtfully — scoped OAuth tokens, SPIFFE workload identities, short-lived credentials — rather than waiting for a purpose-built standard. The security principles are well understood even if the agent-specific tooling isn’t.
When It Goes Wrong
The most common failure mode isn’t a sophisticated attack. It’s an agent with broader permissions than needed, processing untrusted input (a customer email, a scraped web page, a user-provided document), and being manipulated via prompt injection into taking actions within its permission scope that the operator didn’t intend.
The defence is layered: limit what the agent can do (minimal scope), detect unusual action patterns (audit trails), and require confirmation before irreversible actions (human checkpoints). None of these individually make an agent immune. Together, they mean a successful injection results in limited blast radius rather than a catastrophic breach.