Wiz and Pillar link AI discovery with attack-surface validation

At a glance

What this is: The article explains how Wiz discovery and Pillar red-teaming are combined to map AI attack surface and validate runtime risk.

Why it matters: It matters because IAM, NHI, and AI security teams need evidence of how AI workloads behave after exposure is found, not just where they exist.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Pillar Security's analysis of the Wiz partnership for AI discovery and red teaming

Context

AI attack surface mapping is the practice of finding where AI workloads run, what they connect to, and how they can be reached or influenced at runtime. The governance gap is that discovery platforms can show exposure, but they do not prove whether an AI system can be manipulated, bypass controls, or leak data through tools and prompts.

For NHI and IAM teams, that gap matters because AI endpoints behave like identities with runtime privileges, not just software assets. Once models, agents, tools, and data stores are linked together, security needs both inventory and behavioural validation to understand blast radius and control failure.

The primary topic here is agentic AI security, with a strong NHI overlap because the article treats AI systems as connected identities inside cloud environments. That is a typical direction for current enterprise deployments, where cloud visibility and runtime testing are being pulled into the same governance conversation.

Key questions

Q: How should security teams govern AI workloads that connect to tools and data sources?

A: Security teams should govern AI workloads as identity-bearing systems with observable privileges, not as isolated applications. Inventory the workload, map every connected service account and data source, and then validate how the system behaves under adversarial prompting and tool use. The key is to prove runtime behaviour, because static posture alone does not show blast radius or misuse paths.

Q: Why do cloud discovery tools fall short for AI security governance?

A: Cloud discovery tools show where AI workloads exist and what they connect to, but they do not prove how those systems behave when tested. An agent can be visible in inventory and still leak data, expose prompts, or misuse tools at runtime. Governance needs both exposure mapping and behavioural validation before risk is considered understood.

Q: What should teams measure after finding exposed AI endpoints?

A: Teams should measure whether the discovered endpoint can be manipulated, whether it can access sensitive data through tools, and whether the evidence is durable enough for remediation decisions. Useful measures include successful prompt injection attempts, tool discovery results, and the number of validated findings tied back to specific identities or assets.

Q: How do identity and cloud teams share responsibility for agentic AI risk?

A: Identity teams own the privileges, connected accounts, and review process, while cloud teams own exposure, reachability, and workload context. Neither view is sufficient alone. Shared responsibility means validated AI findings must flow into the same governance records used for access decisions, so exposure, privilege, and evidence stay aligned.

How it works in practice

AI discovery vs attack-surface validation

AI discovery answers what exists, where it runs, and what it is connected to. Attack-surface validation asks what that AI system can actually do when probed: whether prompts can be manipulated, whether tools can be discovered, and whether data can be exfiltrated through runtime interactions. The distinction matters because inventory without validation creates false confidence. A workload can appear governed in the cloud graph while still accepting dangerous inputs or exposing sensitive outputs when tested like an adversary would test it.

Practical implication: pair AI inventory with controlled adversarial testing before you trust exposure findings.

Agentic runtime risk and tool-mediated exfiltration

Agentic runtime risk appears when an AI system has enough context, tools, and permissions to act in ways that were not obvious at design time. Tool-mediated exfiltration happens when the agent can use connected services to move data, query systems, or chain actions beyond the original request. In identity terms, the risk is not only access, but how access can be recombined at runtime. That is why posture tools alone are incomplete for agentic systems: privilege has to be observed in motion, not assumed from configuration.

Practical implication: review every AI tool connection as an identity-bearing pathway, not just an integration.

Continuous testing with security-graph feedback

Continuous testing turns one-off red teaming into a repeatable control loop. The article describes scheduled probing that feeds evidence back into a security graph, which means findings become part of the operating picture rather than a standalone report. That architecture is useful because AI behaviour changes as prompts, tools, and connected services change. In governance terms, the control is not only detection, but evidence persistence, so teams can compare risk over time and tie security findings to the assets and identities that matter most.

Practical implication: store validated AI risk evidence where cloud and identity teams already triage exposure.

NHI Mgmt Group analysis

AI discovery without runtime validation leaves a false control boundary: The article shows why cloud visibility alone does not answer the governance question practitioners actually face. A system can be known, mapped, and connected, yet still accept adversarial prompts or unsafe tool use once it is exercised. That means the control boundary is not the asset inventory, but the proven behaviour of the AI workload under pressure. Practitioners should treat discovery as a starting point, not evidence of safety.

AI attack surface mapping is becoming a shared problem between cloud security and identity teams: The article connects workload discovery, connected identities, and runtime testing in one flow. That matters because AI systems now sit inside the same trust graph as service accounts, APIs, and data stores. The field should expect more convergence between NHI governance and agentic AI security, with identity evidence feeding exposure decisions and vice versa. Teams should stop treating AI as an isolated security domain.

Runtime guardrails only make sense once the behaviour gap is visible: The article’s layered model is a reminder that prevention controls need evidence from testing, not assumptions from architecture diagrams. When AI systems can discover tools and move data through connected services, the failure mode is not just misconfiguration. It is an identity and authorisation problem expressed through agent behaviour. Practitioners should evaluate whether their current governance can explain how an AI system behaves when challenged, not just where it is deployed.

Attack-surface evidence must become part of identity governance records: Security findings that remain outside the governance workflow are easy to ignore and hard to operationalise. By feeding red-team evidence back into the security graph, the article points toward a model where AI risk becomes auditable state. That is the direction the market is moving: from static inventory to continuous proof. Practitioners should ensure AI exposure evidence is usable in access review, risk acceptance, and remediation workflows.

Unified AI governance will increasingly be judged by the quality of its evidence chain: The most important shift here is not feature coverage, but how discovery, testing, and reporting are stitched together. Governance programmes will be expected to show traceability from discovered workload to validated risk to resolved control. That raises the bar for NHI and AI security programmes alike. Practitioners should ask whether their controls can produce an evidence chain, not just a dashboard.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Security teams should pair exposure mapping with behavioural evidence, as shown in OWASP Agentic AI Top 10, when AI systems can act through tools and connected accounts.

What this signals

AI attack-surface management is converging with identity governance: once AI workloads are mapped to connected service accounts and data paths, the real programme question becomes who can prove what the system did at runtime. That pushes identity teams toward evidence-based governance rather than asset-based reporting, and it makes Top 10 NHI Issues a useful lens for the connected NHI layer.

With 96% of technology professionals identifying AI agents as a growing security threat, the governance bar is now set by proof, not intent. Teams that can show validated behaviour, linked privileges, and durable evidence will be better placed to handle access review, incident triage, and audit requests.

Validated AI risk is becoming a security-graph problem: when findings are fed back into a shared graph, they can inform exposure decisions across cloud, identity, and application teams. That aligns with the direction of the OWASP Agentic AI Top 10, where tool misuse and identity abuse are treated as runtime risks rather than static configuration issues.

For practitioners

• Map AI workloads to identity-bearing connections Track every AI endpoint alongside the service accounts, APIs, tools, and data stores it can reach so exposure is not assessed as a standalone asset problem. Use the resulting map to identify which connected identities expand blast radius if the model or agent is manipulated.
• Validate runtime behaviour with adversarial testing Test for prompt injection, system prompt extraction, safety bypasses, and data exfiltration through tools rather than relying on design-time reviews. Keep evidence from those tests attached to the workload record so findings can be reused in risk decisions.
• Feed AI findings into governance workflows Route validated exposure and behavioural evidence into access review, exception handling, and remediation queues so AI risk is managed like other identity-linked controls. Link the evidence to the workload and its connected privileges, not just to a vulnerability ticket.
• Review scheduled testing as a control, not a report Treat recurring validation as part of the operating model for AI systems that change often, because one-time assessments age quickly when prompts, tools, and connections evolve. Align the cadence to deployment change rather than to a fixed calendar alone.

Key takeaways

• The article shows that AI discovery alone does not prove safety because runtime behaviour can still expose prompts, tools, and data.
• The evidence base matters: teams need validated findings attached to workloads, not just inventory records or posture scores.
• The practical implication is to link AI exposure, identity privileges, and governance workflows so risk can be reviewed and remediated in one chain.

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.
• Security graph: A relationship map that ties assets, identities, exposures, and evidence together so teams can see how risk propagates across the environment. In AI governance, it helps connect discovered workloads to the privileges and findings that matter for remediation and audit.

Deepen your knowledge

AI discovery, runtime validation, and governance for agentic workloads are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI systems that behave like identities, it is worth exploring.

This post draws on content published by Pillar Security: From AI Discovery to Attack Surface Mapping: Announcing the Wiz + Pillar Partnership. Read the original.