AI Agent Security in the Enterprise — Why 88% of Companies Have Already Had an Incident

AI agents are everywhere. They answer customers, approve invoices, analyse contracts, write code and autonomously call third-party APIs. Yet while 81% of technical teams already have agents in testing or production, only 14% of them have gone through a full security approval process. The result? 88% of organisations report a confirmed or suspected security incident involving AI agents. This article examines why this is happening, where the biggest gaps are — and above all, what to do about it.

State of the Market: Adoption Has Outpaced Security¶

The Gravitee State of AI Agent Security 2026 report, which analysed hundreds of organisations across industries, revealed a troubling gap between AI agent adoption and security. The numbers speak for themselves:

80.9% of teams have AI agents in testing or production

14.4% have full security/IT approval for all agents

88% of organisations report an AI agent security incident

47.1% of agents are actually monitored

The most alarming finding is the disconnect between leadership and reality: 82% of executives believe their organisation is adequately protected — while less than half of all agents are even under surveillance. That is not optimism; it is an illusion of security. And it is precisely this illusion that leads to problems being addressed only after an incident, rather than preventively.

The healthcare sector leads the statistics with 92.7% of organisations reporting incidents, but financial services and manufacturing are not far behind. According to a Dark Reading survey, 48% of security professionals believe agentic AI will be the primary attack vector by the end of 2026. And in January 2026, the US government published a Request for Information on AI agent security, because vulnerabilities in agentic systems can endanger critical infrastructure.

The problem is not that organisations do not want security. The problem is that AI agents are a fundamentally different technology from anything existing security models were designed for. An agent is not an API endpoint. An agent is an autonomous entity that makes decisions, calls tools, chains actions and interacts with other agents. And security frameworks are not ready for that.

Biggest Risks: From Shadow AI to Prompt Injection¶

When OWASP published the Top 10 for LLM Applications (2025 update), it added Excessive Agency among the top threats — a situation where an LLM application is given too many permissions and too much autonomy. For agents, which are by design built for autonomous action, this risk is even more pronounced. Let us look at the specific threats:

Shadow AI — Invisible Agents¶

Developers and business teams deploy AI agents faster than the security team can audit them. An agent connected to the corporate CRM via an employee’s personal API key. A GPT wrapper that has access to internal documents through an unauthorised plugin. A Copilot that automatically commits to a production repository. Shadow AI is the new shadow IT — with the difference that an agent actively takes action, while the old SaaS application merely stored data passively. Without visibility into how many agents are running in your organisation, you cannot secure even one.

Prompt Injection & Tool Poisoning¶

Prompt injection remains at the top of the OWASP Top 10 for LLMs. But with agents, the impact is orders of magnitude worse: an injected prompt does not just change text output — it triggers real actions. An agent with access to email, a database and a payment system can, after a prompt injection, send data to an attacker, delete records or authorise a transfer. Tool poisoning — where an attacker manipulates the description or output of a tool the agent uses — is another vector that traditional security tools do not detect, because it looks like a legitimate interaction.

Uncontrolled Action Chaining¶

An agent typically does not perform a single action — it performs a chain of actions. Read an email → extract data → call an API → write to a database → send a notification. Each step in the chain is a potential failure point. If the agent processes manipulated data from step 1 in step 2, the remaining steps execute with contaminated input. The Microsoft Security Blog emphasises that an agent’s components — topics, tools and knowledge sources — define its attack surface. The more tools an agent has, the larger the attack surface.

Shared Credentials and Over-Permissioning¶

45.6% of organisations use shared API keys for agent-to-agent authentication. This means that compromising a single agent gives the attacker access to all services that all agents with the same key can reach. A classic blast radius problem — but in the context of autonomous entities that decide for themselves what to do with that access. The principle of least privilege, a cornerstone of Zero Trust, is systematically ignored for AI agents.

Why Identity Management Is the Weak Point¶

Only 21.9% of teams treat AI agents as independent identity-bearing entities. The rest handle them either as extensions of a human user or as just another microservice without its own identity. Both approaches are dangerous.

An agent running under the identity of its creator (a developer) inherits all of their permissions — often including admin access to production systems. An agent without its own identity is invisible in the audit log. When something goes wrong, there is no way to trace back which agent did what and why.

The correct approach is clear: every AI agent needs its own identity in the identity management system — just like every employee or service account. This identity must have:

• Unique credentials — no shared API keys, no inherited tokens
• Explicit permissions — scoped to the specific actions and resources the agent needs
• Auditability — every agent action must be loggable and attributable
• Lifecycle management — creation, credential rotation, deactivation, deletion
• Contextual policies — the agent may call the payment API only during business hours, only from the production environment, only for amounts below a threshold

This is not an academic exercise. In practice, it means your organisation must extend its existing IAM (Identity and Access Management) system with a new entity type — a “non-human identity” with agent-specific attributes: model, version, owner, purpose, permitted tools and maximum autonomy. Platforms such as Microsoft Entra Workload ID or HashiCorp Vault already support this category. The question is whether your organisation actually uses it.

Runtime vs. Build-Time Security: Why Testing Before Deployment Is Not Enough¶

Most organisations that address AI agent security at all focus on build-time controls: code review, prompt testing, red teaming before deployment. That is necessary — but far from sufficient. The Microsoft Security Blog states it directly: runtime security checks are critical, because agent behaviour in production differs from what you saw in the test environment.

Why? Because the agent’s input — user prompts, data from external sources, API responses — changes in real time. An agent that worked flawlessly in testing can encounter adversarial input in production that nobody anticipated in testing. Build-time testing catches known patterns; runtime monitoring catches what you could not have imagined.

What Runtime Security Means in Practice¶

• Webhook-based runtime checks — before every risky action (calling an external API, writing to a database, sending an email), the agent sends a webhook to a security endpoint that approves or denies the action in real time
• Orchestrator-level guardrails — the framework (LangChain, CrewAI, Semantic Kernel) enforces limits: maximum number of steps, permitted tools, prohibited actions, output filtering
• Anomaly detection — monitoring detects unusual patterns: the agent suddenly calls an API it has never used before; request volume is 10× higher than baseline; the agent attempts to access data outside its scope
• Human-in-the-loop for critical actions — approval for actions above a defined risk threshold (financial transactions, data deletion, communication with external systems)
• Session isolation — each agent conversation/task runs in an isolated context so that data from one session does not leak into another

The difference between build-time and runtime security for AI agents is analogous to the difference between static code analysis and runtime application security (RASP) for traditional applications. You need both. But if you have to choose, runtime monitoring tells you the truth about what is actually happening — not what was supposed to happen.

5 Steps to Securing AI Agents¶

AI agent security is not a one-off project — it is an extension of your existing security programme to cover a new category of entities. The following five steps will help you get started pragmatically, without unnecessary paralysis.

Step 1 — Inventory

Find Out How Many Agents Are Running in Your Organisation¶

Before you secure anything, you need to know what you are securing. Conduct an audit: which AI agents exist, who created them, where they run, what they have access to and who owns them. Include “unofficial” agents — Copilot plugins, GPT wrappers, Zapier/Make automations with LLM steps. Shadow AI is a real problem, and without an inventory you are building defences blindly. The output should be a central agent registry classified by risk (access to sensitive data, financial permissions, external communication).

Step 2 — Identity & Access

Assign Every Agent Its Own Identity¶

Extend your IAM system with non-human identities for AI agents. Every agent must have unique credentials, explicitly defined permissions (least privilege) and a lifecycle. Eliminate shared API keys — replace them with short-lived tokens with automatic rotation. Implement conditional access: the agent may perform sensitive actions only under defined conditions (time, environment, volume). Connect agent identities to your SIEM for an audit trail.

Step 3 — Runtime Monitoring

Deploy a Runtime Security Layer¶

Implement webhook-based or middleware-based runtime checks. Every risky agent action (calling an external API, writing to a production database, sending data outside the organisation) should pass through a security gateway that evaluates the context and decides: allow, deny or escalate. Integrate with your observability stack — metrics, logs and traces from agents are just as important as from microservices. Define behavioural baselines and alert on anomalies.

Step 4 — Guardrails & Governance

Define What the Agent May and May Not Do¶

Every agent needs an explicit security policy: permitted tools, maximum number of steps in a chain, prohibited actions, output filtering rules and escalation thresholds. Use the OWASP Top 10 for LLM Applications as a checklist: prompt injection protection, training data poisoning prevention, supply chain tool verification, excessive agency limits. Define policies as code (policy-as-code), version them in Git and deploy via CI/CD — just like infrastructure policies in a Zero Trust model.

Step 5 — Testing & Red Teaming

Test Like an Attacker, Not a Developer¶

Establish regular red teaming focused specifically on AI agents: prompt injection attempts, tool poisoning, privilege escalation through action chains, data exfiltration via side channels. Test not just individual agents but also their interactions — multi-agent systems exhibit emergent behaviour that does not manifest in individual agents. Automate basic tests (OWASP LLM test suite) and supplement with manual red teaming for creative scenarios. Repeat whenever the model, tools or permissions change.

Conclusion: Agents Are Not Just Another API — Treat Them Accordingly¶

AI agents are the fastest-adopted enterprise technology of the past decade. And simultaneously the fastest-ignored from a security perspective. 88% of organisations with a security incident is not a statistical anomaly — it is the natural consequence of giving autonomous systems access to sensitive data and critical processes without adequate controls.

The solution is not to stop adoption — that would be like refusing the cloud in 2015. The solution is to extend the security model: add agents as a new identity category, introduce runtime monitoring, implement guardrails and test like an attacker. Organisations that do this now will have a competitive advantage. Those that postpone it will be handling incidents.

Start with the simplest step: find out how many agents are running in your organisation. The answer will probably surprise you.