AI security platforms expose the limits of conventional IAM

At a glance

What this is: This is an analysis of AI security platforms as a new control layer for AI workflows, with the key finding that conventional IAM alone cannot govern prompt injection, rogue agent actions, and data leakage.

Why it matters: IAM, PAM, and NHI teams need to treat AI services and agent actions as governed identities with continuous authorization, logging, and policy checks rather than as ordinary application traffic.

Context

AI security platforms are control layers for AI workflows, not just monitoring tools. Cerbos frames the problem as one where prompts, model outputs, connected tools, and agent actions create security decisions that conventional IAM and network controls were never built to make.

That matters because AI systems now sit inside business workflows, call external services, retrieve data, and sometimes act autonomously. The governance question is no longer whether AI is in use, but whether each AI action is authorized, observable, and constrained at runtime.

Key questions

Q: How should teams approach authorization for AI systems that invoke tools and data?

A: Start by distinguishing bounded automation from genuine autonomy, then decide which actions need live authorization before execution. Use context-aware policies for tool use, data access, and escalation paths, and avoid assuming a pre-approved workflow will stay safe as the system scales. The governance model must match the runtime behaviour, not the label.

Q: Why do traditional IAM and security controls fall short for AI systems?

A: Traditional controls were built for static software and predictable releases. AI systems change through new data, new weights, and new dependencies, so a point-in-time review can miss trust shifts that happen after launch. That is why lifecycle visibility, behavioural evaluation, and runtime oversight matter alongside access control.

Q: What are the signs that an AI security control plane is failing?

A: Common signals include unexplained data exposure through prompts, tool calls that exceed the user’s expected scope, missing decision logs, and agents that continue to act after policy should have blocked them. Those symptoms usually mean authorization is happening too late or not at all.

Q: How do AI security platforms relate to Zero Trust for identity teams?

A: They extend Zero Trust into AI workflows by requiring continuous verification for each action, not just for the initial login. The important difference is that AI systems can make multiple downstream decisions from one request, so trust has to be re-evaluated at each step.

Technical breakdown

Why prompt injection breaks ordinary access controls

Prompt injection is an input manipulation technique that causes a model to ignore intended instructions or reveal data it should not expose. The weakness is not just model quality, but that traditional controls usually inspect network sessions or application requests, while the harmful decision happens inside the AI workflow after the prompt is accepted. That makes policy enforcement at the AI layer necessary. AI security platforms try to inspect prompts, block unsafe content, and limit what the model may return based on context, identity, and data sensitivity.

Practical implication: teams need policy checks that evaluate AI inputs and outputs at decision time, not just perimeter controls.

How agent actions create authorization risk

Agentic AI systems do not just generate text. They can chain tool calls, query databases, and invoke external services to complete tasks. That changes the security problem from content moderation to action governance, because the agent may attempt an operation that is syntactically valid but operationally out of scope. AI security platforms therefore monitor tool use, apply authorization rules to each action, and block high-impact operations when the requested action exceeds policy. This is closer to continuous authorization than to classic application allow-listing.

Practical implication: every tool invocation should be treated as an authorization event, especially where agents can reach sensitive data or operational systems.

Why audit logs matter for AI governance

AI auditability depends on capturing prompts, outputs, policy checks, and agent decisions in a form security teams can actually investigate. Without that record, organisations cannot reconstruct what an AI system saw, why it was allowed to act, or whether it disclosed sensitive information. In governance terms, the control is not just detection after the fact. It is evidence generation for compliance, incident response, and policy tuning. Cerbos positions decision logging as the connective tissue between AI activity and downstream security operations.

Practical implication: log AI decisions with enough context to answer who acted, what was accessed, and why the policy allowed it.

Threat narrative

Attacker objective: The attacker aims to turn an AI workflow into a channel for data exposure, unauthorized action, or policy bypass.

1. Entry occurs when a user or application submits a prompt, retrieves content, or invokes an AI-connected tool through an AI workflow.
2. Escalation follows when the model or agent accepts malicious instructions, expands beyond intended scope, or attempts a tool action outside policy.
3. Impact occurs when the AI leaks sensitive information, performs an unauthorized operation, or propagates unsafe output into business workflows.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

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 security platforms expose an authorization gap, not just an observability gap. The central problem is that AI systems make runtime decisions about prompts, retrieval, and tool use after ordinary application controls have already done their work. That means conventional IAM can still authenticate a user while failing to govern the AI action that user or service triggers. Practitioners should treat AI authorization as a separate control plane.

Prompt governance and agent governance are different problems. Prompt filtering addresses malicious or sensitive input, but agentic systems add tool selection, external calls, and chained actions. Once an AI can initiate steps on its own, the security question becomes whether each step is within policy, not whether the original prompt looked safe. That distinction matters for how teams design review, logging, and denial logic.

Identity-aware authorization becomes the decisive control for AI workflows. AI security platforms only matter when they bind who, what, and context to every AI action. That shifts the governance model away from network trust and toward continuous decisioning, which is the only way to keep AI behaviour within policy when models, users, and tools all participate in one workflow.

AI Security Platform: a runtime policy layer for AI actions. The phrase is useful because it separates governance of AI behaviour from generic AppSec or DLP. The practical implication is that teams need a dedicated decision layer for AI prompts, retrieval, and tool invocation rather than assuming existing IAM or firewall controls can infer intent.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: AI Agent Authorisation Guide

What this signals

AI security platforms push identity teams to move from session-based trust to action-based trust. The practical shift is that prompts, retrieval requests, and tool calls become governed events, not invisible implementation details. Existing IAM still matters, but it now needs a policy layer that can decide what an AI may do at runtime.

AI action authorization: this is the control problem that emerges when an AI workflow can read, retrieve, or act across multiple systems inside one interaction. Without it, teams end up authenticating the caller but not governing the action, which is why policy enforcement has to sit inside the AI path rather than around it.

For practitioners

• Define AI authorization boundaries Map which prompts, data sources, tools, and model actions require explicit policy decisions before deployment. Separate user authentication from AI action authorization so the workflow cannot inherit broad application privileges by default.
• Instrument runtime decision logging Log prompts, outputs, policy checks, and agent tool calls in a way your SIEM can correlate with identity, resource, and context data. Preserve enough detail to reconstruct why a request was allowed or denied.
• Scope tool access by context Restrict agents and AI services to the minimum set of tools and data they need for each workflow, then re-evaluate those permissions as context changes. High-risk operations should require explicit authorization at the point of use.
• Test for prompt injection and rogue actions Include malicious prompt patterns, indirect prompt injection, and unauthorized tool-use scenarios in security testing before release. Validate that blocked actions stay blocked when the agent is connected to real data and external services.

Key takeaways

• AI security platforms are emerging because conventional IAM does not govern AI behaviour well enough once prompts, retrieval, and tool calls become part of the workflow.
• The core risk is not only data leakage, but unauthorized action taken by AI systems that can chain tasks or reach external tools.
• Identity-aware authorization, runtime logging, and contextual policy checks are the controls that turn AI use from an uncontrolled channel into a governable workflow.

Key terms

• AI Security Platform: An AI security platform governs how people and agents use AI systems across prompts, responses, files, and tool calls. It goes beyond traditional content filtering by adding intent-aware policy, runtime enforcement, and audit linkage so the organisation can control both the conversation and the action that follows.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Contextual authorization: A policy approach that evaluates access using real-time signals such as task, location, device posture, and time. It is more precise than static role assignment because it matches how autonomous agents operate, where intent and risk can change across a single workflow.

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