Pillar named Frost & Sullivan leader for AI security strategy

At a glance

What this is: This is a vendor news post about Frost & Sullivan naming Pillar Security a 2025 Competitive Strategy Leader in generative AI security, with the core finding that AI security is being framed as lifecycle governance rather than isolated controls.

Why it matters: It matters because IAM and security teams now need governance that spans AI discovery, testing, runtime enforcement, and deployment boundaries, especially as agentic AI and shadow AI expand the identity surface.

By the numbers:

• Pillar Security says Frost & Sullivan named it the 2025 Competitive Strategy Leader in the global generative AI security industry.

Context

Generative AI security has moved beyond a single control problem. The operating question is now how organisations govern AI assets, testing, policy, and runtime behaviour across the full lifecycle, especially when AI systems are distributed across code repositories, data platforms, local environments, and cloud infrastructure.

In this post, Pillar Security is the source article, but the analytical issue is broader than one vendor ranking. The practical gap is that point-in-time controls do not give security teams durable visibility into shadow AI, agentic workflows, or the policy and trust boundaries that now sit inside development and production pipelines.

Key questions

Q: How should teams govern AI assets and data together without creating duplicate controls?

A: Build a single governance inventory that links datasets, models, policies, and approvals, then reuse governance artefacts only when ownership, versioning, and review evidence remain intact. The goal is not consolidation for its own sake. It is to avoid two parallel governance planes that cannot prove the same control outcome.

Q: Why do static controls fall short for agentic AI security?

A: Static controls assume behaviour stays predictable after deployment. Agentic systems can invoke tools, browse, and execute workflows in ways that change the attack surface during runtime, so governance has to account for live decision paths, not just pre-approved configurations. The control problem shifts from point checks to continuous assurance.

Q: What are the signs that an AI security programme is missing runtime governance?

A: Common signs include incomplete asset inventory, testing that only checks malformed inputs, and guardrails that do not change when workflows, tools, or prompts change. If production behaviour is more complex than the policy model, the programme is lagging behind the system it claims to govern.

Q: What is the difference between red teaming AI systems and ordinary security testing?

A: Ordinary security testing checks whether a control or input fails in isolation. Red teaming asks how an AI system behaves across a sequence of actions, including prompt manipulation, tool use, and workflow chaining. That distinction matters because many AI failures emerge only when the attacker can combine behaviours over time.

Technical breakdown

Why AI asset discovery is now a governance control

AI asset discovery is the process of finding models, prompts, datasets, and connected environments before they become unmanaged risk. In AI programmes, the problem is not only hidden code, but hidden identity and data paths that sit outside the formal inventory. When discovery reaches beyond the CI/CD pipeline into repositories, data platforms, AI/ML frameworks, identity providers, and local environments, it exposes the real attack surface for governance, access review, and policy enforcement. That matters because an AI control plane is only as accurate as the assets it can actually see.

Practical implication: establish inventory discipline for AI assets before attempting policy enforcement or runtime control.

How adversarial red teaming differs from basic fuzz testing

Basic fuzz testing checks whether a system breaks under malformed input. Adversarial red teaming asks how a system behaves under coordinated, multi-step attack paths that combine prompt abuse, workflow manipulation, and trust boundary exploitation. For AI systems, that difference matters because the failure mode is often behavioural and chained, not a single malformed request. White-box and black-box testing both have value here because one reveals internals while the other tests what an attacker can infer externally. Red teaming therefore becomes a control validation mechanism, not just a security assessment exercise.

Practical implication: test AI systems for chained abuse paths, not only for malformed-input rejection.

Why runtime guardrails need feedback from live usage and red team findings

Runtime guardrails are the enforcement layer that attempts to keep AI behaviour inside policy during execution. In an agentic context, static rules age quickly because threats evolve as tools, prompts, and workflows change. A guardrail model that adapts using red team results, live usage patterns, and threat intelligence is trying to close the gap between pre-deployment testing and actual production behaviour. The governance issue is not whether a guardrail exists, but whether it can keep pace with model drift, workflow drift, and expanding tool access across the lifecycle.

Practical implication: treat runtime enforcement as a living control tied to feedback loops, not a one-time configuration.

Threat narrative

Attacker objective: The objective is to abuse unmanaged AI assets and workflow access in ways that bypass governance, visibility, and runtime policy.

1. Entry begins when shadow AI or untracked AI assets sit outside the formal inventory and governance boundary, leaving security teams blind to where models, prompts, and datasets are actually used.
2. Escalation follows when agentic systems can invoke tools or workflows without controls that reflect their runtime behaviour, allowing policy gaps to become operational abuse paths.
3. Impact is reached when the organisation cannot reliably constrain, observe, or audit AI behaviour across hybrid, cloud, and on-premise environments, which weakens trust in the whole AI control plane.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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

AI security is becoming lifecycle governance, not a stack of point controls. The article’s strongest signal is that discovery, red teaming, runtime guardrails, and deployment architecture are being treated as one governance problem rather than separate product features. That shift matters because security teams cannot validate trust in AI systems if inventory, testing, and enforcement live in different operating models. Practitioners should manage AI security as an end-to-end lifecycle discipline.

AI asset discovery is now the prerequisite control for AI governance. If teams cannot find the models, prompts, datasets, and local environments in use, they cannot apply policy with confidence. The named concept here is AI asset visibility debt: the gap between what the organisation believes it governs and what is actually running. Practitioners should treat that debt as a governance failure, not an inventory nuisance.

Runtime guardrails only matter when they are informed by real attack behaviour. Static policy checks are insufficient once AI systems can change behaviour through tool use, workflow context, and external inputs. The report’s emphasis on adaptive protection reflects a broader market reality: AI security is moving toward controls that learn from operational evidence. Practitioners should expect runtime policy to become a continuous assurance function.

Agentic AI raises the governance bar because behaviour can change during execution. The article explicitly points to agents that invoke tools, browse, and execute workflows, which means the security problem is no longer just model misuse but runtime decision paths. That requires governance that spans access, tooling, and execution boundaries. Practitioners should separate static AI use cases from agentic ones when defining controls and accountability.

Enterprise-ready AI security now includes deployment boundaries and compliance integration. Hybrid, cloud, and on-premise support, plus SIEM and compliance integration, show that buyers are looking for operational fit rather than isolated model protection. The market is signalling that AI security will be judged by how well it fits broader governance and monitoring workflows. Practitioners should evaluate AI security platforms on integration depth as much as on detection claims.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: Agentic AI Identity Maturity Model

What this signals

AI asset visibility debt: governance programmes will increasingly be judged by whether they can find every model, prompt, dataset, and connected environment before policy is enforced. Discovery is becoming the control that determines whether the rest of the AI security stack has any practical value.

As agentic systems spread, teams should expect the boundary between AI security and identity governance to tighten. Access, tooling, and execution rights will need to be evaluated together rather than as separate controls, especially where runtime behaviour can change after deployment.

For practitioners

• Map all AI assets across development and runtime Create an inventory that includes models, prompts, datasets, repositories, local environments, and connected identity providers so hidden assets do not remain outside governance.
• Test agentic systems with adversarial scenarios Use multi-step red teaming to validate how AI systems behave when prompts, tools, and workflows are combined in attack chains rather than in isolated tests.
• Bind runtime guardrails to live usage signals Feed production telemetry, red team findings, and threat intelligence into enforcement rules so policy adapts as tools and workflows change.
• Separate static AI use cases from agentic ones Classify where systems only generate outputs and where they can invoke tools or execute workflows, because those two modes require different governance and escalation paths.

Key takeaways

• AI security is shifting from isolated controls to lifecycle governance that spans discovery, testing, runtime enforcement, and deployment boundaries.
• The article’s central signal is that hidden AI assets and agentic workflows create governance gaps that traditional point controls do not close.
• Practitioners should treat asset inventory, adversarial red teaming, and adaptive guardrails as one operating model rather than separate projects.

Key terms

• AI Asset Visibility Debt: The gap between the AI assets an organisation believes it governs and the assets actually in use. In practice, this appears when models, prompts, datasets, and connected environments exist outside a reliable inventory, leaving policy and monitoring incomplete.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
• Adversarial Red-Teaming: Adversarial red-teaming is the practice of actively trying to make a security model fail before it reaches production. The test uses crafted inputs, boundary probes, and mutation strategies to reveal weaknesses that ordinary accuracy testing will not show.
• 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 identity security programme, it is worth exploring.