Permission Is Not Authority

Why identities, access scopes, and approval buttons are not enough when software acts on behalf of a company

Microsoft made Entra Agent ID generally available this year. An AI agent can now receive a first-class identity, a sponsor, lifecycle governance, conditional-access policies, dedicated authentication flows, audit records, and a set of permissions designed for agentic workloads. This is real progress. Organizations need to know which agent is acting, what resources it can reach, who sponsors it, and how its access can be revoked.

The progress also makes the next problem easier to see.

Consider a sales agent with a valid identity, CRM access, permission to read current opportunities, and permission to send email. It can authenticate. Its token is valid. The connector accepts the call. It drafts a proposal with a thirty-percent discount and sends it to a customer.

Nothing in that sequence proves that the company was entitled to make the offer.

The discount may exceed commercial delegation. Delivery capacity may be stale. A conflicting commitment may already exist. The account may be in dispute. The agent may be able to speak through a named salesperson's mailbox without being permitted to represent that person. The proposal may create a commitment that cannot be fulfilled or easily withdrawn.

Identity and access control answer necessary questions. They do not answer the whole organizational question.

Permission asks whether an actor can invoke an action. Authority asks whether the institution is entitled to perform that action, for this purpose, on behalf of these parties, under these conditions, with these consequences.

The previous issue argued that an agent loop sits inside a larger organizational operation. Once the loop reaches a tool that can change the world, that distinction becomes practical. The software may be ready to act. The company still needs a legitimate reason, a bounded delegation, an enforceable limit, and a way to answer for the result.

Permission answers a smaller question

Software systems are good at permissions.

This identity may read the record. That service may write to the ledger. This agent may call the email tool. That workflow may issue a refund. A role, scope, token, or access policy determines what the technical actor can reach.

Organizational authority is a relation among purpose, party, commitment, evidence, decision, action, and consequence. A junior employee may have credentials to download a customer list without authority to use it for an unrelated campaign. A manager may have access to a budget without authority to spend outside the approved purpose. A support tool may permit a refund without establishing that the customer, transaction, policy, amount, and recovery conditions warrant one.

The difference predates generative AI.

On August 1, 2012, Knight Capital's automated router began sending orders into the United States stock market. It was meant to handle 212 customer orders. During the first forty-five minutes, it sent more than four million orders, traded more than 397 million shares, accumulated billions of dollars in unwanted positions, and caused a loss of more than $460 million. An internal system generated ninety-seven automated emails identifying an error before the market opened, but those messages were not designed as formal alerts and did not produce intervention.

The SEC's account describes inadequate safeguards immediately before orders entered the market, controls that did not constrain aggregate exposure, weak deployment and testing procedures, and no effective connection between warning, exposure, and stopping.

The router was using the access Knight had given it. The code was defective, but the organizational failure was larger. Execution moved at market speed while the authority responsible for constraining it did not reach the action surface.

AI agents introduce different mechanisms, but the governing problem is familiar. A system can be authenticated, permitted, and technically successful while performing an action the organization cannot justify, contain, reverse, or explain.

Figure 1. Permission is necessary. Authority is larger. A valid identity and token can still carry an unwarranted action.

The acts hidden inside “the system decided”

“The system decided” compresses several institutional acts into one sentence.

Someone authored a policy. Someone or something interpreted that policy for the current case. A person or institution held decision authority. A human or machine received action authority. The company remained accountable for the arrangement and its consequence.

Those acts can be distributed. A regulator may author a constraint. The company may interpret how it applies. A commercial leader may retain decision authority above a threshold. An agent may assemble the evidence and execute an approved action. A payment service may carry the final transfer.

Keeping the acts separate prevents two common errors.

The first is treating machine execution as machine authority. The agent does not become the source of authority because it selected the action or called the tool. It inherits a bounded delegation from the institution.

The second is assuming that adding a human anywhere in the path restores legitimate authority. A person may click approve without understanding the case, possessing the right to refuse, or holding the power to change the system. Human contact with a transaction is not proof of governance.

The current infrastructure conversation is beginning to recognize the boundary. Microsoft's agent-identity model distinguishes agent identities, blueprints, sponsors, roles, lifecycle, and blocked high-risk permissions. NIST's 2026 concept paper on software and AI-agent identity and authorization asks how identification, authorization, auditing, non-repudiation, and prompt-injection controls should work for agents. The World Economic Forum's Agent Capability and Authorization Profile tries to make delegated decisions and actions auditable and enforceable at the level of a deployed agent.

These are important developments. They are not evidence that identity systems are unimportant. They show that agent identity is becoming organizational infrastructure.

The harder point is that permission still cannot establish its own purpose. A token may prove that an agent can read a mailbox. It does not prove that the current customer request warrants disclosure. A role may permit a refund. It does not prove that the evidence is sufficient, the account is undisputed, the amount is within delegation, or the action can be remedied if the record is wrong.

The authority question is therefore not merely, “Does this actor have the right scope?” It is:

Where did authority originate, how was it interpreted and delegated, what constrains its exercise now, and who can answer for the consequence?

The authority envelope must reach runtime

Inside a bounded operation, the authority envelope describes the conditions under which an actor may decide or act on behalf of the company. It is the operational edge of delegation.

The envelope begins with purpose and parties. What authorized purpose may the action serve? For whom, toward whom, and on whose behalf? It defines scope. Which decisions, actions, resources, and cases are included or excluded? It states the evidence required and how uncertainty or dispute changes the path. It limits consequence through value, volume, rate, burden, exposure, and irreversibility. It preserves the identity chain, the time boundary, and the conditions for recovery, escalation, stop, or refusal.

Figure 2. The authority envelope at runtime. Delegation becomes operational when the conditions for allowing, constraining, escalating, or refusing an action are available where consequence begins.

The envelope does not need to become one enormous policy document. Its parts may live in contracts, operating agreements, service limits, professional standards, budget rules, system policy, and explicit exception paths. What matters is whether a live action can be evaluated against a coherent delegation.

Consider a low-value customer refund. In the inherited arrangement, a support employee gathers evidence, asks a manager, waits for finance, updates the customer, and later checks whether the payment settled. Human approval may exist partly because policy, evidence, budget, execution, and recovery are not connected.

A more executable operation can move the ordinary case without managerial ceremony. The system may act when the customer and transaction are verified, the policy applies, the amount is below a delegated threshold, no dispute or conflicting commitment exists, budget and payment capacity are available, settlement can be observed, appeal remains possible, and the result can be reversed or compensated.

This is not weak governance. It is governance strong enough to support delegation.

The responsibility architecture still comes first. The company must know what it remains responsible for, who carries the commitment, who is affected, who governs the operation, and who learns from consequence. The consequential operation then gives the authority envelope a bounded place to become real.

The same action may be warranted for one customer and prohibited for another. Evidence may be stale. A commitment may have expired. A tool may be available while delivery capacity is not. A representation may resemble a person while lacking current permission to speak for them.

A useful runtime cannot answer only yes or no. It needs states such as evidence insufficient, authority expired, identity mismatch, representation not permitted, commitment conflict, consequence beyond delegation, recovery unavailable, escalate, or refuse.

For consequential action, “cannot establish authority” is not the same as “authority granted.”

Approval can become theater

The strongest objection to runtime authority is that it sounds like more governance at the exact moment companies want agents to move faster.

That objection is correct when governance means adding a committee, another generic policy, or a person who must touch every transaction. Approval can become theater. The reviewer receives the machine's framing, sees a green button, and becomes answerable for a decision they did not have the evidence, time, authority, or power to evaluate.

Large software organizations made this problem visible before generative AI accelerated code production. An engineer could complete a change and then wait for a limited number of senior reviewers. The reviewer was not necessarily protecting status. They were often carrying architecture, platform constraints, performance, maintainability, integration risk, mentoring, and the future question they would be asked if the change failed.

When tests prove too little, downstream consequence is difficult to observe, architectural rationale is not distributed, and rollback is weak, personal inspection becomes the organization's substitute for a designed authority system.

Faster generation can then concentrate accountability in a slower review layer. If a machine produces a thousand cases and one person receives a thousand approval buttons, the company has built an approval factory.

The answer is not to remove judgment. It is to place it where purpose and consequence require it. Low-risk, well-evidenced, reversible actions can move within a narrow authority envelope. Ambiguous, disputed, high-value, identity-sensitive, weakly evidenced, or irreversible cases change path. Review depth follows consequence, uncertainty, reversibility, evidence quality, and demonstrated capability.

Security creates the adversarial version of the same problem.

The Model Context Protocol's current security guidance warns that broad scopes increase blast radius and that a claimed token scope is not sufficient without server-side authorization logic. OWASP's Top 10 for Agentic Applications includes tool misuse and identity or privilege abuse among the central risks.

Least privilege limits which resources an identity can reach. Agentic systems also need least agency: limits on tool modes, sequence, delegation, value, volume, rate, duration, cost, destination, irreversibility, memory writes, and cumulative exposure.

A malicious instruction does not always ask the agent to perform an obviously forbidden action. It may steer an ordinary permitted action toward the wrong purpose, party, destination, or consequence. Security is therefore authority under adversarial conditions. The institution needs to know which untrusted evidence can influence the actor and the maximum consequence that influence can produce before detection and containment.

Executability and autonomy are different

AI strategy is often described as an autonomy ladder: assist, recommend, act with approval, then act alone.

That ladder mixes two dimensions.

Executability concerns how clearly the organization can represent, perform, observe, govern, and revise a responsibility. Autonomy concerns how much discretion an actor exercises without contemporaneous direction or intervention.

They can move separately.

An operation may become more executable because purpose, evidence, delegation, action surfaces, verification, and recovery are clearer while machine discretion remains narrow. Another operation may give an agent broad discretion over poorly represented commitments and call that maturity.

The second is more autonomous. It is not necessarily better designed.

A company designed now would place ordinary delegation directly inside operations rather than leaving authority in documents far from action. Senior control would move away from touching every transaction and toward architecture, evidence, boundaries, exceptions, sampling, recovery, and the places where direct human judgment remains necessary.

Passing an authority check would not end responsibility. Evidence may have been wrong. The model may have misclassified the case. An affected party may reveal a consequence the company did not know how to measure. Someone must be able to reopen the case, contest the record, reverse or compensate the action, revoke the delegated identity, and change the policy or boundary.

Distributed causation does not require distributed evasion. The company remains responsible for the arrangement through which authority was delegated and consequence produced.

Before an agent receives a consequential tool, ask seven questions:

1. What institutional purpose is this action allowed to serve?
2. On whose behalf is the actor operating, and who may be affected?
3. Which current evidence must be present, and what disputes or uncertainty change the path?
4. What value, volume, rate, duration, and cumulative exposure remain inside delegation?
5. Which identity and representation chain will the organization preserve?
6. Who can stop, reverse, compensate, contest, or recover the action?
7. What evidence would justify widening, narrowing, expiring, or retiring the authority?

This is how governance enables faster trusted action. Authority no longer has to be improvised for every case, and a valid permission no longer has to carry more institutional meaning than it can bear.

The next question is where the evidence required by that authority comes from. An agent cannot receive the whole organization as context, and a context window is not institutional memory. The next issue will examine why context is a governed projection rather than the organization itself.

I am interested in real examples. Where does a valid permission currently produce an action that nobody can explain was actually authorized? Where does human approval protect meaningful judgment, and where does it merely transfer liability? Share the pattern rather than confidential details.