Notifications
Clear all
Topic starter
02/08/2026 11:23 am
TL;DR: LLM agents fail in ways single-turn chatbots do not, with Openlayer citing a 41% failure rate on complex multi-step tasks and runtime thresholds for groundedness and toxicity that must be enforced before tool calls complete. The governance problem is no longer output review, but session-level control, auditability, and policy enforcement inside the execution loop.
NHIMG editorial — based on content published by Openlayer: Governance Production Agent Governance Guide (June 2026)
By the numbers:
- The vendor says agents fail 41% of the time on complex multi-step tasks.
- Tool calling fails 3 to 15% of the time depending on task complexity and model capability.
- A five-step workflow with a 10% per-step failure rate produces a correct end-to-end result less than 60% of the time.
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why do endpoint agentic AI tools create more governance risk than chat-only GenAI?
A: Endpoint agentic AI can act inside a user’s session, move data, and trigger downstream actions, which expands the effective privilege boundary.
Q: What breaks when agent governance is limited to output filtering?
A: Output filtering catches unsafe text, but it does not stop an agent from taking an unsafe action first.
Practitioner guidance
- Define tool-level authorisation boundaries for every agent Assign explicit allowlists for each agent session and block any tool call that falls outside its declared scope before execution completes.
- Deploy pre-execution filters at the prompt and tool boundary Screen for injection, jailbreak patterns, malformed parameters, and scope violations before the model can act.
- Measure agent sessions, not just outputs Track contextual consistency, goal completion, abandonment, turn productivity, and cost per session so you can see when an agent is drifting across a workflow.
What's in the full article
Openlayer's full post covers the operational detail this post intentionally leaves for the source:
- Concrete evaluation thresholds for grounding, toxicity, fairness, and cost before deployment
- Step-by-step runtime guardrail patterns for input filtering, tool validation, and output blocking
- The conformity assessment and audit artefact structure used to support EU AI Act mapping
- Session-level monitoring metrics that can be used to tune production thresholds and incident response
👉 Read Openlayer's guide to AI agent governance in production →
AI agent governance in production: are your controls keeping up?
Explore further
02/08/2026 12:40 pm
Agent governance is now an identity problem as much as an AI problem. Once an agent can authenticate to tools, databases, or third-party APIs, the governance question becomes who or what is allowed to act in each step of a session. That puts IAM, PAM, and NHI discipline directly into the AI control plane. Organisations that still treat agent sessions as ordinary model prompts will miss the delegated-access risk that actually drives harm.
A question worth separating out:
Q: Who is accountable when an AI agent makes a destructive tool call?
A: Accountability sits with the organisation that allowed the runtime, connector, and policy model to exist together without sufficient control. In practice, that means security, platform, and application owners all share responsibility for the guardrails that should have stopped the action at the tool boundary.
👉 Read our full editorial: AI agent governance in production demands step-level controls
