The Permission Problem: What Should an AI Agent Be Allowed to Do?

Capability is not permission

A modern agent may be technically able to search mail, edit documents, call APIs, run code and operate a browser. Product demonstrations often present this breadth as intelligence. Security begins with a different question: which exact action is authorized, against which resource, for which purpose and for how long?

This difference is familiar in ordinary software. A database application can contain an administrative function without granting it to every account. AI makes the separation harder because a model can interpret open-ended instructions and choose among tools. The interface may feel conversational, but the effect can be equivalent to giving a software process credentials inside the organization.

An agent needs an identity that can be verified

Accountability is weak when several agents share one service account or silently borrow a user’s full session. A distinct identity makes it possible to authenticate the agent, apply policy, attribute an action and revoke access without disabling the human operator. In 2026, both Microsoft and Google documented agent-specific identity and least-privilege controls, while NIST launched work focused on software and AI-agent identity and authorization.

Identity alone does not make an agent trustworthy. It creates the object to which controls can be attached. A useful record should identify the agent, its owner, its approved purpose, the user or service that initiated the task and the credentials used at execution. If an organization cannot answer which agent changed a record, it cannot investigate the decision reliably.

Least privilege becomes a design requirement

The principle of least privilege grants only the access needed for a defined job. For an invoice agent, that might mean reading invoices in one queue, matching approved purchase orders and creating a proposed entry. It does not automatically mean reading all corporate mail, changing supplier bank details or releasing payment.

Microsoft’s 2026 guidance frames least privilege for agents across identity, scope, tool access, auditing and revocation. Google similarly treats agents as first-class identities with scoped delegation. These controls apply established security principles to a new kind of software actor. The novelty lies in the model’s flexible decisions, not in a reason to abandon proven access control.

Read, propose, approve and execute are different powers

Permission discussions become clearer when actions are divided into levels. Reading retrieves information. Proposing creates a draft or recommended change. Approving confirms that a proposed action satisfies policy. Executing changes the external system. One agent should not automatically possess all four.

A travel agent could search schedules and draft an itinerary with low risk. Booking a non-refundable ticket creates a financial commitment and deserves a separate confirmation. A security agent may summarize alerts and propose isolation, while disabling a production account could require approval from a qualified operator. The boundary should follow consequence, not how confidently the model describes its plan.

The user’s access should not be copied without limits

Acting “on behalf of the user” sounds intuitive, but a human account may have accumulated broad permissions across years of work. Passing every one of those rights to an agent gives a mistaken or manipulated instruction a much larger blast radius. It can also hide whether the human or the system made the effective decision.

Delegation should be specific to the task and resource. The agent can receive a token that permits one operation for a limited period rather than a reusable credential for the entire account. When a tool supports user-level authorization, it should still check whether the particular action falls inside the agent’s approved scope. Human access is an upper boundary, not a default package.

Tool design is part of authorization

An agent cannot use a function that the system does not expose. Narrow tools therefore provide a stronger boundary than a prompt saying “do not make dangerous changes.” A tool called draft refund request can validate the order, limit the amount and return a proposal. A general database or shell tool may permit far more than the business task requires.

OWASP describes excessive agency as a combination of excessive functionality, excessive permissions or excessive autonomy. Reducing any one of these can limit harm. Tool inputs should be validated, outputs should be checked before execution and sensitive operations should not accept arbitrary model-generated commands. Instructions guide the model; code and policy enforce the boundary.

Prompt injection turns data into a possible instruction

An agent may read webpages, emails or documents created by an attacker. Hidden text can attempt to redirect the model, request secrets or trigger a tool. The agent does not need to “believe” the content in a human sense. It only needs to interpret untrusted data as an instruction and possess enough permission to act.

Access control limits the consequence when model-level defenses fail. A research agent with read-only web access cannot transfer money. An email assistant that can draft but not send cannot independently contact every customer. Content filtering and prompt design remain useful, but permission boundaries provide defense at the point where an intention becomes an external action.

Memory is also a permission surface

Persistent memory can help an agent retain preferences and task history. It can also preserve malicious or inaccurate information that influences future work. Permission is therefore not only about reading and writing traditional databases. It includes who can add, modify, retrieve or delete agent memory and whether one user’s information can affect another user’s session.

Memory writes should have provenance, scope and an expiry policy. High-impact facts may require confirmation before they become durable. A model-generated inference such as “this supplier is risky” should not silently become an authoritative profile. OWASP’s agent security guidance identifies memory poisoning as a distinct attack surface because persistence can carry one compromised interaction into later decisions.

High-impact actions need independent validation

Financial transfers, publication, account administration, data deletion and safety-relevant control have effects that may be difficult to reverse. For these actions, approval should come from a person or a separate deterministic policy layer with access to the relevant evidence. Asking the same model to critique its own proposed action is not independent authorization.

The approval interface should show the target, scope, evidence, uncertainty and expected consequence. “Allow?” is inadequate when the reviewer cannot see what will happen. Approval also should be narrow: confirming one payment must not authorize future payments to the same destination unless policy explicitly permits that delegation.

Reversibility can define how much autonomy is reasonable

Not all mistakes have equal cost. Reordering a private task list is easy to correct. Publishing a legal statement or deleting production data may not be. Systems can grant broader autonomy to actions that are low-impact, observable and reversible, while placing stricter gates around irreversible operations.

Reversibility must be real. A software “undo” does not recover confidential information already sent outside the organization. A deleted object may be restored, but the downstream service that consumed it may not forget it. Designers should examine the complete consequence chain rather than the first API response.

Agents must not grant themselves more authority

An agent may discover that it lacks access required to finish a task. The safe response is to request a specific permission through an independent process. Allowing it to alter its own role, create credentials or add tools collapses the separation between requesting authority and granting it.

The same applies to agent-to-agent systems. A coordinating agent should not transfer privileges to a specialist merely because the specialist claims they are needed. Every delegation should remain within the original mandate, and the receiving identity should be authenticated. Otherwise an ecosystem of agents can create permission paths that no owner intended.

Auditability is necessary but does not prevent harm

Logs should record the initiating identity, model and system versions, retrieved evidence, tool request, policy decision, approval and result. This provides the chain needed to diagnose incidents and determine accountability. It also supports evaluation: teams can identify which permission was unnecessary or which approval failed to reveal the risk.

Logging is not a substitute for prevention. A perfect record of an unauthorized transfer does not undo it. Sensitive logs can themselves expose private data and therefore need access controls and retention limits. The objective is a combination of enforceable boundaries before action and useful evidence afterward.

Permissions need a lifecycle

Agents change as prompts, models, tools and organizational processes evolve. An approval granted to version one may be inappropriate after a new tool is added. Microsoft’s risk guidance calls for registration, ownership, approval, expiration and decommissioning. This treats an agent as a managed identity throughout its life rather than a script that remains trusted indefinitely.

Organizations should maintain an inventory of active agents, owners, connected data, tools and granted roles. Dormant credentials should expire. Material changes should trigger review and evaluation. When an employee leaves or a project ends, associated delegation should be revoked without relying on someone to remember every connection.

A practical permission ladder

Teams can begin with observation: the agent reads approved data and produces no external change. The next level is recommendation, where it prepares a structured proposal. Then comes reversible execution within narrow thresholds, followed by higher-impact action behind explicit approval. Only well-evaluated, bounded processes should approach unattended execution.

Progression should depend on measured outcomes, not time in service. Error rates, exception handling, attempted policy violations and rollback success can inform expansion. If the task or environment changes, authority can move down the ladder. Permission is a continuously evaluated operating decision, not a permanent reward for a successful pilot.

The NTS View

The permission problem cannot be solved by deciding whether AI agents are generally trustworthy. Trust is too broad and changes with the task. A system should instead enforce which identity may perform which action, on which resource, under whose delegation and with what evidence.

The safest useful agent is not necessarily the least capable. It is the one whose capability is contained by precise tools, scoped credentials, meaningful approvals and an accountable owner. Read, propose and execute should remain separate until evidence justifies combining them. High-impact autonomy should be earned through evaluation and remain revocable.

AI agents will become more valuable as they connect to real systems. That connection makes authorization the architecture, not an administrative detail. The decisive product question is no longer only “can the agent complete the task?” It is “can the organization prove that every consequential action was allowed?”