The Security Problem Nobody Solved Before Deploying

Agents differ from previous software in one respect that changes the whole security picture: they take actions, and nobody wrote down in advance which actions those would be.

The result is documented and uncomfortable.

For a vendor-side perspective on self-reporting bias, see this page from Monitask.

What the surveys report

The 2026 State of AI Agent Security report found that 88% of organisations confirmed or suspected AI agent security incidents in the past year — rising to 92.7% in healthcare — while 81% of teams are past the planning phase and only 14.4% have full security approval.

The report describes practitioner accounts of agents gaining unauthorised write access to databases and attempting to exfiltrate sensitive information, and concludes that the core of the problem is identity: only 21.9% of teams treat agents as independent, identity-bearing entities rather than extensions of human users or generic service accounts.

A separate 2026 survey found only 24.4% of organisations have full visibility into which agents are communicating with each other, with more than half of agents running without security oversight or logging, and 63% unable to enforce purpose limitations on what their agents are authorised to do.

Deloitte's survey of 3,235 leaders found 73% citing security and data privacy as top concerns, while only 21% have a mature governance model.

Several of these are published by vendors selling agent security and governance products. The direction is consistent across sources and the precise percentages should be read with that in mind.

Why agents break the existing model

Security was built around humans and around programs that do one predictable thing. An agent is neither.

It acts, and the actions are not enumerated in advance. Traditional software does what it was written to do. An agent does what it decides to do within its permissions, which means the permissions are the only real control.

It is not a person. Access control, audit and accountability all assume a human identity behind an action. Attaching an agent to a human's credentials means every action it takes appears to have been taken by that person.

It is not an ordinary service account either. Treating agents as generic service accounts is exactly the pattern the security research identifies as the root problem — a shared account gives no way to distinguish which agent did what, or to revoke one without breaking others.

It reads untrusted input and then acts on it. This is the property that creates an entirely new attack class. See prompt injection.

And it may talk to other agents, in chains where nobody has full visibility.

The four problems, in order

1. Identity

An agent needs its own identity, distinct from any human and from generic service accounts — so that actions attribute to it, permissions apply to it, and it can be revoked individually.

This is the foundation, and getting it wrong makes everything below impossible. See agent identity.

2. Permissions

The question is not what the agent needs to do its job. It is what it must never be able to do.

Over-permissioning is the norm because it is easier and because narrowing permissions requires knowing what the agent will do, which is exactly what is uncertain.

Read access is not safe by default. An agent that can read everything and write nothing can still exfiltrate through its outputs.

See permissions.

3. Observability

More than half of agents reportedly run without oversight or logging. Which means when something goes wrong, there is no record of what happened.

Log the actions, not just the conversation. Which tool, which arguments, which result, on whose behalf, at what time.

See logging and audit trails.

4. Purpose limitation

63% of organisations cannot enforce limits on what their agents are authorised to do.

An agent deployed for one purpose that can be redirected to another is a general-purpose tool inside your systems with somebody else's instructions available to it.

Shadow deployment

The pattern behind much of the incident data.

81% of teams past planning against 14.4% with full security approval describes a large population of agents running without review.

Teams deploy because it is easy. A model provider, a few tool connections, and an agent is touching production data before anyone has assessed it.

The practical response is not prohibition, which drives it further underground. It is making the approved route fast enough that people use it, and having visibility into what exists.

What to do first

In order, for an organisation at any size.

Inventory what already exists. Most organisations underestimate this. Ask, do not assume.

Give agents their own identities. Not shared accounts, not human credentials.

Define what each must never do, before defining what it may. For broader independent background, see OWASP GenAI Security Project.

Log every action with attribution, from day one — retrofitting is the expensive discovery described in the failure data. See where agent projects fail.

Put a human in the loop at the points where an error is expensive. See human oversight.

Treat any content the agent reads as untrusted, including documents, emails, web pages and tickets.

Have a way to stop it. A single control that halts agent activity, tested before you need it.

For small teams and individuals

The surveys describe enterprises. The principles apply at any size and the practice differs.

Do not give an agent credentials to anything you could not afford to have wrong. Financial accounts, customer data, production systems.

Prefer read-only access where the task allows it.

Review before send. Anything going to a customer or a public channel.

Use separate accounts rather than your own, so you can revoke them.

Watch the bill. An agent in a loop can consume a great deal quickly. See what agents cost to run.

See agents for a one-person business.

The honest framing

None of this means agents should not be used. It means the security work is part of the deployment rather than a later phase, and the data shows what happens when it is not.

The incident numbers are high partly because deployment outran review, which is a solvable sequencing problem rather than a property of the technology.

And the organisations rebuilding their permission architecture after a pilot are paying for a decision that would have cost little at the start.

The short version

88% report confirmed or suspected incidents; 14.4% have full security approval. Deployment outran review.

Identity is the root problem — only 21.9% treat agents as entities with their own identity rather than borrowed human or shared service credentials.

Define what the agent must never do before what it may do.

Log every action with attribution from day one, because retrofitting it is what stalls projects at security review.

And treat everything the agent reads as untrusted input, because that is the attack class agents introduced.