A finance director asks an AI agent to reconcile supplier records and prepare a payment run.

To do the work, the agent needs to read invoices, compare bank details, inspect purchase orders, flag mismatches, and create draft payments. It does not need to release those payments. It does not need access to payroll. It does not need the director’s ability to change a supplier account after a phone call.

Yet many companies will give the agent a version of the director’s existing access because that is the fastest way to make the workflow function. The agent inherits permissions accumulated across years of responsibilities, exceptions, temporary projects, and organizational history.

That is a convenient technical decision and a poor authority model.

An assistant produces an answer for a person to consider. An agent can take a sequence of actions across systems. Once software can change records, contact customers, move money, approve a condition, or trigger another system, the design problem is no longer limited to intelligence. The company has to decide what the agent is allowed to do, under which conditions, and on whose behalf.

The safest answer is not to make every agent powerless. It is to stop treating human access as the natural template for machine authority.

A human account contains the history of a job

Employee permissions rarely describe one clean business purpose. They describe a career inside the company.

A commercial leader may have access to old territories, current forecasts, discount tools, customer records, contract folders, and a billing view added during a previous restructuring. An operations manager may retain rights granted for a temporary migration. A founder may have administrator access to almost everything because the systems were installed when the company was small.

People make this untidy model survivable through context. They know that access does not always imply permission. They recognize a strange request, remember an informal boundary, or ask a colleague before taking an unusual action. These controls are inconsistent, but they exist in human judgment and social behavior.

An agent does not inherit that context when it inherits the account.

This is why the conventional security principle of least privilege becomes more demanding in agentic systems. An agent’s task may span several applications and change as it works through a plan. The relevant question is not simply which database it can enter. It is which actions it can perform, on which objects, for how long, within what limits, and with what route back to a person.

Authority should follow the action

A useful authority model begins with the consequence of an action rather than the seniority of the human who requested it.

Consider a customer-service agent. Reading an order status is low consequence. Updating a delivery address is more sensitive. Issuing a small refund has a financial effect. Closing an account may be difficult to reverse and could create legal or retention consequences. These actions belong in different authority bands even if one employee currently performs all of them through the same interface.

The same distinction applies elsewhere. A recruitment agent can schedule an interview without rejecting a candidate. A sales agent can draft a proposal without changing a price. A finance agent can identify a duplicate invoice without releasing a payment. A marketing agent can prepare a campaign without publishing it to the full customer list.

This is more precise than dividing work into “autonomous” and “human controlled.” Autonomy is not a property of the whole agent. It is a set of permissions attached to particular actions.

NIST’s 2026 concept paper on software-agent identity and authorization frames the issue around identifying agents, distinguishing them from the people and organizations they represent, and authorizing their actions. That distinction matters operationally. If an agent acts through a shared human identity, the business may know which account changed a record without knowing whether the employee, the agent, or another automated process made the decision.

Human approval can create the appearance of control

Adding an approval step to every consequential action sounds safe. Sometimes it is. Sometimes it moves the risk into a busy person’s inbox.

An approval is meaningful when the reviewer can understand the proposed action, inspect the relevant evidence, see what rule or reasoning produced it, and reject it without disrupting the entire workflow. Approval is weak when the reviewer receives hundreds of routine requests, sees only a summarized recommendation, or knows that questioning one item will require reconstructing the agent’s work from several systems.

In that setting, the person becomes a confirmation mechanism rather than a control.

The alternative is not to remove review. It is to design review around uncertainty and consequence. A refund within a defined limit for a verified duplicate charge may proceed automatically and remain visible in an audit sample. A larger refund, an unusual account pattern, or a conflict between records can require a person. The boundary should tighten when the action is hard to reverse, the evidence is ambiguous, or the potential harm crosses a threshold the business has explicitly chosen.

This also changes what the interface must show. A reviewer needs more than “approve” and “reject.” They need the agent’s identity, the requested action, the source records, the authority being used, the reason for escalation, and the expected consequence.

Autonomy is a portfolio, not a switch

Organizations often discuss an agent as if it should either run freely or remain a supervised tool. Real work is less tidy.

One agent may be allowed to read broadly, write narrowly, and execute only within transaction limits. It may operate independently during normal conditions but lose authority when a customer is vulnerable, a policy exception appears, or the volume of similar actions rises unexpectedly. Its permissions may expire at the end of a project or shrink after a failed control.

The World Economic Forum’s 2026 playbook for trusted agent adoption treats authorization and scaling as connected problems. That is the useful connection. A pilot can appear safe because its volume is low and the people around it are attentive. At scale, the same authority produces more actions, more edge cases, and more opportunities for a weak boundary to matter.

Security guidance is also moving beyond prompt risks. The OWASP Top 10 for Agentic Applications addresses identity and privilege abuse, tool misuse, and human-agent trust exploitation, while warning against unnecessary autonomy. These problems arise from the operating system built around the model.

Give the agent an identity the business can inspect

Every production agent should have its own identity, separate from the employee who requested the work and the team that owns the process.

That identity should carry a legible authority profile. The business should be able to see which systems the agent can enter, which actions it can take, which limits apply, when approval is required, how long the access lasts, and who is responsible for reviewing its performance. Logs should show the agent’s actions as agent actions, not hide them inside a human account.

This may feel bureaucratic when the first workflow is small. It becomes valuable when something unexpected happens. Without a distinct identity, the investigation begins by asking whether the action was human or automated. Without explicit authority, the company has to infer whether it was permitted from scattered access settings and informal process documents.

An identity does not solve every control problem. A precisely identified agent can still make a poor decision. But it gives the organization something concrete to limit, observe, suspend, test, and improve.

Map authority before scaling agents

The practical work begins with an action map.

For each workflow, list what the agent needs to read, recommend, create, change, approve, communicate, and execute. Then examine the consequence of each action. Is it reversible? Does it affect money, rights, safety, privacy, contractual commitments, or a customer’s ability to recover? What amount or condition changes the risk? Which evidence would make a reviewer capable of intervening rather than merely clicking?

The answers should shape permissions, transaction limits, escalation rules, audit sampling, and expiry. They should also expose a less technical problem: many organizations have never stated their human authority model clearly. The agent does not create that ambiguity. It makes the ambiguity executable.

There is a cost to narrow permissions. An agent that must stop at every boundary may save little time. The response is not to grant the broadest access and rely on monitoring later. It is to widen authority deliberately as the organization learns which actions are predictable, which controls work, and which exceptions still require judgment.

The goal is useful agency with inspectable limits.

An employee’s account is a poor job description and a worse constitution for software. If an agent is going to act for the business, its authority should describe the work it is trusted to do, not the accumulated power of the person who happened to deploy it.