When a human employee is hired, they receive a job description, a set of system access credentials scoped to their role, an approval authority limit, and a manager who can revoke or modify any of those grants. The boundaries are explicit. The employee does not decide what they are authorized to do -- the organization decides, documents it, and enforces it through systems that exist independently of the employee's behavior.
When an AI agent is deployed, the equivalent boundaries are usually absent. The agent's authority is defined implicitly by whatever tools it can access, whatever actions its code permits, and whatever constraints the prompt happens to enforce on any given invocation. There is no formal scope document. There is no authority limit that exists independently of the agent's own processing. There is no mechanism for one agent to grant bounded authority to another agent and have that grant be verifiable, time-limited, and revocable.
This article examines the concept of authority as it applies to AI agents: what types of authority exist, how delegation works (and how it fails), what principles govern safe delegation, and how to assess whether your own agent system has adequate authority boundaries. The goal is a practical framework, not an academic taxonomy -- something an engineering team can use to audit their current agent deployment and identify the gaps that matter.
Three Types of Authority
Not all authority is the same. Conflating different types of authority is one of the most common design errors in agent systems, because it leads teams to grant broad access when they intended to grant narrow permission. The three types that matter for AI agents are resource authority, action authority, and delegation authority.
Resource Authority: Access to Systems and Data
Resource authority governs what systems, data stores, and external services an agent can access. An agent with resource authority over the CRM can read customer records. An agent with resource authority over the billing system can query invoice data. Resource authority is the most familiar type because it maps directly to infrastructure access control -- API keys, service accounts, database credentials, OAuth scopes.
The danger with resource authority is over-granting. It is operationally convenient to give an agent a service account with broad read/write access to the systems it might need, the same way it is convenient to give a contractor admin access to get them unblocked quickly. The result is that the agent's resource authority is defined by the broadest credential it holds, not by the narrowest set of resources it actually needs for its task.
Action Authority: Permission to Execute Operations
Action authority governs what the agent can do, not just what it can see. An agent might have resource authority to read and write the CRM, but its action authority might be limited to updating the notes field on existing records -- it cannot create new records, delete records, or modify the account owner. Action authority is the layer above resource authority: it constrains which operations the agent may perform on the resources it can access.
In most agent systems today, action authority does not exist as a separate concept. The agent's actions are constrained by the tools it has access to and the prompt instructions it follows. If the agent has a tool called update_crm_record that accepts any field name and any value, the action authority is "anything the tool API permits" -- which is typically far broader than the intended scope. The Stanford HAI governance research identifies this gap as a structural problem: agent frameworks provide tool access but not tool authority -- the two are conflated into a single mechanism.
Delegation Authority: The Power to Pass Control
Delegation authority is the most consequential and least understood type. It governs whether an agent can grant some or all of its authority to another agent. In multi-agent systems where agents spawn sub-agents, hand off tasks, or coordinate workflows, delegation authority determines whether authority can propagate -- and how far.
An agent with delegation authority can create a sub-agent and grant it a subset of its own resource and action authority for a specific task. An agent without delegation authority operates in isolation -- it can act within its own boundaries but cannot extend those boundaries to other agents. The distinction matters because delegation is the mechanism through which authority can amplify, cascade, and escape the boundaries that were originally intended.
| Authority Type | Governs | Example Grant | Example Violation |
|---|---|---|---|
| Resource | What systems/data the agent can access | Read access to EMEA customer records | Agent reads APAC customer records it was not granted access to |
| Action | What operations the agent can perform | Update notes field on assigned accounts | Agent modifies the account owner field |
| Delegation | Whether the agent can pass authority to others | Delegate read-only access to sub-agent for 1 hour | Agent delegates write access it was never granted |
Implicit vs. Explicit Authority
Every agent has authority. The question is whether that authority is implicit or explicit.
Implicit authority is authority the agent has because no one restricted it. The agent can send emails because it has access to the email API and nothing in the system prevents it. The agent can delete records because the database credential grants DELETE permissions and no policy enforcement point checks whether the agent should be deleting records. Implicit authority is the default state of every agent system that was built for functionality first and governance second.
Explicit authority is authority that was deliberately granted through a formal mechanism. The grant specifies what the agent can do, under what conditions, for how long, and who approved the grant. If the grant does not exist, the authority does not exist -- regardless of what the agent can technically accomplish. As the NIST AI RMF Govern function establishes, governed AI systems operate on the principle that authority must be explicitly assigned, documented, and reviewable -- not inferred from technical capability.
The practical test is simple: if you shut down every agent in your system right now and asked someone to reconstruct exactly what each agent was authorized to do, could they do it without reading the agent's code? If the authority boundaries exist only in the code (or worse, in the prompt), the authority is implicit. If the boundaries exist in a policy layer that can be inspected independently of the agent's implementation, the authority is explicit.
Four Principles for Safe Delegation
When an agent delegates authority to another agent, four principles determine whether the delegation is safe. These principles are not theoretical -- they are the engineering constraints that prevent the cascading authority failures that McKinsey's AI governance research has documented as one of the primary risks in multi-agent enterprise deployments.
Principle 1: Minimal Footprint
A delegation should grant the minimum authority required for the delegated task -- no more. If the sub-agent needs to read three specific fields from customer records to complete its task, the delegation should grant read access to those three fields, not read access to the entire customer record. Minimal footprint is the delegation-specific application of the principle of least privilege. The difference from traditional least privilege is that in delegation, the granting agent makes the scoping decision at delegation time, not an administrator at configuration time. This means the delegation mechanism must support fine-grained scoping, not just "pass all my permissions to the sub-agent."
Principle 2: Bounded Duration
Every delegation should have an explicit expiration. Authority that was granted for a specific task should not persist after the task completes. The delegation token or grant should carry a timestamp after which it is automatically invalid, regardless of whether the sub-agent has finished its work. If the sub-agent needs more time, it must request a renewal from the delegating agent -- which creates an opportunity for the delegating agent to reassess whether the delegation should continue.
Principle 3: Scoped Targets
A delegation should specify not just what the sub-agent can do but what it can do it to. "Read customer records" is an insufficiently scoped delegation. "Read the name, email, and subscription_tier fields for customer records where region = EMEA and account_status = active" is a scoped delegation. The scope constrains the blast radius: if the sub-agent is compromised, malfunctions, or exceeds its intended behavior, the damage is limited to the resources within the delegation scope.
Principle 4: Non-Delegable Limits
Some authority should be explicitly marked as non-delegable. A human administrator grants an agent the authority to approve expenses up to $5,000. That agent should not be able to delegate that approval authority to a sub-agent -- the approval authority is a trust relationship between the human and the specific agent, and extending it to an unknown sub-agent violates the trust chain. Non-delegable limits prevent the "authority laundering" pattern where authority passes through a chain of delegations until it reaches an agent that the original grantor never intended to authorize.
// Delegation grant with four principles applied
{
"delegation_id": "del-2026-05-22-a7f3",
"delegating_agent": "finance-agent-primary",
"receiving_agent": "expense-lookup-sub-agent",
"authority_granted": {
"resource": "expense_records",
"actions": ["read"],
"scope": {
"fields": ["amount", "category", "date", "status"],
"filter": "department = 'engineering' AND date >= '2026-04-01'"
}
},
"duration": {
"granted_at": "2026-05-22T10:00:00Z",
"expires_at": "2026-05-22T11:00:00Z"
},
"delegable": false,
"granted_by_human": "[email protected]",
"revocable_by": ["finance-agent-primary", "[email protected]"]
}Worked Example: Expense-Approval Agent with Five Authority Boundaries
To make these concepts concrete, consider an expense-approval agent deployed in an enterprise environment. The agent reviews submitted expenses, checks them against policy, and either auto-approves, requests additional information, or escalates to a human approver. Here are the five authority boundaries that govern its behavior.
Boundary 1: Resource Authority -- What It Can See
The agent has read access to expense records for the departments it is assigned to manage. It has read access to the company expense policy document. It has read access to the submitter's profile (name, department, role, approval level). It does not have access to other HR data, compensation records, or performance reviews. The resource boundary ensures that the agent cannot access information beyond what is needed for expense evaluation.
Boundary 2: Action Authority -- What It Can Do
The agent can approve expenses up to $500 without escalation. It can request additional documentation from the submitter by creating a comment on the expense record. It can escalate expenses to a named human approver. It cannot modify the expense amount, change the submitter, alter the expense category after submission, or delete expense records. The action boundary ensures that the agent's write operations are limited to the three specific actions it is designed to perform.
Boundary 3: Delegation Authority -- What It Can Pass
The agent can delegate read-only access to expense records to a sub-agent for lookup and summarization purposes. The delegation is time-limited (maximum 30 minutes), scoped to the specific expense under review, and non-delegable (the sub-agent cannot further delegate). The agent cannot delegate its approval authority -- that authority is marked as non-delegable in the authority grant.
Boundary 4: Temporal Authority -- When It Can Act
The agent operates during business hours for the relevant timezone (Monday through Friday, 8:00 AM to 6:00 PM). Expenses submitted outside business hours are queued for the next business day. The agent's approval authority expires at the end of each fiscal quarter and must be renewed by the finance team. This temporal boundary prevents the agent from making approval decisions during periods when human oversight is reduced and ensures periodic review of the agent's authority.
Boundary 5: Value Authority -- How Much It Can Commit
The agent's auto-approval limit is $500 per individual expense and $2,000 cumulative per submitter per month. If either threshold is exceeded, the expense is escalated regardless of whether it otherwise meets policy criteria. The value boundary ensures that the financial exposure of the agent's autonomous decisions is capped at a level the organization has explicitly accepted. If the business wants to raise the limit, the change goes through the same approval process as any change to financial controls -- it is not a configuration tweak in the agent's code.
Where Delegation Fails: Common Patterns
Understanding how delegation fails is as important as understanding how it should work. Three failure patterns appear consistently in multi-agent systems.
Authority Amplification
Agent A has read access to customer records. Agent A delegates to Agent B, granting read and write access. Agent B now has more authority than Agent A was granted. This happens when the delegation mechanism does not enforce the constraint that delegated authority cannot exceed the delegating agent's own authority. The fix is a non-amplification check at delegation time: the system verifies that every permission in the delegation grant is a subset of the delegating agent's own active permissions.
Stale Delegation
Agent A delegates authority to Agent B for a specific task. The task completes, but the delegation is never revoked. Agent B retains authority that is no longer justified by any active task. Over time, the system accumulates stale delegations that represent authority grants with no current purpose. The fix is mandatory expiration on every delegation -- no perpetual grants -- combined with periodic reconciliation that identifies active delegations and verifies they correspond to active tasks.
Delegation Chain Opacity
Agent A delegates to Agent B. Agent B delegates to Agent C. Agent C takes an action that the original human authorizer of Agent A never anticipated. When the action is investigated, the chain A to B to C must be reconstructed -- but if the delegation records are incomplete or the chain is not traceable, the investigation reaches a dead end. The fix is that every delegation records both the immediate delegator and the original authority source, creating a traceable chain from any delegated action back to the human who originally authorized the capability. The EU AI Act's Article 14 human oversight requirements implicitly demand this traceability: if a human must be able to understand and intervene in AI system behavior, the authority chain that led to any given action must be reconstructible.
Eight-Question Authority Self-Assessment
For teams deploying AI agents in production, the following self-assessment identifies the most common authority gaps. Each question targets a specific risk. A "no" answer indicates a gap that should be addressed before the agent handles consequential tasks.
- Can you enumerate every resource your agent has access to? If the answer requires reading code or checking API credentials rather than querying a policy store, resource authority is implicit rather than explicit.
- Can you list every action your agent is authorized to take, separately from what it is technically capable of? If action authority is defined only by tool availability, the agent can do anything its tools permit -- which is almost certainly broader than intended.
- If your agent delegates to a sub-agent, is the delegation recorded as a verifiable artifact? If delegations are implicit (the sub-agent inherits the parent's credentials), they cannot be audited, scoped, or revoked independently.
- Do all delegations have explicit expiration timestamps? Perpetual delegations accumulate as stale authority grants that represent unmonitored risk.
- Is there a non-amplification check that prevents an agent from delegating more authority than it was granted? Without this check, delegation chains can escalate authority beyond the original grant.
- Can a human revoke a specific agent's authority within minutes, without disrupting other agents? If revocation requires redeploying the agent or rotating shared credentials, the revocation mechanism is too coarse-grained for incident response.
- Can you reconstruct the complete authority chain for any action taken by any agent in the past 90 days? If the answer is "not without significant manual investigation," the audit trail for authority is insufficient for regulatory compliance.
- Has the team explicitly decided which authority grants are non-delegable? If every authority is implicitly delegable, the organization has not made a deliberate decision about where delegation should stop -- and the answer "everywhere" is almost never correct.
If your team answered "no" to three or more of these questions, the agent system is operating with implicit authority that is likely broader and less governed than the organization intends. The gaps are addressable -- they are architectural problems, not fundamental limitations -- but they require deliberate design decisions about authority that most agent frameworks do not force teams to make.
Authority as Infrastructure
Authority boundaries are not documentation. They are infrastructure. A documented authority policy that is not enforced by the system is a liability, not a control -- it creates the appearance of governance without the reality. The engineering work is to implement authority as a runtime property of the agent system: resource authority enforced at the access layer, action authority enforced at the tool execution layer, delegation authority enforced at the agent coordination layer, and all three recorded in an audit trail that satisfies the traceability requirements of frameworks like the NIST AI RMF.
For teams building this infrastructure, the starting point is to make the implicit explicit. Enumerate what each agent can access, what it can do, and whether it can delegate. Write those boundaries down -- not in a document, but in a policy layer that the system enforces. Then build the audit trail that records every authority assertion, every delegation grant, and every authority check. The result is an agent system where the answer to "what is this agent authorized to do?" is not "whatever its code permits" but "exactly what the policy grants specify, and here is the record."
For the broader architectural context on how authority fits into deterministic AI decision infrastructure, and for a detailed examination of four authority model patterns (flat, hierarchical, delegated, and coalition), see Agent Authority Models: Who Decides What Your AI Can Do?.