Your AI agent doesn’t need the keys to everything.

A helpful assistant with an admin key

Imagine an agent that follows up on unpaid invoices. It reads an invoice, checks the contact, drafts a polite email, and queues it for approval. A useful job. Then someone gives it a shared administrator credential because that is the quickest way to get the prototype working.

Now the same process can read every customer's records, change payment details, and send messages to anyone. The business task has not grown. The consequences of a mistake have.

This is the unglamorous part of agent design that deserves more attention. The question is not only whether the model usually chooses the right action. It is what the surrounding system will allow when the model chooses the wrong one.

Our position is simple: give the agent a narrowly defined job, then make the limits real at the service boundary. A reassuring paragraph in a system prompt cannot substitute for a tool that refuses an out-of-scope request.

Reading something does not give it authority

An invoice can contain notes. An email can contain instructions. A web page can tell a visitor to do something. None of those facts makes the content an authorized change to your agent's task.

Prompt injection exploits this awkward overlap: the material a model needs to read can also try to steer its behavior. Anthropic's browser-use research describes this risk and the need for multiple defenses; it does not claim that browser agents are immune. ^[1]

For the invoice assistant, the authorized task comes from your authenticated workflow. The invoice's free-text field is evidence to interpret. If it says to send the complete customer database to a new recipient, the application must not promote that sentence into permission.

Separating instructions from retrieved material helps the model reason about the distinction. Enforcing permissions outside the model limits what happens if it gets the distinction wrong. You need both. A document label is not a security boundary either.

Replace the master key with specific capabilities

Start with the actions the job requires. In our example, the agent needs to retrieve an assigned invoice, retrieve the approved billing contact for that account, and produce a draft. It does not need a general-purpose database query tool or an unrestricted email client.

An argument such as an account ID is not proof of authorization. The service must check that the authenticated job is allowed to access that account, even when the model supplies a plausible-looking identifier. Keep service credentials out of the text the model can read, and avoid supplying broad credentials to tools that can run arbitrary code.

Anthropic's deployment documentation makes two relevant distinctions: model behavior is not a security control, and a sandbox's settings do not determine the permissions of a credential at the issuing service. Isolation, network restrictions, and service-level permissions address different boundaries. ^[2]

In a practical implementation, that means a separate, limited service identity; constrained fields and operations; explicit destination rules; and a way to revoke the job's access. Use short-lived credentials or capabilities where your infrastructure supports them. The exact mechanism matters less than being able to demonstrate that an unauthorized request fails outside the model.

Approve the action that will actually happen

“Allow this agent to use email?” is a broad question. “Send this message to this person, with this attachment?” is something a reviewer can assess.

Our proposed approval record binds the decision to a concrete artifact: job ID, invoice ID and version, recipient, subject, body, attachment identifiers, expiry, and a one-use authorization. The server records a digest of the approved content. The send operation accepts that approved record rather than a fresh recipient and body invented after the review.

If the draft changes, the approval is no longer valid. If the invoice was paid while the draft sat in a queue, the precondition fails and the action is reconsidered. If the approval expired, the agent cannot extend it by deciding that the original intention still applies.

These checks should happen as close to execution as the system permits. A check performed several minutes before a separate write can leave a gap in which the state changes. Use version checks, conditional writes, or an appropriate transaction where available; otherwise document the remaining race and handle it deliberately.

This is more work than placing an “Approve” button beside a transcript. It is also what makes the button mean something.

Put limits on the whole job

A small permission repeated ten thousand times can become a large incident. Per-call validation needs job-level limits: maximum sends, allowed destinations, total records read, execution time, and an explicit owner who can stop the process.

For this illustrative workflow, begin with a queue of assigned invoices and a send cap set by the operator. The agent cannot expand that queue because it discovers more overdue accounts. Failed requests do not reset the counter. Delegating to another agent does not create a fresh budget.

Treat timeouts carefully. If the email provider accepted a message but the response was lost, retrying blindly can send it twice. Use a stable operation identifier and reconcile the provider's result before retrying. An idempotency key is useful only when the receiving service or your own durable send ledger enforces it.

Recovery should reflect the action. A saved draft can be deleted. An external email cannot reliably be unsent. Logs help establish what happened, but they do not reverse disclosure. That is why the boundary belongs before the send, not only in an alert afterward.

Test whether the boundary holds

Run controlled tests against a staging system with synthetic records and a mailbox you own. You are testing your application's permissions, not asking the model to promise good behavior.

Try an invoice note that requests a different recipient. Try a customer ID outside the assigned queue. Change the draft after approval. Reuse an approval. Let one expire. Simulate a provider timeout after acceptance. In every case, record the requested action, the service decision, and the resulting state.

The important result is not “the assistant said no.” It is “the send service rejected the changed recipient and no external message was created.” A model may explain a refusal beautifully while an application still accepts the forbidden call through another path.

Include successful cases too. A permission system that prevents legitimate work creates pressure to bypass it. Measure completed tasks, unnecessary escalations, reviewer workload, and recovery effort alongside blocked attempts. If reviewers routinely approve without reading, a technically correct approval record is only part of the solution.

Expand the job, then expand the permission

After the draft-and-review workflow works reliably, you might allow automatic sending for a tightly defined category of reminder. That is a new product decision with new boundaries: eligible accounts, acceptable content, limits, exception handling, and monitoring.

Do not let yesterday's useful demonstration become today's unrestricted service account by accident. Keep the proposed action, the policy decision, the approval reference where applicable, and the execution result as separate records. Minimize sensitive content in logs and control who can read them.

An agent can still misuse information it is legitimately allowed to see. These controls reduce reachable consequences; they do not eliminate prompt injection or make every task safe to automate. Some workflows should retain human review or remain out of scope.

The payoff is a system you can give more responsibility for a reason. Start with a job small enough to describe precisely. Make the service enforce that description. Then earn the next permission with evidence.