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

At a glance

What this is: This is a comparison of Trust3 AI and Wiz that finds enterprise AI security is splitting into purpose-built agent governance and broader CNAPP coverage.

Why it matters: It matters because IAM and security teams now have to decide whether AI agents need dedicated runtime identity controls or whether cloud-wide posture tooling is enough.

By the numbers:

• According to a survey of 437 enterprise security leaders, enterprises commonly undercount active AI agents by 3 to 10 times.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Trust3's comparison of Trust3 AI and Wiz for AI agent security

Context

AI agent security now sits between two familiar but incomplete models: cloud posture management and identity governance. Traditional CNAPP tools can show where risk exists across code, cloud, and runtime, but they do not automatically answer who or what an agent is, what it is allowed to do, or whether its access should expire with the task.

That gap matters because AI agents are no longer theoretical. They are pulling from data platforms, calling MCP servers, and acting with delegated access in production workflows. Once an agent can initiate actions and touch sensitive data, security teams need to govern it as a non-human identity with runtime accountability, not just as another workload.

The comparison between Trust3 AI and Wiz is therefore less about which product is broader and more about which control problem is being solved. One model is built around agent discovery, observability, and just-in-time authorization. The other correlates AI risk with a wider cloud graph. Both reflect the current state of the market, but most enterprises are still operating with gaps in both visibility and enforcement.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do CNAPP tools alone not solve AI agent security?

A: CNAPP tools correlate cloud and runtime risk, which is useful for prioritisation, but correlation does not decide whether a specific agent action should be allowed. AI agents need runtime enforcement, because the control question is about identity, purpose, and access at execution time.

Q: What happens when AI agents are created without approval or inventory?

A: Shadow agents become ungoverned identities that cannot be reviewed, certified, or retired through normal IAM processes. Once that happens, security teams lose the ability to tie access to an owner, a purpose, or an offboarding event, which creates lasting exposure.

Q: Should organisations run agent security beside CNAPP or replace CNAPP with it?

A: Most organisations will need both. CNAPP gives broad environmental context and attack-path prioritisation, while agent security gives per-action authorization and identity governance for AI agents. The decision is not either-or unless the organisation has no production agent activity.

Technical breakdown

Why AI agent identity needs its own control plane

AI agents behave differently from standard cloud workloads because they can select tools, retrieve data, and execute actions across multiple systems during a live session. That creates an identity problem, not just a monitoring problem. Discovery has to find shadow agents, delegated agents, and ephemeral identities before governance can begin. Observability then has to preserve per-turn traces of prompts, tool calls, and responses so that decisions can be audited at the action level rather than at the workflow summary level.

Practical implication: security teams need inventories and audit trails that resolve agent identity at runtime, not just asset catalogs and aggregate logs.

Runtime authorization for agents versus graph-based risk correlation

CNAPP platforms are strong at correlating risk across code, cloud, and runtime, which helps teams prioritize exposure paths. But correlation is not authorization. When an AI agent attempts to query data or invoke a tool, the control question is whether that specific action should be allowed now, for this purpose, under this identity. Runtime authorization changes the security model from passive detection to active enforcement, which is essential when the agent can act faster than a review cycle can respond.

Practical implication: teams using broad cloud security tooling still need a decision point that can allow or block each agent action as it happens.

MCP servers and delegated agent chains expand the identity surface

Model Context Protocol servers and agent-to-agent communication extend the attack surface because they let tools, data sources, and downstream agents participate in the same workflow. The risk is not simply that an attacker reaches an endpoint, but that identity and purpose can drift across a delegation chain. If the first agent is allowed to act, downstream hops may inherit trust without receiving the same scrutiny. That makes identity propagation and scope control central design concerns.

Practical implication: practitioners should treat MCP servers and multi-agent chains as governed identity paths, not just integration layers.

Threat narrative

Attacker objective: The objective is to use an unmanaged agent identity to reach sensitive data or systems through delegated access that looks legitimate to existing controls.

1. Entry occurs when an AI agent is connected to an unvetted MCP server or deployed without formal approval, creating an unmanaged identity path into data and tools.
2. Escalation happens when the agent inherits delegated access, expands scope across tool calls, or continues with standing permissions that were never narrowed to the task.
3. Impact follows when the agent reads, writes, or discloses sensitive data across platforms such as Snowflake or Databricks without a per-action authorization boundary.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 governance is splitting away from general cloud security. CNAPP and agent-specific control planes are answering different questions. CNAPP correlates cloud and runtime risk, while agent security has to decide who the agent is, what purpose it is serving, and whether it may act at all. Practitioners should stop treating the two as interchangeable layers.

Purpose-based authorization is the right noun for agent security, not role-based expansion. Agents do not need broader roles with more exceptions. They need task-scoped permissions that expire when the action completes. That is a governance model closer to dynamic entitlement control than to traditional workload administration, and it matches the way autonomous systems consume access.

Shadow agents create a discovery problem that most IAM programmes are not organised to solve. The article’s strongest point is that approval-gate models fail at creation time, not just during runtime abuse. If security teams cannot find an agent, they cannot certify it, review it, or retire it. Discovery becomes the first governance dependency, not an operational nice-to-have.

MCP and A2A governance will become the stress test for machine identity controls. The more agents talk to tools and to each other, the more trust has to be propagated, constrained, and revoked in motion. That pushes identity security beyond static registration into runtime policy enforcement across chained non-human actors.

Runtime authorization gap: The distinct failure mode here is not visibility alone but the absence of a control that can approve or block an agent action at the moment of execution. That gap is where existing cloud governance becomes least reliable, and it is where practitioners should expect the next wave of agent abuse to concentrate.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, which means nearly half still lack defensible investigation evidence.
• For a deeper framework view, see OWASP Agentic Applications Top 10 for the control categories that map to this exposure.

What this signals

Runtime authorization gap: AI security is moving toward a split between broad cloud correlation and per-action identity enforcement, and most programmes will need to support both. That means security leaders should expect their current IAM and CNAPP investments to cover only part of the problem, with agent discovery and task-scoped authorization becoming distinct programme workstreams.

With 98% of companies planning to deploy more AI agents within 12 months, the operating assumption has changed from whether agents will exist to whether they will be governable. Teams that wait for a full platform replacement will miss the window to define identity boundaries, audit requirements, and offboarding rules now.

The practical signal is that agent identity is becoming a governance category of its own, with links to the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework both relevant to policy design.

For practitioners

• Inventory agents before you rationalise platforms Build a living inventory of AI agents, MCP servers, and delegated identities across development and production environments. Include shadow agents that were never ticketed, because governance cannot begin with partial discovery.
• Separate correlation from enforcement Keep CNAPP-style graph correlation for prioritisation, but add runtime authorization for each agent action at the data source or tool boundary. Without that second control point, you can see risk but not stop it.
• Scope access by task purpose and expiration Replace standing access for agents with just-in-time grants that expire automatically after the declared task. Tie the grant to purpose, the data source, and the specific action path so reuse is not possible by default.
• Trace prompts, tool calls, and responses together Preserve per-turn audit evidence so investigators can reconstruct what the agent saw, what it chose, and which tools it invoked. Sampled logs are not enough when the security question is action-level accountability.

Key takeaways

• AI agent security is no longer just a visibility problem, because runtime identity and action control now sit at the centre of governance.
• Cloud-wide correlation helps with prioritisation, but it does not replace per-action authorization for agents that can touch data and tools in production.
• Enterprises that cannot inventory shadow agents or expire access by purpose will struggle to prove control over autonomous activity.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority — API access, file writes, workflow triggers — the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• 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.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Per-Turn Audit Trail: A per-turn audit trail records each prompt, tool call, and response as a discrete security event. It gives investigators evidence of what the agent saw and did, rather than a summary that hides the exact decision path behind the action.

What's in the full article

Trust3's full article covers the operational detail this post intentionally leaves for the source:

• Side-by-side feature comparison of Trust3 AI and Wiz across discovery, observability, and runtime enforcement.
• Tool and platform integration detail for Snowflake, Databricks, BigQuery, Copilot Studio, and MCP-connected environments.
• Per-turn audit and authorization workflow examples that show how access decisions are made in practice.
• Deployment and compliance mapping detail for teams evaluating agent governance in production.

👉 Trust3's full article covers the comparison matrix, runtime control model, and deployment considerations in more detail.

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 identity policy or maturing your security programme, it is worth exploring.