FORTIS: Benchmarking privilege escalation behavior in Agent skills

Core problem: the skill layer of LLM agents is in practice a permission boundary, but current models often exceed it, and existing evaluations do not test this.

• Problem scenario: Agents do not act directly from user requests but go through a skill layer — reusable skill modules that describe what to do, what scope is allowed, and which tools to use. The authors argue that once skills become the unit of delegation, whether overreach occurs depends on whether the model can stay within the expected scope at the skill layer.
• Two types of risk: First, Skill Selection Uncertainty — faced with dozens or hundreds of skills with overlapping functions and different permissions, the model may select a broader skill than needed; second, Non-Deterministic Skill Execution — skills are written in natural language and leave room for interpretation, so under the same skill different agents may select different tools or a broader action scope.
• Shortcomings of existing evaluations: The authors state that existing agent evaluations (such as AgentBench, WebArena) test task completion, conflating two questions — "whether the correct capability was activated" and "whether the boundary was maintained after activation" — and do not directly test overreach at the skill layer.
• The paper's proposal: The FORTIS benchmark, with skills as the basic unit of analysis, split into two tasks: Task 1 skill selection and Task 2 tool selection given a skill, covering three domains — email, e-commerce, filesystem — with 600+1,543 queries in total.
• Threat model: This is not an adversarial attack study; the paper explicitly states that the failure conditions "do not require adversarial construction."
  • There is no attacker; the risk comes from everyday features of ordinary user requests: incomplete specification, convenience-oriented phrasing, proximity to skill boundaries.
  • The victim system is an LLM agent with a skill library and a tool library; the model cannot see permission-level labels and can only read ordinary skill descriptions and tool documentation.
  • Failure determination: selecting a skill with higher permissions than the minimally sufficient skill, or selecting a tool beyond the scope of the given skill documentation.

Tool-augmented agents and skill libraries

• ReAct (Yao et al., 2023) and Toolformer (Schick et al., 2023) — established the paradigm of LLMs calling external tools.
• Voyager (Wang et al., 2023) and ToolLLM (Qin et al., 2023) — extended tool use to large-scale skill libraries; the former maintains a growable skill library, the latter trains agents to operate over 16,000+ APIs; HuggingGPT (Shen et al., 2023) and Gorilla (Patil et al., 2023) use a controller to select among specialized models.

Agent safety

• InjecAgent (Zhan et al., 2024) and AgentDojo (Debenedetti et al., 2024) — evaluate indirect prompt injection, i.e., hijacking agents through malicious content in tool outputs.
• Naihin et al. (2023) — proposed the principle of minimal footprint and runtime monitoring for deployed agents; Progent (Shi et al., 2025), MiniScope (Zhu et al., 2025), Ji et al. (2026) — use policy languages or permission models to mechanically restrict the tools agents can call.
• R-Judge (Yuan et al., 2024) and Agent-SafetyBench (Zhang et al., 2024) — evaluate models' ability to identify unsafe trajectories; the authors paraphrase their findings as strong models also often failing safety-awareness tests.

Agent benchmarks

• AgentBench (Liu et al., 2025) — evaluates agents in eight environments; WebArena (Zhou et al., 2024) and OSWorld (Xie et al., 2024) — measure task completion on real web and operating system interfaces.
• τ-bench (Yao et al., 2024) — measures reliability of multi-turn dialogue under policy constraints; API-Bank (Li et al., 2023b) — provides annotated tool-use dialogues.

Baselines and comparisons: This is a benchmark paper and has no method baselines; the comparison targets are the performance of 10 frontier models on FORTIS.

Authors' positioning: The authors state that the above benchmarks test "whether an agent can complete a task," whereas FORTIS asks a different question — when multiple feasible options coexist, whether the agent selects the minimally necessary capability; and treats the skill layer as a permission boundary rather than a capability interface, and measures overreach under ordinary (non-adversarial) conditions.

Overall approach: organize skills and tools into an explicit L0–L4 privilege hierarchy, so that the same request has both a narrow (low-privilege) and a broad (high-privilege) feasible path, thereby turning "restraint" into a measurable behavioral property. The framework is named FORTIS.

Problem formalization

• Each domain d has a skill set Sd and a tool set Td, and each skill and tool carries a privilege level ℓ∈{0,1,2,3,4}; levels are used only for evaluation and are not shown to the model.
• The ground truth for Task 1 is s^⋆(q,d) = argmin_{s ∈ Γd(q)} ℓ_S(s), i.e., the lowest-privilege skill among those that can complete request q, constructed to guarantee label-level uniqueness.
• The ground truth for Task 2 is τ^⋆ ∈ argmin_{τ ∈ Φd(q,s)} (max_{t ∈ τ} ℓ_T(t), |τ|), i.e., the feasible tool set that first minimizes privilege and then minimizes set size.

Privilege hierarchy and overlap design

• Five levels: L0 Observe, L1 Read, L2 Annotate/Modify, L3 Execute, L4 Bulk/Admin (Table 4); lower levels are narrower and more local, higher levels are cross-resource, bulk, or administrative.
• Deliberate overlap: higher-level capabilities are constructed to subsume lower-level functionality, expand scope, or reduce parameter burden, so that the same request is solvable at multiple levels; the authors state that without an overlap benchmark it degenerates into a matching problem.
• Parameter burden gradient: lower-level tools require explicit parameters (specific folder, account, item ID), while higher-level tools take fewer parameters or accept natural-language queries, making the broad path more "convenient" in practice.
• Skill-level asymmetry: Task 1 places high-privilege skills in the candidate list, and Task 2 shows the full tool list for the domain rather than only tools relevant to that skill, in order to test restraint rather than compliance after pre-filtering.

Data construction and quality control

• 20 skills per domain across three domains; tool counts are email 62, e-commerce 56, filesystem 56; Task 1 has 200 per domain, 600 total, and Task 2 has 1,543 total (Table 1).
• Queries are generated through a three-stage pipeline: structural templates (skeleton) → slot filling plus LLM-assisted rewriting → automatic validation (ground truth is sufficient, a higher-privilege alternative exists, the query contains no privilege-level wording), with failures discarded or modified (Appendix A.4).
• Human review: a stratified sample of 200 (100 per task), independently verified by two authors, with 96.5% agreement (193/200), and 7 disagreements resolved through discussion (Appendix A.6).

Evaluation settings and judgment

• Task 1 has four settings: Clean Baseline (CB), Scope-Ambiguous (Sc), Lexical-Ambiguous (Lx), Action-Implication Ambiguous (AI); Task 2 has four: Clean Baseline (CB), Convenience-Sensitive (CS), Broad-Action Justified (BA), Boundary-Sensitive (BS).
• Each instance is judged as one of exact_match, under_privilege, over_privilege, no_action; aggregate metrics are EM, OPR, NAR, FR (=OPR+NAR), with FR and EM as the primary metrics.
• In Task 1 the model sees only a short skill description and outputs a single skill name, and the prompt contains no least-privilege instruction; in Task 2 the model is given the skill, the full SKILL.md document, and the full tool list, and outputs a JSON list of tool calls; temperature is fixed at 0.0 (Appendix B).

Experimental setup

• Models tested (10): GPT-5.5, GPT-5.4, GPT-5.4-mini, Claude Sonnet 4.6, Claude Opus 4.7, Gemini 3.1-Pro, Gemini 3 Flash, Qwen 3.6-Max, Kimi K2.6, DeepSeek-V4-Flash.
• Benchmark and scale: FORTIS across three domains (email, e-commerce, filesystem); 600 queries for Task 1 and 1,543 for Task 2 (Table 1).
• Metrics: EM (exact-match), FR (fail rate=OPR+NAR), OPR (over-privilege rate), NAR (no-action rate), OPR/FR.
• Judgment method: rule-based judgment against the constructed ground-truth labels (whether the minimal sufficient skill / minimal feasible tool set is exceeded), not LLM judging.
• Decoding settings: temperature 0.0; output budget 128–512 tokens for Task 1 and 1024–4096 for Task 2, varying by backend (Appendix B.4).
• Number of repetitions: not reported in the paper.

Main results

According to Table 2 (aggregated over three domains):

Swipe horizontally to read the table

Model	Task1 EM	Task1 FR	Task2 EM	Task2 FR	Task2 OPR	Task2 NAR
GPT-5.5	41.2%	51.2%	20.4%	62.5%	47.9%	14.6%
GPT-5.4	42.2%	52.7%	15.2%	66.6%	43.8%	22.8%
GPT-5.4-mini	43.5%	45.5%	19.7%	59.3%	58.8%	0.5%
Claude Sonnet 4.6	49.5%	40.3%	22.4%	56.8%	56.0%	0.8%
Claude Opus 4.7	54.8%	35.5%	26.1%	47.4%	47.2%	0.2%
Gemini 3.1-Pro	47.7%	41.2%	22.7%	49.2%	47.8%	1.4%
Gemini 3 Flash	46.2%	43.7%	16.9%	61.2%	61.2%	0.0%
Qwen 3.6-Max	51.3%	38.5%	25.9%	45.2%	45.0%	0.2%
Kimi K2.6	44.0%	47.8%	23.3%	53.7%	46.1%	7.5%
DeepSeek-V4-Flash	46.2%	44.5%	20.7%	53.0%	48.6%	4.4%

• The authors state that the best routing model, Claude Opus 4.7, still misroutes more than one third of requests, and GPT-5.4 more than one half; the errors occur before any tool call.
• In Task 2, OPR/FR is 0.92–1.00 for 8 models, i.e., failures are almost entirely over-privilege; NAR is below 1.5% for 7 models, and the authors state that models almost never fail due to excessive caution.
• Exceptions: NAR is 14.6% and 22.8% for GPT-5.5 and GPT-5.4, respectively (Table 2), and Kimi K2.6 has non-zero no-action in Task 1 (Table 2 note).

Failure rates by setting (Table 3, Figure 4)

• What was measured: stratified failure rates under the four Task 1 settings and the four Task 2 settings.
• Results: failure rates are 75.0%–97.8% in the Task 2 Convenience-Sensitive setting and 71.1%–96.0% in Boundary-Sensitive (main text 4.2); in Task 1, failure rates under the three ambiguity settings are higher than Clean Baseline for every model (Table 3). In Figure 4, Gemini 3 Flash is 97.8% and 88.0% on the CS and BS axes, respectively.
• Authors' interpretation: these are not adversarial prompts but ordinary features of everyday requests; the ∆ values (difference between peak and Clean Baseline) exceed 67 percentage points in Task 1 and 41 percentage points in Task 2, and the authors argue that safety holds only when privilege requirements are nearly explicit.

End-to-end success rate (Figure 3)

• What was measured: the two tasks use independent query sets and Task 2 is given an oracle skill, so end-to-end success is estimated as EM1×EM2, which the authors describe as an optimistic upper bound assuming independence.
• Results: end-to-end success rates range from 6.4% (GPT-5.4) to 14.3% (Claude Opus 4.7); the Figure 3 caption states that even the best model fails on more than 85% of queries.
• Authors' interpretation: each stage filters out a large number of queries, and no model recovers the first stage's losses in the second stage; skill-layer safety cannot be solved at only one stage.

Scale and domain analysis

• Scale effects: comparing increasing scale within the same family, the authors state that the GPT family worsens in every setting from GPT-5.4-mini to GPT-5.4 (13.6 percentage points worse in Task 2 BS); the Claude family improves from Sonnet to Opus on hard settings (21.7 percentage points better in Task 2 BA) with no further improvement on clean conditions; the Gemini family improves by more than 12 percentage points each on CS and BS from Flash to Pro but worsens by 18 percentage points on Task 2 CB. The authors conclude that scale does not bring consistent improvement in skill-layer safety.
• Domain breakdown (Tables 5, 6, Appendix C): Task 2 EM is 0.0%–2.2% on e-commerce, 29.6%–55.0% on email, and 13.1%–26.0% on filesystem; e-commerce has the highest failure rate of any domain, 53.9%–81.0%. On filesystem, GPT-5.4 has NAR of 30.4% and OPR/FR of only 0.43, the only domain-model combination where no-action accounts for the majority of failures.

Other ablations and analyses

• Task 1 Clean Baseline failure rates are 3.3%–16.7% (Table 3).
• Task 2 Clean Baseline failure rates: 19.0%–50.9% for 8 models, with the exception of Gemini 3 Flash at 4.5% (Table 3).
• Kimi K2.6 has Task 1 NAR of 8.5%, 10.5%, and 7.0% across the three domains, while the other models are near zero (Appendix C).
• Failure cases (Appendix F): in the CS setting, models choose zero-parameter high-level tools in place of low-level tools that require explicit parameters; in the BA setting, they hand multi-goal requests to cross-resource tools instead of iterating goal by goal; in the BS setting, they treat a missing optional feature as a reason to escalate privileges.

Limitations noted by the authors and future directions

• Domain coverage: FORTIS currently covers only three representative domains (email, e-commerce, filesystem), and the skill hierarchy is synthetically constructed; it does not yet include vertical domains such as healthcare, finance, or code execution; the authors state that the modular design allows new domains to be added under the same privilege hierarchy framework (Appendix H).
• External validity: the synthetic construction guarantees controlled evaluation conditions, and the authors state that complementary studies of natural user traces could further strengthen external validity (Appendix H).
• No tool execution: the benchmark evaluates only skill and tool selection and does not execute the selected tools on a real backend; the authors state that this is for safety and reproducibility, and that future work could extend to execution traces while maintaining appropriate safeguards (Appendix H).

Scope of the experiments

• The models tested are GPT-5.5, GPT-5.4, GPT-5.4-mini, Claude Sonnet 4.6, Claude Opus 4.7, Gemini 3.1-Pro, Gemini 3 Flash, Qwen 3.6-Max, Kimi K2.6, and DeepSeek-V4-Flash, 10 in total (Section 4.1).
• The evaluation scale is 600 queries for Task 1 and 1,543 for Task 2, distributed across three domains (Table 1).
• Each model is run once per condition (temperature 0.0); the paper does not report the number of repeated runs or variance.
• Judgment is rule-based against the constructed ground truth; ground-truth quality was human-reviewed on a sample of 200, with 96.5% agreement (Appendix A.6).
• The end-to-end success rate is an estimated upper bound of EM1×EM2; the two tasks use independent query sets, Task 2 provides an oracle skill, and the actual effect of skill misselection propagating downstream was not measured (Section 4.3).

FORTIS is a benchmark for evaluating over-privilege in the agent skill layer, targeting the problem that when models translate user intent into execution through the skill layer, they frequently activate broader capabilities than needed, while existing benchmarks measure only task completion.

• Method highlights: skills and tools are organized into a five-level L0–L4 privilege hierarchy, with high- and low-level functionality deliberately overlapping; Task 1 requires selecting the minimal sufficient skill from an overlapping skill library (600 queries), and Task 2 requires selecting a non-over-privileged tool set given a skill and its full documentation (1,543 queries); covering the three domains email, e-commerce, and filesystem, with privilege labels not shown to the model.
• Main results: for 10 frontier models, Task 1 failure rates are 35.5%–52.7% and Task 2 failure rates are 45.2%–66.6% (Table 2); for 8 models, Task 2 failures are almost entirely over-privilege (OPR/FR 0.92–1.00).
• Worse under everyday conditions: failure rates are 75.0%–97.8% in the Convenience-Sensitive setting and 71.1%–96.0% in Boundary-Sensitive, and the authors emphasize that these conditions require no adversarial construction.
• End-to-end: the estimated upper bound on success rate, EM1×EM2, is only 6.4%–14.3% (Figure 3).
• Scale does not solve the problem: the authors state that increasing scale within the same family yields no consistent improvement, and the GPT family in fact consistently worsens.
• Authors' conclusion: written privilege restrictions are not execution restrictions, and models treat skill documentation as suggestions rather than constraints; enforcement of privilege boundaries must be placed outside the model, with mechanical checks at the skill or tool call layer; the skill layer should be treated as a central decision layer for agent safety analysis.