Guardrails

Not safety nets: boundaries that define where an agent may operate. Five layers, from data and context up to human oversight. Traditional access controls assume software does what it is programmed to do. Agent guardrails assume it might not.

Runtime enforcement in motion: inputs are filtered for injection and stripped of PII, outputs are scored against policy and redacted, rate limits and confidence thresholds bound the loop, and at multi-agent scale a guardian agent watches for anomalous behavior.

The five layers

In the context of Agentic AI, guardrails are the technical and organizational controls that constrain what an AI agent can decide, access and execute. For the first time we have deployed software that can go do something without us explicitly telling it what to do. The five layers: data and context guardrails (the foundation: graphs, business definitions, policies); design-time governance (who can build what agents, with which data, under what constraints); runtime guardrails (prompt injection filtering, PII redaction, policy violation alerts, risk scoring with thresholds); identity and access (a distinct identity per agent, scoped and short-lived permissions); and human-in-the-loop oversight (approval workflows and escalation paths above the agent's authority).

From standards to runtime

The core challenge at runtime is that existing governance standards like ISO and NIST do not translate directly into runtime controls. One research approach suggests a four-layer translation method: governance objectives, design-time constraints, runtime mediation and assurance feedback. The key insight is that not every governance rule becomes a runtime guardrail. Runtime controls are reserved for things that are observable, deterministic and time-sensitive enough to justify execution-time intervention. Two 2026 studies put numbers behind that reservation: against 4,371 human-written attacks on a live payment agent, a deterministic pre-action check cut unauthorized transfers from 140 in 76,842 evaluations to none in 69,297, and a separate ablation found that giving the planner authority information to reason over still let unsafe decisions through, while a deterministic guard at the point of execution blocked every unsafe intent tested. All else lives in architecture, human escalation or audit.

The ceiling on tag-based filtering

Runtime prompt-injection filtering leans on role tags: labels like system, user, tool and chain-of-thought that are supposed to tell the model where a chunk of text came from. Research probing model internals found that LLMs do not actually track role by the tag around the text; they infer it from the text's content and writing style instead. Swapping the tags around made almost no difference to how the models treated the text. This lets an attacker write content that merely sounds like a privileged role, such as the model's own chain-of-thought, and get the model to act on it as if it genuinely were that role, a technique called chain-of-thought forgery. On a standard jailbreak benchmark, this technique took attack success rates from near zero to about 60%, and the effect held across every model the researchers tested. A separate evaluation of 46 to 48 models across six vendors found the same gap from another angle: models could name forged authority when asked, yet specific configurations still executed the conflicting tool call, while an external monitor that authenticated sources and gated tool execution rejected every forged request tested. It means tag-based input filtering has a ceiling that better training alone does not remove.

The limits of pre-authored policies

Human oversight can approve each action live, or settle whole categories in advance with a standing policy (allow, ask, never). In a controlled study of 113 participants without software backgrounds, supervising a simulated workday with 7 overreach actions, standing policies blocked 20.1 percentage points less overreach than live approval, because participants set 114 of 140 rules to "ask" and handed the decision straight back to runtime. Writing a policy is not a substitute for judgment exercised at the moment of action.

Guardians and the chain of custody

An emerging pattern at multi-agent scale is dedicated agents whose job is to monitor other agents' actions and contain anomalous behavior. Guardian agents seem to be a trend that is here to stay; the practical guidance is still to start with centralized logging, policy enforcement and human-in-the-loop workflows first. In multi-agent systems there is also an emergent compliance problem: when agents collaborate they might violate compliance in their in-between data exchanges, even when each operates within its own permissions. The chain of custody breaks across agent boundaries; this problem has no clean solution yet. In general, guardrails are not a bolt-on compliance checkbox. They are an architectural layer designed in, not added after.