Claude Enterprise governance now extends to AI agent actions

At a glance

What this is: Zenity’s Claude Enterprise integration focuses on governing AI agent activity, tool invocations, and audit trails across enterprise workflows.

Why it matters: This matters because IAM, PAM, and governance teams now need controls that follow autonomous or semi-autonomous actions across tools, data, and delegated enterprise access.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read Zenity's analysis of Claude Enterprise agent governance and security

Context

AI agent governance is moving from theory to control-plane design. In Claude Enterprise, agents are not just generating text, they are invoking tools, touching enterprise systems, and acting across workflows that include sensitive data and operational actions.

For identity teams, that changes the problem from model oversight to identity governance. The control question is no longer only whether the system is trusted at login, but whether the agent’s actions, tool access, and auditability are governed tightly enough to withstand real enterprise use.

Key questions

Q: How should security teams govern AI agents that can invoke enterprise tools?

A: Start by treating the agent as a governed identity with scoped access, not as a chat feature. Map every tool, plugin, and connected application it can reach, then apply approval, logging, and periodic review to those access paths. The goal is to constrain what the agent can do, not just observe what it says.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: Because IAM and PAM are usually designed around stable identities and predictable request flows. AI agents can select tools dynamically, cross application boundaries, and act at runtime in ways that make static permission models harder to certify. That creates a governance gap between granted access and actual behaviour.

Q: What do organisations get wrong about prompt injection in enterprise agents?

A: They often treat prompt injection as a content issue instead of an action issue. The real risk appears when injected instructions change tool use, data access, or downstream actions. Detection must therefore focus on whether the agent’s behaviour diverged from policy, not only whether suspicious text appeared.

Q: Who is accountable when an AI agent takes an unauthorized action?

A: Accountability usually sits with the organisation that granted the agent its access, configured its tools, and failed to define clear approval boundaries. That is why audit trails, lifecycle review, and ownership of each connected capability matter. If the agent can act, someone must own the decision to let it act.

How it works in practice

Tool invocation governance in Claude Enterprise

Claude Enterprise agents can invoke tools, plugins, skills, and connected systems during workflow execution. That means the security boundary is not the model prompt alone, but the entire action path from agent decision to external system call. In identity terms, the risky object is the delegated execution path, where a user-facing agent can inherit or trigger access into downstream systems. Governance therefore has to track not just authentication, but the sequence of actions, the tools available, and the data touched along the way.

Practical implication: security teams need policy controls around tool access, not just model access.

Audit trails and forensic visibility for agent actions

The integration emphasises detailed audit trails for agent activity, configuration settings, and tool invocations. That matters because traditional IAM logs often show who authenticated, but not whether an agent selected the right tool, used the right scope, or crossed into an unintended workflow. For AI agents operating inside enterprise applications, action-level telemetry becomes the evidence layer for investigations, compliance, and behavioural containment.

Practical implication: teams should require action-level logs that tie agent decisions to downstream system calls.

Prompt injection, credential exposure, and unauthorized actions

Zenity frames the threat set around prompt injection attempts, credential exposure, and unauthorized agent actions. Those are different failure modes with different controls. Prompt injection seeks to redirect the agent’s behaviour, credential exposure turns the agent into a leverage point for secrets abuse, and unauthorized actions reveal where governance failed to constrain execution. The core issue is that once an agent can act across applications, control failure propagates faster than in a single-system model.

Practical implication: defenders need layered controls that address instruction integrity, secret handling, and action approvals together.

NHI Mgmt Group analysis

Agent governance is now an identity problem, not a model problem. Once Claude Enterprise agents can invoke tools, act on behalf of users, and touch connected systems, the relevant control surface shifts into IAM and governance. Security teams are no longer just reviewing outputs, they are governing delegated action. That makes agent identity, tool scope, and auditability first-class security objects, not secondary monitoring fields.

Action-level evidence is the new minimum for AI agent oversight. Traditional access logs prove that a session existed, but they do not prove whether the agent stayed within policy when selecting tools or crossing application boundaries. The field needs telemetry that can explain why an agent took a specific action and what downstream system it touched. Without that evidence, investigations become guesswork and containment arrives too late.

MCP server governance is becoming a control-plane issue for agentic identity. The article’s emphasis on discovering and governing MCP servers, plugins, and skills shows where enterprise risk is moving. These components are effectively capability brokers for agents, so their approval status, scope, and lifecycle matter as much as the agent itself. The practitioner implication is simple: if the tool layer is not governed, the agent layer cannot be trusted.

Visibility without behavioural constraint is only partial control. Zenity highlights visibility into agent activity, but visibility alone does not stop risky execution. The security program has to decide where agent autonomy is acceptable, where tool use must be constrained, and where human review remains mandatory. In practice, this is where identity governance and runtime enforcement need to converge.

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.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a broader control lens, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives for how lifecycle and audit obligations map to non-human access.

What this signals

MCP governance is becoming the practical hinge point for agentic identity. As more enterprise workflows expose tools, plugins, and skills to AI agents, the control challenge shifts to capability management. Security teams should expect policy review, recertification, and audit requirements to move down into the tool layer, where agent access actually becomes operational.

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 ecosystems. The next programme priority is not only discovery, but deciding which connected capabilities an agent should never be allowed to reach.

Agent action drift: the point at which an agent’s permitted objective and its actual tool use diverge. That is the metric identity teams will need if they want to distinguish safe delegation from unmanaged autonomy, especially where agents interact with sensitive systems and production workflows.

For practitioners

• Inventory every Claude-connected agent pathway Map which agents can invoke tools, access enterprise applications, or act on behalf of users across Claude Code, Cowork, and Chat. Treat connected systems, plugins, and skills as governed access paths, not convenience features.
• Bind audit trails to agent actions, not just logins Require records that show the agent’s tool invocation, configuration state, and downstream system call for each meaningful action. Use those records for investigations, compliance review, and exception handling.
• Put policy around MCP servers and skills Approve, review, and periodically recertify each Model Context Protocol server, plugin, and skill that an agent can reach. If a capability changes the agent’s reach, it needs the same lifecycle scrutiny as any other privileged access path.
• Separate prompt integrity from secret handling controls Assume prompt injection and credential exposure are distinct failure modes. Use content controls to reduce instruction manipulation and separate secret governance to limit what an agent can reveal or misuse when context is compromised.
• Define where agent autonomy ends Set explicit boundaries for actions that must stop at approval, especially where agents can touch production systems, sensitive data, or operational workflows. The decision point should be documented before deployment, not improvised after an incident.

Key takeaways

• AI agent governance now sits at the intersection of IAM, PAM, and runtime enforcement, because tool access is where enterprise risk becomes real.
• Visibility matters, but action-level telemetry is what turns agent activity into something security teams can investigate and control.
• The control problem is no longer limited to prompts or model output, because the dangerous moment is when an agent is allowed to act across systems.

Key terms

• Agentic identity: An identity assigned to software that can choose actions at runtime, select tools, and execute without waiting for a human at every step. In practice, this means the identity must be governed by behaviour, scope, and auditability rather than by static authentication alone.
• Tool invocation: The act of an agent calling an external system, plugin, or service to complete a task. It is the point where an abstract model decision becomes an operational access event, which is why identity teams need policy, logging, and review around each invocation.
• Model Context Protocol server: A service that exposes tools and data to an AI agent through a standard interface. For security teams, it functions like a capability broker, because whoever governs the server’s scope and lifecycle also shapes what the agent can reach and do.
• Action-level audit trail: A log record that shows what an agent did, which tool it used, what configuration was active, and what downstream system it touched. This is more useful than a login log for investigations because it ties identity behaviour to operational impact.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: Zenity extends AI agent security and governance to Claude Enterprise. Read the original.