Wiz and Pillar link AI discovery with attack-surface validation

At a glance

What this is: This is a partnership announcement showing how cloud AI discovery and autonomous red-teaming are being linked to validate agentic AI attack surfaces, connected identities, and runtime risk.

Why it matters: It matters because IAM and security teams need evidence about what AI workloads can actually do, not just where they exist, especially when connected identities and tools expand blast radius.

Context

Cloud AI discovery tells you where AI workloads exist and what they connect to. It does not prove whether an exposed agent, model endpoint, or tool chain can be manipulated at runtime. That gap matters for agentic AI because the identity and authorisation picture changes once the system can select tools, interact with data, and trigger actions during execution.

This announcement is about closing the gap between visibility and validation. Wiz provides the cloud context, while Pillar Security feeds evidence from adversarial testing back into the security graph so teams can see whether discovered AI assets are exposed in practice, not just in posture reports.

For identity programmes, the key issue is that AI attack surface is no longer a theoretical layer above infrastructure. It is the place where workload identity, connected data, tool access, and runtime behaviour converge, which is why static inventory by itself leaves governance unanswered.

Key questions

Q: How should security teams handle AI workloads that are visible in cloud inventory but untested at runtime?

A: Treat cloud discovery as the inventory layer and require adversarial validation before declaring an AI workload acceptable. Visibility shows what exists and what it connects to, but it does not prove the system cannot be manipulated through prompt injection, unsafe tool use, or data exfiltration paths.

Q: Why do connected identities make agentic AI attacks more dangerous than model exposure alone?

A: Because the risk is not the model in isolation, but the authority it inherits from tools, APIs, and data services. Once an AI workload can act through connected identities, a compromise can expand into broader access, workflow abuse, or exfiltration beyond the original prompt boundary.

Q: What are the signs that an AI attack surface review is failing?

A: A review is failing when it only lists AI assets and cannot show whether exposed endpoints were actually exercised against prompt injection, tool abuse, or data leakage scenarios. If the output stops at posture, you still do not know how the workload behaves under adversarial pressure.

Q: Should teams prioritise runtime validation or cloud discovery for AI security first?

A: Discovery should come first because you cannot test what you have not found, but runtime validation becomes the decisive control once assets are identified. The practical order is inventory, then adversarial testing, then remediation based on validated behaviour and connected blast radius.

How it works in practice

Cloud AI discovery does not prove runtime safety

Cloud discovery tools can tell you where AI workloads run, which services they touch, and which identities they inherit. That is useful inventory, but it is not a behavioural test. Agentic systems can still be vulnerable to prompt injection, prompt leakage, unsafe tool use, or exfiltration paths that only appear when the model, tools, and data are exercised together. The technical difference is between knowing an asset exists and knowing how it behaves under adversarial interaction. For AI security, posture data and runtime evidence answer different questions, and one does not substitute for the other.

Practical implication: treat AI discovery as the starting point and require adversarial validation before declaring an AI workload safe.

Why connected identities and tool access expand AI blast radius

When an AI workload is connected to cloud services, data stores, and external tools, the risk is not just model compromise. The risk is privilege amplification through the surrounding identity chain. An agent with access to tools can move from conversational input to operational action, and a compromise can convert that delegated access into broader data exposure or workflow abuse. In identity terms, the blast radius is determined by what the workload can reach, not only by what it is. That makes connected identities, service permissions, and tool scopes central to the AI attack surface.

Practical implication: map every AI workload to the identities, APIs, and data paths it can reach before allowing production access.

Autonomous red-teaming turns exposure into evidence

Autonomous red-teaming matters because it tests the AI endpoint the way an attacker would, not the way a posture report assumes it behaves. The value is evidence-backed validation: recorded interactions, observable failures, and concrete proof that a prompt, tool, or policy boundary can be crossed. In agentic environments, that evidence is more useful than theoretical risk scores because the security question is behavioural. If an agent can be induced to leak context, reveal tools, or exfiltrate data through a permitted interaction, the control failed at runtime, regardless of how clean the inventory looked.

Practical implication: prioritise evidence from adversarial tests over static risk labels when deciding which AI systems need containment or policy changes.

NHI Mgmt Group analysis

AI discovery is necessary, but it does not establish security. Inventory tells teams where agentic workloads exist and what they connect to, yet runtime behaviour is still the governing risk. In practice, that means the security question shifts from exposure alone to whether the workload can be manipulated into unsafe action. Practitioner conclusion: treat discovery as evidence of presence, not proof of control.

Agentic attack surface is defined by delegated reach, not model existence. The important question is not whether an AI model is deployed, but which identities, services, and data paths it can influence once it is live. That is why cloud context and behavioural testing must be paired. Practitioner conclusion: map the AI workload's effective authority, not just its deployment location.

Runtime validation is now part of identity governance for AI workloads. If an AI system can issue actions through tools or connected services, then governance must account for what it can do at execution time. This is not a posture-only problem, and it is not solved by static review cycles. Practitioner conclusion: move AI governance toward continuous validation of delegated access.

Continuous evidence beats theoretical risk scoring in agentic environments. Security teams need proof of whether prompt leakage, tool misuse, or policy bypass is actually possible in context. That is the difference between a catalogue of AI assets and a defensible control stance. Practitioner conclusion: base remediation priority on validated exploitability, not inventory completeness.

Identity security for AI is converging with cloud security operations. The article shows that AI governance, workload identity, and cloud exposure are now the same operational discussion. Teams that keep them separate will miss the combined blast radius created by model behaviour plus service access. Practitioner conclusion: align cloud security, IAM, and AI governance around one shared evidence model.

From our research library:

• A May 2025 Gartner poll of 147 CIOs and IT leaders found that 24% had already deployed AI agents, 50% were experimenting and 17% planned to deploy by the end of 2026.
• Read next: Agentic AI Identity Maturity Model

What this signals

Validated AI exposure will become the governance baseline: security teams will increasingly be judged on whether they can prove an agentic workload behaved safely, not just whether it was discovered. That pushes AI governance toward continuous testing, evidence capture, and shared ownership between IAM and cloud security teams.

Blast radius now belongs in the AI security conversation: once a model or agent inherits service identities, the question is no longer whether it exists in the environment but how far it can reach if manipulated. That is why connected identities, tool scopes, and data paths must be reviewed together, not as separate programme tracks.

One-third of approximately 500 organizations surveyed by McKinsey in 2026 report maturity level three or higher across agentic AI governance controls, according to the 2026 Infrastructure Identity Survey. That gap explains why discovery-only programmes are still common and why validated runtime testing is becoming the differentiator.

For practitioners

• Map AI workloads to connected identities Inventory every AI workload, its service identities, and the data stores or tools it can reach so you know the true blast radius before deployment.
• Validate runtime behaviour with adversarial tests Test exposed AI endpoints for prompt injection, prompt leakage, tool discovery, safety bypasses, and data exfiltration paths using evidence-based red-teaming.
• Feed findings back into cloud security workflows Use validated AI findings to enrich cloud security graphs and prioritisation so remediation reflects actual exploitability rather than static posture labels.
• Review tool scopes and delegated access Check whether AI agents can reach more tools, APIs, or data than their job requires, especially where cloud identities inherit broad permissions.

Key takeaways

• AI discovery tells teams where agentic workloads exist, but it does not prove those workloads are safe under adversarial pressure.
• The real risk comes from the identities, tools, and data paths an AI workload can reach once it is live.
• Security teams need runtime validation and evidence-backed testing to separate exposed AI assets from exploitable ones.

Key terms

• Agentic AI attack surface: The set of AI workloads, tools, prompts, and connected services that can be influenced or abused at runtime. It includes not only the model itself but also the identities and integrations that let the system act. For governance, the surface is defined by behaviour as much as by deployment.
• Runtime validation: A control practice that tests how an AI system behaves while it is connected to real tools and data, rather than only reviewing configuration or design documents. It matters because agentic systems can appear safe on paper and still fail when prompted, chained, or given access to connected services.
• Connected identity: A service account, token, API permission, or other non-human identity that an AI workload uses to reach tools or data. In agentic environments, connected identity is what turns a model from a responder into an actor with blast radius.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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