Who Holds Authority When AI Can Act?

Artificial intelligence has moved beyond producing an answer for a person to read. An agent can retrieve information, select a tool, communicate in an organization’s name, change a record, open a support case, isolate an endpoint, provision infrastructure, or trigger a payment workflow. Each action can be useful. Each also changes the nature of accountability.

The crucial distinction is simple: software may perform an act, but it does not become the authority that legitimizes the act. Authority remains with the organization and the named people empowered to define its purpose, grant access, accept residual risk, and intervene when the system behaves outside its mandate. A model’s apparent initiative does not reduce those obligations. In a well-governed system, agency is a bounded delegation of execution, not a transfer of responsibility.

This distinction matters because the most consequential failures of agentic systems are rarely failures of text generation alone. They are failures of authorization, scope, evidence, and oversight. A capable agent with an overbroad service account, unbounded tool access, or ambiguous escalation rules can transform a plausible recommendation into an unauthorized operational decision at machine speed. The problem is architectural and institutional at once.

Delegation is not abdication

Organizations already delegate action to people, workflows, and conventional automation. A procurement manager can approve within a spending limit. A database job can execute a scheduled backup. A security analyst can isolate a device under an incident-response playbook. In each case, the delegation is meaningful only because the organization has specified a purpose, a boundary, an accountable owner, and a mechanism for reversal or review.

Agentic systems require the same discipline, with more precision. Their ability to compose actions across tools creates a wider gap between the instruction given and the effect produced. An instruction such as “resolve the incident” may lead an agent to query telemetry, alter a firewall rule, notify a customer, and create a ticket. No single prompt is adequate authorization for that chain of effects. Authority must be expressed through policy-enforced permissions, allowed action types, transaction limits, approval gates, and a clear termination path.

Delegate capability narrowly. Retain accountability explicitly.

An agent may be authorized to execute a defined class of actions. It should not be assumed to possess authority to reinterpret the organization’s objectives, expand its own access, or decide what residual harm is acceptable.

The unit of governance is the system-action pair

The most common analytical error is to classify “the AI system” as if it were a single risk object. It is not. The same language model may draft an internal meeting summary, recommend a customer response, and modify cloud identity settings through separate workflows. Those are materially different delegations with different evidence requirements, failure modes, and accountable decision makers.

Governance should therefore classify the system-action pair. For every action, leaders need to know what triggers it, what evidence the agent uses, which people, systems, records, or funds it can affect, whether the action is reversible, and who can challenge, override, or stop it. This forces an organization to examine the operational system around the model: prompts and skills, orchestration, data sources and memory, identity controls, application programming interfaces, downstream systems, human reviewers, vendors, and affected parties.

This approach also prevents a false sense of safety from a low-risk use case. A model that summarizes meeting notes may be a limited-impact, assistive capability. The same model connected to production administration tools is no longer governed by its summarization behavior. It is governed by its ability to change external state and by the consequences of doing so incorrectly or maliciously.

Authority must be scored on two independent axes

The authority and autonomy model provides a practical starting point: assess impact and autonomy separately, then apply the control baseline that follows from their combination.

Impact measures the severity of a reasonably foreseeable error, misuse, compromise, or outage. A limited-impact action may create a local inconvenience. A critical-impact action can affect safety, legal rights, regulated decisions, privileged cloud control, personal data, or essential operations. The correct score is the highest material dimension, not an average. A critical identity or civil-rights risk is not made moderate because the financial impact is small.

Autonomy measures what the system may initiate, choose, execute, delegate, or adapt without contemporaneous human approval. The progression from passive information handling to assistive drafting and recommendation is important, but the decisive threshold is external execution. Once an agent can change a system, select among tools or targets, invoke other agents, or vary its strategy across a workflow, its authority has changed even if its underlying model has not.

The highest capability that exists in production should govern the autonomy rating. A workflow with strong human review in most cases is still materially autonomous if it can bypass review in one meaningful path. Likewise, a critical-impact action should not receive adaptive, unconstrained execution by default. The highest impact and autonomy combination requires an exceptional case: specific executive risk acceptance, independent assurance, strict runtime enforcement, and a documented justification. In some contexts, the responsible decision is to prohibit the capability altogether.

A decision-rights map makes responsibility visible

Authority cannot remain implicit in a requirements document or distributed across a vendor contract, an engineering ticket, and an operations runbook. Each system-action pair should have a decision-rights map that names, at minimum, the following roles:

One person may hold more than one role in a small organization, but the decision rights should still be stated separately. Combining all authority in an engineering team can hide a business decision about acceptable harm. Conversely, assigning risk acceptance to an executive who cannot see the actual operational boundary creates ceremonial governance. The map should connect authority to evidence: the system charter, action inventory, test results, control verification, open limitations, audit trail, and last review date.

This structure is especially important when a provider supplies the model, a platform team runs the infrastructure, a business unit owns the outcome, and a security team manages controls. Shared operation does not create shared ambiguity. The organization using the agent remains responsible for how it authorizes the agent to act on its behalf.

The practical boundary: recommend, execute, or escalate

Not every use case needs the same operating model. The organization should choose deliberately among three patterns.

Recommendation is appropriate when context is ambiguous, evidence is incomplete, affected people may need an explanation or appeal, or the action carries legal, rights, safety, material financial, or reputational consequence. The agent can organize evidence, rank options, and produce a proposed action. A human with appropriate authority remains the decision maker.

Bounded execution is appropriate when the action is predefined, observable, reversible, and constrained by enforceable policy. Examples include provisioning a tested development environment from approved templates, reconciling low-value records under a transaction limit, or isolating a clearly compromised endpoint within an incident-response playbook. The agent should operate with least privilege, resource quotas, idempotent operations, continuous monitoring, and a tested rollback or circuit breaker.

Escalation is appropriate when the agent reaches a condition outside its authority. Common scenarios include conflicting evidence, a policy exception, an action above a dollar or privilege threshold, an unrecognized tool call, or a degraded confidence signal. Escalation is not a generic fallback. It must specify who receives the case, the evidence package they need, the deadline for response, and the safe state while a decision is pending.

The key is that an escalation path must be executable under stress. If it depends on locating an unavailable approver while the agent retains broad privileges, it is not a control. A robust design defaults to the least harmful state: do not send, do not pay, do not deploy, do not grant, or contain the action until the approval request is resolved.

Controls must enforce authority at runtime

Policy documents describe intended behavior or regulated expectations. Runtime controls determine what an agent can actually do. For agentic systems, the most consequential controls sit between reasoning and execution.

An effective architecture separates the model from the authority plane. The model may propose a tool call, but a deterministic policy gate verifies the caller identity, permitted action, target, environment, data classification, approval state, and other required evidence before the call reaches the external system. As with human users, credentials should be scoped to the smallest required resource set. Free-form tool discovery should be replaced with allowlists where possible. High-risk actions should use purpose-built workflows with just-in-time triggers.

Observability is equally important. An audit record should reconstruct not only that an action occurred, but why it was attempted, which policy authorized or blocked it, which data and system versions informed the action, who approved it, and whether rollback succeeded. Tamper-resistant logs, correlation identifiers, and versioned prompts and skills place accountability in the workflow for each prompt and output.

These controls also make it possible to reduce authority when the evidence does not support broader autonomy. The responsible response to excessive risk is often not more documentation. It is to narrow the delegation: convert autonomous execution into approval-gated execution, replace broad production access with a restricted service account, stage irreversible operations, limit per-action and per-period activity, and prohibit dynamic tool selection outside validated workflows.

Responsibility continues after deployment

An authority decision made at launch is temporary. An agent’s effective authority can increase without a formal redesign when a new tool, data source, memory store, region, user population, or vendor capability is added. A recommendation system may become an execution system when a downstream workflow starts accepting its output automatically. A low-volume internal pilot may become a high-impact public service when it is integrated into a customer channel.

For this reason, organizations should monitor authority use alongside quality and performance. Useful indicators include human overrides, rejected recommendations, privileged tool calls, policy-blocked actions, rollback frequency, changes completed without review, near misses, unsupported-output rates, and disparities in outcomes across affected groups. These are not merely operational metrics. They are evidence about whether the delegated boundary remains appropriate.

Every material change should trigger reclassification. The same is true after an incident, a near miss, a meaningful rise in transaction volume, or a regulatory or contractual change. Reclassification gives leadership a disciplined choice: proceed with controls, run a constrained pilot, seek executive review, reduce the system’s authority, or pause the use case.

The authority test

Can the agent do this? Capability is easy to confuse with permission. The more important question is: who can explain and defend this action, stop it in time, and own the remaining consequences? If the organization cannot name that person or role, identify the policy that constrained the action, and show the evidence that the control worked, then governance has failed.

Agentic systems can create real operational leverage. They can also make unexamined delegations execute faster and at greater scale. The durable response is neither to reject automation nor to treat every model output as a decision. It is to build an explicit chain of authority from organizational purpose to runtime enforcement.

The correct approach includes a zero-trust framing, a definition of actions, impact and autonomy scoring, assigned decision rights, execution constraints, and continuous testing of whether the delegation remains justified.