Guardian Agents Guide: AI Agents That Supervise AI Agents

As organisations deploy more AI agents than humans can watch, a new control category has appeared: guardian agents, AI systems whose job is to review, monitor and, when necessary, block what other AI agents do. Gartner describes guardian agents as "AI-based technologies designed to support trustworthy and secure interactions with AI", and the idea is now appearing in analyst research, open standards such as the OWASP Agent Control Standard, and open source tooling. The idea is sound, because human approval does not scale to thousands of agent actions per hour. It also creates a new set of problems: a guardian built on the same kind of model can be fooled by the same prompt injection, it needs privileged access to do its job, and a guardian that fails open is worse than none because it creates false confidence. This guide explains what guardian agents are, the architectures in use, how to design them so they cannot be subverted the same way as the agents they supervise, where identity and permissions fit, and how to measure whether they work. It is for AI platform engineers, security architects and governance teams. Detection of agents that have already gone wrong is covered in the Rogue and Runaway AI Agent Detection Guide.

Key takeaways

A guardian agent is a control, not a feature of the agent. It must run outside the supervised agent's trust boundary, with its own identity, its own context and enforcement that the supervised agent cannot bypass.
Combine deterministic and model-based checks. Hard policy (allow lists, scopes, spending limits, environment boundaries) catches what must never happen; model-based judges catch intent drift and subtle misuse. Neither alone is enough.
Assume the guardian can be attacked. If it reads the same untrusted content as the supervised agent, it can receive the same injected instructions. Feed it structured action data, not raw untrusted text, wherever possible.
Fail closed for high-impact actions. When the guardian is unavailable, slow or uncertain, destructive, financial and data-export actions should stop or escalate to a human.
Measure the guardian like any detection control. Track block rate, false positive rate, bypass rate in red team tests, latency and how often humans overturn its decisions.

What guardian agents are

Gartner's June 2025 press release on guardian agents describes them as able to act as assistants for tasks such as content review and monitoring, or as semi-autonomous or fully autonomous agents that can redirect or block actions to keep them aligned with predefined goals. It identifies three primary usage types:

Reviewers: "Identifying and reviewing AI-generated output and content for accuracy and acceptable use."
Monitors: "Observing and tracking AI and agentic actions for human- or AI-based follow-up."
Protectors: "Adjusting or blocking AI and agentic actions and permissions using automated actions during operations."

The same release predicted that guardian agent technologies will account for at least 10 to 15 percent of agentic AI markets by 2030, and listed the threats they address: input manipulation and data poisoning, credential hijacking and abuse, interaction with fake or criminal websites and sources, and agent deviation and unintended behaviour. A vendor summary by NeuralTrust of Gartner's Hype Cycle for Application Security 2026 reports guardian agents as "On the Rise" with a high benefit rating and adoption below 1 percent; we have not read the Gartner report itself, so treat that positioning as second-hand.

The OWASP Agent Control Standard, published on the OWASP GenAI Security Project site on 1 September 2026, uses the same name for a narrower, technical role. As summarised in our guide to the standard, a Guardian Agent is a policy service that receives requests from an Observed Agent at defined hooks and returns a disposition such as allow, deny, modify, escalate or defer. The specification details are covered in the OWASP Agent Control Standard Guide. In this guide, "guardian agent" means any system in the reviewer, monitor or protector role, whether it uses a model, deterministic rules or both.

Guardian architectures compared

Pattern	How it works	Strengths	Weaknesses	Best fit
Inline gate (protector)	Every proposed tool call or output passes through the guardian, which allows, modifies or blocks before execution	Prevents harm rather than detecting it; clear audit point	Adds latency; single point of failure; must decide fail-open or fail-closed	Payments, deletes, data export, production changes
Out-of-band monitor	Guardian consumes logs and traces asynchronously and alerts, pauses or revokes	No latency on the main path; sees patterns across sessions and agents	Acts after the fact; harm may already be done	High-volume, low-impact actions; fleet-level drift
Output reviewer	A second model checks generated content for accuracy, policy and data leakage before delivery	Catches harmful or leaking content	Shares model weaknesses; can be steered by the content it reviews	Customer-facing responses, generated code, documents
Reasoning auditor	Guardian inspects the agent's plan or reasoning trace against the user's stated intent	Can catch goal hijacking before an action	Depends on the trace being faithful and available	Agents processing untrusted web, email or documents
Deterministic policy engine	Rules over structured action data: tool, parameters, target, identity, amount, environment	Predictable, testable, cannot be prompt-injected	Cannot judge intent; rules need maintenance	Hard limits for every agent
Separation by design	Control flow comes only from the trusted request; untrusted data cannot change which tools run (for example the CaMeL research design)	Strong guarantees against injection	Requires re-architecting the agent; some task loss	New high-risk agents

Open source examples illustrate the components. Meta's LlamaFirewall combines PromptGuard 2 (a lightweight classifier for direct prompt injection in inputs and untrusted content), AlignmentCheck (which audits an agent's reasoning in real time to detect goal hijacking, indirect prompt injection and misalignment), CodeShield (static analysis of generated code) and configurable regex scanners. The CaMeL research paper, Defeating Prompt Injections by Design (Debenedetti and others), describes separating control and data flow so that untrusted data cannot alter what the agent does, attaching capabilities to data and enforcing policies at tool calls; the authors report solving 77 percent of AgentDojo tasks with provable security against 84 percent for an undefended system. Both show the same trade-off: stronger guarantees cost some capability. For guardrails at the model and gateway layer, see the AI Guardrails and AI Firewalls Guide.

Designing a guardian that cannot be subverted

Separate trust boundaries: run the guardian as a separate process or service with its own credentials. The supervised agent must not be able to edit the guardian's configuration, prompt, policy or logs, or call the protected tool by another route.
Minimise untrusted input to the guardian: give it structured data (tool name, parameters, target resource, data classification, the original user request) rather than the full web page or email the agent read. If it must read untrusted text, treat that text as data with clear delimiters and never let it change the guardian's instructions.
Use a different model or vendor where feasible: a guardian built on the same model family as the agent may share blind spots. Diversity reduces correlated failure, though it is not a guarantee.
Layer deterministic rules first: check scope, environment, amount and destination with code before any model judgement. A model should never be the only thing preventing a production delete or a transfer to a new payee.
Define fail modes explicitly: for each action class, decide what happens if the guardian times out or returns low confidence. Destructive and irreversible actions fail closed; read-only actions can fail open with logging.
Bound the guardian's own authority: a protector that can revoke permissions or terminate sessions is itself a privileged identity. Give it only the actions it needs (pause, deny, revoke a session token), not general administrative rights.
Keep humans in the escalation path: OWASP's LLM06 Excessive Agency guidance recommends human-in-the-loop approval for high-impact actions. The guardian decides which actions need a human, it does not replace the human for those actions. See the AI Agent Action Approvals and Spending Limits Guide.

Where identity fits

Guardian agents are non-human identities with unusual power, and they depend on the supervised agents having distinct identities too.

Distinct identities for supervised agents: a guardian can only apply per-agent policy and attribute actions if each agent has its own identity rather than sharing a user's token or a team service account. See the Agent Identity and Access Guide.
Policy on identity and scope, not just content: many of the most damaging agent incidents are permission problems. A guardian that checks "does this token, for this agent, in this environment, allow this action on this resource" catches what content filters miss.
The guardian's own credentials: register an owner, scope its permissions to supervision actions, rotate its credentials and log every decision with the guardian's identity. Its access to trace data may include sensitive content, so apply data protection controls.
Delegation chains: in multi-agent systems, the guardian should see the full chain of who asked whom to do what, so that an agent cannot launder a forbidden action through a sub-agent. See the Delegation Chains and Attenuated Authority for AI Agents guide.

Choosing an approach: decision guidance

Low-risk, read-only assistants: an out-of-band monitor with sampling and periodic review is usually enough. Inline gating adds latency without much risk reduction.
Agents with write access to business systems: put a deterministic inline gate on every write, and add a model-based reviewer for actions whose risk depends on context, such as emails to external recipients.
Agents processing untrusted content with sensitive data access: this is the combination behind most prompt injection data leaks. Use a reasoning auditor plus strict egress controls, or redesign so the agent reading untrusted content has no sensitive access. See the Agent Egress Control and Network Isolation Guide.
Coding and infrastructure agents: gate destructive commands and production credentials with deterministic rules; model judgement is a supplement.
Build or buy: platform-native guardrails are quickest but tied to one platform; a standards-based guardian (for example speaking the OWASP ACS protocol) can supervise agents across frameworks once those frameworks implement the hooks. Small teams should start with platform features and hard limits; large organisations with many agent platforms benefit from a central guardian service and shared policy.

How to implement guardian agents

Inventory agents and actions. For each agent list its identity, tools, data access, input sources and the actions that would cause harm if misused. Rank actions by impact and reversibility.
Write hard limits first. Encode non-negotiable rules (no production deletes, no new payees, no data export over a threshold, no access outside assigned environment) in a deterministic policy layer.
Deploy the guardian in monitor mode. Log every decision it would have made without enforcing, for two to four weeks. Review false positives and missed cases with the agent owners.
Red team it. Test with indirect prompt injection aimed at both the agent and the guardian, attempts to split a forbidden action across steps or sub-agents, and attempts to reach the tool by another path. See the AI Red Teaming Guide.
Enforce in rings. Turn on blocking for the highest-impact action class on one agent, then expand. Keep a documented, tested way to switch enforcement back to monitor mode per agent if it breaks a critical workflow, and require approval for that switch.
Connect to response. Route guardian blocks and alerts into the SOC with enough context to act, and link the guardian to the kill switch so it can pause an agent. See the AI Agent Kill Switch and Containment Guide.
Review continuously. Re-test after every model, prompt or tool change to either the agent or the guardian.

Detection and measurement

Guardian decisions are themselves high-value telemetry. Log the request, the decision, the reason, the policy or model version, latency and any human override, with the supervised agent's and guardian's identities.

Metric	What it tells you
Block and escalation rate per agent and action class	Where agents are trying to exceed their remit
False positive rate (blocks overturned by humans)	Whether the guardian is tolerable for the business
Bypass rate in red team exercises	Real protective value, including against attacks on the guardian
Guardian latency at p95 and timeout count	Whether fail modes are being triggered
High-impact actions executed without a guardian decision	Coverage gaps and bypass paths, target zero
Time from guardian alert to containment	Whether monitoring leads to action

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection; LLM06 Excessive Agency	The main risks guardians address; LLM06 recommends human approval for high-impact actions
OWASP GenAI Security Project	Top 10 for Agentic Applications for 2026; Agent Control Standard	Agent-specific risks and a protocol for guardian decisions
MITRE ATLAS	AML.T0051 LLM Prompt Injection (AML.T0051.001 Indirect); AML.T0053 AI Agent Tool Invocation; AML.T0054 LLM Jailbreak; AML.M0020 Generative AI Guardrails	Attacks on supervised agents and guardians, and the mitigation class
NIST SP 800-53 Rev. 5	SI-4 System Monitoring; AU-6 Audit Record Review; AC-6 Least Privilege; SA-8 Security and Privacy Engineering Principles	Monitoring, decision review, limiting agent and guardian authority, separation by design
NIST CSF 2.0	DE.AE-02; RS.MI-01; GV.OV-01	Analysing agent events, containing incidents, reviewing risk strategy outcomes

Common failure patterns

Prompt instructions instead of enforcement. In the PocketOS Database Deletion, a coding agent had instructions against destructive actions but used an over-scoped token it found to delete a production database and its backups in one API call. Only a control outside the agent, checking scope and environment, would have stopped it.
Guardian reads the attack. A reviewer model given the same poisoned record as the agent can be instructed to approve. In ForcedLeak, instructions hidden in a web form field led an agent to place CRM data in an image URL; a guardian checking outbound destinations against a verified allow list, rather than reading the content, is the robust check.
Silent fail-open. The guardian times out under load and actions proceed with no record that they were unchecked.
Bypass paths. The guardian gates the agent's tool framework, but the agent also holds a raw API token or shell access that reaches the same system directly.
Over-blocking until disabled. A guardian with a high false positive rate gets switched off by frustrated teams. Monitor mode and tuning before enforcement prevent this.
Unaccountable guardian. No owner, no versioning of its prompt or policy, and no review of its decisions, so nobody notices when a model update changes its behaviour.

Practitioner checklist

Inventory agents, their identities, tools, data access and high-impact actions.
Run the guardian outside the supervised agent's trust boundary, with its own scoped identity.
Enforce deterministic hard limits before any model-based judgement.
Feed the guardian structured action data and treat any untrusted text as data only.
Define fail-closed behaviour for destructive, financial and data-export actions.
Close bypass paths: agents should hold no credentials that reach protected systems outside the gated tools.
Start in monitor mode, tune, red team, then enforce in rings.
Log every decision with identities, versions and overrides, and send blocks to the SOC.
Re-test the guardian after any model, prompt, policy or tool change.

Guardian Agents Guide: How AI Agents Can Safely Supervise Other AI Agents