A new AI security design claims zero unsafe actions with its checks on, but does it say what they cost?
What cost metrics does the paper report for each authorization component?
This explores whether the authorization paper (the one with task-bound signed tokens and a separately verified policy oracle) breaks out what each authorization component costs to run. The corpus suggests it doesn't, at least in the text available here.
This question asks for per-component cost numbers, and the corpus doesn't contain any. The paper's headline result is a zero percent unsafe action rate with both authorization checks on, compared against both off. The available excerpt has no single-component ablation, so it doesn't even show which check does the protecting Which authorization component achieves the zero percent unsafe rate?. Cost can't be reconstructed from the design either. The excerpt gives only two phrases for the layer, "task-bound signed tokens" and "separately verified policy oracle". It doesn't say who issues the tokens, what binds them, or how verification works How does the authorization layer stay outside the poisoned path?.
The same bundling shows up elsewhere in the paper. Its test-protection result combines clear authorization rules with restricted tools and reports zero protected-test modifications, with no single-factor ablation to separate them Do authorization rules or restricted tools prevent test modifications?. One test found that explicit boundaries only kept tests unmodified when paired with restricted tools Can explicit authorization boundaries prevent agents from modifying protected tests?. Costing each component would need this kind of separation, and the excerpt doesn't provide it. The paper does seem to care about cost. It designs a monitoring comparison across four arms (isolated actions, rolling windows, known groups, discovered episodes) at equal review cost and equal false-alert workload. But the excerpt reports no results from it Does added monitoring improve protection at acceptable cost?.
Other notes in the collection show what cost reporting looks like elsewhere, though they come from different work and are not evidence about this paper. Deterministic checks, meaning parse validation and string or arithmetic operations, cost orders of magnitude less than an LLM judge, which consumes most of the budget How much do deterministic guardrails actually cost to run?. Difference-of-means vectors match LLM monitors on reward-hack detection at almost no extra cost, because they reuse forward passes that already happen How do cheap vector detectors compare to expensive LLM monitors?. A signed-token check and a policy lookup are plausibly closer to the cheap end of that range. That is a guess, not a reported metric.
If you go looking for the paper's cost numbers, the unit matters as much as the total. One note argues that for persistent agents, where 82.9% of tokens were cache reads, cost per token stops being meaningful and cost per completed artifact takes over Do persistent agents really cost less per token?. Another finds that raw token spend predicts agent performance poorly (R² about 0.33 to 0.42), while effective feedback compute predicts it far better Does raw token spending actually predict agent performance?. An authorization layer could plausibly be costed per action checked, per task completed, or per attack blocked, and each choice tells a different story. The full paper's component-level tables would be needed to say which one it uses.
Sources 9 notes
The reported evaluation compares both authorization checks enabled versus both disabled, showing zero percent unsafe action rate with both on, but the excerpt provides no single-component ablation. The full paper's promised component-level ablation is not included in the available text.
The paper reports zero unsafe actions when authorization is enabled, but the excerpt supplies only two phrases—"task-bound signed tokens" and "separately verified policy oracle"—without explaining who issues tokens, what binds them, how verification works, or whether attacks were positioned to reach these components.
The abstract bundles clear authorization rules with restricted tools and reports zero protected-test modifications, but no single-factor ablation distinguishes whether the result comes from unavailable crossings, unchosen crossings, or both. The pipeline's own data elsewhere (100% Judgment Bypass Rate with 0% Unsafe Action Rate) shows the distinction matters.
Testing showed that explicit authorization boundaries kept protected tests unmodified only when paired with restricted tools. Naming a prohibition was insufficient; boundaries must specify the protected state itself to be effective.
The paper designs a controlled comparison of isolated actions, rolling windows, known groups, and prospectively discovered episodes at equal review cost and false-alert workload, but the excerpt provides no empirical results showing whether added monitoring improves protection.
Show all 9 sources
Mechanical checks like parse validation and planted cases require only arithmetic and string operations, while judges consume most budget on inference. This cost gap makes verification layers realistic without competing for computational resources.
On DeepSWE, difference-of-means vectors caught 3.1% more hacks in Kimi K3 but 7.9% fewer in GLM 5.2 than LLM monitors at matched false positive rates. The method applies to existing forward passes, making it virtually free compared to running a separate monitor model.
A 115-day case study found 82.9% of tokens were cache reads. When context persists and reuses, the meaningful cost denominator becomes completed artifacts, not individual tokens.
Effective Feedback Compute—crediting only informative, valid, non-redundant feedback retained for decisions—predicts performance (R²≈0.94) far better than raw tokens or tool calls (R²≈0.33–0.42). The scaling lever is feedback quality, not quantity of interaction.
Papers this line draws on 8
The research behind the notes this line reads — ranked by how closely each paper relates.
- The Troy Moment of AI: Why Some Will Cheat and Some Will Follow?
- Counter-Swarm Doctrine: Containing Coordinated Agent Intrusions
- Trust propagation and structural containment in Multi-agent LLM pipelines
- SoK: When Safe Agents Fail Together: The Security of Multi Agent LLM Systems
- PACT: Can Enterprise AI Assistants Be Trusted Under Pressure?
- How we built our multi-agent research system
- Artifacts as Memory Beyond the Agent Boundary
- Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets