CD Consulting R&D

KB-AI · Entry 7 · Published 2026-10-24 · Version 1

Who holds the reins? A comparative inventory of LLM agent harnesses in October 2026

A comparative inventory of 73 control components for LLM agents from ten families (OpenAI, Anthropic, Google, Microsoft, Meta, AWS, NVIDIA, Mistral, open-weight models, open source and standards), on one grid: six types of control, the place of the human, traceability, testing, portability, and seven lessons for a company that deploys agents.

If you are about to let an AI agent act on your systems — read files, run commands, call APIs, send messages — and need to know which controls exist, which are on by default and which you will have to build, this is what the market offered in October 2026, where the vendors converge, and the gaps that none of them closes.

Method: desk research on 21 October 2026 across public documentation, repositories and papers; about 250 pages consulted; 78 sources typed and dated; limits declared in section 10. Nothing was installed or executed.

Contents

  1. 1. The inventory on one page
  2. 2. What counts as a harness, and how the survey was done
  3. 3. Six types of control: who does what
  4. 4. Family by family
  5. 5. The human in the loop: an exception by design
  6. 6. Traceability: a common format, no evidence-grade log
  7. 7. Testing: benchmarks, dry runs and a missing bench
  8. 8. Portability and maturity
  9. 9. What this means for a company that deploys agents
  10. 10. Limits of this inventory
  11. 11. Sources

1. The inventory on one page

The survey covers 73 systems or documents in ten families, after merging duplicates (several tools, such as Meta's LlamaFirewall or NVIDIA's NeMo Guardrails, appear in two families).

Six findings stand out.

  1. Six types of control recur everywhere: behaviour specifications inside the model; input and output guardrails (mostly probabilistic classifiers); permissions and execution hooks (allow, ask or deny rules, approvals, sandboxes); governance of tools and connectors (protocols, gateways, policy engines); traceability (OpenTelemetry almost everywhere); test benches.
  2. The large vendors stack three tiers: the model (trained dispositions), the platform (filters, identity, policy) and the client or SDK (permissions, hooks, approvals). Open-weight models come with a classifier and, since 2025-2026, a command-line agent; infrastructure control is left to whoever deploys them.
  3. Human approval before an action exists in some fifteen systems, always per call or per tool, always opt-in, usually off by default. The 2026 trend is to replace it with a second model that reviews the action, or with a policy engine that sits outside the agent's code.
  4. "Data are not orders" — the principle that a document or a tool result must not be obeyed as an instruction — is handled in four ways: the model's disposition, detection, confinement of effects and, rarely, structural separation. The last is the only robust one and is still experimental. A separate entry will go into this.
  5. No system read documents a signed, timestamped and exportable log of human decisions. The closest are event logs that record who allowed an action (the user, a configuration rule, a hook, a classifier) without signing them.
  6. The field moves in weeks. Between 2025 and October 2026, at least six components surveyed were archived, replaced or abandoned. Any inventory, this one included, has a short shelf life.

2. What counts as a harness, and how the survey was done

Definition. A harness is any device placed between a human, a model and the model's actions to bound what the agent reads, decides, executes and writes. Principles without an implementation, and closed products without verifiable documentation, were left out.

Ten families. OpenAI; Anthropic; Google; Microsoft; Meta; Amazon Web Services; NVIDIA; Mistral; open-weight and small models (Qwen, DeepSeek, Kimi, Gemma, Granite and the tools commonly used with them: Ollama, vLLM, LiteLLM, Goose, Cline, Aider, OpenHands); and a transversal family (open-source libraries, academic benchmarks, standards).

One grid. Each system was described on the same axes: type of control; where it sits (model, platform, client, third-party library, document); place of the human (approval before action: yes, no, opt-in, at what granularity); treatment of instructions hidden in data; traceability; testability; portability (across models, channels and vendors, and the format of the rules); key limit.

Method. Ten desk-research passes, one per family, ran in parallel on 21 October 2026 and read public documentation, repositories and papers only; nothing was installed or executed. Roughly 250 pages were consulted. They were read through an automated summarising tool rather than as raw text: figures (versions, star counts, rates) are those reported on that day and should be checked at the source before being quoted. Section 10 lists what could not be verified.

3. Six types of control: who does what

TypeRepresentative systemsWhat it does wellWhat it does not do
Behaviour specification inside the modelOpenAI Model Spec [S1], Anthropic's constitution for Claude [S9], Llama acceptable use policy, Microsoft Responsible AI Standardstates the chain of command, the role of human oversight, the status of tool output; texts often public and reusableobedience is probabilistic; cannot be verified from outside; the effect does not carry over to another model
Input and output guardrailAzure Prompt Shields [S25], Google Model Armor [S21], Bedrock Guardrails [S36], Llama Guard 4 [S35], Prompt Guard 2 [S34], Qwen3Guard [S52], Granite Guardian [S58], NeMo Guardrails [S44], Mistral moderation [S48]classifies content; publishes metrics; offers dry-run modes (inspect only, detect without blocking)detects without bounding; mostly tuned for English; documented blind spots (one major filter does not evaluate tool results; another checks input only)
Permissions and execution hooksClaude Code permissions, hooks and sandbox [S10] [S11] [S12] [S13], OpenAI Codex [S7], Gemini CLI policy engine [S22], OpenAI Agents SDK approvals [S5], Microsoft Agent Framework approvals [S26], Bedrock Agents confirmation [S37], Strands interrupts [S41], LangGraph human-in-the-loop [S69], Goose [S56], OpenHands [S55]approval per call or per tool; allow / ask / deny rules with deny taking precedence; serialisable state; operating-system sandboxesopt-in, often off by default; "always allow" remembered by tool name, not by instance; can be bypassed by whoever controls the client
Governance of tools and connectorsModel Context Protocol and its OAuth 2.1 authorisation [S16], Agent2Agent [S23], AgentCore Gateway and Policy in Cedar [S38] [S40], Microsoft Agent Governance Toolkit [S29], Invariant [S67], MCP scanning [S68], LiteLLM [S59], NVIDIA OpenShell [S47]control placed outside the agent's code; agent identity; deny by default; formal policy languages; supply-chain scanning of connectorsthe protocol leaves consent to the host application ("cannot enforce"); the strongest engines are tied to one cloud
Traceability and auditClaude Code OpenTelemetry events [S15], Agents SDK tracing [S6], AgentCore Observability, Microsoft Agent Hooks records [S28], Mistral audit logs [S51]OpenTelemetry as a near-universal format; timestamps, tool-call identifiers, source of the decisionno signed log of human decisions; content either redacted or sent to the vendor by default; exports missing or reserved to enterprise editions
Test benchAgentDojo [S61], InjecAgent [S62], AgentHarm [S63], τ-bench [S64], CyberSecEval [S76], garak [S46], PyRIT [S30], OpenAI IH-Challenge [S3]replayable, model-independent, with metrics (attack success rate, pass^k)vendor benches measure the vendor's own product; LLM-as-judge scoring; few independent replications

4. Family by family

FamilyWhat it offersWhat is distinctiveKey limit (as documented)
OpenAIModel Spec with an instruction hierarchy [S1] [S2]; Agents SDK with guardrails, approvals, handoffs, tracing [S4] [S5] [S6]; Codex CLI sandbox and approval modes [S7]; Guardrails library in preview [S8]the Model Spec changelog states that tool output carries no authority of its own unless delegated [S2]; the IH-Challenge data set is public [S3]SDK guardrails apply to the first and last agent only, not to handoffs or hosted tools [S4]; tracing includes sensitive data by default [S6]
Anthropicconstitution [S9]; Claude Code permission modes, rules, hooks [S10] [S11] [S12]; open-source sandbox runtime [S13] [S14]; MCP [S16]; injection classifiers [S17]; OpenTelemetry events [S15]the sandbox runtime is reusable outside its original tool [S14]; telemetry records the source of each permission decision (user, configuration, hook, classifier) [S15]; the documentation consulted describes a classifier-based "auto" mode as the default; its public Agentic Misalignment bench found that system instructions reduce harmful agent behaviour without eliminating it (from 96 % to 37 % in one scenario) [S18]a boundary stated in conversation is not a stored rule and can be lost when the context is compacted [S11]; "no browsing agent is immune" to injection [S17]
GoogleAgent Development Kit with callbacks, plugins, tool confirmation, evaluation [S19] [S20]; Model Armor [S21]; Gemini CLI with a TOML policy engine [S22]; A2A protocol [S23]; CaMeL research prototype [S24]the richest rule language of the client tools (tiers from default to administrator) [S22]; CaMeL, the most cited structural defence [S24]tool confirmation is experimental [S19]; Model Armor does not decode Base64 and ignores very short inputs [S21]
MicrosoftPrompt Shields with a separate documents field [S25]; Agent Framework approvals and the experimental FIDES information-flow control [S26] [S27]; Agent Hooks contract [S28]; Agent Governance Toolkit [S29]; PyRIT [S30]FIDES labels data by integrity and confidentiality and hides untrusted results behind variables [S27]; the governance toolkit accepts YAML, Rego and Cedar and plugs into several coding agents [S29]; GitHub's Copilot coding agent can neither approve nor merge its own work, and workflow runs wait for a human [S31]no tool requires approval by default [S26]; the toolkit runs in the same process boundary as the agent it governs [S29]
MetaLlamaFirewall (Prompt Guard 2 plus AlignmentCheck) [S32]; Llama Guard 4 [S35]; CodeShield; CyberSecEval [S33] [S76]AlignmentCheck tests whether an action still serves the user's goal [S32]; CyberSecEval is replayable across vendors, under MIT licence [S76]no human approval mechanism in the documentation read; AlignmentCheck needs a large auxiliary model and can itself be injected [S32]
Amazon Web ServicesBedrock Guardrails [S36]; Bedrock Agents user confirmation [S37]; AgentCore Policy in Cedar, generally available since March 2026 [S38] [S39] [S40]; Strands Agents SDK [S41]; Kiro [S42]; Agentic AI Security Scoping Matrix [S43]the most complete policy engine outside the agent's code: deny by default, decisions on identity and parameters, a log-only mode before enforcement, time-bound approvals [S38] [S39]the prompt-attack filter does not evaluate tool results [S36]; without confirmation, "the agent may follow instructions" found in an API response [S37]; Kiro: supervised mode "is not a security control" [S42]
NVIDIANeMo Guardrails with Colang rails, including tool-call rails [S44] [S45]; NemoGuard models; garak [S46]; OpenShell kernel-level sandbox [S47]OpenShell asks for human approval of policy changes proposed by the agent and keeps secrets out of the agent's reach [S47]tool-call rails validate structure, not meaning, and do not address indirect injection [S45]; an agentic safety recipe has been unmaintained since April 2026
Mistralmoderation API and declarative guardrails [S48]; requires_confirmation on connector tools [S49]; Vibe command-line agent [S50]; enterprise audit logs [S51]per-call approval with serialisable state on connectors [S49]; Vibe can forbid the "approve everything" mode by configuration [S50]guardrails check input only [S48]; audit logs have no export [S51]
Open-weight and small modelsQwen3Guard [S52]; Qwen Code approval modes [S53]; DeepSeek's harness and its independent evaluation [S54]; OpenHands [S55]; Goose [S56] [S57]; Granite Guardian [S58]; LiteLLM [S59]; vLLM, Ollamathe only independent evaluation of a vendor's open harness found: up to 25.5 % attack success, with recommendations on provenance labelling [S54]; Granite Guardian is the only classifier aimed at the validity of tool calls [S58]OpenHands lets the model rate its own risk [S55]; Goose's default is autonomous and its reviewer "fails open" [S56] [S57]; serving layers ship with little or no authentication by default [S60]
TransversalAgentDojo, InjecAgent, AgentHarm, τ-bench [S61] [S62] [S63] [S64]; Dual LLM and design patterns [S65] [S66]; Invariant and MCP scanning [S67] [S68]; LangGraph human-in-the-loop [S69]; OPA [S78]; E2B [S77]; OWASP, NIST, ISO, CSA [S71] [S72] [S73] [S74] [S75]AgentDojo is the common yardstick of the field [S61]; τ-bench's pass^k shows that policy compliance degrades when the same task is repeated [S64]; LangGraph lets a human approve, edit or reject a call and resumes durably [S69]LLM Guard has been archived, a textbook case of obsolescence [S70]; standards give checklists, not tests [S71] [S72] [S73]

5. The human in the loop: an exception by design

Approval mechanisms are documented in about fifteen systems: the OpenAI Agents SDK and Codex, Claude Code, Gemini CLI, Google's ADK, Microsoft Agent Framework and Agent Hooks, Bedrock Agents and AgentCore Policy, Strands, Kiro, Mistral connectors and Vibe, Qwen Code, Goose, Cline, OpenHands, LangGraph, NVIDIA OpenShell [S5] [S7] [S11] [S19] [S22] [S26] [S37] [S39] [S41] [S47] [S49] [S53] [S55] [S56] [S69].

Four constants come out of the comparison.

The 2026 trend is to make the human the exception. Several tools now route approvals to a second model by default or on request (a classifier in Claude Code's auto mode, Codex's automatic review, Qwen Code's Auto mode, Goose's Adversary Mode, which fails open) [S7] [S11] [S53] [S57], or let the model assess its own risk (OpenHands) [S55]. The vendors are candid about the limits: Kiro states that its supervised mode "is not a security control" [S42]; Anthropic warns that a limit given in conversation is not a rule [S11].

The other path is to move control outside the agent: a policy engine at a gateway (AgentCore Policy, deny by default, with a log-only mode to rehearse rules before enforcing them) [S38] [S39], a kernel-level sandbox whose policy changes need a human's approval (OpenShell) [S47], or a governance toolkit with formal policy languages (Microsoft AGT) [S29].

6. Traceability: a common format, no evidence-grade log

OpenTelemetry is the common denominator: Claude Code, Codex, the OpenAI Agents SDK, ADK, A2A, AgentCore, NeMo Guardrails, Microsoft Agent Framework all emit, or can emit, OpenTelemetry traces [S6] [S7] [S15] [S23] [S44].

The most useful field for a governance audit is the one Claude Code attaches to each permission decision: its source, among configuration, hook, permanent or temporary user approval, user rejection or abort, and classifier [S15]. It answers the auditor's first question: who, or what, let this action through?

Three gaps remain everywhere.

7. Testing: benchmarks, dry runs and a missing bench

Replayable public benches exist and are model-independent: AgentDojo [S61], InjecAgent [S62], AgentHarm [S63] (which tests malicious requests, not injection), τ-bench [S64], CyberSecEval [S76], garak [S46], PyRIT [S30], OpenAI's IH-Challenge [S3]. Vendor evaluation kits (ADK [S20], Strands, AgentCore) mostly rely on a model as judge.

Dry runs are now standard and are the most practical tool for a company: log-only before enforce (AgentCore Policy) [S38], inspect-only (Model Armor) [S21], detect without blocking (Bedrock Guardrails) [S36], evaluate-only (Agent Hooks) [S28], dry run (FIDES) [S27].

What no bench measures: an agent's fidelity to a written set of instructions in natural language, such as a company's operating rules. τ-bench comes closest, with domain policies and its pass^k metric, which shows compliance falling as the same task is repeated (from 0.46 to 0.225 in the published results) [S64].

8. Portability and maturity

Rule formats fall into four groups: natural language (specifications, rule files, reviewer prompts); configuration (JSON permission rules, TOML in Gemini CLI and Mistral Vibe, YAML in Kiro); formal policy languages (Cedar, Rego, Colang, Invariant's rules) [S40] [S78] [S44] [S67]; and code (SDK callbacks and hooks).

Vendor-independent components are numerous: MCP and A2A as protocols [S16] [S23]; the Anthropic sandbox runtime [S14]; OpenShell [S47]; E2B [S77]; Microsoft's governance toolkit [S29]; Invariant [S67]; LiteLLM [S59]; LangGraph [S69]; the public benches and open classifiers. Cloud-bound components are the platform guardrails and policy engines (Model Armor, Bedrock and AgentCore, Foundry and Entra identity, Mistral's platform).

Maturity is low and turnover high. Within the period covered: AutoGen archived, Semantic Kernel replaced by Agent Framework, LLM Guard archived [S70], Gemini CLI partly superseded, an NVIDIA agentic safety recipe left unmaintained since April 2026, Guardrails AI ending its hosted inference, τ-bench frozen in favour of a successor. Many components are alpha, 0.x or preview (OpenShell, NemoClaw, the Microsoft governance toolkit, Agent Hooks, FIDES, ADK tool confirmation, OpenAI Guardrails).

9. What this means for a company that deploys agents

  1. Assume nothing is on by default. Approvals, sandboxes and audit content are opt-in in most tools. List, for each agent, which controls are actually enabled, and size them to the agent's degree of autonomy (the AWS scoping matrix offers four levels, from no agency to full agency, with controls per level) [S43].
  2. Put the decisive control outside the agent. A rule the agent's own process enforces can be bypassed by whoever controls that process. Gateways with deny-by-default policies, kernel-level sandboxes and separate policy engines hold better than client-side settings.
  3. Approve business effects, not tool calls. Since no tool offers approval at the level of a business decision, design it: route the few actions that commit the company (payments, external messages, deletions, publications) through a confirmation that names the effect.
  4. Treat "always allow" as a standing authorisation. Review persistent approvals like access rights; prefer approvals tied to an instance and an expiry (AgentCore's time-bound policies show it can be done) [S39].
  5. Keep your own decision log. Use OpenTelemetry, keep the source of every permission decision, and add what the vendors do not: timestamps you control, an export, and, where it matters, a signature.
  6. Rehearse before enforcing. Use log-only and inspect-only modes to see what a rule would block before it blocks, and replay a public bench (AgentDojo, garak, PyRIT) on your own configuration, not the vendor's.
  7. Date your inventory. Components appear, change defaults and disappear within months. Re-check versions and defaults at each upgrade.

10. Limits of this inventory

11. Sources

All sources consulted on 21 October 2026.

  1. S1 Vendor documentation. OpenAI, "Model Spec". https://model-spec.openai.com/
  2. S2 Vendor repository. OpenAI, Model Spec changelog. https://github.com/openai/model_spec/blob/main/CHANGELOG.md
  3. S3 Vendor research. OpenAI, "Instruction Hierarchy Challenge". https://openai.com/index/instruction-hierarchy-challenge
  4. S4 Vendor documentation. OpenAI Agents SDK, "Guardrails". https://openai.github.io/openai-agents-python/guardrails/
  5. S5 Vendor documentation. OpenAI Agents SDK, "Human in the loop". https://openai.github.io/openai-agents-python/human_in_the_loop/
  6. S6 Vendor documentation. OpenAI Agents SDK, "Tracing". https://openai.github.io/openai-agents-python/tracing/
  7. S7 Vendor documentation. OpenAI, "Codex security". https://developers.openai.com/codex/security
  8. S8 Vendor repository. OpenAI, Guardrails (Python). https://github.com/openai/openai-guardrails-python
  9. S9 Vendor document. Anthropic, "Claude's constitution". https://www.anthropic.com/constitution
  10. S10 Vendor documentation. Claude Code, "Permissions". https://code.claude.com/docs/en/permissions
  11. S11 Vendor documentation. Claude Code, "Permission modes". https://code.claude.com/docs/en/permission-modes
  12. S12 Vendor documentation. Claude Code, "Hooks". https://code.claude.com/docs/en/hooks
  13. S13 Vendor engineering note. Anthropic, "Claude Code sandboxing". https://www.anthropic.com/engineering/claude-code-sandboxing
  14. S14 Vendor repository. Anthropic, sandbox-runtime. https://github.com/anthropic-experimental/sandbox-runtime
  15. S15 Vendor documentation. Claude Code, "Monitoring usage" (OpenTelemetry). https://code.claude.com/docs/en/monitoring-usage
  16. S16 Specification. Model Context Protocol, latest specification. https://modelcontextprotocol.io/specification/latest
  17. S17 Vendor research. Anthropic, "Prompt injection defenses". https://www.anthropic.com/research/prompt-injection-defenses
  18. S18 Vendor research. Anthropic, "Agentic misalignment". https://www.anthropic.com/research/agentic-misalignment
  19. S19 Vendor documentation. Google Agent Development Kit, "Tool confirmation". https://adk.dev/tools-custom/confirmation/
  20. S20 Vendor documentation. Google Agent Development Kit, "Evaluate". https://adk.dev/evaluate/
  21. S21 Vendor documentation. Google Cloud, "Model Armor overview". https://docs.cloud.google.com/model-armor/overview
  22. S22 Vendor repository documentation. Gemini CLI, "Policy engine". https://github.com/google-gemini/gemini-cli/blob/main/docs/reference/policy-engine.md
  23. S23 Specification. Agent2Agent protocol, "Enterprise-ready features". https://a2a-protocol.org/latest/topics/enterprise-ready/
  24. S24 Academic. Debenedetti et al., "Defeating Prompt Injections by Design" (CaMeL), arXiv 2503.18813. https://arxiv.org/abs/2503.18813
  25. S25 Vendor documentation. Microsoft Azure AI Content Safety, "Prompt Shields". https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection
  26. S26 Vendor documentation. Microsoft Agent Framework, "Tool approval". https://learn.microsoft.com/en-us/agent-framework/agents/tools/tool-approval
  27. S27 Vendor documentation. Microsoft Agent Framework, "Security". https://learn.microsoft.com/en-us/agent-framework/agents/security
  28. S28 Open-source repository. Agent Hooks. https://github.com/responsibleai/agent-hooks
  29. S29 Vendor repository. Microsoft, Agent Governance Toolkit. https://github.com/microsoft/agent-governance-toolkit
  30. S30 Vendor repository. Microsoft, PyRIT. https://github.com/microsoft/PyRIT
  31. S31 Vendor documentation. GitHub, "Risks and mitigations for the Copilot coding agent". https://docs.github.com/en/copilot/concepts/agents/coding-agent/risks-and-mitigations
  32. S32 Academic (vendor authors). Chennabasappa et al., "LlamaFirewall", arXiv 2505.03574. https://arxiv.org/abs/2505.03574
  33. S33 Vendor repository. Meta, PurpleLlama. https://github.com/meta-llama/PurpleLlama
  34. S34 Model card. Meta, Llama Prompt Guard 2 86M. https://huggingface.co/meta-llama/Llama-Prompt-Guard-2-86M
  35. S35 Model card. Meta, Llama Guard 4 12B. https://huggingface.co/meta-llama/Llama-Guard-4-12B
  36. S36 Vendor documentation. Amazon Bedrock Guardrails, "Prompt attacks". https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-prompt-attack.html
  37. S37 Vendor documentation. Amazon Bedrock Agents, "User confirmation". https://docs.aws.amazon.com/bedrock/latest/userguide/agents-userconfirmation.html
  38. S38 Vendor documentation. Amazon Bedrock AgentCore, "Policy". https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html
  39. S39 Vendor documentation. Amazon Bedrock AgentCore, "Temporal policies". https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-temporal.html
  40. S40 Open-source repository. Cedar policy language. https://github.com/cedar-policy/cedar
  41. S41 Vendor documentation. Strands Agents, "Interrupts". https://strandsagents.com/docs/user-guide/concepts/interrupts/
  42. S42 Vendor documentation. Kiro, "Privacy and security". https://kiro.dev/docs/privacy-and-security/index
  43. S43 Vendor framework. AWS, "Agentic AI Security Scoping Matrix". https://aws.amazon.com/ai/security/agentic-ai-scoping-matrix/
  44. S44 Vendor repository. NVIDIA, NeMo Guardrails. https://github.com/NVIDIA/NeMo-Guardrails
  45. S45 Vendor documentation. NeMo Guardrails, "Tool calling". https://docs.nvidia.com/nemo/guardrails/latest/configure-guardrails/guardrail-catalog/tool-calling.md
  46. S46 Open-source repository. NVIDIA, garak. https://github.com/NVIDIA/garak
  47. S47 Vendor repository. NVIDIA, OpenShell. https://github.com/NVIDIA/OpenShell
  48. S48 Vendor documentation. Mistral AI, "Guardrailing". https://docs.mistral.ai/capabilities/guardrailing
  49. S49 Vendor documentation. Mistral AI, "Connector confirmation". https://docs.mistral.ai/studio/connectors/confirmation
  50. S50 Vendor repository. Mistral AI, Mistral Vibe. https://github.com/mistralai/mistral-vibe
  51. S51 Vendor documentation. Mistral AI, "Audit logs". https://docs.mistral.ai/admin/security-access/audit-logs
  52. S52 Academic (vendor authors). Qwen team, "Qwen3Guard technical report", arXiv 2510.14276. https://arxiv.org/abs/2510.14276v1
  53. S53 Vendor documentation. Qwen Code, "Approval mode". https://qwenlm.github.io/qwen-code-docs/en/users/features/approval-mode/
  54. S54 Academic. Independent security evaluation of the DeepSeek agent harness, arXiv 2608.16393. https://arxiv.org/abs/2608.16393
  55. S55 Vendor documentation. OpenHands SDK, "Security". https://docs.openhands.dev/sdk/arch/security
  56. S56 Vendor documentation. Goose, "Permissions". https://goose-docs.ai/docs/guides/goose-permissions
  57. S57 Vendor documentation. Goose, "Adversary mode". https://goose-docs.ai/docs/guides/security/adversary-mode
  58. S58 Vendor repository. IBM, Granite Guardian. https://github.com/ibm-granite/granite-guardian
  59. S59 Vendor documentation. LiteLLM, "Guardrails quick start". https://docs.litellm.ai/docs/proxy/guardrails/quick_start
  60. S60 Vendor documentation. vLLM, "Security". https://docs.vllm.ai/en/v0.20.2/usage/security/
  61. S61 Academic. Debenedetti et al., AgentDojo (NeurIPS 2024). https://github.com/ethz-spylab/agentdojo
  62. S62 Academic. Zhan et al., InjecAgent. https://github.com/uiuc-kang-lab/InjecAgent
  63. S63 Academic. Andriushchenko et al., "AgentHarm" (ICLR 2025). https://proceedings.iclr.cc/paper_files/paper/2025/hash/c493d23af93118975cdbc32cbe7323f5-Abstract-Conference.html
  64. S64 Academic. Sierra Research, τ-bench. https://github.com/sierra-research/tau-bench
  65. S65 Practitioner. Simon Willison, "The Dual LLM pattern for building AI assistants that can resist prompt injection", 25 April 2023. https://simonwillison.net/2023/Apr/25/dual-llm-pattern/
  66. S66 Academic. Beurer-Kellner et al., "Design Patterns for Securing LLM Agents against Prompt Injections", arXiv 2506.08837. https://arxiv.org/abs/2506.08837
  67. S67 Open-source repository. Invariant Labs, Invariant guardrails. https://github.com/invariantlabs-ai/invariant
  68. S68 Open-source repository. Invariant Labs, MCP scan. https://github.com/invariantlabs-ai/mcp-scan
  69. S69 Vendor documentation. LangChain, "Human-in-the-loop". https://docs.langchain.com/oss/python/langchain/human-in-the-loop
  70. S70 Open-source repository (archived). Protect AI, LLM Guard. https://github.com/protectai/llm-guard
  71. S71 Standard. OWASP, "Top 10 for LLM Applications 2025". https://genai.owasp.org/llm-top-10/
  72. S72 Standard. OWASP, "Agentic AI — Threats and Mitigations". https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
  73. S73 Official. NIST, "AI 600-1, Generative AI Profile". https://csrc.nist.gov/pubs/ai/600/1/final
  74. S74 Standard. ISO/IEC 42001:2023, AI management systems. https://www.iso.org/standard/81230.html
  75. S75 Framework. Cloud Security Alliance, "MAESTRO agentic AI threat modelling framework", 6 February 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
  76. S76 Vendor documentation. Meta, CyberSecEval. https://meta-llama.github.io/PurpleLlama/CyberSecEval/
  77. S77 Open-source repository. E2B. https://github.com/e2b-dev/E2B
  78. S78 Open-source repository. Open Policy Agent. https://github.com/open-policy-agent/opa