Agents Will Transact Everything. Authority Comes First.

Agents will transact everything

AI agents are going to transact. That part isn't hypothetical anymore. So what does "transact" actually mean? For most of the conversation, and most of the capital, it means one thing. Pay. Faster rails, cheaper rails, agent-native checkout.

Payments are the smallest slice of what's coming. Agents will buy and sell, yes. They'll also transfer assets, sign and execute agreements, license data, commit inventory, settle obligations between companies, and move rights of every kind on behalf of the people and organizations they work for. Value in the broadest sense.

So the question isn't how to build a faster payment rail. It's how to build a transaction layer that any kind of value can move across, safely, when the party acting is software. And that question has one answer that sits underneath every transaction type.

Authority is the foundation

Read it top down: people create authority, agents are bound by it, and every kind of transaction draws on it.

Every transaction, of any kind, rests on one prior question. Was the party acting legally allowed to act? Not whether it had access. Not whether a system authorized the call. Whether it held legal authority, the thing our legal system runs on, to bind someone to the outcome. Before money moves, before title transfers, before a signature binds anyone, that authority has to exist.

None of this is new. We already define, scope, grant, revoke, and delegate legal authority in every contract and legal agreement we sign. An employee signs a contract because the company granted signing authority up to a limit. A broker trades because a client opened an account and set the terms. Someone holding a power of attorney acts under a document that says exactly what they can do and for how long. The authority comes from a principal, it has edges, it can be delegated only within those edges, and it can be taken back.

Agents have to be treated the same way. To be very clear, an agent is not a principal. It acts on behalf of a human or an organization, and only within the scope that principal defined. Humans create authority, scope it, grant it, and revoke it. Agents are bound by it. That is the only model under which an agent's actions bind its principal predictably, inside edges both sides can see.

Get authority right and every transaction type built on top of it inherits the guarantee. Get it wrong and no amount of speed, monitoring, or cryptography above it will save you.

Six things authority has to do

For authority to hold up when the actor is software running a thousand times a minute, it has to do six things, every time, for every transaction type.

The last one is the one most systems miss. Agents will hire agents. A procurement agent will spin up a negotiation agent, which calls a payments agent. Each hop can carry no more authority than the one above it, traceable back to the original human grant. If authority can expand as it moves down the chain, the chain is the attack surface. And that property has to be proven mathematically, not checked by convention and hoped for.

A deterministic substrate, not touched by AI

Here's the line. The layer that holds authority must be deterministic, and AI never touches it. Agents are probabilistic. They reason, infer, and sometimes get it wrong. That's fine for deciding what to do. It is not fine for deciding what they are allowed to do.

So the legal authority protocol sits underneath the agents as fixed rules, not model output. The same grant, the same request, the same answer, every time. An agent can operate inside it. It can never interpret it, rewrite it, extend it, or argue its way past it. A contract isn't reinterpreted by the party it binds, and an authority protocol shouldn't be either.

That substrate is what holds agents, and the humans they act for, bound to our legal system. Every action traces to a grant a person or organization made, within edges the law already recognizes, checked by rules no model can bend. Without it, an agent's "authority" is whatever it concludes it has.

Capability is not authority

The industry is making one confusion at scale. It treats an agent's capability, the fact that it can call an API, move funds, or sign a document, as if it were authority, the right to do it. Capability, as I mean it here, is what the software is able to do. Authority is what a principal permitted it to do. Confuse the two at machine scale and you've built an ATM for software with no idea who is standing at it.

Legal authority is not access, and it is not authorization in the computer science sense. Authentication proves who you are. Authorization decides what a system lets you reach. Legal authority sits over the top of both: it decides what you are entitled to do on someone's behalf, and whether the result binds them. Computer science has real tools for delegating access, from capability tokens to OAuth scopes. What it doesn't model is legal authority: whether the act binds the principal. The closest real-world model is the nuclear football at a presidential transition. The incoming president is handed the codes ahead of time, but they're useless until noon on Inauguration Day, when the office transfers. The codes prove identity. The authority comes from the office. Most of what we call "permission" in software today is the codes without the authority.

Today, permission is an API key. A role called "admin." A spending cap typed into a settings page. None of it expresses all six requirements above. You can't ask an API key who authorized this, for what, within what limits, and prove the answer. The key doesn't know. It just opens the door.

For a person clicking buttons, that was good enough, because the person was the authority check, applying judgment a thousand times a day without calling it that. Take the person out and hand the key to something that acts a thousand times a minute, and it doesn't scale. Period.

Down the stack: one foundation, every transaction

Once authority is in place, each transaction type is just a specific question asked of it. The asset changes. The question doesn't.

A payment rail answers one question: did the money move. A transaction layer has to answer the question that matters once the human is out of the loop: was this agent allowed to do this, right now, with this counterparty, under authority a specific person or organization actually granted? Settlement speed is a race to zero that everyone is already running. Where authority work exists today, it's scoped to payments and sits above the rail as signed credentials and mandates. What we haven't seen anyone build is a semantically bound grammar for legally scoped authority that works across every transaction type, or a mathematical proof that authority can never be over-delegated. That's the missing layer, because it's harder and it doesn't demo as well as a fast checkout.

Prevention, not detection

Look at how the industry talks about making agents "safe," and most of it is detection. Let the agent act, log what it did, flag the bad ones, review them later. Guardrails that observe. Dashboards that alert.

Detection is a confession that the action already happened. By the time the monitoring lights up, the asset has moved, the contract is signed, and someone is writing an incident report. That isn't safety. It's forensics with a nicer UI.

The version that holds up flips it around. This is the work we do at Conduit, so I'll be direct about the shape of it. Authority becomes a proof, not a credential. Before an agent's action executes, it has to show that it was permitted: bound to a scope, to the principal who granted it, and to the chain of delegation that traces back to a real human grant. The proof is checked first, by deterministic protocol, not by a model. If the action falls outside the granted scope, it doesn't execute. Not "executes and gets flagged next quarter." It doesn't execute.

That's the unlock. Over-delegation stops being something you monitor and becomes something the system can't do by construction. You also get the dial everyone actually wants: grant an agent authority to observe, to recommend, to prepare an action for your approval, or to execute on its own, narrowly, and revoke it cleanly. Think bumpers on a bowling lane. All the room to run you want, and no way into the gutter. Intelligence never outruns authority.

Authority and the transaction must be one event

A lot of people hear this and say, fine, bolt an authority layer on top of the existing rails. Some will, and a policy layer above a fast rail beats nothing. But authority checked in application code, sitting above the transaction, can be misconfigured, bypassed, or simply outrun by the very thing it's meant to govern. For this to be a guarantee instead of a hope, the authority check and the transaction have to be the same event.

On Conduit they are. Authority, the agreement it runs under, and the movement of rights or value commit atomically, as one operation, with economic finality in under 100 milliseconds. There's no window where the asset has moved and the permission is still pending, because there's no gap between them.

And this isn't the crypto answer wearing a new hat. Trust is anchored in attested hardware at each node, not in validator consensus. There's no single global public ledger that every agent's every transaction has to be broadcast to and reconciled against. Each counterparty keeps its own privacy-preserving ledger, and only the parties to an event need to know it happened. You get provable, bounded agent authority without publishing your machines' entire economic life to a shared log and calling that decentralization.

What to ask before you let it loose

I'm not betting against agentic transactions. Agents will transact, they'll need rails, and I'm glad serious people are building them. I just don't want the industry to walk past the layer that decides whether any of it works.

So before you let an agent act for you, or fund a company that will, ask better questions than "how fast does it settle":

1. Where does the agent's authority come from: a specific person or organization, or a key someone generated?
2. Is that authority defined as an explicit legal scope, or implied by whatever the credential can reach?
3. Can it be revoked cleanly, effective before the next action?
4. Can a counterparty prove the authority before acting, or only trust it?
5. When an agent delegates to another agent, is the scope guaranteed to narrow?
6. Is the authority layer deterministic, or can a model interpret, extend, or override it?
7. Is the check made before the transaction or after, and does it live in the same event, or above it where it can be outrun?

Faster rails are coming. Good. Speed was the easy problem, which is exactly why everyone is racing to solve it. The real work is making sure every agent, on every kind of transaction, acts only within authority a human gave it, and proving that before it acts. Get that right and speed and safety stop being a trade-off. That's how you increase velocity while reducing risk, and it's what lets us actually hand the work to the machines.