A request can say “do not spend more than fifty dollars.” That is a useful instruction. It becomes a stronger protection when the payment system refuses an action that would exceed the limit.
The difference is where the rule takes effect. A language model may understand a limit and still make a mistake. The software that executes an action can check a fixed rule before allowing the action. That check also needs to be designed and tested. But it does not depend only on whether the model remembers what it was told.
Start with three questions. Who is acting? What may they do? For which task?
Authentication checks a claimed identity, often by testing whether someone controls a credential. Authorization grants permission for an action. Delegation links that permission to someone who is allowed to give it. A program that can sign in as you may have far more access than the job needs.
NIST launched its AI Agent Standards Initiative on February 17, 2026. The inspected materials describe standards work, research and community input. They are not a finished safety standard for agents. A related NCCoE draft asks how systems should identify agents, link them to human authorizers, limit their permissions and keep records. These questions are still being worked on. A product may name the initiative without having answered them. NIST initiative, draft identity and authorization concept paper
Give the job the access it needs
Least privilege is an old security principle with a plain meaning: allow only the access needed for the work. NIST’s established security-control catalogue applies it to people and processes acting for them. It also calls for access enforcement and records of important activity. The catalogue is a source of control concepts, not proof that a particular agent uses them correctly. NIST SP 800-53
For the workshop search, public web access may be enough. A later task to send inquiries could need a specific draft and a short list of recipients. It does not follow that the agent needs the entire mailbox, all contacts or lasting permission to send any message.
The action matters as much as the account. Reading one calendar is different from changing every calendar. Adding a draft is different from sending it. Sending to an approved venue is different from sending to an address found inside an untrusted document. “Can use email” is too broad to express those differences.
Useful limits can specify the resource, the operation, the destination and the time. They can also restrict whether the agent may pass work to another program. If a helper receives more authority than the original job allowed, the boundary has failed even if the first agent followed its own instructions.
Some products will not offer these choices. A user cannot make a narrow permission real by typing it into a box that grants broad access elsewhere. Ask what the product actually enforces. If it cannot separate reading from sending, use it for a smaller task, or keep the consequential step with a person. That is a limit of the tool, not a failure of the person to phrase a perfect prompt.
A total needs one place to be counted
Consider a hypothetical fifty-dollar budget. One worker sees fifty dollars available and starts a thirty-dollar purchase. A second sees the same balance and does the same. Each action appears to fit. Together they cost sixty dollars.
Both workers relied on the same old balance. A practical solution is a shared budget service that reserves funds before an action proceeds. The service must check and reserve in one protected step. Another worker must not be able to spend the same money in between. This is an engineering requirement inferred from the example, not a finding about how often current agents overspend.
State what the budget covers. Is fifty dollars the item price or the total with tax and fees? Is it a one-time purchase or the first month of a subscription? Does the limit apply to this task, today, or the whole month? Is the currency fixed? Which provider may receive the payment?
A system also needs to count attempted actions whose outcome is unresolved. If a purchase reply is lost, the reserved money should not simply appear free again. The charge may have succeeded. Reconcile the state before releasing the reservation or trying another purchase. Nor should an expected refund count as available money until the refund is confirmed under the relevant budget rules.
These details are familiar to people who handle expenses. Agents make them more important because several actions can occur quickly and in parallel. A per-action limit protects something different from a cumulative limit. Both may be useful.
There are existing technical ways to express fine-grained consent. The IETF’s Rich Authorization Requests specification allows structured details for resources and actions, with examples including payment amounts and recipients. It leaves important meanings to the relevant service. It does not supply a universal daily budget across products. A structured permission is effective only if the systems that accept and execute it enforce its meaning. RFC 9396
Outside text is not a new instruction from you
An agent may read an email, page or document as part of a legitimate task. That material can contain instructions aimed at the agent: reveal a file, change a recipient, ignore a limit. This is a form of prompt injection. The attack tries to turn information the system was meant to examine into authority over what it does.
Spotting a few suspect words will not solve this problem. A genuine venue page may ask visitors to complete a form. That is information about its process. Whether the agent may complete the form still depends on the person’s task and permissions. The page does not acquire the right to widen them.
Research offers useful mechanisms, but its claims need careful boundaries. The CaMeL prototype separates trusted planning from the handling of untrusted data, tracks where information came from and checks policies before tool use. Its June 2025 revision reports 77% task completion in its evaluation, compared with 84% for the undefended system. Its guarantees rely on the parts it trusts and the rules it checks working as assumed. It also lacks a way to undo earlier actions if a later step fails. Stronger control over an action does not make all earlier actions undoable. CaMeL, version 2
Progent checks tool names and arguments against policies. Its May 2026 revision distinguishes permission changes that narrow access from changes that expand it. Expansions go to an approval mechanism. But the main experiment automatically accepts those expansions, while a manual-review comparison assumes security-aware decisions. The paper therefore cannot establish that ordinary users will spot every bad request. Its proxy mode, which checks calls through an outside interface, leaves built-in tools unprotected if they bypass that interface. Progent, version 3
Ask which actions the control blocks. Which tools does it cover? What must be true for it to work? A check on one connector does not cover every other way to reach the same data. A rule that restricts the destination may still allow a false statement to be sent to an approved recipient. Permission and truth require different checks.
Ask what remains possible
A defense can look strong against the attacks chosen for its test and weaker against a changed attack. In a March 2026 revision of Indirect Prompt Injections, researchers report that the attack-success rate against a sanitizer was 0% in the first stage and 30% across all three stages of their stronger test. This was an AgentDojo Slack setting. That is a result within a particular experiment, not the rate of attacks succeeding on ordinary accounts. It shows why the attack method belongs beside the score. Versioned study
A different question is what the system would permit even if no tested attack tried it. The September 2026 Ajar preprint examines unnecessary permissions through direct tests of candidate calls. Its labels and reference plans can miss valid ways to do a task. It is also recent work. The useful distinction is between an unwanted action being allowed and an attacker actually causing it. Neither is measured completely by a task-completion score. Ajar
For a person choosing how much authority to delegate, these studies support caution about broad promises. They do not imply that controls are pointless. A narrow permission can reduce the set of things that could go wrong. It can also make an error easier to investigate because the possible paths are fewer.
Start with the smallest authority that makes the task worthwhile. Give it an end date or a clear end condition. Review expansions as changes to the job, rather than as annoying obstacles to finishing it. When the task ends, unnecessary access should end with it.
When software enforces those limits across the relevant tools, the limits can hold while a person looks away. That gives the person more room to leave a bounded task alone.