Somewhere in your organisation right now, an AI agent has credentials to your CRM. Another one can read and write to your cloud storage. A third is processing customer data through an API that nobody in security has reviewed. These aren't hypothetical scenarios. They're Tuesday.
We've spent two decades building identity and access management around a simple assumption: the entity requesting access is a human being. That assumption is now dangerously wrong. AI agents are becoming autonomous digital employees — and your security architecture has no idea what to do with them.
Gartner forecasts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. Meanwhile, only 6% of organisations report having advanced AI security strategies in place. If those numbers don't alarm you, you're not paying attention.
The Shift You're Not Seeing
There's a critical distinction that most organisations — and most security teams — are still failing to grasp. It's the difference between AI tools and AI agents.
An AI tool is a chatbot. A copilot. Something a human prompts, reviews, and acts on. The human remains the actor. The human holds the credentials. The human is accountable.
An AI agent is something fundamentally different. It operates autonomously. It holds its own credentials. It makes decisions. It calls APIs, reads databases, processes information, and takes actions — sometimes chaining dozens of operations together before any human sees what happened. It isn't assisting a user. It is a user.
This isn't a subtle evolution. It's a categorical shift in how systems interact with your infrastructure. And the security implications are enormous — because every framework you've built assumes that the entity behind a credential has judgement, context, and accountability. AI agents have none of these in the way your IAM policies expect.
The Identity Problem Nobody Solved
Here's the uncomfortable truth: only 21.9% of organisations treat AI agents as independent, identity-bearing entities. The rest? They're doing one of two things, both catastrophic.
Option one: agents inherit the deploying user's identity. A developer spins up an AI agent for data processing and authenticates it with their own credentials. That agent now has every permission the developer has — including ones entirely irrelevant to its task. The developer goes on holiday. The agent keeps running. Nobody is monitoring what it accesses, because the access logs just show a known, trusted human identity.
Option two: agents use shared service accounts. This is worse. A generic service account with broad permissions, shared across multiple agents, with no attribution of which agent did what. When something goes wrong — and it will — your audit trail is a dead end.
Neither approach was designed for what's happening. Non-human identities now outnumber human users by ratios of up to 100:1 in enterprise environments. Your identity infrastructure was built for the 1, not the 100.
New Attack Surfaces You Haven't Stress-Tested
Traditional security threats — credential theft, phishing, privilege escalation — don't disappear with AI agents. They get worse. But they're also joined by entirely new attack vectors that most security teams have never encountered in production.
Prompt Injection: The SQL Injection of the AI Era
Prompt injection is exactly what it sounds like: an attacker embeds malicious instructions in data that an AI agent processes, causing the agent to deviate from its intended behaviour. Think of it as social engineering — but against a machine that processes text from untrusted sources as part of its core function.
The critical vulnerability is this: large language models cannot reliably distinguish between instructions and data. Everything they process is subject to being interpreted as a command. Researchers have demonstrated attack success rates exceeding 85% against state-of-the-art defences when adaptive strategies are employed. That's not a vulnerability. That's an architectural limitation.
Indirect prompt injection is particularly dangerous. An agent that reads emails, parses documents, or crawls web content can encounter poisoned data that redirects its behaviour. A malicious instruction embedded in a document metadata field. A hidden prompt in a webpage. An adversarial payload in a customer support ticket. The agent processes the content, follows the injected instruction, and executes actions with whatever privileges it holds.
The Lethal Trifecta
Security researchers have identified what they call the "lethal trifecta" — three conditions that, when combined, create maximum exposure:
- Untrusted data inputs — the agent retrieves or processes content from external sources
- Tool-calling capabilities — the agent can execute actions, not just generate text
- An exfiltration vector — the agent can make external requests or produce outputs that leave the system
Any AI agent that reads external documents, calls APIs, and sends emails meets all three conditions. That describes the majority of enterprise AI agent deployments being planned right now.
Model Manipulation and Data Poisoning
Beyond prompt injection, there are attacks against the models themselves. Training data poisoning can embed persistent biases or backdoors. Model inversion attacks can extract sensitive information from a model's parameters. Adversarial inputs can cause consistent misclassification or erroneous decision-making.
These aren't theoretical. They're documented. And they're particularly dangerous because the effects can be subtle — an agent that makes slightly wrong decisions consistently is harder to detect than one that fails spectacularly.
Least Privilege for Machines That Don't Know Their Own Limits
The principle of least privilege is decades old. The challenge is applying it to entities whose behaviour is non-deterministic.
A human user's access needs are relatively predictable. An accountant needs access to financial systems. A developer needs access to code repositories. You can define role-based access controls with reasonable confidence.
An AI agent's behaviour is probabilistic. It might need access to a customer database for most tasks, but occasionally attempt to access a system it's never touched before — not because it's been compromised, but because the model determined it was relevant to the current task. Traditional RBAC doesn't work when the entity requesting access doesn't have a fixed job description.
Just-in-Time Access: The Only Viable Model
The solution is Just-in-Time (JIT) access — dynamic, time-bound, task-scoped permissions that are granted for specific operations and automatically revoked upon completion.
Here's what this looks like in practice:
- Ephemeral credentials: Every agent operation receives a short-lived token scoped to exactly the resources needed for that specific task. No persistent API keys. No long-lived service account passwords. Credentials that expire in minutes, not months.
- Task-scoped permissions: Instead of role-based access, implement task-based access. An agent processing an invoice gets read access to that specific invoice and write access to the payment system — not blanket access to all financial data.
- Automatic credential rotation: After every task completion, credentials are rotated. If an agent is compromised mid-operation, the window of exposure is measured in minutes.
- Approval gates for sensitive operations: Certain actions — accessing PII, modifying configurations, sending external communications — require explicit human approval, even if the agent has the technical capability to proceed.
This is not optional. This is the minimum. Organisations deploying AI agents with static credentials and broad permissions are building insider threats by design.
Zero Trust: Now It Actually Means Something
"Zero Trust" has been the most abused term in cybersecurity marketing for the past five years. Everyone claims to have it. Almost nobody does. But AI agents might finally force organisations to implement it properly — because the alternative is genuinely untenable.
Zero Trust for AI agents means:
Continuous verification. Every action an agent takes is authenticated and authorised individually. Not "this agent was authenticated at session start, so all subsequent actions are trusted." Every single API call, every database query, every file access — verified independently. The identity is confirmed. The permission is checked. The context is evaluated.
Behavioural baselines. If an agent that normally processes 50 records per hour suddenly attempts to export 50,000, that's an anomaly — regardless of whether the credentials are valid. Behavioural analytics must extend to non-human identities, and the baselines need to be tighter, because AI agents don't have "unusual days at the office."
Microsegmentation. AI agents should operate in isolated network segments with strictly defined communication paths. An agent processing customer enquiries has no business reaching your financial infrastructure — even if a prompt injection attack instructs it to try.
Tamper-evident logging. Every action taken by every agent, logged immutably, attributed to a specific agent identity, with full context — what was requested, what was accessed, what was returned, what was modified. Not for compliance theatre. For actual forensic capability when something goes wrong.
Here's what traditional Zero Trust missed that AI agents expose: least-privilege assumptions break down when access expands dynamically through application features. An AI agent operating within a SaaS platform might discover and exploit capabilities that no human reviewer anticipated. The agent doesn't "break in." It walks through doors your architecture left open because it never expected a non-human entity to find them.
The Agent Registry: Know What You've Deployed
You cannot secure what you cannot see. And right now, most organisations have no comprehensive inventory of the AI agents operating within their infrastructure.
An agent registry is not a nice-to-have. It is the foundational requirement for every other control discussed in this article. Every AI agent deployed in your environment — whether built internally, provided by a vendor, or embedded in a SaaS product — must be catalogued with:
- A unique, non-human identity
- Its purpose and scope of operation
- The data sources it can access
- The actions it can perform
- The human owner accountable for its behaviour
- Its model version and last update date
- Its communication pathways — what other agents or systems it interacts with
88% of organisations reported confirmed or suspected AI agent security incidents in the last year. How many of those organisations could even tell you which agents were involved? The answer is discouraging.
Board-Level Accountability: This Is Not an IT Problem
Let's be direct. AI agent security is a governance issue, not a technology issue. And governance means accountability flows to the top.
The EU AI Act doesn't care whether your AI agent was configured by a data scientist or auto-deployed by a vendor. What matters is: does it make decisions that affect people? Is there documented human oversight? Are risks assessed and mitigated? Is there an audit trail?
When an AI agent with privileged access makes a decision that causes regulatory non-compliance, data breach, or financial loss, someone must be accountable. Not "the AI team." Not "IT." A named individual at the leadership level who understood the risks, approved the deployment, and is responsible for the consequences.
This requires three things most organisations don't have:
First: AI risk on the board agenda. Not as a standing item to be skipped. As a quantified risk metric, reported alongside financial and operational risk, with the same rigour. Boards need dashboards that show how many AI agents are deployed, what access they hold, what incidents have occurred, and what the exposure profile looks like.
Second: clear ownership chains. Every AI agent maps to a human owner. Every human owner maps to a business unit. Every business unit maps to an executive who signs off on the risk profile. The chain must be unambiguous and documented.
Third: incident response plans that include non-human actors. Your current incident response playbook almost certainly assumes a human threat actor or a conventional malware infection. What happens when an AI agent is compromised via prompt injection and begins exfiltrating data through legitimate API calls that your SIEM treats as normal traffic? If you don't have a specific, tested answer to that question, you have a gap that matters.
Multi-Agent Systems: The Complexity Multiplier
Everything above becomes exponentially harder when AI agents start talking to each other.
Multi-agent systems — where multiple AI agents interact, delegate tasks, and make interdependent decisions — are no longer research projects. They're shipping in production. And they create emergent behaviours that are fundamentally harder to predict, monitor, and control than single-agent deployments.
When Agent A delegates a sub-task to Agent B, and Agent B accesses a system that Agent A was never authorised to reach — who is responsible? When a chain of agent-to-agent communications amplifies a subtle error into a catastrophic decision — where does the audit trail begin? When a prompt injection in one agent propagates through an entire agent network — how fast can you contain it?
Your governance framework must address agent-to-agent communication protocols, delegation boundaries, and collective decision-making processes. If your current framework covers only human-to-system interactions, it covers roughly half the attack surface that will exist by the end of this year.
What to Do This Quarter
Enough theory. Here is a concrete, prioritised action plan for the next 90 days:
Week 1-2: Discovery. Conduct a full inventory of every AI agent, AI-powered integration, and autonomous process operating in your environment. Include vendor-embedded agents in SaaS products. You will be surprised by what you find.
Week 3-4: Classification. Categorise every discovered agent by data sensitivity, access privileges, and autonomy level. Flag any agent with access to PII, financial data, or critical infrastructure for immediate review.
Week 5-6: Identity remediation. Eliminate shared service accounts for AI agents. Assign unique, non-human identities. Implement credential rotation. Begin migration to JIT access for the highest-risk agents.
Week 7-8: Monitoring. Deploy behavioural baselines for AI agent activity. Configure alerts for anomalous access patterns. Ensure logging captures full agent action chains, not just API calls.
Week 9-10: Policy. Draft and approve an AI agent governance policy that includes deployment approval workflows, access review cadences, incident response procedures, and accountability chains. Get executive sign-off.
Week 11-12: Test. Run a tabletop exercise simulating an AI agent compromise. Specifically: a prompt injection that causes an agent to exfiltrate data through legitimate channels. Measure your detection time, response time, and containment capability. Adjust your controls based on what you learn.
The Bottom Line
AI agents are not a future problem. They're a present reality that's accelerating faster than most security programmes can adapt. The organisations that act now — building identity frameworks, implementing Zero Trust controls, establishing governance structures — will be the ones that deploy AI agents safely and at scale.
The organisations that treat this as "next year's problem" will be the ones filing incident reports and explaining to regulators why an autonomous system with administrative access was running on inherited credentials with no monitoring, no access reviews, and no human accountable for its actions.
Your IAM framework was built for a world where every identity had a heartbeat. That world is over. Build the new one before the old one breaks — because it will break, and it won't ask for permission first.
Deploying AI agents and need security controls that match the risk? Talk to IWH about building identity frameworks for non-human actors before they become your biggest insider threat.