We already have policies and an approval process. Why is runtime visibility a separate problem?

Because a policy is a claim about what should happen and telemetry is evidence about what did. The survey's own numbers show the two coming apart: 82% of executives say their policies protect them from unauthorised agent actions, while 88% of organisations report an incident and only 21% have runtime visibility. Approval gates are also weaker than they look — 80.9% of technical teams have moved past planning into active testing or production, but only 14.4% of those agents went live with full security and IT approval. A policy nobody can measure compliance against is a statement of intent, and an agent is a system whose behaviour is decided at runtime by content the policy author never saw.

Where should a small team start?

Start with egress, because it is the cheapest surface to instrument and it maps to the incident type most likely to become a regulatory problem under India's DPDP Act or UK GDPR. Log every outbound call an agent makes: destination, payload size, the tool that made it, and the task that requested it. Then move to delegated authority — replace shared service accounts with per-task, short-lived, narrowly scoped credentials so an authorisation decision is attributable to a task. Persistent state comes third, and mostly means putting a write-path audit on memory and vector stores so a bad entry can be found, attributed and rolled back. Do all three at trace level rather than log level, so a single incident reads as one causal chain.

88% of Enterprises Hit Agent Security Incidents Last Year

Q: Is the 88% figure trustworthy?

Treat it as directional, not precise. It comes from Gravitee's State of AI Agent Security 2026, a survey of 919 executives and practitioners, and Gravitee sells API and agent governance tooling — a finding that enterprises cannot see what their agents are doing is a finding that supports the product. Self-reported incident surveys also suffer from definitional drift, because one respondent's near-miss is another's incident. What makes the number worth reading anyway is the internal tension rather than the headline: the same survey reports 82% executive confidence in policy coverage and 21% runtime visibility, and a vendor with an axe to grind would have no reason to publish a confidence figure that high. The independent weight comes from the academic literature, not from the survey.

Q: What actually counts as an AI agent security incident?

In the survey the two commonest categories were data leakage, reported by 50.1% of respondents, and manipulation by malicious or untrusted inputs, reported by 49.6%. Those map cleanly onto two of the three threat surfaces in the arXiv survey: leakage is an information-flow failure, and manipulation that causes the agent to act is a delegated-authority failure. The category that barely appears is corruption of persistent state — a poisoned memory entry or vector record that changes behaviour in a later, unrelated run. That absence is more likely to reflect what organisations can detect than what is happening to them.

What the two reports actually say

Two documents worth reading together landed this summer. One is a vendor survey with a headline number engineered to make a board sit up. The other is an academic literature review with no marketing department behind it. The survey tells you how often agents are going wrong. The review tells you where to look. And the survey's own data quietly explains why its respondents cannot answer that second question for themselves.

88% reported an incident. Gravitee's State of AI Agent Security 2026, a survey of 919 executives and practitioners, found that 88% of organisations reported AI agent security incidents in the last twelve months. Healthcare came in higher still at 92.7%, against that 88% all-industry average.
82% believe their policies cover it. Eighty-two per cent of executives say their policies protect them from unauthorised agent actions — held against the 88% who reported an incident, that is the finding worth arguing about.
21% can see what is happening. Only 21% have runtime visibility into what their agents are actually doing.
Leakage and manipulation lead. The commonest incident types were data leakage at 50.1% and manipulation by malicious or untrusted inputs at 49.6%.
Deployment is outrunning sign-off. 80.9% of technical teams have moved past planning into active testing or production, but only 14.4% of those agents went live with full security and IT approval.
The literature agrees on the shape. Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation (arXiv 2606.10749, updated 23 August 2026) synthesises 247 papers published between January 2023 and April 2026, and organises the whole field around three things: information flow, delegated authority, and persistent state.

Belief is not observability

Put the two headline percentages side by side and the shape of the problem becomes obvious. Eighty-two per cent of executives are confident their policies stop unauthorised agent actions. Eighty-eight per cent of organisations had an incident. Twenty-one per cent can watch an agent at runtime. Confidence is running at roughly the same level as incidence, and telemetry is running at a quarter of it.

That is not a policy failure in the ordinary sense. Most of these organisations almost certainly have sensible policies: least privilege, data classification, an approval gate before production. The failure is that a policy is a claim about what should happen, and without runtime telemetry nobody can produce evidence about what did. You cannot audit a control you cannot observe, and an agent is precisely the kind of system where the gap between intent and behaviour is decided at runtime, by content the policy author never saw.

The approval-gate numbers make the same point from the other direction. If 80.9% of technical teams are past planning and into testing or production while only 14.4% of those agents shipped with full security and IT approval, then the gate is not holding. It is not obvious it could — agents are cheap to stand up, they look like an internal tool rather than a system integration, and the risky part is a set of tool permissions that never appear in a design document.

Now the caveat, plainly stated: Gravitee sells API and agent governance tooling. A finding that enterprises cannot see what their agents are doing is a finding that sells the product, and self-reported incident surveys drift on definitions, because one respondent's near-miss is another's incident. So read the 88% as directional rather than precise. What makes the survey worth citing anyway is its internal tension rather than its headline — a vendor optimising purely for alarm has no reason to publish an 82% executive-confidence figure, which is the number that does the actual analytical work. And the independent weight sits elsewhere: with the arXiv survey, whose authors are academics at Nanjing University and the Technical University of Munich with no product to sell.

Three surfaces: information flow, delegated authority, persistent state

The arXiv survey — Yuchen Ling, Shengcheng Yu, Zhenyu Chen and Chunrong Fang — is useful for a reason beyond its coverage. Rather than cataloguing attacks by name, it builds a lifecycle-based, systems-oriented framework and models agent security around three properties: how information flows into and out of the agent, how much authority the agent has been delegated, and what state it carries forward between runs. Its framing is worth quoting in substance: failures are no longer limited to unsafe text generation, because untrusted content may redirect control flow, misuse tool privileges, corrupt persistent state, leak sensitive information, or trigger harmful external actions.

That triad is the most useful thing either document offers, because it turns the survey's incident categories from a list into a map. Data leakage is an information-flow failure. Manipulation that causes the agent to act is a delegated-authority failure. And the third surface is the one nobody filed an incident for.

Threat surface	What it looks like in production	Survey signal	What to instrument
Information flow	Untrusted content — a fetched page, a customer PDF, an email body, a tool result — enters the context window and changes what the agent does next, or sensitive context leaves through a tool call nobody was watching	Data leakage, 50.1%	Provenance tags on every context segment, so trusted instruction and untrusted content are distinguishable; egress logging of what left the boundary, to where, and at whose request
Delegated authority	The agent holds a credential broader than the task needs and calls a tool it was talked into calling — the refund issued, the record deleted, the ticket escalated, the file written	Manipulation by malicious or untrusted inputs, 49.6%	Per-task, short-lived, narrowly scoped credentials instead of a shared service account; every authorisation decision logged against the task that requested it
Persistent state	Memory entries, vector records, scratch files and shared task queues carry a poisoned item forward into a later, unrelated run — and into other agents that read the same store	Not separately reported	Write-path audit on memory and vector stores; the ability to diff, attribute and roll back an individual entry; provenance on retrieved records at read time

On the first two surfaces the literature is dense. The arXiv survey finds that prompt injection and tool-mediated control-flow hijacking dominate the papers it reviewed — unsurprising, given prompt injection is ranked LLM01, the top entry, in the OWASP Top 10 for LLM Applications. There is no shortage of published defensive technique here; our own walkthrough of defence in depth against prompt injection covers the layers, and the delegated-authority half is a well-understood identity problem once you stop treating the agent as a single principal, which is the argument in token exchange for sub-agents.

The surface nobody filed an incident for

Persistent state corruption and multi-agent propagation are named in the arXiv survey as emerging concerns — thinner in the literature than injection, but rising. They are almost invisible in the incident data, and the reason is not that they are not happening. It is that a corrupted memory entry does not present as an incident. It presents as an agent that behaves oddly next Tuesday, in a different session, for a different user, on a task unrelated to the one that planted it.

This is where the 21% figure stops being an abstraction. Detecting an information-flow failure needs egress logs. Detecting a delegated-authority failure needs an audit trail of tool calls. Detecting a persistent-state failure needs both of those plus write-path provenance on your memory layer and the ability to trace a bad output back through a retrieval to the run that wrote the record. Almost nobody has the third, so almost nobody reports the third.

Watch out

An incident type that does not appear in your data is not evidence of absence — it is usually evidence of a missing sensor. Persistent state is the clearest case: the harm is separated from the cause by hours or days, by session boundaries, and often by a different user entirely. If your memory and vector stores have no write-path audit, a poisoned entry is not an incident you failed to escalate. It is an incident you had no mechanism to notice, and in a multi-agent setup it can propagate to every agent reading the same store before anyone does.

The practical answer is that agent telemetry has to be causal rather than categorical. Logs tell you a tool was called. Traces tell you which retrieved document was in context when it was called, and which earlier run wrote that document. That is a tracing problem with an established shape — spans, attributes, tail sampling — and it is why instrumenting agents with OpenTelemetry is a security investment and not just a cost-attribution one. It is also the cheapest way to close the distance between the 82% who believe and the 21% who can demonstrate.

Every article here is written by a Verified Builder. Want your name on the next one?

AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.

Become a Verified Builder →

In India and the UK, a leak is a reportable event

Data leakage at 50.1% is the incident type that leaves engineering and becomes somebody else's problem. Under India's Digital Personal Data Protection Act, a personal data breach carries notification duties to the regulator and to affected individuals. Under UK GDPR the equivalent obligation sits with the Information Commissioner's Office. Neither regime cares whether the exfiltration path was a misconfigured bucket or an agent that was talked into summarising a customer record into an outbound email. The reporting clock is the same, and the clock starts when you become aware.

Which is where the observability gap acquires a cost. A team with 21%-grade visibility cannot answer the questions a notification requires: which records, whose, through which path, over what window. That is not a policy question — no policy document answers it. It is a query against telemetry you either kept or did not.

There is a market-access dimension as well. The EU AI Act's transparency obligations came into application in August 2026, and they apply on the basis of where a system is placed on the market rather than where the vendor is incorporated. A Bengaluru product company selling an agent into a German manufacturer, or a London agency shipping one to a Dutch bank, is inside that perimeter regardless of domicile. The clause detail is worth reading properly rather than summarising from a headline, but the direction is not in doubt: buyers' security questionnaires, in Chennai and Manchester alike, now ask for runtime evidence rather than a policy PDF.

What proves you can do this work

The hiring consequence of an 88% incident rate is straightforward. Agent security is becoming a named, budgeted role in both markets — inside Indian GCCs building platform teams around agent deployments, and inside UK consultancies and fintechs who have to answer client questionnaires about it. What is scarce is not enthusiasm but evidence: nearly everyone applying has read about prompt injection, and very few can show what they did about it. The distinguishing artefact is a public one, and it looks like one of three things.

A threat model for a real agent, written against the three surfaces. Take something you actually built — a support agent, an internal RAG assistant, a code-review bot — and enumerate, per surface, what untrusted content can reach the context, which tools are reachable and with whose authority, and what state survives the run. Two pages of this, specific and unflattering about your own system, beats any certificate.
A tool-permission audit. List every tool the agent can call, the credential it calls with, the blast radius of the worst plausible call, and the narrower scope it should have had. Most audits of this kind end with a shared service account being replaced by per-task tokens, which is a concrete, describable before-and-after.
An eval harness that tries to break your own agent. Injection payloads in retrieved documents, a tool call the agent should refuse, a memory entry designed to fire two sessions later. Wire it into CI and report the pass rate honestly, including where it fails. Our guide to adversarial safety evals for LLM apps covers the harness shape; the value is in publishing your actual numbers, not the framework choice.

Pro tip

Pick the smallest agent you have already shipped and write the tool-permission audit first — it is a single afternoon and it produces a number you can quote in an interview, such as the count of tools reachable with a credential broader than the task required. Publish it with the fix alongside the finding. Hiring managers in both markets have read a great many prompt-injection explainers and almost no evidence that a candidate has actually reduced an agent's blast radius.

The wider ecosystem context is not reassuring, either. A large-scale audit of MCP servers found how loosely much of the tool layer under these agents has been assembled — which matters here, because delegated authority is exercised through exactly that layer. An agent is only as constrained as the tools it can reach, and most teams inherited those tools rather than reviewing them.

None of this requires waiting for a standard to settle. The triad is stable enough to design against today: know what enters the context and where it came from, know what authority each call carries and why, know what survives the run and who can change it. Instrument all three, and the 82% belief becomes something you can evidence. Instrument none, and next year's survey will report a similar number, and your organisation will still not know whether it is in it.

Primary sources: Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation at arxiv.org/abs/2606.10749, and the OWASP Top 10 for LLM Applications at owasp.org. Survey figures are from Gravitee's State of AI Agent Security 2026.