Trust3 AI and Wiz expose the split between agent security and CNAPP

At a glance

What this is: This is an analysis of how Trust3 and Wiz split the AI security problem between purpose-built agent governance and broader CNAPP coverage.

Why it matters: It matters because identity teams now have to decide whether agent discovery, runtime authorisation, and data-layer control belong inside a cloud platform or a dedicated agent security plane.

By the numbers:

• Most enterprises undercount active agents by 3 to 10 times, according to Trust3.
• According to a survey of 437 enterprise security leaders, most enterprises don’t have a complete inventory of their AI agents.

Context

AI agent security is becoming its own governance problem because agents can discover data, call tools, and act across platforms without fitting neatly into traditional cloud posture models. In this article, Trust3 contrasts that problem with CNAPP, showing why agent discovery and runtime authorisation are not the same control layer as infrastructure correlation.

The practical issue for identity teams is that AI agents behave like non-human identities with delegated access, but their permissions are often created outside normal approval and ownership workflows. Once agents can query Snowflake, write to Databricks, or call MCP servers, the security question shifts from posture visibility to whether access can be scoped and revoked at the moment of action.

This is a market comparison piece, not a benchmark or product review. The underlying question is how much of agent governance belongs in broader cloud tooling versus a control plane built specifically around agent identity, observability, and per-request enforcement.

Key questions

Q: What breaks when AI agents are governed only through CNAPP visibility?

A: Visibility alone leaves a gap between knowing an agent exists and controlling what it can do at runtime. CNAPP can correlate code, cloud, and runtime risk, but it does not necessarily enforce request-time purpose or prevent a single agent action from crossing a sensitive boundary. That is why agent identity needs a separate authorisation layer.

Q: Why do AI agents create more cloud access risk than human users?

A: AI agents can chain API calls quickly, interact with multiple services in one session, and operate without the familiar human signals that security tools expect. That makes over-permissioned access harder to spot and faster to abuse. In practice, the risk comes from effective privilege, not just who initiated the action.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: Should teams centralise AI agent security inside CNAPP or use a dedicated control plane?

A: Use both when agents are in production. CNAPP is better for broad environment context and attack-path correlation, while a dedicated control plane is needed when the question is whether an agent may perform a specific action right now. The decision usually turns on runtime enforcement, not just asset visibility.

Technical breakdown

Why agent discovery is a separate control problem from cloud inventory

Agent discovery matters because many AI agents are created in developer tools, copilots, or workflow layers without a formal asset record. In NHI terms, these are shadow identities with delegated authority, not just another workload. CNAPP tools can show cloud assets and correlated exposure, but that is different from establishing who or what the agent is, what purpose it serves, and whether it exists outside approved governance. When a tool can be connected in an afternoon and begin acting immediately, inventory lag becomes an identity risk, not just a documentation issue.

Practical implication: Treat agent inventory as an identity control surface and require explicit ownership and approval for every agent before it can act.

Per-turn observability and runtime authorization for AI agents

Per-turn observability means capturing each prompt, tool call, and response as a discrete security event, rather than relying on summary logs. That matters because agent behaviour can drift within a session, and prompt injection or tool misuse may only be visible at the point of action. Runtime authorisation moves the decision from static role assignment to request-time policy, so the agent is only allowed to perform the specific action it is attempting right now. This is a different governance model from post-hoc correlation or periodic review, because the control must decide before the agent completes the action.

Practical implication: Require request-time enforcement for sensitive agent actions and preserve immutable traces for every tool invocation.

How MCP servers and data platforms expand the attack surface

MCP servers, Snowflake, and Databricks are not just integrations. They are privileged interaction points where agents can reach data and external tools. Once an agent can chain through MCP and data platforms, the main risk becomes over-broad delegated access that survives longer than the task itself. A CNAPP graph can help correlate those connections, but a purpose-built agent plane can enforce purpose-based access at the source. The distinction is architectural: one layer sees exposure across the environment, the other constrains what the agent can do inside the session.

Practical implication: Map every agent-to-tool and agent-to-data path, then decide whether each path needs visibility, enforcement, or both.

Threat narrative

Attacker objective: The objective is to get an agent to perform unauthorised actions or expose data through delegated access that was never tightly scoped.

1. Entry occurs when an AI agent is created in a developer or workflow environment and connected to a tool or MCP server outside formal approval.
2. Credential or access exposure follows when the agent inherits broad delegated permissions to data platforms, APIs, or external actions.
3. Escalation happens when the agent uses standing access across multiple systems, expanding what it can read, write, or trigger beyond its immediate task.
4. Impact is the uncontrolled execution of agent actions across data and tools, with security teams unable to intervene at request time.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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 security and CNAPP are solving adjacent but non-identical identity problems: CNAPP excels at correlating cloud risk, but it does not by itself answer who the agent is, what it is allowed to do right now, or whether that permission should exist for this specific action. Trust3's framing reflects a broader shift in identity governance: AI agents are now operational actors, not just workloads with cloud metadata. Practitioners should stop treating agent visibility as a substitute for agent authorisation.

Purpose-based access control is a more accurate model for AI agents than role assignment: Static roles describe identity categories, but agents act through task intent and ephemeral context. That makes request-time purpose more relevant than a pre-baked role, especially when the same agent may touch Snowflake, Databricks, or an MCP server in one workflow. The implication is that identity programmes need to govern action purpose, not only entitlements.

Shadow agents create an assumption gap that traditional approval workflows do not close: Approval-gate models assume the system exists in a queue long enough to be reviewed before first use. That assumption weakens when developers can spin up agents inside toolchains and connect them immediately to data and APIs. The governance implication is not just faster discovery, but a redefinition of what counts as a governed identity.

Identity blast radius for AI agents: The real control question is how far an agent can move once it has a valid session, not whether the platform can see the asset. If access is standing, broad, or reusable, the blast radius expands across data stores and toolchains even when monitoring is strong. Identity teams should judge their agent control model by how tightly it constrains action scope at runtime.

Continuous audit evidence is becoming an identity requirement, not a compliance afterthought: Per-turn traces create a record of what the agent did, but the deeper value is that they expose whether authorisation happened at the right moment. That moves audit from a retrospective reporting task to a live governance signal. Organisations should treat traceability as part of the control itself, not just the evidence pack.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Agent governance is moving from inventory to enforcement: security teams can no longer stop at discovering that agents exist, because the control failure usually appears when the agent is allowed to act with standing access. The programme shift is toward request-time authorisation, immutable traces, and ownership for every deployed agent.

Purpose-based access is the emerging operating model for agent identity: agents do not fit cleanly into the old role-centric model when the same identity can query data, call tools, and trigger downstream workflows in one session. Identity teams should expect more pressure to validate intent at runtime, not just assign entitlements at build time.

For practitioners

• Map every production AI agent to an owner and purpose Build a current inventory of agents, including shadow agents in developer tools, copilots, and workflow systems. Record the human or team responsible, the declared purpose, and the systems each agent can reach.
• Separate cloud exposure review from agent authorisation Use CNAPP for environment-wide correlation, but add a distinct control for request-time approval of agent actions. Do not assume posture visibility means the agent can safely act.
• Scope MCP and data-platform access to the current task Limit Snowflake, Databricks, and MCP access to the exact operation the agent is performing, then expire that access when the task ends. Standing access should not be the default for agent workflows.
• Preserve per-turn traces for sensitive agent actions Log prompts, tool calls, responses, and authorisation decisions as an immutable sequence so drift, injection, or misuse can be reviewed later. Summary logging is not enough for agent governance.

Key takeaways

• AI agent security cannot be reduced to cloud posture, because the real governance problem is whether an agent can be authorised at the moment it acts.
• The article frames shadow agents, MCP servers, and data-platform access as a runtime identity problem, not just an observability problem.
• Identity teams should separate environment-wide risk correlation from purpose-based access enforcement if they want agent governance to hold in production.

Key terms

• Agent Discovery: Agent discovery is the process of finding every AI agent across cloud platforms, low-code tools, repositories, and deployment pipelines. It matters because governance cannot start until the organisation can see where the agent exists, who owns it, and what it can reach.
• Per-Turn Observability: A logging and tracing model that records each prompt, tool call, and response as a discrete security event. For autonomous or agentic systems, it provides the evidence needed to detect drift, replay behaviour, and prove whether authorisation happened at the right moment.
• Purpose-Based Access: An access model that allows or denies AI use based on why the request is being made, not only who the requester is. It is more precise than role alone because it can combine identity, data labels, and request context to control sensitive AI interactions at runtime.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

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 programme, it is worth exploring.