Over the past eighteen months, AI agents have moved from drafting things to actually doing them.

They file claims. Issue refunds. Rebook appointments. Post entries to general ledgers.

That shift, from suggesting to committing, is the defining change in agentic AI in 2026. It is also where most existing security thinking starts to fall short.

This year, we looked through the product pages, funding announcements, and customer case studies of more than 200 companies building AI agents that take real actions inside customer systems. We wanted to answer one simple question:

When an agent is about to do something that cannot be undone, what checks it first?

In the overwhelming majority of cases, the answer was: nothing designed specifically for that moment.

Almost every serious agent company has invested in safety. The problem is where that safety sits.

Most of it happens either before the agent runs or after the action has already happened. The actual moment of execution, the point where a decision becomes a real-world change, remains largely unguarded.

Five of these six layers are well served by existing products.

The middle one, the moment the action actually fires, is where almost nothing lives.

A threshold rule can tell you that a $400 refund is within policy. It cannot tell you that the refund is about to land on the wrong customer's account.

A permission system can tell you that an agent is allowed to update appointment records. It cannot tell you whether the "John" it just matched is the right John out of three people with that name in the system.

This isn't hypothetical. It is exactly the kind of failure that starts to matter once agents are operating in production.

This isn't a blind spot the industry has completely missed.

If anything, the opposite is true.

In our screening, at least six companies now ship some form of named oversight component as part of their own product: a "judgment layer," a deterministic policy engine, a controls agent, a governance agent, patented workforce-management tooling, or human-in-the-loop approval workflows built around MCP servers.

The pattern is clear. Companies building agents that act have independently arrived at the same conclusion:

Something needs to sit in front of the action.

An independent market analysis published in mid-2026 reached a similar conclusion from the funding side. Standalone "human approval agent" companies raised almost nothing in 2024 and 2025, not because oversight doesn't matter, but because oversight is increasingly being absorbed into vertical agent products, security tooling, and control planes rather than emerging as a standalone category.

The problem is that most of what gets built in-house is a rule, not a check.

A threshold verifies an amount.

A policy engine matches a request against a static condition.

Neither asks a contextual question about the specific action sitting in front of it.

A refund can be the correct amount, satisfy every policy in the stack, and still go to the wrong account.

That distinction keeps appearing throughout our research:

A rule checks the amount. It doesn't check the account.

One pattern became obvious after reading enough of these product pages back to back.

You can often tell how much autonomy a company has actually shipped simply by looking at the verbs it uses to describe its agent.

Agents that genuinely commit actions are described with verbs like submits, files, issues, posts, books, pays, executes, negotiates, and settles.

Agents that stop short are described as recommends, flags, surfaces, suggests, assesses, and drafts.

It's a small distinction, but remarkably consistent. And it maps directly to how much oversight a company needs, and how much it currently has.

There is one phrase that rarely appears accidentally:

"Without human intervention."

Nobody puts that in their marketing copy unless the agent is actually operating that way.

Maven AGI describes its support agent looking up an order and issuing a refund or replacement without escalation, resolving up to 93% of queries without a human.

Lemonade reports that 96% of first notices of loss are taken with no human involved, with settlement completed in two seconds.

Trellis describes a single guest message triggering a $450 damage claim filing, a replacement purchase, and a guest credit, all from one agent, with a published automation rate of 84.5%.

These aren't edge cases.

This is what production agent deployment already looks like in 2026.

And the actions are happening before anyone reviews them.

This is the layer we built Salus to occupy.

Not before deployment.

Not after the fact.

At the exact point where an agent has decided what to do and is about to hand that decision to your backend.

For every proposed action, Salus asks a narrower, and more useful question than anything upstream or downstream:

Is this specific action permitted by policy, supported by the evidence the agent actually has, and safe to execute right now?

Take the appointment-rebooking example.

An agent proposes moving "John" to Friday at 4:30, but it hasn't verified which John it means.

A permissions system misses this.

A threshold rule misses it too.

Neither is designed to reason about the specific record in front of it.

A commit-time check can catch it, return a concrete reason to the agent verify identity, and allow the corrected retry to go through.

In controlled internal evaluations on AgentDojo's banking benchmark, adding this kind of runtime check in front of a GPT-4o-mini agent reduced mean prompt-injection attack success from 47.7% to 0.69% across three repetitions a 98.6% reduction, while the agent continued performing its intended tasks.

On AgentDojo's workspace benchmark, task-completing utility actually increased from 37.5% to 64.4% while attack success fell from 17.1% to 1.73%.

Why?

Because a significant share of what looks like "agent failure" is actually an agent proceeding with missing or ambiguous evidence. That's exactly the kind of problem a commit-time check is designed to catch before it becomes a written record.

Across 1,705 gated write actions on the τ²-bench benchmark, two-thirds passed through completely untouched.

The rest were clarified, revised, or, in a small fraction of cases denied outright.

Most actions are fine.

The point is to have a layer in place for the ones that aren't.

None of this means ripping out the systems you already use.

Evals still matter.

Permissions still matter.

Thresholds still matter.

Audit trails still matter.

They are simply answering different questions from:

"Should this action happen?"

The rollout can be intentionally boring.

Start by replaying recent traces to understand what your agent is actually attempting. Then write a policy for the one action route where a mistake would hurt the most. Run that policy in shadow mode alongside production, enforcing nothing. Only after you understand the results should you turn it on.

For most teams, moving from replay to a protected route requires a single endpoint change.

If you're running agents that touch money, patient records, or anything else you can't unsend, it's worth spending twenty minutes looking at what a check at the commit moment would have caught in your own traffic.

Salus runs that first pass in shadow mode against real traffic, with nothing enforced until you decide it should be.