What it takes to trust an AI agent with real work

Most security products for AI start from a list of threats and add a feature for each one. Threat lists grow every month, so a product built that way is always one item behind. A steadier place to begin is the agent itself: what it is, and what would have to be true before a company could hand it real work.

An agent reads, decides and acts. It sends the email, updates the record, calls the payment service, using credentials your company gave it.

So the risk of an agent is not what it says. It is what it can reach, how fast it can act, and how long it takes anyone to notice when something goes wrong.

That one observation rules out a lot. A filter that only reads what a person types into a chat box misses the part that matters, which is what the agent does next.

No tool can read the purpose behind an action. What can be read, reliably and every time, is the action itself: the tool being called and with what arguments, the destination of an outgoing request, the content of a call to a model.

So Excubitor checks at the point of action.

Inside the application, or at a gateway in front of the tool servers, each call is checked before it runs: against the agent's policy, against the destinations the company allowed, and for instructions hidden in what the agent was given. The checks are deterministic and fast, because a control that adds seconds to every action does not stay switched on.

It follows that the content an agent reads is untrusted. A document, an email or a tool's answer can carry instructions written by someone else. Excubitor treats it that way: a tool whose description hides an instruction is taken out of the agent's list, and an answer carrying one is withheld before the agent reads it.

If an agent can act on its own, someone must be able to stop it on their own, and the stop cannot depend on the agent agreeing.

In Excubitor, a run that loops or races is contained by rule. Anyone on the team can freeze an agent, and its next call is refused. Releasing it takes an administrator and a note. Anything that cannot be undone, such as a payment or a deletion, waits for a named person to approve it. Stopping is automatic only where it can be reversed.

After an incident, or in front of an auditor, the question is what happened. A log that the people under review could have changed answers nothing.

So every action goes into a ledger where each record is chained to the one before, and the chain is signed every hour.

On our hosted service, any single record comes with a short proof that anyone can check offline with our public key, without access to the console and without trusting us. The records hold fingerprints of what was sent and received, never the content itself, so the security record does not become a second copy of the company's data.

Managed with evidence, never on faith.

Some companies can send records to a hosted service. Others cannot let anything leave their own cloud, and some run networks with no route out at all. A control that only works in the vendor's cloud is a control those companies cannot use.

Excubitor runs hosted, in the customer's own cloud, or fully air-gapped from a signed offline bundle that is checked before it is installed.

No standing vendor access, ever.

One question remains: what happens when the check itself cannot run. A security tool then has to choose between stopping the business and letting work continue.

By default, Excubitor lets the agent keep running and records the gap, so the outage of a security tool is never an outage of the company.

A team that would rather stop can set it to fail closed.

What that adds up to

Taken together, these describe the product:

• Control at the action: tool calls, outgoing connections and model calls, checked before they happen.
• Stopping without cooperation: containment by rule, Freeze by a person, irreversible actions held for approval.
• Evidence that does not depend on trust: a chained, signed ledger, with single-record proofs on our hosted service.
• Deployment where the data is: hosted, the customer's cloud, or air-gapped.
• Failure that does not take the business down: the gap is recorded, the work continues, unless the customer chooses otherwise.

What it does not do

The same reasoning sets the limits. Excubitor records what an agent did and never claims to judge what the agent meant. Its checks catch the patterns they know; an attacker patient enough to stay inside normal behavior will not trip a real-time threshold, which is why each agent is also compared with its own normal over time. And it runs inside the application, so it is paired with network policy, not offered instead of it.

If you are deciding whether your company can trust AI agents with real work, start with the agent, not the threat list. We would be glad to show you how Excubitor holds up on an agent of your own.