Four guardrails for safe AI agent adoption in enterprise IAM

At a glance

What this is: Onyx argues that safe AI agent adoption depends on four week-one guardrails: inventory, configuration scanning, session capture, and tool-call enforcement.

Why it matters: IAM teams need to govern AI agents as runtime identities, because broad tool access, hidden configuration changes, and weak audit trails can turn routine usage into uncontrolled privilege and data exposure.

Context

AI agent governance is the problem of controlling what an agent can access, what it can do with tools, and what evidence exists after the session ends. In this article, Onyx frames the issue as a gap between adoption and oversight rather than a question of whether agents should exist at all.

The operational failure is not hidden in theory. Security teams are learning about agent use through tickets, not approvals, and the controls that work for static human access do not explain prompt, tool-call, or file-write activity inside a live agent session.

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. It is the absence of visibility into agent inventory, active instruction sets, and connected tools, which means the security team cannot govern what it cannot see. Without that baseline, access decisions, risk review, and enforcement are all built on incomplete information.

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. That means a compromise can move from data exposure to active execution much faster than in a traditional web app. The risk is not just stolen data, but uncontrolled use of the identity and permissions attached to the agent.

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. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

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.

Technical breakdown

Why agent inventory is the first control plane

Agent inventory is the discovery layer for runtime identities. The article treats every agent installation, instruction set, and connected MCP server as part of the governable surface. That matters because a security team cannot scope policy, review exposure, or measure compliance if it cannot see where agents are running and which tools they can reach. In practice, the inventory must include both managed endpoint coverage and the agent configuration artifacts that define behaviour. This is the difference between knowing a developer uses an agent and knowing what that agent can touch.

Practical implication: discover every agent runtime and connected MCP server before broad access is approved.

Why agent configurations behave like code

Agent configuration files are not passive settings. They define instructions, tool scope, URL fetch behaviour, and credential handling, which makes them a pre-execution risk surface. If the configuration pulls untrusted content, stores secrets in plaintext, or grants overly broad tool permissions, the problem exists before the model ever runs. That changes the governance model from a runtime-only control to a configuration posture problem. Security teams need to review the declared behaviour of the agent the same way they would inspect code or policy-as-code, because the configuration is effectively part of the identity's authority.

Practical implication: scan agent instructions and workflow definitions before execution, not after a session starts.

Why session-level audit is different from endpoint monitoring

Endpoint detection and response tells you a process executed, but not what the agent decided, which tool it called, or what data it read and wrote. Session capture closes that gap by preserving the prompt, tool calls, model responses, and resulting actions as a single record tied to user identity and device. That record is what makes an agent session auditable in a way EDR cannot replicate. For IAM and security teams, the key architectural shift is that governance must attach to the session, not just the endpoint or account.

Practical implication: retain session records that link prompt, tool use, and resulting actions to the accountable user.

Threat narrative

Attacker objective: The objective is to turn agent-mediated workflow access into destructive changes or sensitive data exposure while reducing the organisation's ability to audit the action.

1. Entry occurs when developers adopt AI agents through normal workflow tools and connect them to Jira, GitHub, databases, or other MCP-backed systems without formal review.
2. Credential or authority exposure occurs when the agent inherits broad tool permissions, unreviewed instruction sets, or insecure MCP configurations that expand its effective access.
3. Escalation and impact occur when the agent issues destructive or data-exposing tool calls, and the security team lacks session evidence to reconstruct what happened or stop the action at the boundary.

Breaches seen in the wild

• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group 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.

Session auditability is the missing governance primitive for AI agents. Static access models can tell you who had access, but they cannot reconstruct what an agent did across prompts, tool calls, and file writes. That makes the audit trail itself a control requirement, not a reporting feature. The field needs to accept that agent sessions generate their own evidence chain, and governance fails when that chain is missing or fragmented. Practitioners should elevate session-level evidence to the same status as entitlement records.

Tool-call enforcement is where agent identity becomes operationally governable. Broad tool access turns a routine workflow into an identity blast radius problem, especially when MCP-connected tools span tickets, code, and databases. The meaningful control is not the model's reasoning quality but the policy boundary at the moment a tool is called. That is where destructive actions, sensitive data masking, and just-in-time scoping can be enforced in a way users and auditors can both understand. Practitioners should verify the boundary, not the model.

Instruction sets are a supply chain for behaviour, not just for configuration. The article is right to treat every agent configuration as code, because malicious or unreviewed instructions change what the agent is allowed to infer and execute. That means governance has to account for provenance, review, and ongoing change control of the agent's behaviour layer. In identity terms, the configuration becomes part of the trust perimeter. Practitioners should manage instruction provenance as rigorously as any privileged policy artifact.

Runtime visibility is what separates a controlled pilot from shadow AI. The article's inventory-first sequence is really a discovery model for unmanaged agent identity. If the security team cannot see the runtime, the instruction set, and the connected tools, then the agent is outside the governance program even if it was installed for productivity. That is the operational boundary between accepted use and shadow AI. Practitioners should define visibility as the threshold for policy eligibility.

From our research library:

• 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.
• Read next: AI Agent Authorisation Guide

What this signals

Session visibility is the boundary between managed use and shadow AI. Security teams should not measure agent adoption by installation counts alone. The programme question is whether every active runtime, instruction set, and connected tool is visible enough to be governed before a destructive session completes.

Tool-call policy needs to move closer to identity issuance. For agents, the old assumption that permissions are stable enough to review later is weak. The control has to be expressed at the moment access is used, especially when a session can write, delete, or fetch sensitive data across multiple systems.

AI agent governance now spans human IAM, NHI, and operational control. The same organisation may need human approval models for adoption, NHI-style lifecycle thinking for connected tool credentials, and runtime enforcement for agent behaviour. The point is not to merge those disciplines, but to stop pretending a single static access review can cover them all.

For practitioners

• 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.
• Enforce policy at the tool-call boundary Block destructive operations, mask sensitive data in transit, and scope just-in-time access so a read-only session cannot quietly gain write capability.
• Calibrate controls in week one Start with alert-only enforcement, review the first week of session data, and harden policy once the team understands the normal pattern of agent behaviour.

Key takeaways

• AI agent adoption is already happening inside enterprise workflows, which makes visibility and control a live governance issue rather than a future planning topic.
• The main gap is not whether the agent exists, but whether the organisation can prove what a session did and restrict what it can do next.
• Inventory, configuration review, session capture, and tool-call enforcement form the minimum control stack for governable AI agent use.

Key terms

• Agent Session Chain: An agent session chain is a sequence of child sessions derived from a root session, where each hop records lineage back to the original authority. It allows an agent to split a long job into smaller, separately revocable units while keeping identity and scope tied to the same underlying agent instance.
• 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.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme, it is worth exploring.