How should teams decide between guardrails, human approval, and runtime baselines?

How to choose the control at the point of failure

Think of the three controls as sitting at different layers of the decision path. Guardrails are best when the problem is input shaping and prompt-level abuse, human approval is best when the action has external consequences, and runtime baselines are best when the failure only becomes visible once the agent is already behaving outside its normal envelope. That separation matters because each control fails differently.

Guardrails are a front-door control. They work when you can reliably identify obviously hostile, irrelevant, or policy-breaking text before it reaches the model or tool layer, but they are weaker against indirect manipulation, legitimate-looking instructions, and multi-step coercion. Human approval is a decision gate, not a text filter, so it should be reserved for actions that change state, spend money, move data, or alter access. Runtime baselines are the backstop when the agent’s output looks acceptable in isolation but its sequence of actions, timing, tool use, or volume starts to diverge from expected behaviour.

The practical test is simple: ask what you are trying to stop first. If you are blocking an obvious prompt or message, start with guardrails. If you are authorising a consequential action, require human approval. If you are trying to catch abuse that only appears across a session, workflow, or population of actions, add runtime baselines. Mature teams usually need all three, but not all three in the same spot.

Why one control cannot cover prompt, action, and behaviour risk

Guardrails and approvals are both useful, but they answer different questions. A guardrail asks whether the content should be allowed through at all. A human approval asks whether this specific action should be executed. A runtime baseline asks whether the behaviour remains plausible given the agent’s normal role, permissions, and past activity. If you blur those functions, you create either false confidence or so much friction that people bypass the control.

This is why runtime baselines are often the missing layer in agent programmes. They are not just another content filter, they are a way to notice drift, abuse of delegated authority, unusual call sequences, or an agent that becomes technically compliant while still being operationally wrong. For teams evaluating broader AI security controls, the AI Security Platform Buyer’s Guide is useful because it frames guardrails, gateways, red teaming, and agent security as separate capabilities rather than one blended category.

That distinction also helps with approval design. If every action needs human review, the system becomes unusable. If no meaningful action ever needs review, the organisation has not really introduced a control, only a logging requirement. The right balance is to reserve approval for state-changing or high-blast-radius actions and to let baselines handle the quieter, cumulative forms of abuse that approvals will miss.

What mature teams watch for in practice

Mature teams map controls to failure mode. They use guardrails to block obviously unsafe language, approval gates to intercept irreversible actions, and behavioural baselines to detect when the agent is still “following instructions” but no longer following the intended operating pattern. That last point is especially important when agents can chain tools, query external systems, or operate across multiple steps where each individual step looks legitimate.

For runtime detection and baseline thinking, container and workload guidance can be a helpful analogue because the security problem is similar: you are comparing observed runtime activity with expected behaviour and looking for departures that signal abuse or compromise. NIST SP 800-190 Container Security is relevant here because it treats runtime as a distinct control plane, not just a deployment issue. Where the baseline is meant to detect tool abuse or abnormal execution, MITRE ATT&CK Enterprise Matrix helps teams think in terms of observable behaviours, post-compromise actions, and detection opportunities rather than only policy violations.

For guardrail-heavy systems, input filtering should be treated as necessary but insufficient. For approval-heavy systems, escalation criteria must be precise enough that reviewers know what makes an action exceptional. For baseline-heavy systems, the question is whether you can actually define “normal” for an autonomous system that may vary by task, user, environment, or time of day. If you cannot define that, the baseline is probably too vague to trust.

Practitioner Guidance

What to prioritise: Start by classifying the agent’s actions into low-risk text handling, human-reviewable state change, and behavioural anomaly detection. That gives you a clean control split and prevents overusing approvals for issues that should be caught earlier.

Decision rule: If the risk is reversible and content-based, use guardrails first; if the risk is consequential and irreversible, require human approval; if the risk is cumulative, evasive, or only visible across a sequence, add runtime baselines.

What to verify: Make sure each control has a distinct trigger, owner, and escalation path. The common mistake is to define all three controls as “AI safety” and then discover that nobody can tell which one failed or why.

What good looks like: The programme blocks obvious abuse early, forces review for high-impact actions, and still detects suspicious drift when the agent behaves in ways that are individually plausible but collectively wrong.

Practitioner takeaway: Do not choose the “best” control in the abstract, choose the control that fails least badly at the point where the agent is most likely to be coerced.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How do teams decide between evaluation tooling and runtime guardrails?
• How should teams secure non-human identities across cloud and SaaS?
• What is the difference between code scanning and runtime identity monitoring?