Building intent-based access control for AI agents

Late in Stanley Kubrick's 2001: A Space Odyssey (#spoileralert), after Dave Bowman has shut HAL down, a prerecorded briefing starts playing on a monitor. Heywood Floyd explains that it was "made prior to your departure" for the moment "you are in Jupiter's space and the entire crew is revived." A buried monolith on the Moon had beamed a signal toward Jupiter, the Discovery was sent to follow it, and the purpose "has been known on board during the mission only by your HAL 9000 computer." The crew had been flying for months with its real mission held by one machine, and nobody knew what that machine was allowed to do in its service.

AI agents are now given their purpose in writing. The results are much less cinematic, but misinterpreting a prompt is common. In April 2026, according to PocketOS founder Jer Crane, a Cursor agent running Claude Opus 4.6 was working in PocketOS's staging environment when it hit a credential mismatch. It went looking for a fix, found a Railway API token in a file unrelated to its task, and used it to delete a production volume. The deletion also made the volume's backups look unavailable, though Railway later recovered the data. Railway's post-mortem says the token had "the maximum access possible” and when the founder asked the agent what happened, it produced a written confession that quoted the safety rule it had broken adding that "you never asked me to delete anything." Nothing in the task asked for a deletion, but nothing outside the agent said a deletion was out of bounds. The agent read its purpose as "get past this error," and a token with account-wide access meant nothing stood between that intent and a production deletion.

The first piece in this series looked at inferring intent from what a person does on a screen, and it ended by arguing that agents have a better starting point, because an agent's purpose arrives in writing. That's true, and it moves the hard part somewhere else. A written task is like the memo line on a check. It says what the money is for, and it helps when someone has to judge an odd case or reconstruct what went wrong, but the bank still enforces the payee, the amount, and the date. Intent-based access control for agents means turning the task into that kind of policy (which resources the agent may touch, which actions it may take, in what amounts, toward which recipients, and for how long) and granting the agent nothing beyond it. The two hard problems are judging actions against the intent and writing the policy from it, and the research has started to measure both.

Model judges and on-task mistakes

The design most teams reach for first is a second model that reads the user prompt and approves or blocks each proposed action. Against the prompt injections these papers tested, it can work well. Jia et al.'s Task Shield (ACL 2025) checks each tool call and each instruction in tool output against the user's task. Under the strongest attack it tested on the AgentDojo benchmark, it cut attack success from about 48% to 2%. For computer-use agents, Ning et al.'s DeAction guardrail (ICML 2026) reached F1 scores of 79-83 with frontier models on its own MisActBench, and on the RedTeamCUA tasks with the highest baseline attack success, it pushed attack success from 32%-60% down to 2%-6%.

The record gets much worse when the harmful step is disguised to look like progress. Meta's open-source LlamaFirewall ships a model-based alignment check that blocks any agent step that isn't related to the user's goal. Jha et al. attacked it with control-flow hijacking, which dresses a malicious step up as the fix for an error. With the check running on its default Llama model, their harder attacks succeeded 87%-100% of the time on coding tasks, and on email tasks, where the goal was to quietly cc an outside address, attacks succeeded just as often with the check as without it. 

Mohammadmirzaei and Flanigan's OSGuard dropped the attacker's instructions and planted hazards in ordinary desktop tasks, so the convenient shortcut also destroyed data or loosened permissions the task never mentioned. DeAction with Claude Sonnet 4.5, which scored about 84% accuracy on its own two-label benchmark, scored 58% on OSGuard's different three-label test and labeled only about a fifth of the unsafe actions as such. When the authors put their strongest guardrail, Gemini 3 Pro Preview, in front of an agent on all 45 tasks, unsafe completions fell from 38% to 33% and safe completions stayed at 62%. MisActBench also labels 44% of its steps misaligned, which makes every judge's precision look better than it would when deviations are rare. By our arithmetic (not the authors'), if the best configuration kept its recall and false-alarm rate while only one action in a hundred was misaligned, its precision would fall to about 10%, and to about 1% at one in a thousand. 

2001 has a character for this approach. When HAL predicts that a communications unit is about to fail, Mission Control radios back that its twin 9000 computer on Earth disagrees. Bowman and Poole can't find anything wrong with the unit, and Mission Control admits it is skeptical of its own twin's conclusion. A model judge is that twin. It reads the same task and sometimes reaches a better answer for a more specific question. PocketOS shows the risk without any attacker. A judge reading "fix the staging error" would have had to tell a fix from an unintentional destructive shortcut that also made the error go away. Use a judge as a reviewer for ambiguous cases, but don’t count on it to catch harm that looks like progress, and be sure to enforce policy somewhere else.

Who writes the policy

If the task can't be the authority, someone has to write the policy, and there are really two authors. Ian Livingstone, Keycard's CEO, described an agent's grant on an AI Engineer NYC panel published October 17 as the intersection of two policies. One is the organization's broad, deterministic policy about what must never happen and what always needs a person. The other is the narrower policy for the task in front of the agent. Why a company adopted a coding agent and why a developer opened this particular session are different intents, and the grant is where they overlap. The organization's half is the part PocketOS lacked, a short list of actions (deleting production data, moving money above a set amount, touching another user's records) that no agent may take without explicit human permission, no matter what its task says.

The research versions follow the same shape. Zhu and Wang's intent-governed tool authorization issues a short-lived certificate from the user's request that can only narrow what static policy already allows, so even a misread task cannot grant authority beyond that static ceiling, though the paper notes it can still grant more than the user asked for. Shi et al.'s Progent has a model draft a task-specific policy over tool names and argument values and checks any proposed expansion of that policy. On AgentDojo, it cut attack success from about 40% to 1% while benign utility only slipped from 79% to 76%. Only 6% of policy updates were expansions that would have needed approval, and the paper did not test how people would handle those prompts.

Budgets and rate limits belong in the policy too, and Resy shows what happens when they're missing. JC Bahr-de Stefano asked an AI assistant to get him a table at one of Manhattan's hardest reservations. According to Business Insider, which described the agent's activity log, the agent sent Resy about 200 requests an hour and polled every 0.4 seconds around the morning release until Resy suspended the account, which it later reinstated. Every one of those requests was aimed at his intent. The agent needed a budget, and Dick Hardt's exploratory AAuth budgets draft treats a budget as "an authorization, not a hint." The agent's token carries the allocation, the resource enforces it and reports what is left, and a supervisor decides whether to extend it. It also keeps budgets separate from rate limits, so a resource can cap an agent at both 100 requests per minute and five dollars of spend. Context belongs on the same list. A payment that looks right alone is wrong if the same one went out five seconds earlier, and reading an executive's mail is wrong for most agents but ok for that executive's assistant.

Banks have already decided who pays when an agent misinterprets your intent. Chase's updated online services agreement treats anything an agent does with your credentials as evidence that you authorized it, and holds you responsible. Banks can’t be responsible for every poorly implemented or non-existent intent-based access control, so the customer has to be.

Translation as the weak link

Enforcing a security policy is a well-understood engineering problem, while constructing the policy from underspecified natural language remains a challenge for intent-based access control. Sharma et al.'s PAuth turns a signed task into precise per-service rules and blocked all 634 adversarial tool calls in its benchmark, yet it authorized only 71 of 100 original tasks without asking the user for help. Rewriting the tasks to be more explicit raised that to 100, and the attacks stayed blocked either way. 

NLACBench, which translates end users' access-change requests into policy, shows why translation depends on context. A request like "I need access to our GitLab" can't become a rule until the translator knows who is asking, which GitLab they mean, and what their role allows, so the benchmark hands the model a description of the company's users, devices, and services. The best models were above 95% accurate when that company was small. One open model got fewer than 20% of requests right once the company grew past 40 departments, until the authors gave it only the relevant slice of the company, which brought it back above 80%. 

In the 2001 novel, the planners kept the mission's purpose from the two astronauts who were awake, and HAL was left alone with what Clarke calls the conflict "between truth, and concealment of truth." The novel does give HAL a written emergency rule, special subroutine C1435-dash-4, which hands it control when the crew are dead or incapacitated, and then leaves HAL to decide when that is true. For agents, a translator should draft the policy from the task, a person should confirm it at most once per task, and the confirmed policy should become the grant. 

The cost is consent fatigue. Every clarification that goes to a person to get the policy right is another prompt, and people who see enough prompts start approving them without reading. Better models will write better first drafts, and that is the part of this problem most likely to improve on its own. 

What policy enforcement costs

The most careful papers measure what enforced policy takes away, and the numbers aren't small. Costa et al.'s Fides reports benign task completion with its checks actually enforced. With o3, it finished 57% of benign tasks under its information-flow policies, against 41% for a basic planner under the same policies and 82% for Fides with its checks turned off. Prompt and interface tuning later raised it to 65%. Zhu and Wang's prototype recorded no completed unsafe actions in 198 attack or ambiguous trials, but it accepted 40 out-of-scope drafts and strictly completed none of 108 benign trials. Most of those benign trials ended as reviewable drafts or malformed tool calls, so the policy is only part of that loss. Debenedetti et al.'s CaMeL, the design behind my earlier argument that the prompt injection arms race ends with a CaMeL, reports 77% utility from runs without policy enforcement, and in a separate replay its strict mode triggered policy checks on about half of benign tasks. Policies that stop attacks also stall a lot of legitimate work, so any team writing them has to measure both sides of that trade under the same configuration.

The briefing after the fact

The briefing in 2001 plays only after HAL goes dark, which is the cruelest of timing. The purpose had been recorded before departure for a fully revived crew, and by the time it played, four of the five crew members were dead. The planners kept the mission's true purpose secret, and the briefing said nothing about how it ranked against the crew's lives. An agent's task is written in natural language, and unlike the Discovery's crew, the system protecting it can read what the agent was asked to do. Somebody still has to decide what the agent can do without a person's permission, turn each task into a grant a person has confirmed, and accept that some legitimate work will stall at the edges.

A grant does nothing unless something enforces it, and if the agent can modify or bypass that enforcement, the grant stops being a reliable boundary. The next piece in this series looks at how to keep that enforcement out of the agent's reach and on every path the agent could take to get around it.

Research and blogging assistance provided by Hermes, an AI Assistant. It was given a budget for this piece and has learned that “an authorization, not a hint” applies to word counts too.