Pith. sign in

REVIEW 4 major objections 6 minor 29 references

Individually permitted AI tools can violate policy when chained; a monotonic policy compositor plus runtime taint tracking can block those chains before and during execution.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · grok-4.5

2026-07-12 02:34 UTC pith:E6PQQPQT

load-bearing objection Clean, usable composition design for a real multi-tool risk, but the headline block rates are mostly catalog geometry and Phase 2 is only three walkthroughs. the 4 major comments →

arxiv 2607.03423 v1 pith:E6PQQPQT submitted 2026-07-03 cs.CR cs.AI

Securing Multi-Tool AI Agent Chains With Dynamic, Real-Time Compositional Policies

Chris Schneider , Kriti Faujdar , Philipp Schoenegger , Ben Bariach This is my paper
classification cs.CR cs.AI
keywords multi-tool agentscompositional securitypolicy compositiontaint trackingAI agent safetyNIST SP 800-53monotonicitysession checkout
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Modern AI agents chain many tools in one session. Each tool may pass its own security check, yet the combination can leak sensitive data or process it without the controls that classification requires. This paper proposes DSCC, a two-phase system for that gap. At session checkout, a Most Restrictive Set algorithm merges every tool’s policy into one effective control set that can only get stricter as the chain grows, and rejects incompatible sets before anything runs. At runtime, a sticky taint state tracks the highest sensitivity of data the agent has actually touched and revokes the session if a later tool would breach that bound. On a reference catalog of 32 tools under 16 NIST-aligned policies, the default clearance mode blocks 79.2% of policy pairs and 95.5% of triples, while an alternative taint mode admits mixed-classification chains but still keeps sensitive data away from outbound tools.

Core claim

The paper claims that compositional security for multi-tool agent chains is achievable by treating the agent as an untrusted stochastic caller and composing per-tool policies with a Most Restrictive Set operator that has a formal monotonicity invariant—extending a chain can only tighten controls—then enforcing the same high-water-mark taint state at runtime so unsafe paths are refused at checkout or revoked when actual data exposure would breach policy.

What carries the argument

The Most Restrictive Set (MRS) algorithm: it takes each tool’s six-tuple policy (control bindings, classification, prohibition flag, flow direction, zones, TTL), resolves controls by the maximum restriction level, takes classification and prohibition high-water marks, intersects network zones, and rejects chains that fail compatibility, clearance (default mode), or DENY-level boundary checks. The same max operators feed a session-level taint state in Phase 2.

Load-bearing premise

Every tool must carry an accurate standardized security policy, and every resource the agent touches must have a correct sensitivity label at access time; if those labels are missing or wrong, both static composition and runtime taint checks fail by construction.

What would settle it

Apply the same MRS enumeration and runtime guards to a production agent tool catalog with real classification labels and measured workflows; if multi-tool chains that move Confidential or Restricted data to outbound tools still execute without Phase 1 rejection or Phase 2 revocation, the defense-in-depth claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Organizations can refuse cross-classification tool combinations at session checkout instead of discovering violations after the fact.
  • A single effective control set per session gives auditors one policy artifact rather than an unenforced pile of per-tool rules.
  • Clearance mode partitions tools into classification-level clusters; taint mode allows mixed levels while still containing exfiltration above Public.
  • Policy work becomes a continuous federated task: a central team owns the vocabulary, tool developers author bindings, and denials point to the blocking binding.
  • Fail-closed composition can sit as a control-level backstop for frontier agent risk, either always on or switched stricter when capability thresholds are crossed.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Production agents with thousands of tools will force either finer policies or workflow decomposition into smaller sub-chains, or else block rates will dominate day-to-day use.
  • The same n-way zone-intersection failures that pairwise checks miss will matter more as multi-agent teams and cross-server tool protocols become common.
  • Incomplete resource classification catalogs create Phase 2 false negatives even when Phase 1 policies are perfect, so labeling accuracy becomes a first-order operational risk.
  • The reported block rates are catalog-dependent; a different distribution of tools across classification levels would change the utility cost without changing the structural guarantee.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper proposes DSCC, a two-phase architecture for compositional security of multi-tool LLM agent chains. Phase 1 applies a Most Restrictive Set (MRS) algorithm at session checkout that merges per-tool six-tuple policies (NIST control bindings, classification, prohibition, flow direction, zones, TTL) into a single effective control set via max/min/intersection operators, with a formal monotonicity invariant that chain extension can only tighten constraints. Two modes are defined: clearance (default), which rejects cross-classification chains, and taint, which admits mixed-classification chains while preserving an exfiltration boundary. Phase 2 maintains a monotonic session taint state over resource classifications at runtime and revokes the session before outbound calls that would violate accumulated constraints. A .NET 9 reference implementation over 32 tools and 16 NIST SP 800-53-aligned policies reports block rates of 79.2%/95.5% (pairs/triples) in clearance mode and 42.5%/60.5% in taint mode, plus three illustrative Phase 2 walkthroughs. Governance implications for policy lifecycle and frontier-risk mitigation are discussed.

Significance. The compositional authorization gap for multi-tool agents is real and timely: the paper correctly situates the problem against STAC, ChainFuzzer, and MCP threat work, and the MRS design is a coherent systems response. Strengths include a clean policy model (Definition 1), an explicit four-step composition procedure with attributed rejections, a well-stated monotonicity invariant (Invariant 1) that follows from the operators, dual composition modes that make the utility-security tradeoff operational, and a fully specified reference catalog (Appendix Tables 6–8) that makes Phase 1 enumeration reproducible. If the architecture can be shown to block realistic multi-tool violations under production-like policy distributions and resource catalogs, it would be a useful control-layer complement to capability evaluations. The contribution is primarily architectural and definitional rather than empirical; its significance therefore hinges on whether the evaluation is reframed and strengthened to match the defense-in-depth claim.

major comments (4)
  1. §4.3, Table 5, Figure 2: The headline block rates (79.2%/95.5% clearance; 42.5%/60.5% taint) are presented as evaluation of DSCC’s security effectiveness, but as the paper itself states, they are “a function of how policies are distributed across levels in this catalog, not an intrinsic property of the algorithm.” Under clearance, 95.8% of blocked pairs fail solely on the high-water-mark clearance check. The numbers therefore characterize the authors’ hand-built 16-policy distribution, not the operators. Either reframe Table 5 as a catalog characterization (not a security efficacy result), or evaluate under multiple realistic policy distributions (e.g., production coding-agent tool mixes, MCP server catalogs) and report sensitivity of block rates to classification-level occupancy.
  2. §4.4, Figure 3: Phase 2 is load-bearing for the “defense in depth” claim in the abstract and §1, yet it is supported only by three hand-chosen walkthroughs. There is no enumeration, no attack-corpus evaluation, and no measurement of false-positive/false-negative revocation under realistic resource-label noise. Given that the introduction cites STAC (>90% ASR via multi-turn tool chains) and ChainFuzzer (82.7% of vulnerabilities multi-tool), Phase 2 should be evaluated against at least one of these corpora or an equivalent multi-tool attack suite, with reported detection and over-revocation rates. Without that, the runtime half of the architecture remains unvalidated.
  3. §2.1 Definition 1 and §3 (resource classification): Both phases assume that every tool carries a correct six-tuple policy and every accessed resource has an accurate classification/prohibition label at access time. This is the load-bearing operational assumption, but the manuscript never stress-tests mislabeled tools, incomplete catalogs, or adversarial policy under-declaration. A short sensitivity analysis (e.g., fraction of chains that become incorrectly permitted under random under-classification of k tools, or under missing prohibition flags) would bound how much the security guarantees degrade when the axiom fails—which is the realistic deployment case.
  4. §2.2–2.3: Monotonicity (Invariant 1) is stated and follows by construction from max/min/intersection, but there is no formal security theorem connecting MRS + taint to a non-interference or information-flow property (e.g., “no session that reaches an outbound tool can have touched data with ϕ=1 or C≥Confidential”). The Bell–LaPadula analogy is mentioned but not carried through. A short theorem (even informal) stating what is and is not guaranteed—especially the difference between clearance and taint modes—would make the central claim precise and falsifiable rather than architectural description alone.
minor comments (6)
  1. Abstract and §1: “Outputs of any tool call propagate their classification constraints into a session-level taint state” is described as part of Phase 1 in the abstract, but §3 places taint updates in Phase 2. Align the phase boundary wording.
  2. Table 5 note: Tool-level pairs are directed (32×31) while operators are commutative; reporting undirected tool pairs would avoid double-counting and match the policy-level presentation.
  3. §2.2 Step 3: The classification boundary rule (reject if Ceff≥Confidential and chain contains outbound tools) is stated in prose and in Table 3, but is not numbered as an equation alongside (2)–(4); numbering it would aid citation.
  4. Figure 1: The right-hand “enforcement checks (§3)” box is underspecified relative to the three guards listed in §3; labeling the three guards on the figure would improve readability.
  5. §5.3: Frontier-governance citations [19–22] are useful, but the claim that DSCC is “orthogonal” to capability evaluations would benefit from one concrete example of a capability that MRS cannot bound (e.g., within-cluster lateral movement among Confidential tools).
  6. Typos: “defaultclearancemode” / “taintmode” spacing in abstract; “session session” in §1; “ccessed” in [21]; “Int.+Out” legend in Figure 2 is unexplained in the caption.

Circularity Check

0 steps flagged

No significant circularity: MRS operators, monotonicity, and catalog block rates are explicit systems design and enumeration, not fitted or self-referential predictions.

full rationale

DSCC’s load-bearing chain is definitional and algorithmic, not an empirical derivation that collapses into its inputs. Definition 1 fixes a six-tuple policy model; §2.2 defines composition via max on restriction/classification/prohibition, intersection on zones, and min on TTL; Invariant 1 then states the immediate consequence that chain extension can only tighten those quantities. That is a formal property of the chosen operators (analogous to lattice join/meet), not a claim that something independent was predicted from data. Phase 2 reuses the same max operators on resource labels (Eq. 5) and three outbound/taint guards—again by design, not by fit. The reported 79.2%/95.5% (clearance) and 42.5%/60.5% (taint) figures are exhaustive enumeration over a hand-authored 16-policy/32-tool catalog (§4.2–4.3, Table 5); the paper itself notes they depend on classification distribution, not on free parameters tuned to a target rate. There are no self-citations of prior author uniqueness theorems, no ansatz smuggled from overlapping work, and no renaming of an external empirical law as a new prediction. Residual concerns (synthetic catalog, three hand-picked Phase-2 scenarios) are evaluation/generalization limits, not circular reductions of a claimed first-principles result. Score 0 is therefore the correct finding.

Axiom & Free-Parameter Ledger

4 free parameters · 6 axioms · 4 invented entities

This is a systems/security architecture paper. Load-bearing content is the policy model, composition operators, and the assumption that tools and resources are accurately labeled. There is no empirical curve-fitting; free parameters are design choices (mode, catalog, defaults). Invented entities are the named architecture pieces. Background axioms are standard lattice/taint operators and NIST control vocabulary.

free parameters (4)
  • composition_mode (Clearance vs Taint)
    Deployment-time switch that gates the clearance check and drives the large difference between 79.2%/95.5% and 42.5%/60.5% block rates; not fitted to external data but chosen by operators.
  • policy_catalog_distribution (16 policies across 4 classification levels)
    Authors construct how many policies sit at Public/Internal/Confidential/Restricted; paper states observed block rates are a function of this distribution, not an intrinsic algorithm constant.
  • default_session_TTL (48h) and per-policy TTLs
    Hand-set lifetimes in Table 7 that determine τeff = min_i τi; design knobs, not measurements.
  • classification_boundary_threshold (Confidential+)
    Hard rule that Ceff ≥ Confidential plus outbound tools is rejected even without ϕ=1; a policy floor chosen by the authors.
axioms (6)
  • domain assumption Restriction and classification levels form total orders so max is well-defined (Allow<Restrict<Deny; Public<Internal<Confidential<Restricted).
    Required for Leff and Ceff in §2.1–2.2; standard MAC lattice assumption adapted from Bell–LaPadula.
  • domain assumption Composition operators max, min, Boolean OR, and set intersection are the correct semantics for merging multi-tool security constraints.
    Core of MRS Steps 2–3; encodes ‘most restrictive wins’ rather than majority or least restrictive.
  • domain assumption NIST SP 800-53 control identifiers (AC-3/4/6, SC-7/8/13/28, AU-2/6, SI-4, MP-5) are an adequate shared vocabulary for tool policies.
    Used throughout the reference implementation and evaluation catalog (§4.1, Appendix Table 6).
  • domain assumption An agent is an untrusted stochastic caller whose tool sequence cannot be predicted at session checkout.
    Threat model stated in Introduction; justifies both static composition of the full requested set and runtime taint.
  • standard math Monotonicity of max/min/intersection implies Invariant 1: extending a chain never relaxes the effective control set.
    §2.3; elementary order theory, not machine-checked.
  • ad hoc to paper Resource classification catalogs exist and can be resolved accurately at access time for every resource the agent touches.
    Phase 2 premise in §3; without it runtime taint cannot work as specified.
invented entities (4)
  • Dynamic Security Control Compositor (DSCC) no independent evidence
    purpose: Name the two-phase architecture combining static MRS composition and runtime taint revocation for agent tool chains.
    Architectural packaging of known MAC/taint ideas for the agent setting; no independent physical evidence required.
  • Most Restrictive Set (MRS) algorithm no independent evidence
    purpose: Compose n tool policies into one effective control set or an attributed rejection.
    Central algorithmic contribution; falsifiable only via reimplementation on the published catalog.
  • Session taint state S=(Cs, ϕs) no independent evidence
    purpose: Monotonic high-water mark of classification and sticky external-transmission prohibition during runtime.
    Standard taint record specialized to the paper’s policy model; independent of external measurement.
  • Effective Control Set E no independent evidence
    purpose: Single session-governing policy artifact produced by MRS for audit and enforcement.
    Output type of the composition algorithm; definitional.

pith-pipeline@v1.1.0-grok45 · 21364 in / 3990 out tokens · 34635 ms · 2026-07-12T02:34:54.737176+00:00 · methodology

0 comments
read the original abstract

Modern AI agent implementations such as frontier coding agents chain multiple tools at runtime that create a security surface that per-tool guardrails are unable to address, as individually permitted tools can violate organizational policies when composed. We propose the Dynamic Security Control Compositor (DSCC), a two-phase approach to compositional security for multi-tool agent chains. In Phase 1, at session checkout, a Most Restrictive Set (MRS) algorithm composes per-tool security policies into a single effective policy with a formal monotonicity invariant that extending a chain can only tighten the result, blocking incompatible combinations before any tool executes. Outputs of any tool call propagate their classification constraints into a session-level taint state, so subsequent invocations must satisfy the most restrictive constraints seen so far. In Phase 2, at runtime, the system tracks the sensitivity of data the agent touches through a monotonic taint state and revokes the session if the accumulated exposure would make a subsequent tool call a policy violation. Together, these phases provide defense in depth, where static composition prevents unsafe chains from starting, and runtime taint tracking catches violations that emerge from the specific data used. We provide a reference implementation on 32 tools governed by 16 NIST SP 800-53 aligned policies and evaluate it under two composition modes. In the default clearance mode, permitted combinations are partitioned into classification-level clusters, blocking 79.2% of policy pairs and 95.5% of triples. The alternative taint mode admits mixed-classification chains within the exfiltration boundary, blocking 42.5% and 60.5% respectively. We discuss the governance implications for organizations deploying multi-tool agents, including the utility-security tradeoff and the changes needed to operationalize chain-aware policies.

Figures

Figures reproduced from arXiv: 2607.03423 by Ben Bariach, Chris Schneider, Kriti Faujdar, Philipp Schoenegger.

Figure 1
Figure 1. Figure 1: DSCC architecture overview. Phase 1 (left) uses the MRS composition engine, operating in one of two modes [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Phase 1 composition under both modes (clearance and taint). [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Phase 2 (runtime enforcement): These three illustrative scenarios show how the session taint state evolves during [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

29 extracted references · 6 linked inside Pith

  1. [1]

    Toolformer: Language models can teach themselves to use tools

    Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. arXiv preprint arXiv:2302.04761, 2023

    Pith/arXiv arXiv 2023

  2. [2]

    Re- act: Synergizing reasoning and acting in language models

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. Re- act: Synergizing reasoning and acting in language models. InProceedings of the International Confer- ence on Learning Representations (ICLR), 2023

    2023

  3. [3]

    Patil, Tianjun Zhang, Xin Wang, and Joseph E

    Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez. Gorilla: Large language model connected with massive apis.arXiv preprint arXiv:2305.15334, 2023

    Pith/arXiv arXiv 2023

  4. [4]

    Toolllm: Fa- cilitating large language models to master 16000+ real-world apis.arXiv preprint arXiv:2307.16789, 2023

    Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. Toolllm: Fa- cilitating large language models to master 16000+ real-world apis.arXiv preprint arXiv:2307.16789, 2023

    Pith/arXiv arXiv 2023

  5. [5]

    Github Copilot coding agent, 2025

    GitHub. Github Copilot coding agent, 2025. URL https://github.com/features/copilot/agen ts. Agentic coding agent. Accessed 2026-04-09

    2025

  6. [6]

    Claude code, 2025

    Anthropic. Claude code, 2025. URLhttps://do cs.anthropic.com/en/docs/claude-code/over view. Agentic coding tool. Accessed 2025-03-24

    2025

  7. [7]

    Codex CLI, 2025

    OpenAI. Codex CLI, 2025. URLhttps://openai .com/codex/. Open-source coding agent. Accessed 2025-03-24

    2025

  8. [8]

    STAC:Wheninnocenttools form dangerous chains to jailbreak LLM agents

    Jing-Jing Li, Jianfeng He, Chao Shang, Devang Kul- shreshtha, Xun Xian, Yi Zhang, Hang Su, Sandesh Swamy, andYanjunQi. STAC:Wheninnocenttools form dangerous chains to jailbreak LLM agents. arXiv preprint arXiv:2509.25624, 2025

    arXiv 2025

  9. [9]

    ChainFuzzer: Greybox fuzzing for workflow- levelmulti-toolvulnerabilitiesinLLMagents.arXiv preprint arXiv:2603.12614, 2026

    Jiangrong Wu, Zitong Yao, Yuhong Nan, and Zibin Zheng. ChainFuzzer: Greybox fuzzing for workflow- levelmulti-toolvulnerabilitiesinLLMagents.arXiv preprint arXiv:2603.12614, 2026

    arXiv 2026

  10. [10]

    MSA: A cross-MCP privacy attack via memory exfiltration of large language models

    Yiheng Sun, Linkang Du, Zhou Su, Yuntao Wang, Han Liu, Quan Zhao, and Xiaolin Niu. MSA: A cross-MCP privacy attack via memory exfiltration of large language models. InProceedings of the 24th Workshop on Privacy in the Electronic Society (WPES), 2025. Co-located with ACM CCS 2025. DOI: 10.1145/3733802.3764057

    doi:10.1145/3733802.3764057 2025

  11. [11]

    Silent egress: When implicit prompt injection makes LLM agents leak without a trace.arXiv preprint arXiv:2602.22450, 2026

    Qianlong Lan, Anuj Kaul, Shaun Jones, and Stephanie Westrum. Silent egress: When implicit prompt injection makes LLM agents leak without a trace.arXiv preprint arXiv:2602.22450, 2026

    arXiv 2026

  12. [12]

    MCP-ITP: An automated framework for implicit tool poisoning in MCP.arXiv preprint arXiv:2601.07395, 2026

    Ruiqi Li, Zhiqiang Wang, Yunhao Yao, and Xiang- Yang Li. MCP-ITP: An automated framework for implicit tool poisoning in MCP.arXiv preprint arXiv:2601.07395, 2026

    arXiv 2026

  13. [13]

    Model context protocol threat modeling and analyzing vulnerabilities to prompt injection with tool poisoning.arXiv preprint arXiv:2603.22489, 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.arXiv preprint arXiv:2603.22489, 2026

    arXiv 2026

  14. [14]

    MCP security bench (MSB): Benchmarking attacks against model context protocol in LLM agents.arXiv preprint arXiv:2510.15994, 2025

    Dongsen Zhang, Zekun Li, Xu Luo, Xuannan Liu, Peipei Li, and Wenjun Xu. MCP security bench (MSB): Benchmarking attacks against model context protocol in LLM agents.arXiv preprint arXiv:2510.15994, 2025. Accepted at ICLR 2026

    arXiv 2025

  15. [15]

    Function calling and other API updates,

    OpenAI. Function calling and other API updates,

  16. [16]

    Blog post, 13 June 2023

    URL https://openai.com/blog/functi on-calling-and-other-api-updates. Blog post, 13 June 2023. Accessed 2026-03-25

    2023

  17. [17]

    LangChain, 2022

    Harrison Chase. LangChain, 2022. URL https: //github.com/langchain-ai/langchain. Open- source LLM application framework. Accessed 2026- 03-25

    2022

  18. [18]

    White, Doug Burger, and Chi Wang

    Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yi- ran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xi- aoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Awadallah, Ryen W. White, Doug Burger, and Chi Wang. Autogen: Enabling next-gen llm applica- tions via multi-agent conversation.arXiv preprint arXiv:2308.08155, 2023

    Pith/arXiv arXiv 2023

  19. [19]

    LaPadula

    David Elliott Bell and Leonard J. LaPadula. Se- cure computer systems: Mathematical foundations. Technical Report MTR-2547, Vol. I, MITRE Cor- poration, 1973. ESD-TR-73-278-I

    1973

  20. [20]

    Microsoft frontier governance framework,

    Microsoft. Microsoft frontier governance framework,

  21. [21]

    Accessed 2026-06-26

    URL https://cdn-dynmedia-1.microsoft .com/is/content/microsoftcorp/microsoft/ final/en-us/microsoft-brand/documents/Mic rosoft-Frontier-Governance-Framework.pdf . Accessed 2026-06-26

    2026

  22. [22]

    Frontier safety framework, ver- sion 3.0, 2025

    Google DeepMind. Frontier safety framework, ver- sion 3.0, 2025. URL https://storage.google apis.com/deepmind-media/DeepMind.com/Blog /strengthening-our-frontier-safety-frame work/frontier-safety-framework_3.pdf . Ac- cessed 2026-06-26

    2025

  23. [23]

    Responsible scaling policy, 2025

    Anthropic. Responsible scaling policy, 2025. URL https://www.anthropic.com/responsible-sca ling-policy. ccessed 2026-06-26

    2025

  24. [24]

    Preparedness framework, version 2, 2025

    OpenAI. Preparedness framework, version 2, 2025. URL https://cdn.openai.com/pdf/18a02b5d-6 b67-4cec-ab64-68cdfbddebcd/preparedness-f ramework-v2.pdf. Accessed 2026-06-26

    2025

  25. [25]

    Regulation (EU) 2024/1689 of the euro- pean parliament and of the council laying down harmonised rules on artificial intelligence (Arti- ficial Intelligence Act)

    European Parliament and Council of the European Union. Regulation (EU) 2024/1689 of the euro- pean parliament and of the council laying down harmonised rules on artificial intelligence (Arti- ficial Intelligence Act). Official Journal of the 11 European Union, L series, 2024. URL https: //eur-lex.europa.eu/eli/reg/2024/1689/oj . (Arts. 51–55). Accessed 2026-06-26

    2024

  26. [26]

    Managing misuse risk for dual-use foundation mod- els

    National Institute of Standards and Technology. Managing misuse risk for dual-use foundation mod- els. Technical Report NIST AI 800-1 (Initial Public Draft), NIST, 2024. URL https://nvlpubs.ni st.gov/nistpubs/ai/NIST.AI.800-1.ipd.pdf . Accessed 2026-06-26

    2024

  27. [27]

    International AI safety report 2026

    Yoshua Bengio, Stephen Clare, Carina Prunkl, et al. International AI safety report 2026. Techni- cal Report DSIT 2026/001, Department for Sci- ence, Innovation and Technology, 2026. URL https://internationalaisafetyreport.org

    2026

  28. [29]

    URL https://arxiv.org/abs/2305.15324

    Pith/arXiv arXiv

  29. [30]

    Lin, Hjalmar Wijk, Joel Burget, Aaron Ho, Elizabeth Barnes, and Paul Christiano

    Megan Kinniment, Lucas Jun Koba Sato, Haox- ing Du, Brian Goodrich, Max Hasin, Lawrence Chan, Luke Harold Miles, Tao R. Lin, Hjalmar Wijk, Joel Burget, Aaron Ho, Elizabeth Barnes, and Paul Christiano. Evaluating language-model agentsonrealisticautonomoustasks.arXiv preprint arXiv:2312.11671, 2024. URLhttps://arxiv.or g/abs/2312.11671. 12 Appendix This app...

    Pith/arXiv arXiv 2024