TL;DR: Enterprises are already running AI agents before formal risk review, and the real gap is not adoption but auditability, session visibility, and tool-call enforcement, according to Onyx. The decisive issue is that governance models built for static access do not explain what an agent session actually did, especially when MCP-connected tools expand blast radius.
Editorial analysis by NHI Mgmt Group, based on content published by Onyx: “Four Guardrails: The Customer Success Pattern for Safe AI Agent Adoption”.
Key questions
Q: What is the first governance failure when AI agents are already running in the environment?
A: The first failure is not technical compromise.
Q: Why do AI agents create a larger security risk than ordinary web applications?
A: AI agents can act with delegated authority, chain tool calls, and reach internal APIs without human pacing.
Q: What are the signs that AI governance is failing in the enterprise?
A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk.
Practitioner guidance
- Build the agent inventory first Discover every agent installation, active instruction set, and connected MCP server across managed endpoints before broad developer access is allowed.
- Scan configurations before execution Review instruction files, workflow definitions, and rule sets for hardcoded secrets, untrusted content fetching, insecure credential handling, and overly broad tool permissions.
- Capture session-level evidence Record prompts, tool calls, model responses, and file actions for each session so the security team can reconstruct what the agent actually did.
Bottom line: AI agent adoption is already happening inside enterprise workflows, which makes visibility and control a live governance issue rather than a future planning topic.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Agent governance is becoming a runtime identity problem, not an approval problem. The article shows that agent adoption is already happening before formal review, which means the governance question moves from permissioning an idea to controlling an active runtime identity. That shift matters because the control point is the session, the configuration, and the tool boundary, not the procurement decision. Practitioners should treat agent governance as continuous authorization over behaviour, not a one-time enablement event.
A few things that frame the scale:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should teams respond when AI agent sessions lack audit evidence?
A: They should treat the missing session record as a control failure, not a logging inconvenience. If you cannot tie the prompt, tool call, and resulting file or data action back to a user and device, you do not have an auditable agent governance model, only a partial endpoint view.
👉 Read our full editorial: Four guardrails for safe AI agent adoption in enterprise IAM