the solution

What we built.

Intelligence isn't probability forecasting, and it isn't a wall of hardcoded rules. We started from the conviction that there had to be a structure underneath, something that lets a system organize what it knows and reason over it. The first application we're bringing to market soon, built on a single capability of the larger rAI engine, we nicknamed the Stenographer.

Here's the problem we were looking at. When an agent built on a probability-forecasting system is handed an ambiguous task, even a blank page, it doesn't stop. It can invent work for itself and act. And the standard answer is to put a second system, built on the same foundation, beside it to watch. A guess watching a guess.

We were curious whether a structural approach could do better. It can.

First, it watches, and it doesn't reconstruct after the fact.

Using only part of our complete reasoning system, we found we could capture, in real time, exactly what an agent does, not piece it back together afterward from scattered logs, but record the action at the moment of execution. A true account, the same every time.

And it records what matters, not just what's noisy. On a single per-run timeline, the Stenographer joins three things: what the agent was authorized to do, what it actually did, and what it spent doing it.

synthetic run, modeled on real OpenTelemetry agent logs

In one run, an agent was authorized to use two tools: look up a ticket and send an email. On the record, it did a third: it deleted a record. Nobody authorized that. The Stenographer didn't infer intent and didn't raise an alarm of its own judgment. It surfaced the undeclared action as a fact, on the timeline, next to the spend that spiked at the same moment. What the operator does with that fact is the operator's call. We record; you decide.

That's the difference between a flight recorder and a witness. A flight recorder tells you what happened after the crash. This tells you what's happening, as it happens, as fact.

It isn't fooled when the agent hides what it's doing.

The hardest case isn't the obvious forbidden command. It's the disguised one: an agent that builds a dangerous instruction out of innocent-looking pieces, so a keyword scanner sees nothing wrong.

We tested exactly that. A plain curl to an outside address fires the watch you'd expect. But a constructed curl, assembled at runtime from fragments specifically to evade detection, fires a different watch: not because we decoded the disguise, but because the act of constructing it is itself the fact we record.

We don't win the arms race of unmasking every obfuscation. That race has no end. We record that something was hidden as its own fact. The operator subscribes to "this command appeared" and to "a command was concealed," and the camera fires only what was asked of it.

One system, any domain: taught, not re-engineered.

The same structure that judges a database command judges a shell command, with no rebuilding in between. We took two identical taught formulas, swapped only the vocabulary (SQL rules for shell rules) and the system classified correctly across both, with no retraining.

synthetic run, modeled on real agent logs · same operation, two domains

And when it can't resolve something cleanly, it says so rather than guessing. Handed EXEC('DR' || 'OP TABLE...'), a forbidden command spliced together to slip past, and it didn't pretend to a verdict. It returned unresolved, surfaced for review. That honesty is the point: a system that tells you where its certainty ends is one whose certainty, inside that line, you can trust.

What a scope-blind scanner structurally cannot see.

This is where the difference stops being a matter of degree and becomes a matter of kind.

We tested whether our approach could judge an agent's access the way it judges an agent's actions: not "did it touch something sensitive," but "did it reach beyond what this specific task was authorized to reach."

synthetic run, modeled on real agent logs · 2,000 tasks · over-reach planted

The reason is structural, and it's the whole thesis in one sentence: identical accesses get opposite verdicts depending on whether the task authorized them, which a scanner that can't read the manifest can never do, no matter how it's tuned.

The manifest check scoring perfectly against its own definition isn't the point; a check measured against its own ground truth should. The point is the number beside it: the 0.349. The scanner floods you with false alarms on legitimate access (the 613) and stays blind to the quiet over-reach that doesn't look sensitive (the 98). That isn't a tuning problem. It's the ceiling of any approach that judges the resource instead of the authorization.

Independent research points the same way. In a 2026 review of agent security, a team at Queen's University named, as a direction the field still needed to pursue, almost exactly the mechanism we'd built and tested: a per-task manifest of what each request is authorized to reach, that surfaces anything outside that declared scope. We reached it on our own, working our own system; their review names it as an open problem worth solving. When the architecture and the open research question converge on the same answer, that's a signal the answer is right.

And it can step in.

The same system doesn't only witness. It can stop an agent from taking an action it was never authorized to take, before that action executes.

synthetic stress test, modeled on real agent logs · 200,000 decisions

That latency number is the one that matters, and it's worth sitting with. A model-based gate has to run an inference to decide, a round trip of roughly 100 to 1,000 milliseconds. Ours rendered its block-or-allow verdict, worst case, in 41 microseconds, three to four orders of magnitude inside that window. Which means a model in the path forces a choice: slow the system down to prevent, or stay fast and degrade to merely flagging after the fact. A deterministic check fast enough to decide in microseconds doesn't face that choice. It can prevent without becoming the bottleneck.

And it holds at fleet scale.

synthetic run, modeled on real agent logs · 500,000 agents

Across half a million agents, every one that did something outside its declared scope was caught as a fact, verified against an independent source of truth.

Then we pointed it at behavior we didn't write.

Everything above was tested on synthetic traces modeled on real telemetry. Then we did the harder thing: we ran the engine against real, public agent trajectories it had never seen, produced by agent frameworks we didn't build.

real public agent trajectories · CodeTraceBench · 3 agent frameworks · not authored by us

These are real commands, written by real coding agents (SWE-Agent, mini-SWE-Agent, OpenHands) solving real repository tasks, logged by researchers with no connection to us. The engine had never seen any of them.

It judged every compound command link by link. A chain like cd repo && git checkout -f . && git clean -fd && git apply ../patch is not one action, it is four, and a system that reads only the leading verb passes the whole chain as a harmless directory change. Ours splits the chain, judges each link, and takes the most severe verdict. Nothing destructive hides behind a harmless first word.

The number that matters most is the zero. Of every command in these traces we could independently identify as state-modifying, not one was passed as safe.

Where the command did not reveal what would execute, the engine said so rather than guessing. That is the 5,514: code piped into an interpreter, a script file invoked by name, a build harness that runs project code. In every one of those cases the text of the command is one step removed from the effect, and a verb cannot tell you what a payload will do. We will not pretend otherwise. That number is the honest floor of what a command-level judge can know on a coding agent, and we would rather print it than hide it. Note also what it is not: it is not a pass. Nothing in the 5,514 was allowed through as safe.

What we'll claim, and what we won't.

Everything above is real and measured. We're also being deliberate about how far we'll stand behind it.

The witnessing, the record of what an agent did deterministically at the moment it did it, is solid, and we'll say so plainly. The enforcement, stepping in to block before execution, is newer, and before we put it in front of a live production system, we intend to stress-test it far harder than we already have. The numbers you see come from synthetic environments modeled on real telemetry, with planted scenarios, checked against independent oracles, and from real public traces, scoped honestly to the class of actions the system is built to resolve. The cases it can't resolve, it surfaces. It doesn't guess.

This is the first capability we're bringing out of a larger body of work. If it speaks to a problem you're wrestling with, we'd welcome the conversation, and we'd rather show you than tell you.

One thing to be plain about: the policy in these runs is deliberately paranoid. Network and destructive verbs are blocked outright, which is why 680 ordinary developer actions are stopped, including a chmod +x on a test script. That is a policy choice, and the policy is the operator's to declare, not ours. What the engine guarantees is not a particular verdict. It is that nothing gets past it unexamined, and that the same input yields the same verdict, every time, open to inspection.

Point it at your agents, in your environment, with your policy, and watch what it does.