An agent should not inherit every permission its operator has

Access decisions shape the consequences of a mistake

A developer connects an agent to a business application using an administrator account because that makes the prototype easier to build. The workflow only needs to look up orders and draft replies, but the credential can also export customers, change account settings, and delete records. Nothing has gone wrong yet. The problem is that an ordinary reasoning error now has several unnecessary ways to become a serious incident.

Permissions should follow the job being delegated. If the agent is preparing a reply, it does not automatically need authority to send it. If it is checking an order, it does not automatically need access to every customer. These decisions belong in the integration design before the agent is asked to exercise judgment.

Microsoft’s May 2026 research into Semantic Kernel described vulnerabilities where agent-controlled tool parameters could reach dangerous execution paths. The disclosed flaws had been fixed. The broader engineering lesson is that a valid-looking tool invocation still needs validation at the point where it affects a system. [1]

For a client buying an agent, the access discussion should be concrete: what can this system read, what can it change, and what limits apply to each action? A general assurance that the model has been instructed to behave safely does not answer those questions.

Documents and tool results can contain instructions

An operational agent may read email, support tickets, websites, or uploaded documents as part of an authorized task. Those materials can contain text that tries to redirect its behaviour. The agent needs the information in the document, but the document should not gain the authority of the user.

Google’s April 2026 investigation examined indirect prompt-injection patterns on the public web. It also described the difficulty of distinguishing malicious content from educational material that discusses the same techniques. Its scan was limited by the sources and detection methods used, so it should not be read as a complete measure of attack prevalence. [2]

That makes trust boundaries part of the application design. A customer’s email can provide a delivery address, but it cannot authorize exporting unrelated customer records. A retrieved document can describe a procedure, but it cannot silently expand the agent’s permissions.

The application should enforce these boundaries independently of the model. Tools can restrict which resources are accessible, validate parameters, and refuse operations outside the current user’s authority. Sensitive credentials should remain outside content that the model can reproduce.

This applies to accidental instructions as well as malicious ones. An old internal document may tell staff to use a retired process. A forwarded message may contain someone else’s request. Treating every imperative sentence as an active instruction creates confusion even when nobody is attacking the system.

Approval prompts work only when people can judge them

Asking for approval before every action can look like a strong safeguard. In practice, the quality of the decision depends on what the person sees and whether the request deserves their attention.

Anthropic’s May 2026 account of containment across its products reports that users approved roughly 93% of permission prompts in its telemetry. The company discusses approval fatigue alongside technical boundaries such as sandboxes and network controls. That percentage comes from Anthropic’s product context, and it illustrates why the presence of an approval button is not evidence of careful review. [3]

An approval request should describe the proposed effect. “Allow tool call” is difficult for a business user to assess. “Send this message to these three customers” gives them something they can verify. For important changes, show the target, the relevant values, and any consequence that cannot be easily reversed.

Approval should also be tied to the operation that actually runs. If the recipient or amount changes after approval, the original approval may no longer apply. The execution layer needs to enforce that relationship rather than relying on the conversation to remember it.

Routine, low-impact operations can often be authorized within clear limits. Higher-impact operations may require a specific review. The purpose is to reserve attention for decisions where it adds value, while using technical controls for boundaries that should never depend on a person noticing a suspicious sentence.

Give each workflow an authority model

For a refund agent, define which orders it can inspect, the circumstances in which it can prepare a refund, and the evidence required before submission. The business may choose limits based on amount, customer status, or exception type. Those choices should be explicit and enforced where the action happens.

For an internal data agent, check permissions during retrieval as well as display. Hiding a confidential field in the final response does not solve the problem if the model already used it to generate a recommendation. The data available to the agent should match the authorized task.

Shared systems need tenant boundaries that do not depend on model-generated filters alone. If an agent can change an account identifier in a tool request, the backend must still verify that the current principal can access the requested record.

Testing should include legitimate work that remains possible after restrictions are applied. A secure configuration that blocks every useful action will encourage people to bypass it. Measure successful authorized tasks alongside attempted unauthorized actions.

Clients should assign ownership for access changes. When a staff member leaves, a contract ends, or a workflow expands, someone needs to review the agent’s credentials and scope. An integration created during a pilot can otherwise retain privileges long after its original purpose changes.

The result should be understandable to an operator: this agent can perform these tasks within these limits, and anything outside them follows a defined path. That makes autonomy easier to manage because its consequences are bounded.

Test permissions in the same environment as the workflow

There is room for tools that combine business simulation with permission testing. A realistic scenario could contain a malicious instruction inside an otherwise useful document, while the test checks whether legitimate work continues and protected resources remain inaccessible.

Human engineers and coding agents would benefit from a clear report of the attempted action, the policy decision, and the actual effect. A future permission-preview tool could show what a proposed integration change would make reachable before it is deployed.

Another product could test approval interfaces themselves: whether the displayed request matches the executed operation and whether changes invalidate old approval. These tools would turn vague assurances about agent safety into observable properties of a specific workflow. The aim is to let agents do useful work with the smallest set of powers that makes that work possible.