Four guardrails for safe AI agent adoption in enterprise IAM

At a glance

What this is: This is an operational framework for governing AI agents in enterprise environments, with a focus on discovery, configuration scanning, session capture, and tool-call enforcement.

Why it matters: It matters because IAM, security, and compliance teams need controls that can see, constrain, and evidence agent behaviour before broad developer use turns into unmanaged identity risk.

👉 Read Onyx's four-guardrail approach to AI agent governance

Context

AI agent governance starts with a simple problem: most organisations discover agent use after deployment, not before it. In practice, that means security teams are asked to review behaviour they did not inventory, approve, or observe in advance, while developer and platform teams are already connecting agents to data sources and tools.

For identity programmes, the issue sits at the intersection of NHI governance, access control, and auditability. An agent session can combine a user identity, connected MCP servers, and tool permissions in ways that create a much broader blast radius than a standard application session, so the security model has to account for runtime behaviour as well as entitlement design.

Key questions

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. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

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. An agent may need cloud runtime permissions, customer data access, and tool-level OAuth tokens at the same time, which means standing privilege and lifecycle assumptions break down fast. That is why one control model rarely covers the full path.

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. Users can copy data, authorise connected apps, and interact with web-based AI tools without those actions being visible at the endpoint layer in a useful way. That leaves a governance gap between sign-in and actual use.

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.

Technical breakdown

AI agent inventory and discovery across endpoint fleets

AI agent inventory is the foundation of any control model because you cannot govern runtimes you cannot see. In this pattern, discovery runs across managed endpoints to identify agent installations, active instruction sets, and connected MCP servers, then ties those assets back to the security programme. The architectural point is that agent risk is not only in the model itself. It also lives in the configuration layer, the connectors, and the unreviewed runtime spread across developer devices. Without discovery, every later control is partial because the programme lacks the asset baseline required to classify exposure.

Practical implication: Run discovery before policy debates so the security team can see every agent runtime, instruction set, and connector in scope.

Agent configuration scanning before execution

Agent configurations behave like code because they define what the agent can read, fetch, and call before a prompt is processed. Scanning these files before execution surfaces hardcoded secrets, untrusted external URL fetches, insecure MCP server handling, and overly broad tool permissions. This is a pre-runtime control, which matters because many failures happen at the configuration layer long before any individual session begins. For identity governance, the key issue is that policy is being embedded in the agent’s operating instructions, not only in downstream security tooling, so configuration posture becomes part of identity risk.

Practical implication: Treat agent instruction files and workflow definitions as security artefacts and block high-risk configurations before deployment.

Session capture and tool-call enforcement for AI agent identity

Session-level telemetry closes the audit gap that endpoint tools cannot. EDR can show that a process ran, but it cannot show the prompt, tool call, or file write that occurred during the interaction. Session capture records the runtime exchange, while tool-call enforcement controls the boundary where the agent attempts to act. In this model, the tool call is the common control surface across commercial and self-built agent stacks. That makes the session record both a forensic artefact and a governance record, which is why agent identity management has to extend beyond endpoint monitoring into action-level oversight.

Practical implication: Capture session activity and enforce policy at the tool boundary so destructive or out-of-scope actions can be blocked or reviewed.

Threat narrative

Attacker objective: The objective is to use agent-connected tools and prompts to cause destructive actions or expose sensitive data while remaining difficult to reconstruct from endpoint-only telemetry.

1. Entry occurs when AI agents are introduced through developer adoption and connected to Jira, GitHub, databases, or MCP servers before formal security review.
2. Escalation happens when broad tool permissions, unreviewed instruction sets, or compromised MCP connections allow the agent session to reach beyond its intended scope.
3. Impact follows when the session makes destructive changes, exposes sensitive data, or leaves no sufficient audit record for incident review.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime visibility is the new governance baseline for agentic systems. EDR and endpoint controls cannot tell security teams what a session prompted, which tool it called, or what it wrote. That gap is why session records become the evidence layer for legal, audit, and incident review, and why agent identity has to be managed at the interaction level.

Blast radius in agent environments is defined by connectors, not just credentials. A session tied to Jira, GitHub, and database access can expand far beyond what the operator intended, even when the user never meant to create that scope. The named concept here is agent connector blast radius, which is the compounded exposure created when one session inherits multiple tool relationships at once.

Policy at the tool-call boundary is the control that turns agent governance into enforcement. Detection without blocking only documents bad outcomes after they occur. Inline action control matters because the same agent runtime can be safe for read-only work and dangerous for destructive or write-capable actions, so the governance question becomes whether policy is applied where execution actually happens.

AI agent security is converging with NHI governance, but the control assumptions are stricter. Agent sessions can be short-lived, multi-tool, and user-mediated, yet still leave behind security-relevant artefacts that must be attributable. Practitioners should treat agent identity as an operational extension of NHI discipline, with added emphasis on runtime evidence and action scoping.

From our research:

• 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.
• For a broader view of identity sprawl and lifecycle control, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Agent connector blast radius: the practical risk is no longer just whether an agent exists, but how many systems it can touch in a single session. Teams that do not inventory connectors, session telemetry, and tool permissions will keep discovering identity exposure only after the fact.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the same visibility problem is now appearing in agent governance. The lesson is that discovery and runtime evidence must be treated as one control plane, not two separate programmes.

For practitioners

• 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. Flag anything outside managed endpoint coverage and treat unknown runtimes as ungoverned identity surfaces.
• 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. Endpoint telemetry alone is not enough for AI agent governance.
• Enforce policy at the tool-call boundary Block destructive operations, mask sensitive data in transit, and scope access so read-only sessions cannot gain standing write capability. Make the policy apply at the moment the agent attempts to act, not after the fact.

Key takeaways

• AI agent governance is now an identity problem because sessions can combine multiple tools, permissions, and decisions in one runtime.
• Endpoint monitoring alone cannot answer the audit question, because it does not capture prompts, tool calls, or session outcomes.
• The practical control stack is clear: discover, scan, observe, and enforce at the tool boundary before agent use spreads further.

Key terms

• Connector blast radius: Connector blast radius is the amount of downstream reach a single integration path gives to an agent or application. A small number of connectors can still create large risk if they can touch sensitive systems, write actions, or privileged data without strong controls.
• Session capture: Session capture records what happened during a privileged access session, such as commands, queries, or screen activity. It creates evidence that supports investigations, audits, and control validation. For infrastructure teams, it is the difference between knowing a session occurred and being able to reconstruct what the identity actually did.
• Tool Call Boundary: The point at which model output is converted into a real system action, such as calling a function, querying a database, or invoking a shell. This boundary must be treated as an authorization checkpoint, because it turns text generation into operational authority.
• Agent Inventory: A governed record of every AI agent in use, including who created it, who can invoke it, what data it can reach, and what actions it can trigger. Without a current inventory, security teams cannot judge whether agent access still matches the business purpose.

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.

👉 The full Onyx article covers the week-one rollout sequence, session telemetry, and tool-call enforcement details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.