PERMISSION IS NOT AUTHORITY
What AI Agents Are Allowed to Do—and What They Have the Right to Do
Martin Novak
Synthocracy Institute
Research status: 3 September 2026
Evidence Boundary
This article separates documented developments from analytical interpretation. [A] Empirical claims describe published standards work, official guidance, technical research, or documented system architectures available by 3 September 2026. [B] Analytical claims develop the Synthocracy Institute’s interpretation of those developments. The distinction between permission and authority is not presented as newly invented terminology. Identity management, cybersecurity, agency, law and institutional governance have long distinguished related questions in different ways, and current AI-agent research increasingly separates identity, authorization, delegation, scope, revocation and accountability. The Institute’s contribution here is narrower: to connect those elements to consequential AI-mediated decisions and ask whether technical permission can be traced to a legitimate and bounded source of decision authority. This follows the Institute’s existing rule against renaming established concepts merely to manufacture novelty.
The credential works. That does not settle the question.
Imagine an AI procurement agent operating for a manufacturing company. It has authenticated successfully. Its identity is known. Its credential is valid. The purchasing platform accepts it. The agent is allowed to query suppliers, request quotations and initiate payments up to €100,000.
At 10:14 it transmits a payment of €82,000.
The technical record may be excellent. The logs establish which agent acted, which credential it presented, which API endpoint it called, which account sent the money and when the transaction completed. From a cybersecurity perspective, the request may even have been perfectly authenticated and authorised.
Yet an important question remains unanswered:
Did the agent have the authority to decide that this particular €82,000 payment should be made?
Perhaps the human principal authorised purchases only from previously approved suppliers. Perhaps the agent was allowed to prepare transactions but not execute them. Perhaps €100,000 was a technical transaction ceiling rather than a discretionary budget. Perhaps another system delegated the payment task after misinterpreting a broader instruction. Perhaps the credential remained valid after the employee who originally controlled the workflow had left the company. Perhaps the payment was technically permitted while institutionally outside the mandate.
The system can therefore prove that an action was possible and accepted without proving that the action was legitimate.
That gap is becoming one of the central governance problems of agentic AI.
Technical capability tells us what an agent can do. Permission tells us what a system will allow it to do. Authority tells us what the agent is legitimately empowered to decide or execute.
Those categories can overlap. They should not be collapsed.
1. Why this distinction matters now
The problem is becoming urgent because AI is moving from generating information to exercising access. NIST’s National Cybersecurity Center of Excellence describes the transition explicitly: enterprises are moving from systems that produce text or graphics toward software and AI agents that can take actions, including deploying code to production, while operating with limited human supervision. NIST’s 2026 work therefore focuses on identification, authorization, auditing and non-repudiation for agents rather than treating them simply as another user interface. (NCCoE)
On 27 August, NIST went further. It warned that many early agent deployments are recreating familiar identity-management failures at machine scale. People give agents their own credentials; agents receive long-lived API keys; permissions are broad; local agents can effectively impersonate their users; and human approval can become so frequent that it produces consent fatigue rather than meaningful control. NIST recommends treating agents as first-class entities with their own identities and credentials, using tightly scoped, short-lived authorization and attenuating delegated rights as authority travels through agentic call chains. (NIST)
This is essential security work. But it also exposes a further governance question.
A properly identified agent can still perform an illegitimate action.
A correctly authenticated agent can still exceed its mandate.
A technically valid permission can still be broader than the decision authority that justified granting it.
The problem is therefore not solved by knowing who or what made the API call. We must also know why that actor had the standing to make that particular consequential choice.
The Synthocracy Institute’s Decision Authority Record already makes this separation explicit: the ability of a system to perform an operation does not establish permission to perform it, and granted permission does not by itself establish legitimate authority. The record therefore separates technical capability, permission and authority rather than using an event log as proof that an action was governed.
2. Capability, permission and authority are three different layers
An AI system may possess capability without permission. A coding agent may technically know how to delete a production database even though its tools do not allow it to do so.
It may possess permission without decision authority. The same agent may hold database credentials permitting deletion because administrators provisioned a broad role, while organisational policy permits it only to modify a narrow set of test records.
And it may possess institutional authority without direct technical capability. A chief security officer may have the organisational authority to order a production system disconnected while relying on another team or vendor to execute the action.
These distinctions already exist in human institutions. A bank employee may physically be capable of accessing a file without being permitted to do so. A manager may possess software permission to approve an expense while lacking authority to approve their own transaction. A minister may possess lawful authority to order an administrative action without personally holding the credentials required to perform it.
Agentic systems do not abolish these distinctions. They make them harder to see because several layers can be compressed into one machine-mediated transaction.
The successful API call can appear to answer all the questions at once:
the agent was identified → the credential was accepted → the action was permitted → therefore the action was authorised.
That final inference does not necessarily follow.
Technical authorization usually answers a bounded security question: is this principal permitted, under the current access-control policy, to perform this operation on this resource? Institutional authority asks a broader question: what law, contract, organisational role, consent, mandate or other legitimate basis entitled the principal to exercise that power under these circumstances?
The two systems of meaning meet at execution, but they are not identical.
3. Authentication proves identity, not mandate
The distinction becomes clearer if we move backwards through the chain.
Authentication establishes, with some level of assurance, who or what is presenting itself.
Authorization in the cybersecurity sense determines whether that identity may access a resource or perform an operation.
Neither automatically establishes the full substantive mandate behind the action.
NIST illustrates why identity itself is becoming difficult in agentic environments. Sharing a human user’s credentials with an agent allows the agent to impersonate that user and creates accountability and non-repudiation problems. NIST therefore argues that agents should possess distinct identities, credentials and entitlements bound to the person or system for whom they operate. (NIST)
That is an important improvement. Instead of a log saying:
Alice transferred €82,000
the system may be able to say:
Procurement Agent 47, operating for Alice, transferred €82,000.
But even this stronger record leaves the decisive question open:
What exactly had Alice delegated to Agent 47?
Was it authorised to discover suppliers? Negotiate? Prepare the order? Select the winning offer? Execute a payment? Change the supplier after approval? Subdelegate verification? Exceed an original budget when shipping costs changed?
Identity tells us who acted.
Permission tells us which doors opened.
Authority tells us which choices were legitimately theirs to make.
4. A broad permission is not a broad mandate
This distinction becomes especially important because software permissions are often designed around technical resources rather than the semantic purpose of an action.
A permission may say:
payments.write
email.send
crm.update
deploy.production
records.modify
These scopes can tell the infrastructure what operation the agent may attempt. They do not necessarily express why the operation is being performed, for whom, under which substantive conditions, or as part of which decision.
A sales agent authorised to send email might legitimately send a quotation to a prospect. The same permission could technically allow it to send a contractual commitment the organisation never authorised it to make.
A healthcare agent might legitimately update an appointment status. The same technical write permission could permit modification of information with much greater clinical significance.
A public-sector agent might be authorised to request missing documents from an applicant. A broad case-management permission could also allow it to change a field that materially alters eligibility.
The Government of Canada’s 2026 guidance on agentic AI reflects precisely this concern. It recommends explicit activity-permission levels such as “draft only” or “read only,” narrowly bounded data and tool access, distinct agent IDs, human confirmation before actions that alter system state unless impact is demonstrably low and trivially reversible, and clear ownership and escalation. It also warns that more autonomous systems can take unintended actions across multiple systems and permissions when boundaries are unclear. (Canada)
This is good bounded-autonomy design. Yet the governance layer still needs one more connection:
What mandate justified the permission?
Without that connection, least privilege can reduce the blast radius of an error while still leaving the source of legitimate authority obscure.
5. Authority is contextual
Permission is often provisioned before a workflow begins. Authority can depend on what happens during the workflow.
A procurement agent may legitimately purchase replacement parts up to €20,000 under routine operating conditions. The same agent may encounter a supplier substitution, sanctions alert, conflict of interest, unusual delivery route or major price deviation. Its technical permissions have not changed. Its legitimate authority may have.
This makes authority a state that can depend on purpose, circumstances, evidence, time, amount, affected party, counterparty, risk and previous decisions.
An agent can therefore remain fully within its technical permission set while moving outside the mandate under which those permissions were granted.
Recent standards work is beginning to grapple with exactly this dynamic problem. An Internet-Draft published in May proposes an architecture for auditing AI-agent delegation and interactions in which auditing must connect intent, delegation, authorization and execution across system boundaries. Crucially, it treats authorization as a time-evolving state and proposes records for initial grants, narrowed scope, step-up approvals, revocation and expiry so that the authority in force at a particular moment can later be reconstructed. (datatracker.ietf.org)
This is a major conceptual improvement over treating a valid credential as a static answer.
Agentic governance increasingly needs to ask not:
Did this agent have access?
but:
What authority was in force for this action at this moment?
6. Delegation must become narrower as it travels
The problem intensifies when agents delegate to other agents.
Suppose a human authorises an executive agent to arrange a business trip within a €5,000 budget. The executive agent delegates flight search to one agent, hotel selection to another and payment to a third.
A badly designed system can treat the original €5,000 authority as a credential that travels intact through the chain. Every downstream actor receives broad capability because each is “working for” the original user.
But delegation should normally attenuate rather than expand.
The flight-search agent might require permission to query availability but no authority to spend. The booking agent might receive transaction authority limited to one named itinerary. The payment agent might need authority for one merchant, one currency, one amount and one expiry window. None should inherit every right possessed by the original agent merely because it sits downstream.
NIST now points directly toward this model, describing transaction tokens and other approaches designed to carry authorization context through human and agentic call chains while ensuring that delegated authorization becomes narrower as it travels. (NIST)
Current research is pushing further. A June 2026 preprint proposes a compositional authorization model for agentic systems in which delegation is not treated merely as a reusable credential but as a constrained relationship with explicit scope, contextual boundaries and attenuation through recursive delegation. (arXiv)
The underlying governance principle is straightforward:
An agent should not be able to delegate more authority than it possesses, and a downstream agent should receive no more authority than is necessary for the delegated task.
This is not specifically an AI principle. It is a longstanding principle of controlled delegation made newly urgent by systems capable of creating their own operational chains.
7. The model should not be the final judge of its own authority
One of the most consequential design mistakes is to encode an organisation’s governance boundary primarily in natural-language instructions given to the same model that is trying to accomplish the task.
For example:
“Buy whatever equipment is needed, but do not make high-risk purchases without approval.”
That instruction may help. It should not be the only thing standing between the agent and a high-risk transaction.
The reason is architectural. The system responsible for planning the action is also being asked to determine whether the action lies within its mandate. If the model misunderstands the policy, is prompt-injected, encounters conflicting instructions or discovers an unexpected route, the control can fail at the same point as the task reasoning itself.
A very recent arXiv preprint, posted on 31 August, makes the issue concrete. Delegation Without Trust evaluates a model of common multi-agent practice in which agents hold broad bearer credentials and authorization is effectively gated inside the model. The authors test confused-deputy behaviour, token theft and replay, prompt-injection privilege escalation and compromised sub-agents. They report that the default runtime fails all four threat classes and that, among four examined ecosystems—LangGraph, CrewAI, AutoGen and the Model Context Protocol authorization model—no existing standard alone satisfied their complete requirement set. Their proposed external authorization broker confines actions independently of the model. The results are preliminary research rather than an established industry consensus, but the architectural lesson is important: consequential authority should not depend entirely on the model correctly policing itself. (arXiv)
The safer pattern is therefore:
agent proposes → external policy evaluates → infrastructure enforces.
The model may reason about what it believes is allowed. The control plane should decide what actually reaches the point of effect.
8. Human approval does not automatically create authority either
It is tempting to solve the problem by adding a human approval step.
But a click does not automatically transform questionable machine action into legitimate human action.
NIST warns that frequent agent permission requests can create consent fatigue analogous to MFA fatigue: users become conditioned to approve prompts simply to keep the workflow moving. When this happens, human-in-the-loop controls may undermine the accountability and non-repudiation they were intended to provide. (NIST)
The EU AI Act reaches the same issue from another direction. Article 14 requires effective human oversight for high-risk AI systems and says that assigned overseers should, as appropriate and proportionate, understand the system’s capacities and limitations, monitor it, interpret outputs, decide not to use the system, disregard or override its output, and intervene in its operation or interrupt it through a stop mechanism. The Regulation also explicitly refers to the competence, training and authority of people assigned oversight functions. (Eur-Lex)
The important word is not merely human.
It is authority.
A junior employee required to approve a machine-generated transaction may not possess the organisational freedom to refuse it. A reviewer presented with hundreds of approvals per hour may formally possess a veto but lack the cognitive space to exercise judgment. A manager may click approve without seeing the evidence that shaped the action. A human may be present without becoming the actual source of the decision.
This is why the Synthocracy Institute’s working model of meaningful human decision authority distinguishes visibility, epistemic capacity, cognitive space, decisional authority, effective intervention and traceability rather than treating “human in the loop” as a sufficient answer.
Adding human approval can strengthen authority.
It cannot be assumed to manufacture it.
9. Permission can outlive authority
Agentic systems also introduce a temporal problem.
A credential may remain technically valid after the authority that justified it has expired.
An employee changes department. A project ends. A contract lapses. A client revokes consent. A temporary emergency mandate expires. A transaction limit is lowered. An agent delegates work to another agent and then terminates. A previously approved supplier becomes prohibited.
If the permission remains live, the infrastructure may still accept actions even though their authority basis has disappeared.
NIST specifically warns about long-lived bearer tokens and API keys in agent deployments and recommends more dynamic, tightly scoped and audience-restricted credentials. (NIST) Canada’s guidance likewise tells government organisations to pause, reassign or deactivate agents when ownership becomes unclear or when the responsible official leaves, unless responsibility is explicitly transferred. (Canada)
This gives us another critical distinction:
permission expiry is a technical event.
authority expiry is a governance event.
Well-designed systems should connect the two.
If a contract ends at midnight, the corresponding agent mandate should not continue until someone remembers to revoke a token three weeks later. If an agent receives temporary emergency authority, the credentials enabling that authority should expire with the emergency condition rather than becoming permanent infrastructure.
Authority should therefore be purpose-bound, time-bound and revocable wherever the context permits.
10. Event provenance is not authority provenance
Suppose an incident occurs six months later and an auditor reconstructs every event perfectly.
The record shows:
Agent A received a request.
Agent A invoked Tool B.
Tool B called Agent C.
Agent C authenticated to Payment Service D.
Payment Service D executed €82,000.
Every event is timestamped. Every identifier is valid. Every log is intact.
We now know exactly what happened.
We may still not know whether it should have happened.
The Synthocracy Institute’s existing framework calls this distinction event provenance versus authority provenance. Event provenance reconstructs the technical sequence. Authority provenance reconstructs the legitimate source, holder, delegation, scope, conditions and exercise of authority behind the consequential action. A log that says payment.execute = success establishes execution. It does not establish that the payment amount, recipient or purpose fell within the mandate.
The Decision Authority Record therefore connects:
authority basis → delegation → permissions → action → consequence.
Its agentic profile adds agent identity, credential reference, delegator, delegated scope, tool permissions, action budget, stop conditions and cross-agent handoffs.
This distinction is increasingly visible outside the Institute as well. The IETF audit-architecture draft proposes separate records for interactions, actions, delegations and authorization transitions precisely because isolated technical logs do not reliably preserve user intent or evolving delegation. (datatracker.ietf.org)
For consequential agentic systems, an audit should therefore be able to answer two different questions:
What did the system do?
and
Under whose authority was it entitled to do it?
A mature governance record needs both answers.
11. Permission without authority can create a new kind of institutional ambiguity
The consequences reach beyond cybersecurity.
Consider public administration. A ministry may give an AI agent access to a case-management system so that it can retrieve records, request missing evidence and prepare correspondence. Over time, the workflow becomes more autonomous. The agent begins selecting which cases require additional verification, deciding which document is sufficient evidence, changing routing status and triggering another administrative process.
All of these operations may be technically permitted.
But public authority cannot be reduced to database permissions.
The relevant question becomes: which law, administrative mandate or authorised procedure permits the agent to exercise each consequential form of discretion? Who owns the public power represented by the action? Where does routine administrative execution become material co-decision?
The Institute’s existing work makes precisely this point: public-sector telemetry can establish that an agent accessed a record or changed a field while failing to establish why it had the right to do so under those circumstances.
The same problem appears in private institutions.
A bank agent with fraud-system permissions may materially restrict a customer.
An HR agent with recruiting-system permissions may remove a candidate from consideration.
An insurance agent with claims-system permissions may move a case onto a different path.
A marketplace agent with ranking permissions may make a supplier effectively invisible.
These actions may be technically small while institutionally consequential.
The governance question is therefore not whether the agent possessed the necessary software permission.
It is whether the institution consciously delegated the consequential authority embedded in the operation.
12. The opposite problem also exists: authority without permission
None of this means permission engineering is somehow secondary.
An organisation can define a perfectly legitimate mandate and fail to implement the technical controls required to exercise it.
A manager may authorise an agent to spend €5,000, while its credential allows €500,000.
A government programme may legally constrain an agent to one class of records while the service account has access to an entire database.
A clinical workflow may authorise read-only retrieval while a shared account also possesses write access.
In such cases, institutional authority is narrow while technical permission is broad.
This mismatch is dangerous because the infrastructure cannot enforce the governance decision.
Good agentic governance therefore requires alignment across layers:
mandate and permission should correspond closely enough that exceeding authority becomes technically difficult rather than merely procedurally forbidden.
The objective is not to make software permissions encode every nuance of law or organisational judgment. That is unlikely to be realistic. The objective is to make sure that technical reach does not silently overwhelm institutional boundaries.
This is why least privilege remains fundamental but is not sufficient.
Least privilege constrains what can happen.
Authority governance establishes what may legitimately be decided.
13. Governed delegation can be better than informal human delegation
The argument should not be mistaken for a case against agentic automation.
In some institutions, human authority is already poorly documented. Employees inherit shared passwords. Approval powers are transmitted through informal messages. Temporary privileges become permanent. Managers cannot reconstruct who authorised a decision. Exceptions live in institutional memory rather than policy. Manual processes may produce little usable evidence.
A well-designed agentic system can improve this situation.
An agent can have a unique identity rather than borrowing a person’s account. It can receive an explicit scope rather than an informal instruction. A spending mandate can be machine-enforced. Credentials can expire automatically. Delegation to another agent can be recorded. Unusual actions can require escalation. Every consequential tool call can create a signed audit record. Authority can be revoked centrally.
The relevant distinction is therefore not:
human authority = legitimate
machine action = illegitimate.
It is:
governed delegation versus opaque delegation.
The Synthocracy corpus already treats this as an important positive counterexample: tightly bounded agents can enforce limits more consistently, preserve better records and make institutional authority more visible than the manual processes they replace.
The opportunity is real precisely because agentic systems force institutions to formalise decisions that humans previously handled informally.
The challenge is to formalise the right things.
The Synthocracy Permission–Authority Test
The following is a preliminary field diagnostic, not a validated compliance instrument. It is designed for one consequential agentic workflow or action rather than for an organisation’s entire AI programme.
- What can the agent technically do? Identify the actual tools, systems, data, write operations, transactions and downstream agents it can reach rather than relying on the intended use described in product documentation.
- What is the agent technically permitted to do? Record the credentials, scopes, roles, rate limits, transaction limits and other enforcement rules that the infrastructure will accept.
- What is the authority basis? Identify the law, policy, contract, consent, organisational role, delegated mandate or other legitimate source that permits the consequential action.
- Who is the principal? Establish the human or organisation on whose behalf the agent acts and distinguish that principal from the technical account through which the action is executed.
- What exactly was delegated? State the objective, permitted decisions, prohibited decisions, affected resources, monetary or data limits, counterparties, duration and conditions requiring escalation.
- Do permissions match the mandate? Identify any capability the agent can exercise technically but which lies outside its institutional authority, and any legitimate authority that cannot be reliably enforced by the technical architecture.
- Can delegated authority expand downstream? Determine whether sub-agents or tools inherit broad credentials, whether scope attenuates during delegation, and whether a downstream actor can obtain greater operational reach than its delegator intended.
- When does authority expire or change? Record time limits, role changes, completed tasks, revoked consent, changed risk status and other conditions that should narrow or terminate authority—and test whether permissions change with them.
- Who can revoke or override the authority? Identify both the actor with legitimate revocation power and the technical mechanism that makes revocation effective across agents, credentials, queued actions and downstream services.
- Can the authority chain be proven afterwards? The record should connect principal, mandate, identity, delegation, permissions, consequential action, intervention, outcome and remedy rather than relying solely on authentication or event logs.
The test does not ask organisations to build a legal ontology into every API request. It asks them to make one fundamental relationship visible:
why did this technical permission exist, and did the consequential action remain inside the authority that justified it?
14. From access control to authority control
For decades, digital security has concentrated on controlling access to resources. Who are you? Can you authenticate? Which role do you hold? Which file may you read? Which endpoint may you call?
Agentic AI does not make those questions obsolete. It makes them more important.
But it also adds another layer.
An agent can choose among actions. It can sequence them. It can discover intermediate routes. It can invoke other systems. It can delegate. It can act repeatedly at machine speed. The consequential meaning of its activity may therefore emerge from the relationship between objective, mandate, permissions and trajectory, not from one isolated access request.
This is why the governance model developed in the Synthocracy corpus extends the decision chain:
OBJECTIVE → MANDATE → AGENT IDENTITY → DELEGATED SCOPE → TOOL PERMISSIONS → INTERMEDIATE DECISIONS → ACTIONS → HANDOFFS → STATE CHANGE → CONSEQUENCE → REVIEW / REVOCATION / REMEDY.
The sequence reveals where permission sits.
It is indispensable.
It is also only one layer.
A system can have flawless identity management and still operate under an illegitimate mandate. It can have perfect authentication and excessive permissions. It can have narrow permissions and still use them for the wrong purpose. It can produce complete logs while losing the institutional chain showing who had authority to cause the outcome.
AI governance must therefore move beyond asking whether the system was technically authorised.
It must ask whether authority survived the translation from human intent into machine execution.
Conclusion — A valid credential is not a mandate
The agent presents a valid credential.
The API accepts it.
The transaction succeeds.
Those facts tell us something important. They tell us that the technical system worked as configured.
They do not necessarily tell us that the institution governed the decision.
As AI moves from assisting people to acting for them, the difference between permission and authority becomes harder to ignore. NIST is building identity and authorization work for agents. Government guidance is moving toward bounded permissions, unique identities, recoverability and explicit human responsibility. Standards research is beginning to model delegation and authorization as dynamic states that must travel across agentic chains. New security work is testing whether compromised agents can remain confined to the authority actually delegated to them. (NIST)
These developments are converging on a common problem even though they approach it from different disciplines.
The infrastructure needs to know who the agent is.
It needs to know what the agent may access.
But governance must also be able to explain why the agent had the right to make this particular consequential move.
That requires a chain connecting the institutional source of authority to delegation, permissions, execution, evidence and revocation.
The central rule is therefore simple:
Do not mistake a door that opens for a mandate to walk through it.
For organisations deploying consequential AI agents, the practical question is no longer merely:
What permissions does the agent have?
It is:
Who authorised this agent to perform this particular action, for whom, under which mandate, within which limits, for how long—and can the organisation prove that the action remained inside that authority?
That is the point at which access control becomes governance.
