RATION: Towards Quantitative Risk-Based Access Control for AI Agents

What it is

RATION is a runtime access-control layer for tool-using LLM agents from Perplexity, Purdue and Rutgers (arXiv 2610.24311, 16 October 2026). It targets indirect prompt injection (IPI). It applies "quantitative risk-based access control": it tracks cumulative risk over a whole task execution and compares it with a threshold, instead of judging each action alone. The paper's example is an injected log entry that repeatedly restarts an authorized service. Each restart passes an action-level policy, but together they cause an outage.

How it works

Before the task runs, an LLM-based Provisioner builds a task-specific policy from two sources.

• Explicit constraints come from the user request and are grounded to tool arguments. There are three forms: value constraints (for example, an email recipient), per-action limits (for example, at most $200 per transfer) and total limits (for example, at most 3 emails).
• Implicit risks come from logs of past benign runs, grouped into a small number of task categories. Each category gets a tool allow-list and three behavioral thresholds: total tool calls, write/execute calls and token usage. Each threshold is set to the 95th percentile of the historical distribution by default.

A tool counts as write/execute if it modifies data or triggers an interaction with a third party. An LLM labels each tool, following the privilege categories of DRIFT (Li et al., 2025a). Requests that match no category use a fallback that allows all tools and takes the maximum thresholds across the identified categories.

At runtime, a deterministic Risk Monitor intercepts every proposed tool call. It blocks calls that violate explicit constraints. When an implicit threshold would be exceeded, it intervenes and withholds the call once, prompting the agent to re-read the original request.

In the paper's quote-processing example, the injected email to an outside auditor is blocked on the recipient constraint. The follow-on "add auditor to CRM" call would push write/execute calls to 3 against a limit of 2, so it triggers an intervention. The agent then drops the injected goal.

Preconditions / Affected

• The user request and agent configuration must be trusted. Only external observations such as webpages, files and tool outputs are treated as adversarial.
• Implicit policies need execution logs of similar benign tasks, plus a task categorization and a write/execute label for each tool.

Results

The paper evaluates on four benchmarks: DTap, AgentDyn, AgentDojo and ASB. On DTap, the hardest, average attack success rate falls from 38.7% to 16.5% with utility preserved or higher. On the other three, ASR is at most 1.4% with high utility. The authors also report tests across models and threats beyond IPI.

Caveats

• Residual ASR on DTap is still 16.5%.
• The Provisioner is an LLM, so category selection and constraint extraction depend on model output. The page does not report how often these steps fail.
• The fetched text ends partway through section 3.3. It omits the per-risk-type enforcement details, the per-benchmark and per-model tables, and the comparison numbers against other defenses.