Agent Authority Models: Who Decides What Your AI Can Do?

When an AI agent takes an action -- sends a customer email, updates a billing record, approves an expense, routes a support ticket -- it is exercising authority. The question that most teams never answer explicitly is: where does that authority come from? Who granted it? What are its boundaries? And can it be revoked when conditions change?

In human organizations, authority is governed by role hierarchies, delegation policies, approval chains, and institutional norms that have been refined over decades. In AI agent systems, authority is usually implicit: the agent can do whatever its tool integrations technically allow, constrained only by prompt instructions that the model may or may not follow. This is not an authority model. It is the absence of one.

This article examines four authority model patterns for AI agent systems: flat, hierarchical, delegated, and coalition. For each pattern, we describe how authority is asserted, verified, and revoked -- and where the compliance and safety gaps emerge. The goal is a framework that engineering and governance teams can use to select and implement the right authority model for their agent architecture.

Why Authority Models Matter Now

The urgency of this problem has increased sharply for three reasons. First, agent systems are moving from single-agent architectures to multi-agent topologies where agents spawn, delegate to, and coordinate with other agents. The OpenAI Agents SDK and similar frameworks now provide first-class primitives for agent handoffs and sub-agent creation, which means delegation is becoming a default pattern rather than an advanced one.

Second, regulatory frameworks are converging on explicit authority requirements. The NIST AI Risk Management Framework requires organizations to define accountability structures for AI systems. The EU AI Act's Article 14 mandates human oversight capabilities for high-risk AI systems, which presupposes that someone has defined what the AI is authorized to do and that a human can intervene when it exceeds that boundary. You cannot comply with these requirements if your agents have no formal authority model.

Third, as MIT Technology Review has documented, the practical failures in enterprise AI agent deployments frequently trace to authority confusion: agents that take actions they were not intended to take, delegation chains that lose track of the original authorization scope, and systems where no one can determine after the fact who authorized a particular action. These are authority model failures, not model capability failures.

Implicit vs. Explicit Authority

Before examining the four patterns, it is worth distinguishing between implicit and explicit authority, because most agent systems operate entirely on implicit authority and do not realize it.

Implicit authority is authority that exists by default because no one restricted it. An agent has access to a CRM API that exposes read and write endpoints. Nothing in the system explicitly grants the agent write access -- but nothing prevents it either. The agent's authority is defined by the union of all technically accessible capabilities, minus whatever prompt instructions the model happens to follow on any given invocation.

Explicit authority is authority that is granted through a formal mechanism, with defined scope, conditions, and expiration. The agent's authority to write CRM records is specified in a policy that names the agent, defines the scope (which record types, which fields), specifies the conditions (only for accounts assigned to the delegating user), and carries an expiration or review date. If the policy does not grant the authority, the authority does not exist -- regardless of what the agent can technically access.

The difference between implicit and explicit authority is the difference between "the agent has not been told not to" and "the agent has been specifically authorized to." In production systems where actions have consequences, only explicit authority is defensible.

Pattern 1: Flat Authority

In the flat authority model, every agent in the system has the same level of authority. There is no hierarchy, no delegation chain, and no distinction between agents based on their role or context. Each agent can access the same tools, invoke the same actions, and operate within the same (typically broad) scope.

When It Appears

Flat authority is the default model for most early-stage agent implementations. A team deploys a single agent with access to a set of integrations. The agent can read and write to the CRM, send emails, create tickets, and query the knowledge base. All capabilities are available to all invocations. As the team adds more agents -- a support agent, a sales agent, a billing agent -- each new agent inherits the same broad access because the integration architecture was not designed to distinguish between them.

Authority Assertion and Verification

In a flat model, authority is asserted by possession: if the agent has the API key or tool integration, it has the authority. There is no separate verification step. There is no mechanism to distinguish between an agent that should have write access and one that should not, because the model does not represent that distinction.

Strengths and Limitations

Flat authority is simple. For single-agent systems with low-stakes actions and a human reviewing every output, it is often sufficient. The limitations emerge at scale: flat authority cannot enforce least-privilege, cannot distinguish between agent roles, cannot restrict actions based on context, and cannot be audited at the per-action level. When something goes wrong, the investigation question "was this agent authorized to take this action?" has no meaningful answer, because every agent is authorized to take every action.

Pattern 2: Hierarchical Authority

Hierarchical authority introduces levels of authority that correspond to agent roles. A supervisor agent has broader authority than a worker agent. Authority flows downward: higher-level agents can access capabilities that lower-level agents cannot. The hierarchy is typically static and mirrors organizational roles.

When It Appears

Hierarchical authority is common in enterprise agent deployments where the agent topology maps to an organizational structure. A management-level agent can approve expenses up to $10,000; a team-level agent can approve up to $1,000; a task-level agent can only draft expense reports for human review. The hierarchy reflects the organizational delegation of authority.

Authority Assertion and Verification

Authority is asserted through role assignment. Each agent is assigned a role that carries a predefined set of permissions. Verification consists of checking the agent's role against the required permission for the requested action. This is role-based access control (RBAC) applied to agent systems.

Strengths and Limitations

Hierarchical authority provides least-privilege enforcement for static topologies. Each agent has only the authority its role grants. The limitation is rigidity: hierarchical models struggle with dynamic situations where an agent temporarily needs elevated authority, where authority should vary based on context rather than role, or where the hierarchy itself changes over time. Hierarchical authority also does not address delegation -- what happens when a supervisor agent needs to grant a temporary capability to a worker agent for a specific task.

// Hierarchical authority check (pseudocode)
function checkAuthority(agent, action, resource) {
  const role = agent.assignedRole;
  const permissions = rolePermissions[role];

  if (!permissions.includes(action)) {
    return { decision: "DENY", reason: "Role lacks permission", role, action };
  }

  if (action.valueLimit && resource.value > permissions.valueLimit) {
    return { decision: "ESCALATE", reason: "Exceeds role value limit",
             escalateTo: role.parent };
  }

  return { decision: "ALLOW", role, action, resource };
}

Pattern 3: Delegated Authority

Delegated authority adds a dynamic dimension to the hierarchical model. Instead of static role assignments, authority is granted through explicit delegation acts. A principal (human or agent) delegates specific authority to an agent for a defined scope, duration, and set of conditions. The delegation is recorded as a first-class artifact that can be inspected, verified, and revoked.

When It Appears

Delegated authority emerges in systems where agents act on behalf of specific users or in specific contexts. A customer success manager delegates authority to an agent to handle their accounts for the next 8 hours. A compliance officer delegates review authority to an agent for a specific audit scope. A background process delegates data access to a sub-agent for a specific ETL job.

Authority Assertion and Verification

Authority is asserted through delegation tokens -- explicit, verifiable artifacts that carry the delegating principal's identity, the scope of the delegation, the conditions under which it is valid, and the expiration. When the agent requests an action, the enforcement point verifies the delegation token against the authority registry: is the token valid? Is the requested action within the delegated scope? Have the conditions been met? Has the delegation expired or been revoked?

The Non-Amplification Principle

The critical constraint in delegated authority is non-amplification: an agent cannot delegate more authority than it was granted. If Agent A is delegated read-only access to customer records for accounts in the EMEA region, Agent A cannot delegate write access to Agent B, and it cannot delegate read access to accounts outside EMEA. Each delegation in the chain can only maintain or narrow the scope -- never expand it. This principle, borrowed from distributed systems security (specifically, the Biba and Bell-LaPadula models), prevents the cascading approval failures that plague multi-agent systems without formal authority models.

Strengths and Limitations

Delegated authority provides the flexibility of dynamic authority grants with the safety of explicit, verifiable, revocable permissions. It maps naturally to how human organizations actually work -- authority is granted by people in roles, scoped to specific tasks, and time-limited. The limitation is implementation complexity. Delegation requires an authority registry, token verification at every enforcement point, and revocation propagation across the agent topology. For teams building their first agent system, this may be over-engineering. For teams operating multi-agent systems in regulated or high-stakes environments, it is the minimum viable authority model.

Pattern 4: Coalition Authority

Coalition authority addresses systems where no single agent or principal has sufficient authority to authorize an action unilaterally. Instead, authority emerges from the agreement of multiple agents or principals, each contributing a partial authorization that is insufficient on its own.

When It Appears

Coalition authority appears in high-stakes decision environments: a loan approval that requires sign-off from both a risk assessment agent and a compliance review agent; a production deployment that requires authorization from both a testing agent and a security scanning agent; a customer data export that requires consent verification from both the data governance agent and the requesting customer's identity verification agent.

Authority Assertion and Verification

Authority is asserted collectively. Each participating agent contributes its partial authorization to a coordination point. The coordination point verifies that all required authorizations are present, that each authorization is within the granting agent's authority, and that the composite authorization satisfies the policy for the requested action. Only when all required authorizations are assembled does the action proceed.

// Coalition authority check (pseudocode)
function checkCoalitionAuthority(action, resource, authorizations) {
  const policy = getCoalitionPolicy(action, resource);
  const requiredRoles = policy.requiredAuthorizers;

  for (const role of requiredRoles) {
    const auth = authorizations.find(a => a.role === role);
    if (!auth) {
      return { decision: "PENDING", missing: role };
    }
    if (auth.expired || auth.revoked) {
      return { decision: "DENY", reason: "Stale authorization", role };
    }
    if (!isWithinScope(auth, action, resource)) {
      return { decision: "DENY", reason: "Authorization out of scope", role };
    }
  }

  return { decision: "ALLOW", authorizations: authorizations.map(a => a.id) };
}

Strengths and Limitations

Coalition authority provides the strongest safety guarantees because no single point of failure can authorize a high-stakes action. It naturally implements separation of duties, which is a requirement in many regulatory frameworks. The limitations are latency and complexity: coalition authorization requires coordination between multiple agents, which adds time to the decision path, and the coordination logic itself must be carefully designed to avoid deadlocks, stale authorizations, and race conditions.

Choosing the Right Authority Model

The right choice depends on your agent topology, the stakes of the actions your agents take, and your regulatory environment. Most teams should start with hierarchical authority -- it provides meaningful least-privilege enforcement with manageable complexity -- and evolve to delegated authority as their agent topology becomes more dynamic and their compliance requirements become more demanding.

Coalition authority is appropriate for specific high-stakes decision points rather than as the default model for all agent actions. A system might use hierarchical authority for routine operations, delegated authority for user-specific tasks, and coalition authority for actions that require multi-party authorization -- such as large financial transactions, production deployments, or data export requests.

Implementing Authority Revocation

An authority model that can grant but not revoke is a liability. Revocation must be a first-class operation, and it must propagate quickly. The scenarios that require revocation are predictable:

• User deprovisioning: When a user leaves the organization or changes roles, every authority they delegated to agents must be revoked immediately. If the agent retains delegated authority from a deprovisioned user, it is operating without a valid principal.
• Incident response: When a security event is detected -- a compromised API key, a suspected prompt injection, an anomalous action pattern -- the ability to revoke an agent's authority in seconds rather than minutes is the difference between a contained incident and a breach.
• Policy change: When compliance requirements change, authority grants that were valid under the old policy may need to be narrowed or revoked under the new one. The authority registry must support bulk revocation by scope, role, or delegation chain.
• Time expiration: Delegation tokens should carry explicit expiration timestamps. Authority that was granted for an 8-hour shift should not persist into the next day. Time-limited authority is a simple but effective safeguard against stale permissions.

Revocation is where implicit authority models fail catastrophically. If authority was never explicitly granted, it cannot be explicitly revoked. The only recourse is to remove the agent's tool access entirely, which is a sledgehammer solution that disrupts legitimate operations along with illegitimate ones.

Authority Models and the Compliance Landscape

Regulatory frameworks are converging on a set of requirements that implicitly demand formal authority models. The NIST AI RMF requires that organizations "define, document, and implement measures to manage identified risks," which includes the risk of unauthorized agent actions. The EU AI Act's Article 14 requires that high-risk AI systems be designed to allow effective human oversight, which is only possible if the system has a defined authority model that humans can inspect, modify, and override.

Without a formal authority model, an organization cannot answer the basic compliance questions:

• What is this agent authorized to do? (Scope)
• Who authorized it? (Accountability)
• Under what conditions? (Context)
• How can the authorization be changed or revoked? (Oversight)
• What is the record of every authorization that was granted and exercised? (Audit)

These questions are not new -- they are the same questions that compliance frameworks have asked about human authorization for decades. The difference is that agent systems answer them at machine scale and machine speed, which means the answers must be systematic rather than procedural.

Building Decision Infrastructure for Authority

An authority model is not a standalone artifact. It is a component of the broader decision infrastructure for agents that governs what agents can do, how decisions are made, and how outcomes are traced. The authority model sits at the first layer -- it determines which actions are within scope before any decision logic evaluates whether those actions should be taken.

Implementing an authority model requires three concrete components:

• An authority registry that stores all active authority grants (role assignments, delegation tokens, coalition memberships) and supports real-time queries: "does this agent have authority to perform this action on this resource in this context?"
• A policy enforcement point that sits between the agent's action output and the execution layer, querying the authority registry before every consequential action.
• An audit log that records every authority assertion (what was requested), every verification (what was checked), and every outcome (was authority granted, denied, or escalated) -- with the full context needed to replay the decision after the fact.

Teams that are building or evaluating agent systems should treat the authority model as a design decision, not an afterthought. The choice between flat, hierarchical, delegated, and coalition authority shapes the safety envelope of the entire system. Getting it right before production is significantly cheaper than retrofitting it after an incident -- and regulatory frameworks are increasingly making it a requirement, not a recommendation.