Notifications
Clear all
Topic starter
01/08/2026 10:48 pm
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.
NHIMG editorial — based on content published by Onyx: Four Guardrails: The Customer Success Pattern for Safe AI Agent Adoption
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents complicate existing IAM and NHI governance models?
A: AI agents complicate governance because access is no longer confined to a single environment or a single identity type.
Q: What breaks when organisations rely on endpoint controls alone for AI use?
A: Endpoint-only control misses the in-session behaviour that determines whether AI use is safe or compliant.
Practitioner guidance
- Inventory every agent runtime and connector before broad rollout Run discovery across managed endpoints to identify agent installations, active instruction sets, and connected MCP servers.
- Scan agent configurations as code before execution Review instruction files, rules, and workflow definitions for hardcoded secrets, untrusted external URL fetching, insecure credential handling, and overly broad tool permissions before you permit production use.
- Capture session-level evidence for every material agent action Record prompts, tool calls, model responses, and file writes so audit and incident teams can reconstruct what happened after the session closes.
What's in the full article
Onyx's full article covers the operational detail this post intentionally leaves for the source:
- Week-one onboarding sequence with day-by-day deployment timing for discovery, posture review, and enforcement.
- Operational examples of how the tool-call boundary blocks destructive actions and masks sensitive data in transit.
- The control mapping used to decide which agent sessions stay in alert mode and which move to blocking.
- How Onyx positions its Secure AI Control Plane across mixed commercial and self-built agent runtimes.
👉 Read Onyx's four-guardrail approach to AI agent governance →
AI agent governance guardrails: what security teams must verify?
Explore further
01/08/2026 10:56 pm
AI agent adoption is creating an identity governance problem, not just an application security problem. The article shows that agents are arriving through developer use before formal approval, which means identity teams inherit runtime behaviour they did not provision or review. The practical conclusion is that agent governance now sits inside IAM, PAM, and NHI oversight rather than outside them.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- That same research found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
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: Four guardrails for safe AI agent adoption in enterprise IAM
