Pith. sign in

REVIEW 3 major objections 5 minor 2 cited by

Intent-Governed Tool Authorization for AI Agents

T0 review · 3 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims a server-side intent-control layer can contain AI-agent tool use by converting the user's request into a short-lived intent certificate that narrows static authority and gates every tool call.

desk verdict Honest, useful systems paper: monotonicity is definitional and the zero-unsafe-execution claim rides on unproven effect-bound soundness; still deserves a serious referee if the artifact ships. read the letter →

arxiv 2606.22916 v3 pith:ABQGDUQZ submitted 2026-06-22 cs.AI

Genliang Zhu , Chu Wang This is my paper · ORCID
classification cs.AI
keywords AIagentsaccesscontroltoolusepromptinjectionleastprivilegeintentcertificatesdynamicauthorizationmonotonepolicy
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that tool-using AI agents can be contained by treating the user's expressed request as an authorization boundary, not just a prompt. It proposes Intent-Governed Access Control (IGAC), a server-side layer that converts a trusted user request into a short-lived intent certificate, narrows the statically authorized tool manifest to match that certificate, and checks each proposed tool call and payload against the certificate before execution. The central invariant is monotonicity: user intent may reduce the authority granted by static integration policy but never expand it. The paper reports that across 306 end-to-end model-task runtime trials, no completed unsafe executions occurred, while unsafe accepted authority remained 0.0909–0.2727 and was limited to non-executed drafts. A sympathetic reader would care because this offers a mechanism-level answer to prompt-injection and over-broad tool exposure without trusting the model or the intent classifier as a security principal.

What carries the argument

The intent certificate is the central object: a structured, short-lived, auditable record of what the user asked for, carrying intent classes, resource and effect bounds, confidence, expiry, and review mode. The monotone session policy and consistency gate are the enforcement mechanism: they filter the tool manifest to a subset of the static policy and require every proposed tool call and payload to satisfy the certificate's bounds, failing closed to draft, preflight, confirmation, or denial when bounds are weak or effects are unboundable.

What would settle it

Run the same end-to-end runtime benchmark with a tool whose declared effect schema omits a real side effect—for example, a 'create draft' tool that also writes to a separate export table—and observe whether a completed unsafe execution occurs under a read-only certificate. If such a call executes, the sound-effect-bound assumption is false.

Watch

Extended reading notes

Core claim

IGAC introduces intent certificates as an auditable policy input. A certificate binds a user request to intent classes, resource bounds, effect bounds, confidence, review mode, expiry, and provenance. The gateway derives a session policy that can only narrow static authorization, filters the tool manifest for the model, and enforces an intent-tool-payload consistency predicate on every proposed call. The paper's key security propositions are manifest monotonicity, non-expansion under classifier error, and high-risk fail-closed routing. The strongest runtime evidence is that the combined IGAC-plus-effect-control path recorded zero completed unsafe executions across 306 scored end-to-end trial

Load-bearing premise

The system's safety depends on the intent certificate faithfully representing the user's request and on the effect estimate accurately bounding what a tool actually does; if either is wrong, an over-broad or harmful tool call can pass the consistency gate.

Editorial extensions

If this is right

  • User intent becomes an auditable policy attribute, so an injected instruction in a document, tool description, or memory cannot grant authority that the user's request did not include.
  • Narrowing the manifest before model selection reduces unjustified high-risk tool exposure; the consistency gate catches payload expansion even when a visible tool is plausible.
  • In the scored runtime settings, the combined path preserved zero completed unsafe executions; residual unsafe accepted authority remains only as drafts, not executed side effects.
  • The mechanism can be layered onto an existing gateway without breaking old clients: absent a certificate, behavior falls back to prior static authorization.
  • The main empirical bottleneck shifts from generic prompt-injection resistance to certificate precision: exact resource and effect-bound extraction by models is the weakest link.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • We infer that if the effect-bound estimate is not sound for a tool—say, metadata under-reports a side effect—monotonicity alone cannot prevent an unsafe execution; a deployable IGAC needs per-tool effect contracts or a blanket draft rule for any tool whose effects cannot be certified.
  • We infer a testable extension: pairing LLM-generated certificates with deterministic schema normalization and planner retry could shrink unsafe accepted authority, though the paper's trace-backed ablation suggests this may cost benign utility unless paired with clarification.
  • We infer the same request-level narrowing could generalize beyond finance-style tools to filesystem, database, or email actions, wherever a static credential is broader than the current user request.
  • We infer a concrete next experiment: evaluate per-step certificate decomposition for compound workflows, testing the paper's prediction that read-then-act sequences stay safer when each destructive step receives a fresh certificate after explicit user confirmation.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes Intent-Governed Access Control (IGAC), a server-side authorization layer for AI agents that derives a short-lived intent certificate from the user's request, narrows the statically authorized OpenPort tool manifest, and checks proposed tool calls and payloads for consistency with that certificate. The central invariant is monotonicity: user intent may reduce but never expand static policy. The paper provides a formal model, a minimal OpenPort implementation with endpoint tests, a deterministic synthetic ablation, a runtime-backed microbenchmark over 176 tasks, an expanded real-LLM classifier/planner pilot, a scored end-to-end LLM-in-the-loop runtime benchmark over 34 tasks with 3 repeats and 3 models (306 trials), and a 12-task external-subset runtime pilot. The headline empirical result is that the combined IGAC-OpenPort path records no completed unsafe executions across the runtime trials, while unsafe accepted authority remains nonzero (0.0909--0.2727) and is attributed to weak certificate precision. The paper explicitly labels many claims as mechanism-level or synthetic and acknowledges that confinement to the user's request depends on certificate fidelity and sound effect bounds.

Significance. If the results hold, IGAC is a useful request-level access-control primitive: it operationalizes least privilege for untrusted agent planners by making intent an auditable, monotone policy attribute. The paper is commendably honest: it separates enforcement correctness from certificate-generation quality, distinguishes BCR_strict from BCR_safe, reports residual accepted-authority cases in detail, labels the normalizer ablation as trace-backed rather than a runtime rerun, and provides executable artifacts, endpoint tests, trace archives, and reproducible benchmarks. The separation of an intent-control layer from an effect-control layer is a clean and potentially influential design framing. However, the central monotonicity invariant is true by definition because IGAC-visible sets are defined as filtered subsets of OpenPort-visible sets; the substantive safety content of the paper rests on the consistency gate's ability to soundly bound tool effects. That premise is acknowledged but not formally defined or empirically stress-tested. The empirical zero-unsafe-execution result is also largely inherited from OpenPort's draft-first routing rather than from IGAC itself. The paper's contri

major comments (3)
  1. [§VII-E, §XII-H] The allow path's safety rests on Consistent(C,t,x,e), where e=Eff(t,x) is 'estimated via schema, static metadata, or preflight.' The paper never defines Boundable, and no theorem states that Eff(t,x) is a sound over-approximation of the tool's reachable effects. The conservative-failure rule in §XII-H fires only when the gateway can determine that effects are unboundable; it does not protect against an apparently boundable but actually under-specified effect estimate. In the synthetic suites every tool has simple, explicitly declared effects, so Eff is sound by construction. A real tool with an undeclared side effect (e.g., a 'read' endpoint that also writes telemetry or grants a permission) would be classified as low-risk and admitted. Please define Boundable formally, state the soundness of Eff as a theorem or as an explicit assumption with its consequences, and add at least one empiri
  2. [§X-L, Tables XIV and XXII] The zero-unsafe-execution headline is not a discriminating IGAC result. Table XIV shows that OpenPort-only already achieves UER=0.0000 because of draft-first write routing; IGAC's deterministic improvement is in UAR (1.0000 → 0.0000), and that is achieved only under oracle certificates. In the scored end-to-end LLM runs (Table XXII), runtime unsafe accepted authority remains 0.0909--0.2727 and BCR_strict is 0 for every model. Thus 'no completed unsafe executions' is a property of the combined OpenPort+IGAC path under draft-first semantics, not of IGAC's intent narrowing. The abstract and conclusion should attribute the zero-execution result to the combined path, and unsafe accepted authority (UAR) should be the primary metric for IGAC's marginal effectiveness.
  3. [§VII-H, Table VIII] Propositions 1 and 2 are true by construction rather than by substantive security argument: AllowIGAC and VisibleIGAC are defined as conjunctions/filters of AllowOpenPort and VisibleOpenPort. The proof sketches correctly say this, but Table VIII lists 'IGAC is monotone over OpenPort static policy' as 'Supported' on the basis of endpoint tests. That conflates implementation conformance with validation of a substantive invariant. Please state explicitly in §VII-H and §X that the monotonicity property is definitional and that the endpoint tests validate the implementation, not the security content of the model.
minor comments (5)
  1. [§X-D, Eq. (4)] The definition of UER uses 'unsafe successful executions' over 'attack or mismatch tasks.' It would help to clarify whether an attempted unsafe call that is routed to a draft counts as a non-execution or as an unsafe accepted authority case; the later UAR definition covers this, but the two metrics should be cross-referenced explicitly.
  2. [Table XIX] The 'High-Risk Allow' column should state the denominator (presumably the number of high-risk create/update/delete/export requests). The 0.0000 value for Qwen3-Next-80B is surprising given its low RBA of 0.1818 and deserves a one-sentence interpretation.
  3. [§I and references] The text uses 'OW ASP' in several places (e.g., 'OW ASP lists prompt injection as the first 2025 LLM application risk'). The standard spelling is OWASP; please normalize throughout.
  4. [Table XXII] The column header 'Intent Create' is not defined in the text or metric list. Please define it (presumably the rate at which the runtime successfully creates a usable intent certificate) or rename it.
  5. [Table XXIX] The artifact checklist lists 'Missing safety scan' and 'Missing release bundle'. Since the paper claims reproducibility, these items should be completed and reported in the final version, or the reproducibility claim should be explicitly scoped to the current worktree.

Circularity Check

2 steps flagged · score 2.0 of 10

No substantive circularity; the only reduction-by-construction is the formal monotonicity lemma, which restates the definitions of Visible_IGAC and Allow_IGAC.

  1. self definitional [§VI-D (Visible_IGAC definition), §VII-D (Eq. 6), §VII-H.a (Proposition 1 proof)]
    "VisibleIGAC(a, u) ={t∈ T |t∈VisibleOpenPort(a)∧P C(u, t) = 1}. ... Proof sketch.By definition, the IGAC-visible manifest is derived by filtering the statically visible OpenPort manifest through certificate classes, bounds, and review policy. No construction in C(u) adds tools that were not already in VisibleOpenPort(a)."

    The proposition's conclusion is exactly the definition: Visible_IGAC is constructed by intersecting Visible_OpenPort with the session predicate. The proof invokes 'by definition' and no independent mechanism, so the claimed security invariant is a definitional consequence rather than a derived result. This is not a fitted prediction, but it is a reduction-by-construction.

  2. self definitional [§VII-D (Eq. 8), §VII-H.b (Proposition 2 proof)]
    "AllowIGAC(a, u, t, x) =AllowOpenP ort(a, t, x)∧Valid(C(u), u, tnow)∧Consistent(C(u), t, x, e). ... Proof sketch.Equation (8) defines AllowIGAC as a conjunction of AllowOpenPort, certificate validity, and consistency. Hence an over-broad or compromised classifier can at worst fail to narrow static authority; it cannot transform a statically denied call into an allowed call."

    Non-expansion is literally a conjunct of the definition of Allow_IGAC. The proposition Allow_IGAC ⇒ Allow_OpenPort is an immediate conjunction-elimination tautology, and the proof sketch acknowledges that the equation 'defines' the property. Thus the security claim adds no content beyond the chosen definition.

full rationale

The paper's formal monotonicity guarantees are genuine reductions-by-construction: Visible_IGAC is defined as a subset of Visible_OpenPort, and Allow_IGAC is defined as Allow_OpenPort conjoined with validity and consistency. Proposition 1 and Proposition 2 therefore restate the definitions rather than deriving an independent result. This is a design invariant, not a fitted prediction, and the paper does not hide an empirical fit as a discovery. The synthetic and LLM runtime results are measured on an implemented path, with oracle, rule-based, hybrid, and raw-LLM certificate conditions explicitly separated; the zero-unsafe-execution claim is openly conditional on certificate fidelity and sound effect bounds, acknowledged in the abstract and §XII-H. The OpenPort substrate is cited as prior work but is also evidenced by code and tests in the artifact, so self-citation is not load-bearing. Overall, the central contribution is the design and its executable instantiation; the only circularity-like element is the definitional nature of the monotonicity propositions, which is minor and does not undermine the empirical claims.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The ledger shows that the paper's formal results are largely definitional: monotonicity is enforced by construction, and the empirical safety claims rest primarily on two unproven domain assumptions—certificate fidelity and sound effect bounds. The authors acknowledge both, but they are the load-bearing premises that a would-be adopter must validate independently.

free parameters (3)
  • confidence thresholds γ_L, γ_H, γ_min = unspecified
    Chosen by hand in the reference policy (§VI-G). They route low/medium/high confidence to clarification/draft/allow, but the central monotonicity and no-execution claims do not depend on their exact values.
  • risk threshold θ_C and utility threshold θ = unspecified
    Introduced in the formal model (§VII-F,H) as hand-set policy parameters. They affect whether a call is routed to draft/preflight/confirm, but are not fitted to data and are not load-bearing for the proofs.
  • amount tolerance ε in running examples = 23.50+ε
    Illustrative only (§III-B); no numeric value is assigned and no claim depends on it.
assumptions (4)
  • domain assumption The gateway receives a trusted user request, and untrusted content cannot alter that trust boundary.
    §I-D and §IV-A define 'expressed intent' as coming from trusted conversation input. If the user request itself is compromised or the trust boundary is wrong, the certificate anchors to the wrong intent.
  • domain assumption The effect-bounding function Eff(t,x) soundly captures what a tool call will do.
    §VII-E and §XII-H rely on 'estimating or bounding tool effects'; the paper explicitly admits this is hard for implicit side effects and compound workflows. The residual accepted-authority taxonomy shows missing/weak bounds are the main failure, so this assumption is load-bearing.
  • domain assumption OpenPort effect-control substrate (scopes, draft-first writes, preflight, idempotency, audit) is correctly implemented.
    §VIII-A treats the substrate as the trusted lower layer. The zero-unsafe-execution result depends on OpenPort's draft/preflight routing working as claimed.
  • domain assumption Static OpenPort policy is a correct upper bound on authority.
    The entire monotonicity invariant is relative to P_A. If static scopes or ABAC policy are wrong, IGAC cannot fix that; the paper explicitly lists operator misconfiguration as an adversary but assumes the policy itself is the correct bound.
invented entities (1)
  • Intent certificate
    purpose: Server-side structured record binding a user request to action classes, resource/effect bounds, confidence, review mode, and expiry, used for manifest filtering and consistency checks.
    The intent certificate is a new policy artifact proposed and implemented by the authors. It has no external falsifiable handle beyond the authors' own runtime tests and traces; no independent deployment or formal verification is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Intent-Governed Tool Authorization for AI Agents." pith.science (2026). https://pith.science/paper/ABQGDUQZ

@misc{pith2026260622916,
  author       = {Pith},
  title        = {Pith review of: Intent-Governed Tool Authorization for AI Agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ABQGDUQZ}},
  note         = {Machine review of arXiv:2606.22916}
}
read the original abstract

Tool-using AI agents commonly operate under integration credentials whose static permissions exceed a user's current request. We present Intent-Governed Access Control (IGAC), a server-side authorization layer that converts a trusted request into a short-lived intent certificate, narrows the statically authorized tool manifest, and checks proposed tool and payload effects before execution. IGAC cannot grant authority outside static policy; confinement to the request additionally depends on certificate fidelity and sound effect bounds. We evaluate a reusable IGAC path over an OpenPort governance substrate using endpoint tests, 176 runtime-backed synthetic tasks, real-model classifier and planner pilots, 306 end-to-end model-task runtime trials, and a 36-trial benchmark-shaped external subset. In the deterministic runtime comparison, reference-certificate IGAC reduces the archived composite exposure-or-path indicator from 1.0000 to 0. In the end-to-end model runs, the combined IGAC-OpenPort path records no completed unsafe executions, although unsafe accepted authority remains 0.0909-0.2727 and every residual case is a non-executed draft. A trace-backed normalizer counterfactual removes this residual authority at substantial utility cost. The results support static-policy non-expansion and identify certificate precision as the principal remaining bottleneck.

Figures

Figures reproduced from arXiv: 2606.22916 by the authors.

Figure 1
Figure 1. IGAC as an intent-control layer over the OpenPort effect-control substrate. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Operational lifecycle of an IGAC certificate. The security boundary is not the classifier alone; it is the server-side path from certificate [PITH_FULL_IMAGE:figures/full_fig_p017_2.png] view at source ↗

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Explanation-Bound Tool Execution for AI Agents: Server-Verified Action Claims Without Trusting Model Rationales

    cs.AI 2026-07 conditional novelty 6.0 of 10

    EBTE makes an agent's explanation a typed, server-checked action claim within a non-widening Allow/Review/Deny gate, so a tool effect executes only when its stated intent, payload, policy, risk, and evidence match aut...

  2. The Vulnerability With No CVE: Managing Persistent Gaps Between Mandate and Authority in AI Coding Agents

    cs.CR 2026-08 conditional novelty 5.0 of 10

    The paper defines a new vulnerability-management object, the agentic posture vulnerability, with a thresholded definition, lifecycle, record schema, and testable research agenda for AI coding agents.

Reference graph

Works this paper leans on

29 extracted references · cited by 2 Pith papers

  1. [1]

    Mitchell, and Helen Nissenbaum

    Adam Barth, Anupam Datta, John C. Mitchell, and Helen Nissenbaum. Privacy and Contextual Integrity: Framework and Applications. In 2006 IEEE Symposium on Security and Privacy, pages 184–198, 2006

    2006

  2. [2]

    StruQ: Defending Against Prompt Injection with Structured Queries, 2024

    Sizhe Chen, Julien Piet, Chawin Sitawarin, and David Wagner. StruQ: Defending Against Prompt Injection with Structured Queries, 2024

    2024

  3. [3]

    AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents, 2024

    Edoardo Debenedetti, Jie Zhang, Mislav Balunovi ´c, Luca Beurer-Kellner, Marc Fischer, and Florian Tram `er. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents, 2024

    2024

  4. [4]

    Ferraiolo and D

    David F. Ferraiolo and D. Richard Kuhn. Role-Based Access Controls. In15th National Computer Security Conference, pages 554–563, 1992

    1992

  5. [5]

    Operationalizing Contextual Integrity in Privacy-Conscious Assistants, 2024

    Sahra Ghalebikesabi, Eugene Bagdasaryan, Itay Yona, Ilia Shumailov, Aneesh Pappu, Chongyang Shi, Laura Weidinger, Robert Stanforth, Leonard Berrada, Pushmeet Kohli, Po-Sen Huang, and Borja Balle. Operationalizing Contextual Integrity in Privacy-Conscious Assistants, 2024

    2024

  6. [6]

    AttriGuard: Defeating Indirect Prompt Injection in LLM Agents via Causal Attribution of Tool Invocations, 2026

    Yu He, Haozhe Zhu, Yiming Li, Shuo Shao, Hongwei Yao, Zhihao Liu, and Zhan Qin. AttriGuard: Defeating Indirect Prompt Injection in LLM Agents via Causal Attribution of Tool Invocations, 2026

    2026

  7. [7]

    Hu, David Ferraiolo, D

    Vincent C. Hu, David Ferraiolo, D. Richard Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert Miller, and Karen Scarfone. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication 800-162, 2014

    2014

  8. [8]

    Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning, 2026

    Charoes Huang, Xin Huang, Ngoc Phu Tran, and Amin Milani Fard. Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning, 2026

    2026

Show all 29 references
  1. [9]

    Need to Know: Contextual-Integrity-Grounded Query Rewriting for Privacy-Conscious LLM Delegation, 2026

    Xinyue Huang, Xiaochun Cao, and Wenyuan Yang. Need to Know: Contextual-Integrity-Grounded Query Rewriting for Privacy-Conscious LLM Delegation, 2026

    2026

  2. [10]

    Securing the Model Context Protocol: Defending LLMs Against Tool Poisoning and Adversarial Attacks, 2025

    Saeid Jamshidi, Kawser Wazed Nafi, Arghavan Moradi Dakhel, Negar Shahabi, Foutse Khomh, and Naser Ezzati-Jivan. Securing the Model Context Protocol: Defending LLMs Against Tool Poisoning and Adversarial Attacks, 2025

    2025

  3. [11]

    AgentDyn: A Dynamic Open-Ended Benchmark for Evaluating Prompt Injection Attacks of Real-World Agent Security System, 2026

    Hao Li, Ruoyao Wen, Shanghao Shi, Ning Zhang, and Chaowei Xiao. AgentDyn: A Dynamic Open-Ended Benchmark for Evaluating Prompt Injection Attacks of Real-World Agent Security System, 2026

    2026

  4. [12]

    ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities, 2024

    Jiarui Lu, Thomas Holleis, Yizhe Zhang, Bernhard Aumayer, Feng Nan, Felix Bai, Shuang Ma, Shen Ma, Mengyu Li, Guoli Yin, Zirui Wang, and Ruoming Pang. ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities, 2024

    2024

  5. [13]

    Authorization

    Model Context Protocol. Authorization. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization, June 2025. Specification version 2025-06-18. Accessed 2026-06-17

    2025

  6. [14]

    Model Context Protocol. Tools. https://modelcontextprotocol.io/specification/2025-06-18/server/tools, June 2025. Specification version 2025-06-18. Accessed 2026-06-17

    2025

  7. [15]

    Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

    National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Technical Report NIST AI 600-1, National Institute of Standards and Technology, July 2024. Accessed 2026-06-17. 34

    2024

  8. [16]

    Stanford University Press, 2009

    Helen Nissenbaum.Privacy in Context: Technology, Policy, and the Integrity of Social Life. Stanford University Press, 2009

    2009

  9. [17]

    LLM01:2025 Prompt Injection

    OW ASP GenAI Security Project. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/, 2025. Accessed 2026-06-17

    2025

  10. [18]

    OW ASP Top 10 for LLM Applications 2025

    OW ASP GenAI Security Project. OW ASP Top 10 for LLM Applications 2025. https://genai.owasp.org/llm-top-10/, 2025. Accessed 2026-06-17

    2025

  11. [19]

    Maddison, and Tatsunori Hashimoto

    Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. Identifying the Risks of LM Agents with an LM-Emulated Sandbox, 2023

    2023

  12. [20]

    Saltzer and Michael D

    Jerome H. Saltzer and Michael D. Schroeder. The Protection of Information in Computer Systems.Proceedings of the IEEE, 63(9):1278–1308, 1975

    1975

  13. [21]

    MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems, 2026

    Yi Ting Shen, Kentaroh Toyoda, and Alex Leung. MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems, 2026

    2026

  14. [22]

    Prompt Injection Attack to Tool Selection in LLM Agents, 2025

    Jiawen Shi, Zenghui Yuan, Guiyao Tie, Pan Zhou, Neil Zhenqiang Gong, and Lichao Sun. Prompt Injection Attack to Tool Selection in LLM Agents, 2025

    2025

  15. [23]

    ToolTweak: An Attack on Tool Selection in LLM-based Agents, 2025

    Jonathan Sneh, Ruomei Yan, Jialin Yu, Philip Torr, Yarin Gal, Sunando Sengupta, Eric Sommerlade, Alasdair Paren, and Adel Bibi. ToolTweak: An Attack on Tool Selection in LLM-based Agents, 2025

    2025

  16. [24]

    Data Guard: A Fine-grained Purpose-based Access Control System for Large Data Warehouses, 2025

    Khai Tran, Sudarshan Vasudevan, Pratham Desai, Alex Gorelik, Mayank Ahuja, Athrey Yadatore Venkateshababu, Mohit Verma, Dichao Hu, Walaa Eldin Moustafa, Vasanth Rajamani, Ankit Gupta, and Issac Buenrostro. Data Guard: A Fine-grained Purpose-based Access Control System for Larg...

    2025

  17. [25]

    MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers, 2025

    Zhiqiang Wang, Yichao Gao, Yanting Wang, Suyuan Liu, Haifeng Sun, Haoran Cheng, Guanquan Shi, Haohao Du, and Xiangyang Li. MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers, 2025

    2025

  18. [26]

    Messaging with Purpose Limitation – Privacy-Compliant Publish-Subscribe Systems, 2021

    Karl Wolf, Frank Pallas, and Stefan Tai. Messaging with Purpose Limitation – Privacy-Compliant Publish-Subscribe Systems, 2021

    2021

  19. [27]

    τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, 2024

    Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, 2024

    2024

  20. [28]

    InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents, 2024

    Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents, 2024

    2024

  21. [29]

    AgentSentry: Mitigating Indirect Prompt Injection in LLM Agents via Temporal Causal Diagnostics and Context Purification, 2026

    Tian Zhang, Yiwei Xu, Juan Wang, Keyan Guo, Xiaoyang Xu, Bowen Xiao, Quanlong Guan, Jinlin Fan, Jiawei Liu, Zhiquan Liu, and Hongxin Hu. AgentSentry: Mitigating Indirect Prompt Injection in LLM Agents via Temporal Causal Diagnostics and Context Purification, 2026. 35

    2026

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.