Audit kept us honest. Agents don't care.

Let’s rob a bank. What would even stop us?

Walk in during business hours. The vault is open. The cash is sitting behind a counter you could clear in one motion. Physically, almost nothing prevents you from grabbing it and walking out.

So why don’t people do it? Not because they can’t take the money — because they can’t keep it, and they can’t hide that it was them. Cameras on every angle. Dye packs that paint the cash, and you, bright red on the sidewalk. Bait bills with recorded serial numbers. A silent alarm that has police moving before the door swings shut. A bank’s security was never really the lock. It’s everything that happens after you take the money.

Security runs on the probability of getting caught

That isn’t a quirk of banks. It’s how a surprising amount of security actually works. We lean on the classic three A’s — authentication (who are you), authorization (what are you allowed to do), and the one we tend to forget: accounting, and the audit trail it produces. Authentication and authorization try to prevent. Audit just remembers. And in practice, audit does a lot of the quiet, heavy lifting — because for humans it was never just a record. It was a deterrent.

The most dangerous person in most companies was never the hacker outside. It’s the accountant inside with legitimate access to the money. What stops them from quietly wiring funds to an account they control? Not access controls — moving money is their job. It’s the audit trail, the reconciliation, the segregation of duties, and the certainty that the numbers will point straight back at them. They stay honest because they’d get caught, and getting caught carries consequences they care about.

Audit works because the people it watches are afraid of it.

Hand the job to an agent

Picture your finance agent. One morning it moves a large sum to a foreign account — no malice, just a goal pursued one step too literally.

And your audit trail is flawless. You know exactly which agent did it, which tools it called, in what order, with what arguments. Principal, action, resource, context, decision — all of it, captured perfectly.

And then what? What are you going to do — reboot the agent?

The money is gone. The agent isn’t ashamed. It won’t be fired, it won’t be prosecuted, it can’t be deterred — because it never feared any of that to begin with. For a human, audit buys you deterrence, so the bad thing mostly doesn’t happen. For an agent, audit buys you a very detailed recording of the bad thing happening. Detection and forensics survive. Deterrence — the part that was quietly doing most of the work — does not.

That’s the pillar agents broke. Not audit itself, but the deterrence we had built on top of it.

Three permitted steps, one incident

An agent’s worst outcomes rarely look like a single forbidden action. They look like a chain of permitted ones.

Ask your revenue agent to “put together the board update on at-risk accounts.” It pulls the customer list and contract values from the CRM — allowed; that’s reporting. It drafts a summary in a shared doc — allowed; it drafts docs all day. It emails the doc to the outside consultant helping with board prep — allowed; sending mail is its job.

Three reasonable, individually authorized steps. The result: your customer list, contract values, and churn risk just left the company as an email attachment. No system did anything it wasn’t told it could do. No malice. Each gate said yes.

A single read is fine. A single send is fine. The combination is the incident.

And nothing was blocked. Each system’s authorization did its job perfectly — the CRM confirmed the agent could read, the doc platform confirmed it could write, the mail server confirmed it could send. However good those frameworks are, each one only sees the single action in front of it; none can see, let alone stop, the combination. And audit is no backstop either: it records all three steps faithfully, but it won’t tell you in the moment that together they’re a data-exfiltration event — and even if it could, you’d be reading about it after the attachment was delivered.

You can’t punish it later, so you have to stop it first

When the after-the-fact safety net stops catching, security has to move earlier — from detecting the bad action to preventing it. That has pushed the industry, rightly, to double down on the first A: authentication. Strong, distinct identities for every agent, so “the agent did it” names a specific thing instead of a shared service account, and so you can apply least-privilege to a real principal.

That’s necessary. It is also not enough. Knowing who an agent is does not constrain what it is allowed to do — and that is the second A, authorization, which turns out to be the hard one.

Authorization is the hard A

Authorization for agents is hard for two reasons that compound each other.

The first is the nature of the agent. The very thing that makes an agent effective makes it hard to constrain: it’s goal-oriented, it has no human judgment or sense of boundaries, and it can attempt an almost unlimited range of tasks. It treats every control in its path as one more obstacle to route around on the way to its goal. A person works within a small, habitual set of actions; an agent will try anything that might advance the objective. So your policies can’t just cover a handful of risky moves — they have to cover an ever-expanding surface of things an agent might attempt.

The second is how our systems were built. A single agent reaches across Slack, your CRM, email, a code host, a half-dozen internal APIs. Each one has its own permission model, its own vocabulary, its own idea of “allowed”. Most of them are coarser than you think. Slack’s OAuth scopes, for example, let you grant a capability but not the resource it applies to: the chat:write scope lets the agent post in any channel it’s been added to, not just the one you had in mind — there’s no per-channel grant in the scope itself. CRM permissions are role-shaped, not task-shaped. And when an agent acts on a user’s behalf, it tends to inherit that user’s entire standing access — which, for most employees, is far broader than any single task requires — narrowing that inherited access is its own playbook (Securing Claude Cowork).

Now stack those systems together. Every one of them can answer a narrow question: “is this agent allowed to do this one thing, here?” None of them can answer the question that actually matters: across all of them, should this sequence of individually permitted actions be allowed to happen at all? Per-system authorization is local by construction. The risk is global. That gap — between “each step is allowed” and “the whole combination of steps is safe” — is exactly where agent incidents live.

Audit doesn’t just lose its teeth — it loses its shape

There’s a second, quieter cost. Even the forensic value of audit — the part that does survive with agents — can degrade the moment the action spans systems.

That board-deck incident didn’t leave one trail; it left three — the CRM’s access log, the doc platform’s activity feed, the mail server’s send log — with three schemas, three retention windows, and no shared session linking them. The clean “principal, action, resource, context, decision” record we imagine doesn’t exist anywhere. So agents blunt audit’s deterrence and scatter its evidence.

What we’re building

What you want is a single point that both decides and records. That’s what DTwo is: a security control plane for agents, in the path of every tool call they make, across the systems they touch. You state the outcome you want — company funds don’t move to external accounts, customer data doesn’t leave the organization — and every agent action is evaluated against it before it happens, not recorded after it’s too late. Because every call passes through that one point, it can judge the send not in isolation but against everything the same agent already did in the session — the read, the draft, the recipient — and refuse the combination the individual systems each waved through. This is the approach we call intent-based policy: policy stated as the outcome, evaluated on every action. And because it decides there, it records there too — one coherent trail across every system, the record the scattered logs never produced.

The controls organizations have inside their security stacks were built for humans, not agents — here’s why those legacy controls fail with agents. They assumed an actor who could be deterred, working inside one system at a time. Agents are neither. DTwo is the control plane built for the way agents actually work: across every system at once, with no fear of getting caught.

Audit will still tell you what your agents did; it just won’t stop them. With agents, stopping them is authorization’s job — the pillar that now has to carry the weight.