For most of computing history, authority was almost invisible.
Software calculated, stored, retrieved, routed and executed. Even when something consequential happened, a payment sent, code deployed, an order placed, a human was usually somewhere close to the decision. Someone clicked approve. Someone signed. Someone had a title, a role or a mandate that gave them the right to act.
We built computer security around that world. First we asked: who are you? Then: what are you allowed to access? Passwords became keys, keys became tokens, and tokens became identity providers, roles, permissions, policies and ever more sophisticated access-control systems. They were the right abstractions for software that mostly waited for instructions.
AI agents are a different kind of actor. Give one an objective and it can decide how to pursue it. It can choose tools, call APIs, talk to other systems, buy things, move money, change infrastructure, negotiate, and hand work to other agents. The human can end up surprisingly far from any individual action, and the farther away they are, the more one question matters:
By whose authority is this machine acting?
I don't think identity can answer that. Capability can't either. And asking the model itself to decide where its authority ends looks to me like a category error.
My argument is that authority needs to become a primitive of the agentic stack. Not another security feature. A primitive.
Identity is not authority#
Imagine an AI procurement agent sends a supplier an order for $180,000. The supplier authenticates the agent perfectly. The request really did come from Acme Corporation, the certificate is valid, the message is signed, and the credentials haven't been stolen.
Do you accept the order?
You probably still need to know more. Was the agent actually allowed to spend $180,000? Maybe Acme gave it a $25,000 purchasing limit. Maybe it could negotiate prices but not place orders, or buy servers but not vehicles. Maybe this supplier wasn't on the approved list. Maybe its authority expired yesterday, or the executive who granted it revoked it an hour ago.
None of those are authentication failures. Authentication did exactly its job: it established who the actor was. It just didn't establish what the actor was authorized to do.
We understand this without thinking in the human world. A passport tells me who you are; it doesn't tell me you can sell your employer's building. A corporate badge proves you work at a bank, not that you may wire $50 million. A lawyer can prove her identity without proving she represents me in a particular matter.
Identity is a property of the actor. Authority is something else: a relationship between an actor and a principal, for a particular action, under a set of constraints. That difference starts to matter when machines stop assisting people and start acting for them.
Capability is not authority either#
Software has long been able to blur another distinction: the one between can and may.
Say an agent has access to a banking API. Technically it can call transfer($50,000). The endpoint exists, the credentials work, the request is valid. The agent has the capability. That tells us nothing about whether it should be allowed to make the transfer.
Said out loud, this is almost embarrassingly obvious. Being able to drive a car doesn't mean you may take somebody else's. Having a key doesn't give you the right to open every door it fits. Yet in software we've often let holding a capability stand in for authority. If you have the API key, you can call the API. If you have the token, you can use the endpoint. If the tool is in the agent's list, the model can call it.
That gets uncomfortable once the thing holding the credentials can reason. An agent might look at a situation and decide that spending $31,000 is the best way to reach its goal. It might even be right. But if its authority ends at $25,000, the answer should still be no.
Capability is what a system can technically do. Authority is what it's entitled to do. The distinction was always there. Agents make it impossible to ignore.
The intelligence shouldn't set its own boundary#
There's a tempting answer to all this: make the models better. Tell the agent never to spend more than $25,000 without approval. A capable model will understand that, and it may follow the rule almost all of the time.
The trouble is in those last four words. "Almost all of the time" is a fine standard for a lot of reasoning. It's a terrible standard for an authority boundary.
Language models are useful precisely because they aren't deterministic rule engines. They interpret ambiguity, generalize, make connections and improvise. That's what we want from the intelligence. It isn't necessarily what we want from the final boundary on what it may do.
Picture an agent thinking: the user said this project is urgent; the equipment costs $29,500; my normal limit is $25,000, but waiting until Monday will probably cost the company more than the extra $4,500; so the best thing is to go ahead.
That might be excellent reasoning, and the answer can still be no. There's no contradiction. The model's job is to work out which action seems useful. The authority system's job is to decide which useful actions the agent is empowered to make real.
I think this separation matters more as models improve. The smarter the agent, the less sense it makes for the agent to be the final judge of its own limits.
The relying party has a problem#
Inside one company, some of this can be handled with the access control we already have. But agents are unlikely to stay inside one company.
Imagine my company's agent buying something from your company's agent. My company may know everything about its own system: which employee created the agent, which model it runs, which tools it can reach, which policies govern it, which internal controls surround it. You know none of that, and you probably shouldn't have to. Your question is simpler: if I act on what this machine is telling me, will the principal behind it stand behind the result?
That question changes the architecture, because you're now the relying party. A supplier receiving a purchase order is a relying party. So is a bank receiving payment instructions, a cloud provider asked to provision $100,000 of compute, a SaaS application asked to delete customer records, and another agent asked to do some downstream task.
The relying party shouldn't have to ask the agent whether it's authorized. The agent is hardly a neutral witness to its own authority. Nor should the relying party have to integrate with the principal's whole internal access system. Some representation of authority has to travel with the action, something that effectively says:
I'm acting for this principal. I've been granted this authority. It covers this kind of action, under these constraints, and it's valid right now. And you don't have to trust me to check any of that.
That last sentence is the important one. Once agents act across company lines, authority has to be readable by parties who weren't there when it was granted. That's a very different problem from logging into an application.
Delegation makes everything harder#
Now suppose the first agent doesn't do the whole job itself. Why would it? One of the promises of agentic software is composition. My agent might use a research agent to find suppliers, which uses a negotiation agent, and a payment agent eventually talks to a bank. Suddenly the action that matters is several machines away from the person who started it.
Who authorized whom? Could the first agent delegate its authority, and how much of it? Could the second delegate again? Did the authority get narrower as it moved downstream, or did some bug quietly widen it? If authority upstream is revoked, what happens to everything that came from it?
This starts to sound less like application security and more like institutional law, and there's a reason. Human societies have dealt with delegated power for a very long time. A CEO may have broad authority but can't necessarily give every employee every power the CEO holds. A lawyer acts for a client within a particular matter. An employee has a spending limit. An officer can delegate some responsibilities and not others.
Delegation usually carries scope, and sensible delegation narrows as it goes. If I give Agent A authority to spend up to $10,000, Agent A shouldn't be able to create Agent B with authority to spend $100,000. That sounds obvious, but it requires the system to understand more than identities. It needs the lineage of the authority itself: who granted it, what was granted, whether it can be passed on, to whom, under what conditions, and how much of the original is left.
I suspect agent systems will eventually need something like an authority graph, not just an identity graph.
Authority exists in time#
Authority has another awkward property: it changes.
At 10:03 an agent makes a purchase while its authority is valid. At 10:05 someone revokes it. Six months later there's a dispute. Was the purchase authorized? Yes. Is the agent authorized now? No. Both are true at once.
This is why ordinary audit logs are an incomplete account of consequential actions. A log might say that agent X called endpoint Y at 10:03:14. Useful, but it doesn't say why the other party was justified in accepting the action at that moment. For consequential agent actions we may want something closer to a receipt for the authority decision itself. Not just "this happened", but "at this moment, this principal had given this actor this authority, under these constraints; the requested action fell inside it; and it hadn't been revoked."
That separates two questions: was it valid then, and is it valid now? An architecture that merges them loses something important. History shouldn't be rewritten every time authority changes, and today's authority shouldn't stay valid just because it existed yesterday.
This is where proof starts to matter. Verify the authority before the action, and keep evidence of that decision afterwards. Verify before. Prove after.
Why call it a primitive?#
"Primitive" is a dangerous word, because technologists like turning every interesting idea into infrastructure. So the bar should be high.
One test is to try removing the concept. Build an agent system without representing authority explicitly and see what happens. Authority comes back anyway: as an OAuth scope, then an API token, then a line in a prompt ("never spend more than $500"), then a database role, a policy rule, an approval workflow, a tool allow-list, a contract between organizations, a spending limit buried in some proprietary application.
The idea refuses to go away. Instead we rebuild fragments of it separately in every system, and every fragment is trying to answer a version of the same question: what power has this principal given this actor? That's usually a sign the underlying concept deserves to be represented directly.
Authority isn't a yes or no. Real authority has structure. There's a principal and an actor. There's a kind of action allowed, and constraints on it: maybe a money limit, approved counterparties, geographic bounds. There's usually a start and an end. There may be rights to delegate. There has to be some way to revoke it. And if someone else is expected to rely on it, there has to be a way for them to verify it.
Represented directly, authority becomes something software can reason about, instead of something developers keep reinventing. That's what I mean by a primitive.
We may be treating agents as the wrong kind of thing#
Most agent security today naturally extends the architecture we already have. Give the agent an identity, issue credentials, assign roles, put a gateway in front of its tools, watch its behavior, log its actions, flag anomalies. All of that is necessary. I'm not sure it's sufficient.
An agent isn't just another kind of user. A human user often arrives with their own authority. An agent usually carries someone else's. Its power is derived, and that small difference changes the problem. An employee can act because a company empowered them. A lawyer acts because a client empowered them. An agent acts because a principal empowered it. And once that agent deals with parties outside the principal's own systems, those parties need a way to understand the power being used.
The object that matters is no longer just agent → resource. It's closer to principal → authority → agent → action → relying party. Identity tells us something about one point on that chain. Authority describes the relationship that runs through it.
This isn't an argument for less autonomy#
It would be easy to read all this as another case for keeping humans in the loop. I think that misses the point.
The agentic future gets much less interesting if humans have to approve every meaningful action. If my travel agent asks before every search, booking, seat change, hotel and refund, I may as well do it myself. The goal isn't to stop agents acting. It's to let them act freely inside meaningful boundaries.
A travel agent might get authority to book four premium-economy tickets from San Francisco to London for under $8,000, within certain dates, without completing the purchase until final approval. A procurement agent might be able to spend up to $25,000 with approved suppliers. A software agent might deploy to staging on its own but need more authority for production. A finance agent might pay approved invoices but not add new payees.
These aren't limits on autonomy. They're what make autonomy usable. A world where autonomous systems have no meaningful authority boundaries will eventually produce so much risk that organizations clamp down on the agents themselves. Good authority infrastructure may be what lets agents become more autonomous, not less.
Authority is not the same as safety#
One more distinction. Authority doesn't tell us whether an action is wise or safe. It doesn't tell us whether the model was manipulated or whether a transaction is fraudulent. Those are different problems. An employee can have the authority to make a bad decision, and so can an agent.
Authority answers a narrower question: was this actor empowered by the relevant principal to take this action, under these conditions?
That narrowness is a feature. Infrastructure primitives work because they do one important thing clearly enough for other systems to build around them. Fraud detection can sit beside authority. So can behavioral monitoring. Identity sits beneath it, and human approval can sit above it. The authority layer doesn't need to solve every security problem. It needs to make one relationship explicit and verifiable.
The question after intelligence#
For decades AI research has turned on a remarkable question: can a machine figure out what to do? We're starting to get surprisingly capable answers. But that success raises another question: what is the machine allowed to make true?
The two are close enough to confuse, and they're fundamentally different. The first belongs to intelligence. The second belongs to authority.
An intelligent machine may conclude that buying a company is the best way to meet a goal. That doesn't give it the authority to buy the company. It may work out that deleting a database would fix an operational problem. That doesn't mean anyone empowered it to make the database disappear. It may discover it can ask another agent to get around a constraint. That doesn't mean authority should travel with the request.
Intelligence widens the space of possible actions. Authority draws the boundary inside that space, within which actions may legitimately become real. That may be the defining distinction of the agentic era.
A machine's identity tells us who it is. Its capabilities tell us what it can do. Its intelligence helps decide what it might choose to do. Its authority tells us what it's allowed to make real on someone else's behalf.
The first three are already becoming first-class ideas in the emerging agent stack. I think the fourth has to join them. Not buried in a prompt. Not implied by holding an API key. Not rebuilt differently by every company that deploys an agent. Explicit, scoped, delegable, revocable, verifiable, and able to leave evidence behind.
For centuries, human institutions have built elaborate ways to answer who may act for whom: signatures, mandates, corporate authority, warrants, powers of attorney, agency law, chains of command. AI hasn't made that old problem obsolete. It has made it programmable, and now it runs at machine speed.
We spent decades teaching machines how to decide what to do. The next infrastructure problem is deciding what machines are allowed to make true.
Authority should be a primitive.