Notifications
Clear all
Topic starter
20/08/2026 6:00 pm
TL;DR: AI agent approvals fail when teams rubber-stamp declared permissions instead of proving observed behaviour, baseline coverage, and response readiness, according to ARMO. The decisive issue is not whether an agent exists, but whether its runtime evidence closes the gap between intended access and actual tool use.
NHIMG editorial — based on content published by ARMO: The CISO’s AI Agent Production Approval Checklist: 7 Gates to Clear Before Go-Live
Questions worth separating out
Q: How should security teams evaluate AI agent trust before production use?
A: Security teams should evaluate AI agent trust by combining identity posture, intended access, delegation paths, and governance metadata in one approval decision.
Q: Why do AI agents create access problems that human approval processes do not solve well?
A: AI agents can inherit credentials, chain actions, and execute at machine speed, while human approval models assume slower, request-based behaviour.
Q: What breaks when declared permissions do not match observed AI agent behaviour?
A: The entire approval decision breaks because the team is certifying access it has not validated.
Practitioner guidance
- Build a runtime AI-BOM before production review Record the agent’s loaded models, RAG sources, MCP tools, reachable APIs, named owner, and autonomy tier from runtime discovery rather than manual self-reporting.
- Compare declared permissions to observed behaviour Approve only when observed tool use, network destinations, and data paths align with the declared access set, and treat any delta as unresolved blast radius.
- Set tier-based evidence thresholds Use a stricter observation window and coverage requirement for higher-autonomy agents, because one week of logs is not enough for a workflow agent with write access.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- The full seven-gate approval checklist with concrete evidence standards for each gate.
- Autonomy-tier thresholds that show how evidence bars change between read-only agents and multi-agent workflows.
- The one-page approval artifact template used to turn a go-live discussion into a signed decision record.
- Practical examples of declared-vs-observed mismatches and what security reviewers should look for in the console.
👉 Read ARMO's checklist for AI agent production approval gates →
AI agent go-live approvals: are your evidence gates ready?
Explore further
20/08/2026 6:39 pm
Declared access is not an approval control when observed behaviour diverges: The checklist’s strongest insight is that approval decisions fail when teams certify intended permissions instead of runtime reach. If an agent is declared for 47 APIs but only shows 3 in observation, the missing 44 are not theoretical. They are ungoverned surface area that security has not actually measured. The practitioner conclusion is that go-live approval must be evidence-led, not narrative-led.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, which fragments control and slows consistent governance across workloads.
A question worth separating out:
Q: How do organisations know when an approved AI agent needs re-review?
A: Re-review is needed when the agent’s prompt, model, tools, or reachable data changes enough to alter its behaviour baseline. Security teams should also re-check after new integrations, scope expansion, or unexpected access patterns. In practice, any drift from the approved runtime profile should trigger a fresh decision.
👉 Read our full editorial: AI agent production approval needs seven evidence gates
