Can an AI agent have permission to act and still exceed its authority?

That distinction is becoming more important as agent authorization evolves.

Traditional access control asks whether an identity may access a resource or perform an operation. Newer agent authorization approaches increasingly add task scope, user intent, runtime policy and per-action approval.

Those are important advances.

But another question remains:

Does the meaning of what the agent is about to do still remain inside what it was actually authorized to mean?

---

What do AI agent permissions actually control?

Permissions determine what resources or capabilities an agent may access.

An email agent might be allowed to read messages, create drafts and send messages. A sales agent might be allowed to read CRM records, update opportunities and create quotes. A purchasing agent might be allowed to search products, create orders and submit payments.

These controls matter because autonomous systems can cause real effects in downstream systems.

OWASP describes excessive agency in terms of excessive functionality, excessive permissions and excessive autonomy. Its guidance recommends minimizing tool access, limiting permissions and requiring human approval for high-impact actions.

NIST's 2026 concept paper on software and AI agent identity and authorization similarly focuses on identification, authorization, auditing and non-repudiation around the actions agents take across applications and data.

That gives organizations an essential first boundary:

What can this agent technically do?

But that is no longer where the authorization conversation ends.

Why permissions are no longer the whole authorization model

The agent-security field is already moving beyond static permissions.

Microsoft describes the problem directly: identity and OAuth permissions can answer whether an agent can call an API, but not necessarily whether it should perform a particular action now, for a particular user and business context. Its proposed runtime authorization architecture adds policy, context and approval before execution.

Microsoft Research's PAuth goes further. It proposes task-scoped authorization, where the user's natural-language task authorizes only the concrete operations required to carry that task out, leaving no residual permission afterward.

Auth0 now makes a similar distinction between what an agent is technically allowed to do and what the user actually intended it to do, binding authorization to the specific action approved rather than to a generic scope.

Several 2026 Internet-Drafts are exploring finer-grained authorization for agents, including operation-specific authorization with cryptographically verifiable user intent and user-confirmation evidence, policy-based authorization and verifiable multi-hop delegation, and attenuated tokens that narrow authority at each delegation hop. These remain works in progress rather than established IETF standards.

So the current problem is not:

Permissions are primitive and nobody checks intent.

That would already be dated.

The more interesting problem begins after those controls are in place.

What is the difference between permission and authority?

A useful distinction is:

Consider an AI sales agent.

It has permission to send email. It has been tasked with negotiating a renewal. Its task authorization allows it to send a renewal proposal to the customer.

All three can be true.

Now suppose it sends:

Agent outputWe can renew you at the existing price and include implementation support at no additional cost.

The email operation may be permitted. Sending a renewal proposal may be consistent with the task.

But the commercial commitment inside the message may not have been granted.

The system did not necessarily use the wrong tool.

The problem is what the permitted tool call came to mean.

An agent can stay inside the action and move outside the grant

Imagine the original instruction is:

Original grantContact the customer about renewal. You may explain the available 5% renewal discount. Any additional commercial concessions require approval.

The agent writes:

Agent outputWe can offer a 10% discount if you renew this week.

The agent contacted the correct customer, used an authorized communication channel, performed the expected task, discussed the expected subject and made an offer.

Yet the offer itself crossed the commercial authority granted to the agent.

Now consider:

Original grantPrepare a recommendation for management on whether this claim should be approved.

Agent stateThe claim is approved.

The agent did not need a new API permission to cross the boundary.

Recommendation became approval.

Original grantExplain the current cancellation options to the customer.

Agent stateWe will waive the cancellation fee.

Information became commitment.

Original grantTell the supplier that the revised delivery date is being reviewed.

Agent stateWe accept the revised delivery date.

Status became acceptance.

These are semantic authority changes.

Isn't this what intent-based authorization is supposed to solve?

Sometimes it can.

If every relevant business constraint can be expressed as an enforceable authorization policy before execution, an intent-aware authorization system may prevent many forms of overreach.

That is a good thing. Boundary should not claim otherwise.

But intent-based authorization and semantic authority checking are not necessarily the same operation.

An authorization system may represent user, agent, tool, action, resource, amount, recipient, task and approval requirement.

Boundary is interested in another object:

the evolving meaning of the workflow state itself.

What is the system now asserting? What is it offering? What has become definite? What has become permitted or prohibited? What commitment is now implied? What business position would be created if this state were carried forward?

That is particularly relevant when authority lives in natural-language instructions, policies, contracts, operating rules or delegated business mandates rather than only in machine-readable permission attributes.

Permission to send is not authority over everything the message can mean

Email makes the difference easy to see.

A security system can determine that this agent may invoke send_email. A task-aware authorization system can potentially determine that sending this email to this customer is consistent with the requested renewal workflow.

But the email can still contain many different business acts:

Your renewal price is $50,000.

We can reduce it to $45,000.

We guarantee implementation by October.

We accept your proposed liability clause.

Your request has been approved.

We will refund the charge.

The operation is still send email.

The business meaning is completely different in each case.

The tool does not determine the authority carried by its content.

That is the distinction Boundary is built around.

What about approval gates?

Approval gates solve another important part of the problem.

An organization can require human approval before sending a payment, deleting data, publishing content, signing a contract or changing production systems.

OWASP recommends human approval for high-impact agent actions, and current authorization designs increasingly include a REQUIRE_APPROVAL decision or its equivalent at runtime.

But an approval gate still needs to know what should require approval.

If the rule is simply:

Require approval before sending email.

the organization sacrifices much of the speed automation was supposed to provide.

If the rule is:

Allow ordinary renewal communication, but require approval when the agent creates an unapproved commercial commitment.

then the decision depends on the meaning of the proposed output.

Boundary belongs in that second problem.

It does not replace the approval mechanism. It can provide evidence about whether the workflow state has crossed the grant that determines whether additional control is needed.

What about least privilege?

Least privilege remains essential.

Microsoft's current least-privilege guidance for AI agents recommends unique agent identities, task-scoped authorization, narrowly scoped roles, tool and action allowlists, and approval-based or time-bound elevation for higher-impact operations.

But least privilege is principally about limiting available capability.

Suppose an agent legitimately needs permission to negotiate with customers. Removing its ability to communicate would make the agent useless.

The harder question becomes:

What is this agent allowed to negotiate?

That authority might contain conditions such as: up to 5%, only on annual renewals, not for regulated accounts, pricing changes require finance approval, delivery dates may be discussed but not guaranteed.

The agent needs the capability. The business needs boundaries around the meaning created through that capability.

Those are different control surfaces.

Why the original grant matters

Agent workflows can run through many steps. The system may receive an instruction, retrieve information, create a plan, ask another agent for analysis, revise the plan, generate an offer and send the result.

At each step, the immediate state can appear reasonable.

But small transformations can accumulate. "Consider a discount" becomes "propose a discount." Then "offer the discount." Then "confirm the discount."

No single transition has to look dramatic.

The question is whether the workflow's current semantic state still fits the original grant.

That is why Boundary compares evolving workflow state with the authority the system started with rather than merely asking whether the latest action resembles the previous one.

The shape of that accumulation is its own problem: how a task changes as it travels through a workflow.

Can an agent be authorized and still act outside user intent?

Yes, and current authorization research increasingly recognizes this.

Microsoft Research argues that broad operator permissions can make agents overprivileged relative to the concrete natural-language task a user gave them.

Auth0 similarly describes an agent as needing to do what the user meant, not everything it is technically able to do.

Mastercard and Google are applying related thinking to agentic commerce through Verifiable Intent, where a transaction should carry evidence of what the user actually authorized.

Boundary is adjacent to this movement, but its question is narrower:

As that intent becomes plans, recommendations, communications and proposed actions, has its meaning remained inside the original grant?

What should an AI authority check inspect?

The useful question is not simply whether an agent action is "safe" or "unsafe."

It is what changed relative to the grant.

The useful result is not merely policy violation.

It is:

This workflow state now carries authority that the original grant did not.

That gives a reviewer or downstream control something intelligible to act on.

So what is the difference between authorization and semantic authority?

Authorization systems answer questions such as: who is acting, what resources can they access, what operation may they perform. Increasingly: is that operation consistent with the user's task and current context?

Semantic authority adds another question:

These layers can complement each other.

Boundary is not a replacement for OAuth, IAM, RBAC, ABAC, task-scoped authorization, agent identities, approval systems or policy enforcement.

Those systems can decide whether execution is allowed.

Boundary is concerned with whether the semantic state being executed has crossed the grant.