AI security roles are shifting as data becomes executable

At a glance

What this is: This is a Pillar Security opinion piece arguing that core security roles are being reshaped by AI-native threats and controls.

Why it matters: It matters because IAM, NHI, and security governance teams now have to account for AI systems that behave like new identities, new attack surfaces, and new control planes at once.

👉 Read Pillar Security's analysis of how AI is reshaping security roles

Context

AI security roles are changing because the underlying control problem has changed. Data can now drive runtime behaviour, and AI systems can act on it in ways that traditional security roles were not built to manage. For IAM and governance teams, that means the boundary between identity, policy, and execution is getting thinner, not wider.

The article frames this as a role evolution across penetration testing, GRC, cloud, DevSecOps, and infrastructure security. The practical issue is not only new tooling, but new accountability for how AI systems are discovered, governed, monitored, and constrained across the environment.

Key questions

Q: How should security teams govern AI systems that can act on data at runtime?

A: They should treat AI systems as governed actors with explicit ownership, policy boundaries, logging, and review. The key is to control how data influences behaviour at runtime, not just to approve the system before deployment. That means combining inventory, access oversight, and monitoring into one operating model.

Q: Why do AI systems complicate traditional access and governance models?

A: AI systems complicate traditional models because they can transform input data into actions, decisions, and outputs without the same fixed execution path as conventional software. That makes static approval and inventory controls insufficient on their own. Teams need runtime visibility and accountable ownership to keep pace.

Q: What do security teams get wrong about shadow AI?

A: They often treat shadow AI as a discovery problem only. In practice, discovery is the start of governance, not the end. Once an AI system is found, teams still need ownership, policy binding, telemetry, and a lifecycle process that prevents unmanaged use from becoming permanent.

Q: How can organisations tell whether AI guardrails are actually working?

A: They should test whether the guardrails still hold when inputs are adversarial, ambiguous, or intentionally misleading. If a model can leak sensitive data, bypass intended restrictions, or produce unauthorised actions under pressure, the control is not effective enough for production use.

Technical breakdown

AI-native attack surfaces in testing and AppSec

The article treats prompt injection, jailbreaking, model extraction, and data leakage as distinct AI-era threats that sit alongside familiar application flaws. That is the right technical frame. Prompt injection manipulates model behaviour through input content, while model extraction and inversion attack the confidentiality of the model or its training data. For AppSec, the shift is from static validation of code paths to runtime evaluation of how a model interprets and acts on data. Practical control design has to account for AI output handling, input sanitation, and misuse of embedded AI features.

Practical implication: Practitioners need test plans that include AI red teaming, model abuse cases, and output-control validation, not just traditional application testing.

Runtime guardrails and AI governance across security roles

Runtime guardrails are the core control idea in the piece because AI systems are described as context-aware, dynamic, and able to leak or transform data during operation. In governance terms, that means controls cannot stop at design-time approvals or inventory registers. The article also points to AI-specific compliance layers such as ISO 42001 and NIST AI RMF, which map to governance, measurement, and accountability rather than pure detection. The technical issue is that AI systems need policy enforcement during inference, not only after deployment.

Practical implication: Teams should align policy, logging, and approval boundaries to runtime AI behaviour, especially where AI outputs affect data exposure or privileged action.

Shadow AI discovery and AI agent controls in infrastructure

The infrastructure section is really about visibility and control plane sprawl. The article says shadow AI discovery, AI agent controls, and unified governance now sit beside IDS, IPS, and PAM. That matters because AI workloads are ephemeral, distributed, and often invisible to conventional asset management. The control challenge is not simply whether an AI system exists, but whether it can be monitored, bounded, and tied to an accountable owner across cloud and platform layers. Without that linkage, infrastructure teams cannot enforce policy consistently.

Practical implication: Security teams should extend discovery, telemetry, and ownership mapping to AI workloads and agentic services before treating them as governed assets.

NHI Mgmt Group analysis

AI security is becoming an identity problem, not just a model problem. The article shows that penetration testing, cloud security, DevSecOps, and GRC are all being pulled toward the same issue: who or what is allowed to act on AI-generated decisions. That is an identity governance problem because runtime authority, not just technical capability, now determines risk. Practitioners should treat AI systems as governed actors, not isolated features.

Shadow AI is the clearest proof that discovery now precedes control. If teams cannot see AI deployments, they cannot bind them to ownership, review, or policy enforcement. The article's infrastructure and CISO sections point to a familiar control failure: unmanaged assets create unmanaged decisions. The practical conclusion is that AI discovery has to be part of the security baseline before any deeper governance can work.

Data has become executable, which collapses the old boundary between content and control. The article's central claim is that AI systems can transform data into action, meaning content handling and access governance are no longer separable disciplines. That shifts the security model from protecting records alone to constraining how information influences runtime behaviour. Practitioners should rethink policy enforcement as an execution control problem, not only a data protection problem.

AI governance now sits across the full security stack, so role boundaries will keep blurring. The piece describes GRC, AppSec, infrastructure, cloud, and DevSecOps as converging on the same AI risk surface. That is not a temporary overlap. It signals that organisations will need shared operating models for ownership, escalation, and audit across AI systems, or they will keep duplicating controls without closing the gap.

Executable data is the named concept that best captures this shift. Once data can shape model behaviour and downstream action, the security assumption that information is passive no longer holds. That assumption failed first in AI, but the implications reach identity, privilege, and governance across the enterprise. Practitioners should build programmes around that broken premise rather than around role-specific silos.

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, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control model, read OWASP Agentic AI Top 10 for the agentic risk patterns that make discovery and guardrails non-optional.

What this signals

With 98% of companies planning to deploy more AI agents in the next 12 months, the governance burden will grow faster than most IAM programmes can absorb. The practical signal is that discovery, ownership, and policy binding need to move ahead of adoption, not follow it.

Executable data: AI systems are turning information into behaviour, which means identity and access teams can no longer treat data controls and runtime controls as separate programmes. The result is a control model that must track not only who can access AI, but what that AI can do with the data it sees.

For teams building their operating model, the relevant next step is to anchor AI governance in established controls and external guidance, including the OWASP Agentic AI Top 10 and AI security posture work that fits into the broader identity programme.

For practitioners

• Map AI systems to accountable owners Create an inventory of AI tools, models, and agentic services and tie each one to a business owner, technical operator, and governance reviewer. Without that ownership chain, approval, audit, and incident response all break down when AI behaviour changes.
• Extend red teaming into AI misuse scenarios Add prompt injection, model extraction, data leakage, and jailbreak testing to existing security validation. Use the same discipline you apply to application abuse cases, but validate how the model behaves when inputs are adversarial or misleading.
• Treat AI outputs as governed data flows Classify where AI responses, embeddings, and downstream actions can expose sensitive information, then apply logging, masking, and approval boundaries at those points. The control objective is to constrain runtime influence, not just store data safely.
• Build discovery into the AI control plane Use shadow AI discovery and telemetry to identify AI deployments that are not in the approved architecture. Pair that with lifecycle review so unknown systems cannot persist outside standard governance and access oversight.

Key takeaways

• AI security roles are expanding because AI systems now blur the line between data handling, decision-making, and execution.
• The article's central warning is operational rather than theoretical: unmanaged AI deployments create blind spots that conventional governance cannot close on its own.
• Teams should respond by tying AI discovery, ownership, runtime guardrails, and auditability into one identity-led control model.

Key terms

• Shadow AI: AI tools, models, or agents that exist in an organisation without formal approval, ownership, or visibility. In practice, shadow AI is a governance problem because unmanaged systems cannot be inventoried, reviewed, or constrained, which leaves security teams unable to enforce policy or assign accountability.
• Runtime guardrails: Controls that shape what an AI system can say, access, or do while it is operating. They matter because AI risk often emerges during inference, not only at design time, so governance has to be enforced in the moment the system processes data and produces action.
• AI governance: The set of ownership, policy, oversight, and audit processes used to manage AI risk across an organisation. It includes decision rights, logging, review, and compliance mapping, but in practice it only works when tied to the operational behaviour of the AI system itself.
• Executable data: Information that can influence behaviour or trigger action inside an AI system rather than remaining passive content. This is a useful way to describe why AI changes security planning, because the same data now affects both what the system knows and what it may do next.

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

This post draws on content published by Pillar Security: Redefining Security Roles for the AI Era: Responsibilities and Controls. Read the original.