40% of Enterprise Apps Will Ship an Agent. Almost None Will Ship a Blast Radius

Gartner’s projection is that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. Their upside case has agentic AI driving around 30% of enterprise application software revenue by 2035.

Assume the direction is right even if the number moves. That means most business software your organisation runs will, within about eighteen months, contain something that takes actions on your data without a human pressing the button for each one.

Almost every team building one of those is spending their effort on capability. Very few are spending it on the thing that determines whether the agent survives contact with production: what happens when it is wrong.

Assistants and agents are different risk objects#

The distinction Gartner draws is the right one and it is worth being pedantic about, because the governance implications are entirely different.

An assistant drafts, suggests, summarises. It depends on human input and a human commits the result. If it hallucinates, a person catches it or does not, but the failure is bounded by the review step.

An agent has task specialisation and takes actions. It calls tools. It writes to systems. It can chain steps without returning to a human between them.

The moment you cross that line, you have not added a feature. You have added a new principal to your security model — one that authenticates as something, holds permissions, acts asynchronously, and whose behaviour is not deterministic. Most organisations have a mature process for granting a new employee access to systems and no process at all for granting an agent access to the same systems.

The five controls that decide whether this is safe#

These are what we insist on before an agent touches a production system. None of them are exotic. All of them are routinely skipped because the demo did not need them.

1. A scoped identity, not a service account with everything.

The default implementation gives the agent the same credentials as the application, which typically means broad database access. That is the single worst decision in the build. An agent should have its own identity with the narrowest permission set that lets it do its specific job, and that permission set should be readable in one place.

The test: can you answer, in under a minute, exactly which tables and which endpoints your agent can write to? If not, your blast radius is undefined, which in practice means it is everything.

2. Idempotency on every write.

Agents retry. Frameworks retry. Users click again. Networks time out after the write succeeded but before the response returned. An agent that issues a refund, sends a message, or creates a record must carry an idempotency key so the second attempt is a no-op rather than a duplicate.

This is the most common bug we find in agent deployments, and it is invisible in testing because you rarely trigger a partial failure by hand. It surfaces in production as duplicate invoices.

3. A reversibility classification on every tool.

Sort every action the agent can take into three buckets and enforce them differently:

• Reversible — updating a draft, adding a tag, writing to a scratch table. Let the agent proceed.
• Reversible with cost — sending an internal notification, reassigning a ticket. Let it proceed, log loudly, make undo easy.
• Irreversible — money movement, external communication, deletion, anything touching a regulated record. Human confirmation, always.

The mistake is treating this as a policy question. It is a code question: the irreversible tools should be behind a different interface that structurally cannot be called without an approval token.

4. An audit trail that reconstructs the decision, not just the action.

“Agent updated record 4471” is useless in an incident. You need the prompt, the retrieved context, the model and version, the tool calls with arguments, and the outputs — enough to answer why it did that six weeks later when someone complains.

This is a storage problem people under-budget. Full traces for a busy agent are large. Store them anyway, with a retention policy, because the first serious incident will otherwise be unresolvable and you will end up disabling the whole feature.

5. A kill switch someone other than the author can find.

A per-agent feature flag, documented in the runbook, that any on-call engineer can flip without a deploy. If disabling your agent requires a code change and a release, your mean time to recovery during a bad incident is a deploy cycle, and that is not acceptable for a component that can act autonomously.

The organisational failure underneath#

Here is the pattern I see repeatedly, and it is not really a technical one.

The agent is built by a product team under time pressure. It works well in the happy path. It ships behind a small rollout. Security reviews it as an application feature, because that is the box it arrived in, and applies application-level controls — authentication, input validation, rate limits.

But the agent is not a feature. It is a non-human actor with delegated authority, and the correct review model is closer to onboarding a contractor with system access than to shipping a form. Nobody owns that review, because identity governance covers humans and application security covers code, and an agent falls in the gap between them.

Fixing this is cheap if you do it before you have thirty agents. Maintain a register: every agent, its owner, its identity, its permission scope, its irreversible actions, its kill switch, its audit location. One table. Review it quarterly. If Gartner is even directionally right about the 40%, the organisations that will struggle in 2027 are the ones discovering in an audit that they have dozens of these and no inventory.

Where this lands in our verticals#

In a Hospital Management System, agents that draft discharge summaries, chase outstanding results, or triage referral queues are genuinely valuable and every one of them touches a regulated record. The reversibility classification is not a nicety here; an agent that can amend a clinical record without human confirmation is a regulatory finding waiting to be written.

In a School ERP, agents handling attendance follow-ups, fee reminders, and parent communication are attractive precisely because the volume is high and the messages are formulaic. They are also outbound communication about minors, which is squarely in the irreversible bucket. Send once, cannot unsend.

In both cases the agent is worth building. It is worth building with the five controls, and the controls take about two weeks. The version without them takes two days and gets switched off after the first bad month.

---

An agent is a new principal in your system, not a new button. We design the permission model, the audit trail and the off switch before the demo. Talk to us before it ships.