75% Say Their Agents Are Secure End to End. 88% of Them Had an Incident Anyway

Surya Pratap
By Surya Pratap

September 12, 2026

12 min read

AI & Technology
A chart pairing four enterprise confidence figures with the control that would make each one true: 77 percent believe they have a complete inventory of every agent against 44 percent who run active discovery; 74 percent trust their testing to catch a production-impacting failure against 19 percent with a gate that automatically blocks a bad release; 76 percent believe they could disable a misbehaving agent in under fifteen minutes against 33 percent with an instant kill switch; and 75 percent who call their agents secure end to end, whose security incident rate of 88 percent is marked as indistinguishable from the 87 percent recorded across the whole sampleFour claims, four controls, one flat lineHover to explore
The first three bars are gaps you can close this quarter. The fourth is the finding: believing you are secure moves the incident rate by one point, in the wrong direction.

There is a specific kind of survey finding that is worth more than the headline it gets, and Harness published one on 10 September 2026.

Four questions, asked four ways, produced the same shape every time: a large majority is confident, and a small minority has the control that would make the confidence true. That part is ordinary. The part that is not ordinary is what happened when the confident group's actual outcomes were checked.

1. What was measured

The State of Agent DLC 2026, fielded by Sapio Research for Harness in July 2026: 700 technology professionals, all at organisations with 1,000+ employees, 100+ developers and over $100M in annual revenue, across the United States, the United Kingdom, France, Germany and India.

One screening rule does most of the work in reading it: non-adopters were excluded. Every respondent already had agents running in production, in pilot, or at proof of concept. This is not a survey about whether enterprises will adopt agents. It is a survey of the ones that already did, which makes it the closest public approximation of your buyer.

Harness's own framing is useful even if you never buy anything from them — the Agent DLC, the lifecycle for building, testing, securing, deploying and governing an agent, as distinct from the software lifecycle the agent takes part in. It exists, in their words, because "agent behavior varies from run to run, and standard testing and release checks weren't designed for that kind of variability."

2. The same gap, four times

Confidence, and the control underneath it

Each pair is one question about belief and one about mechanism

  • Inventory. 77% are confident they have a complete inventory of every agent, MCP server and LLM in their environment. 44% run active discovery tooling to verify it.
  • Testing. 74% are confident their testing would catch a production-impacting failure. 19% have a gate that automatically blocks every bad release.
  • Containment. 76% believe they could disable a misbehaving agent in under fifteen minutes. 33% have an instant kill switch.
  • Spend. 74% report complete visibility into what each agent costs. 60% went over budget last quarter.

Each of those is a gap between a claim and the thing that would make the claim checkable. The inventory one is the cleanest: 33 points of the population believes it knows what is running because nobody has told them otherwise.

3. The finding that makes the rest matter

Any of those pairs could be explained away. A team can have a real inventory without discovery tooling if the estate is small enough to hold in your head. Confidence can be earned rather than assumed.

So the useful question is whether the confident group does better. Harness reports that 75% say their agents are secure end to end — and that this group experienced security incidents at 88%, against 87% across the whole sample.

Believing your agents are secure moved the incident rate by one point, in the wrong direction. Confidence is not a leading indicator of anything.

One point on a 700-person sample is noise; the honest reading is not that confidence is harmful but that it is uncorrelated with outcome. That is a stronger and more uncomfortable result than any of the individual gaps, because it removes the obvious defence. A team cannot look at the 44% discovery number and conclude that they are in the competent fraction on the basis of feeling competent. Feeling competent is exactly what does not separate the two groups.

It also sets the base rate: 87% of these organisations had an agent-related security event in the past year. Not a risk. An event, already, at nearly seven in eight.

4. Why this is not just cloud again

The comforting story is that this is a phase. Every platform shift outruns its controls, then the controls catch up. Harness's Field CTO and Head of Research, Keith Mann, names the reason that story might not hold here:

Keith Mann, Field CTO and Head of Research at Harness

Cloud and mobile both went through a phase where confidence outran governance, but eventually the controls caught up because the underlying systems stayed predictable once you built the guardrail. Agents don't hold still in the same way.

That is the whole technical argument in one sentence, and it is correct. A guardrail works when the same input produces the same behaviour, so a test that passed yesterday means something today. An agent's behaviour varies run to run — same prompt, different tool calls, different path, occasionally a different outcome. Testing that samples behaviour once and declares it safe is measuring a draw from a distribution and reporting it as a fact.

The survey's process numbers show the consequence. Only 53% run agent changes through standard pipelines before production, 37% put fewer than half of their changes through any established pipeline, 42% route prompt edits through code pipelines at all, and just 34% have a dedicated system for AI configuration. Over 40% decide case by case whether a change can be trusted.

That last one is the mechanism behind every gap in section 2. A case-by-case decision cannot be audited, cannot be delegated, and cannot be shown to a buyer. It is also the reason 58% report more production incidents per 100 changes since deploying agents: the change volume went up and the gate did not.

5. If you sell agent products into these companies

This is the part I would act on this week. Your buyer is in that 700. Three things follow.

Their stated maturity is not their real maturity

One
The security questionnaire you are asked to complete was written by a team with a 77% belief in its own inventory and a 44% chance of tooling behind it. Do not calibrate your product to the questionnaire. The gap is where your differentiation lives: build for the control they do not have, not the one they claim.

Ship evidence, not assurance

Two
Everyone in this market says "secure", "governed", "observable". Those words now carry no information, because 75% of buyers say them about themselves while running at the base incident rate. What carries information is an artefact: a per-run trace, an exportable action log, a documented kill path with a measured time. Sell the thing that survives a sceptic.

Be the inventory, don't add to it

Three
Every agent you deploy inside a customer becomes another entry in an estate that 56% of them have no discovery tooling for. A product that registers itself, declares its tools and permissions, and reports what it did is solving their actual problem as a side effect of being well built. A product that is one more opaque process is competing with their anxiety.

There is a commercial reading too: 76% told Harness they see high or moderate value in a unified control platform. Demand for the governance layer is real. It is also exactly what the survey's publisher sells, which brings us to how much of this to believe.

6. If you are running agents yourself

Most founders reading this are not the 1,000-employee enterprise. You are three people with four agents in production, and the honest news is that every one of these controls is cheap now and expensive later. In the order I would build them:

A kill switch you have actually pulled

First
One flag, checked by every agent before it acts, that stops all of them. The 76%/33% gap is not really about tooling — it is that most teams have never tested the path. Build it in an afternoon, then pull it in production once, on purpose, and time it. An untested kill switch is a belief, and beliefs are what this survey measured.

An inventory that cannot drift

Second
Not a spreadsheet. A registry the agent has to appear in to get credentials — no entry, no key, no run. Discovery tooling exists because inventories maintained by hand are wrong within a quarter. At your size you can make the inventory a precondition instead of an audit, which is the version large enterprises cannot retrofit.

One gate that blocks, not warns

Third
Given run-to-run variance, a single-sample test proves little — so evaluate the change n times and gate on the distribution, not on one green run. Even a crude bar (this task must succeed 19 times in 20 before it ships) puts you ahead of the 81% without one.

Cost per completed task, per agent

Fourth
The 74%-visibility, 60%-overran pair is the most familiar failure in this list: per-call spend is visible, per-outcome spend is not, and agents retry. Instrument the unit that matters — the finished piece of work — or you will discover the number in a monthly invoice, which is the same way the 60% discovered theirs.

None of these is a platform. They are an afternoon each, and they are the difference between an agent product you can sell to a cautious buyer and one you can only demo.

7. How much of this to believe

Stated plainly, because the house rule here is that a number's provenance travels with it:

Discounting the survey

Harness sells the missing controls. This is a vendor-commissioned survey whose every finding points at a unified control plane, which is the product. That does not make the numbers wrong — Sapio is an independent field house, the sample is large and the screening is disclosed — but it does mean the questions were chosen by someone with an answer. Read it as a well-measured description of a gap, not as a neutral judgement about what closes it.

Three more caveats worth carrying:

It is all self-report. Both halves of every pair are what a respondent said, including the incident rates. The 88%-versus-87% comparison is robust to that in a way the absolute numbers are not: whatever bias makes people overstate their controls should also make them understate their incidents, in both groups.

July is old. The field date is July 2026 and the agent tooling market has moved twice since. Some of the 19%-with-a-gate number is simply that the gates did not exist yet.

These are not your constraints. 1,000+ employees, 100+ developers, $100M+ revenue. A twelve-person company does not need the governance apparatus this report is implicitly selling. It needs the four things in section 6, and it needs them to actually work.

8. Where I would land

A straight answer by situation

The gap is an opportunity for exactly one of these groups

  • Selling agent infrastructure or tooling. The 44%, 19% and 33% are your market, sized. Build the control, then prove it with an artefact the buyer can inspect without trusting you.
  • Selling an agent product into the enterprise. Assume your buyer cannot enumerate their own estate and has had a security event this year. Arrive with the trace, the log and the kill path already built; you will be the only vendor who does.
  • Running agents in your own small product. Kill switch, registry, one blocking gate, cost per completed task. Four afternoons, in that order, before the next feature.
  • Considering agents and not yet started. Note that the base rate for an agent-related security event among adopters is 87%. Plan for the event rather than for its absence — that is a design input, not a reason to wait.
  • Confident your setup is fine. So were three quarters of a 700-person sample whose incident rate was identical to everyone else's. The only way out of that group is a measurement, not a conviction.

The honest summary

The four gaps in this report are the story everyone will quote, and they are real: most teams cannot enumerate their agents, cannot block a bad release automatically, cannot demonstrate a kill path, and cannot say what an agent costs per unit of work.

But the finding worth keeping is the flat one. Self-assessed security predicted nothing about incidents — 88% against 87%, which is to say no signal at all. Everything an enterprise buyer tells you about their controls, and everything you tell yourself about yours, has just been shown to be uninformative on its own.

Which leaves the only durable move: replace the claim with the artefact. Not "we have an inventory" but a registry that issues the credentials. Not "we could shut it down" but a stopwatch reading from the last time you did. The teams that will look competent in next year's version of this survey are the ones who can show, not say — and at founder scale that is still a week of work rather than a platform migration.

Sources: Harness, "The State of Agent DLC 2026" · PR Newswire, "New Harness Report Reveals Enterprise Confidence in AI Agents Isn't Backed by Real Controls," 10 September 2026 · Survey conducted by Sapio Research, July 2026, among 700 technology professionals at organisations with 1,000+ employees, 100+ developers and $100M+ revenue in the US, UK, France, Germany and India; non-adopters excluded. All statistics and both executive quotes are as reported by Harness and are self-reported by respondents. The reading of confidence as uncorrelated with outcome, the discounting in section 7 and every recommendation are mine. For the same gap measured a different way, see 85.5% of engineers trust their agents and half hit problems daily.

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :