Notifications
Clear all
Topic starter
18/08/2026 2:13 pm
TL;DR: Long-running AI agents fail in the harness as often as in the model itself, because orchestration, permissions, retries, and evaluation design shape whether outputs remain reliable, according to Arize. The operational lesson is that autonomy increases control depth, not just model quality, and that guardrails and evals must be designed together.
NHIMG editorial — based on content published by Arize: AI agent guardrails vs. evals: How to build more reliable agent systems
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams use static guardrails for AI agents?
A: Use static guardrails as a first-pass control for known bad inputs, prohibited outputs, and obvious data leakage.
Q: Why do autonomous agents create a bigger governance problem than chat-based AI assistants?
A: Chat-based assistants usually begin with a visible human prompt, so the initiation point is easier to govern and audit.
Q: What do security teams get wrong about AI agent benchmarks?
A: They often measure end-to-end complexity or general model quality instead of the exact failure moment.
Practitioner guidance
- Define executable guardrails for agent authority Convert prompt intent into code-enforced limits on tool access, response concurrency, retry counts, and approval requirements for irreversible actions.
- Separate reversible tasks from privileged actions Classify agent actions by business impact, then require human approval for actions that spend money, change production data, send external messages, or create legal commitments.
- Instrument the full execution trajectory Retain traces for tool calls, branching decisions, retries, and context changes so reviewers can reconstruct how the agent reached an outcome.
What's in the full article
Arize's full post covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how guardrails are encoded in the agent harness for tool access, retries, and response concurrency.
- The evaluator design questions that determine whether an eval can actually judge a run using current context and policy.
- A step-by-step feedback loop showing how failed runs become prompts, tests, and code changes for the next iteration.
- The voice-agent failure example that illustrates why output quality alone does not prove safe execution.
👉 Read Arize's analysis of AI agent guardrails and evals →
AI agent guardrails vs. evals: are your controls keeping up?
Explore further
18/08/2026 3:05 pm
Guardrails are the control plane for agent authority, not a polishing layer. The article is right to separate runtime constraints from post-run evaluation because the two controls answer different governance questions. For IAM teams, that means the meaningful question is not whether an agent can be scored after execution, but whether it was ever permitted to take the risky action in the first place. In identity terms, this is least privilege for agent behaviour, enforced at the action layer.
A question worth separating out:
Q: Who is accountable when an AI agent acts outside its intended scope?
A: The organisation is accountable, but operational responsibility should sit with a named owner and a governance process that can explain the agent’s purpose, access, and recorded actions. Without that, autonomous behaviour becomes unassignable risk rather than managed automation.
👉 Read our full editorial: Guardrails and evals are both required for reliable AI agents
