AI security platforms expose the limits of conventional IAM

At a glance

What this is: This is an analysis of AI security platforms and their role in controlling prompts, outputs, agents, and data flows across enterprise AI workflows.

Why it matters: It matters because practitioners now need identity controls that can govern AI agents, service identities, and human users in the same operating model.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Cerbos' analysis of AI security platforms and identity control

Context

AI security platforms are control planes for prompts, model calls, agent actions, and data exposure, not just another layer of application security. They exist because traditional endpoint, network, and cloud tools were never built to evaluate whether an AI request should be allowed, what data it may see, or which tools it may invoke.

For identity teams, the important shift is that AI introduces a new decision surface where human users, service identities, and autonomous agents can all trigger access decisions. That makes authorization, logging, and policy enforcement central to AI governance, especially when shadow AI and tool integrations expand faster than security review cycles.

Key questions

Q: How should security teams govern AI agents that can call tools and access data?

A: Security teams should govern AI agents as non-human identities with tightly scoped, runtime-enforced permissions. Each model call, data lookup, and tool invocation should be authorized separately, logged, and tied to an accountable owner. If the agent can chain actions, approval for the initial prompt is not enough to control the later steps.

Q: Why do AI workflows expose identity risks that conventional IAM misses?

A: AI workflows create new authorization events inside prompts, retrievals, and tool calls, which traditional IAM does not inspect at that level. The risk is not only data leakage. It is also unintended execution, because an agent can transform a benign request into a privileged action across connected systems.

Q: How do organisations know whether AI security controls are actually working?

A: They know controls are working when every AI interaction produces a complete decision trail, denied actions are visible, and sensitive data cannot leave approved boundaries through prompts, responses, or tool calls. If AI activity cannot be audited end to end, governance is still partial.

Q: What is the difference between prompt filtering and identity-based AI authorization?

A: Prompt filtering inspects the content of a request, while identity-based authorization decides whether the actor is allowed to perform the action at all. Both matter, but only authorization can stop an approved-looking prompt from reaching a restricted dataset, tool, or workflow.

Technical breakdown

AI gateway and policy engine architecture

An AI Security Platform commonly places an AI gateway or proxy in the request path between users, applications, and model providers. The gateway inspects prompts and responses, then consults a policy engine to decide whether the request is allowed. This is not just filtering text. It is contextual authorization over who is asking, what model or tool is being used, what data may be exposed, and what the output may contain. In practice, that means the control point sits at the AI boundary, not deep inside the model. The same pattern can govern external LLM APIs, internal models, and retrieval-augmented generation flows.

Practical implication: put the enforcement point where AI requests can be denied before data leaves approved boundaries.

Agentic AI access control and tool invocation

Agentic AI changes the problem because the system does not merely answer questions, it can chain tasks and invoke tools. That means a policy must govern each tool call, file read, database query, or workflow action independently. If the agent is allowed to plan but not to execute sensitive operations, the platform has to stop the action at decision time rather than after the fact. This is a classic identity problem with a runtime twist: the agent becomes a non-human actor whose privileges must be evaluated continuously as it moves through a task. Without that, a harmless prompt can become a harmful workflow.

Practical implication: authorize every high-impact tool call separately, especially when the agent can chain actions across systems.

Audit logging, data loss prevention, and prompt injection defence

AI security also depends on observability. A platform that logs prompts, outputs, policy decisions, and denied actions creates the evidence needed for compliance and forensics. Data loss prevention matters because users may paste sensitive material into external AI services or retrieve restricted information through a model response. Prompt injection defence addresses a different failure mode: malicious input can steer a model into ignoring instructions or leaking hidden context. These controls do not make AI safe by themselves, but they make the behaviour inspectable and governable. That is the baseline required before any mature AI security programme can scale.

Practical implication: retain prompt and decision logs, then use them to prove what the AI saw, did, and returned.

Threat narrative

Attacker objective: The objective is to turn AI workflows into a data-exfiltration path or an unintended action path by abusing prompts, tool access, or agent behaviour.

1. Entry occurs when a user, application, or agent sends a prompt, tool request, or retrieval query into an AI workflow with access to sensitive data or connected systems.
2. Escalation happens when the model or agent is induced to reveal hidden context, call an unauthorized tool, or chain actions beyond the original request boundary.
3. Impact follows when the AI exposes confidential data, performs an unintended system action, or creates an auditable policy failure that conventional security tools would not have caught.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

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 are becoming identity control planes for machine actions, not just content filters. The article is correctly pointing to a shift in where security has to sit: prompts, outputs, model calls, and tool invocations are all authorization events now. That makes AI governance a cross-domain identity problem spanning NHI, human access, and agentic execution. Practitioners should treat AI controls as part of the identity plane, not an add-on security layer.

Policy enforcement at the AI boundary is the right model, but the real governance test is whether the platform can distinguish intent from execution. In human IAM, the requestor and the actor are usually the same or at least stable enough to review. In AI workflows, the actor can fan out into tools, delegates, and sub-actions, which means access decisions must follow the action path, not just the initial prompt. That is why contextual authorization matters more than static entitlements. Practitioners should re-evaluate whether their current controls can track AI decisions at the point of use.

Shadow AI creates an identity inventory problem before it creates a data-loss problem. If security teams cannot discover every model, integration, and agent using enterprise data, they cannot govern them consistently. This is the same failure mode that has long plagued unmanaged service accounts, except the blast radius is broader because AI can combine retrieval, generation, and execution in one session. The practical conclusion is that AI discovery and entitlement mapping must be part of the identity programme, not a side project.

Agentic AI turns least privilege into a runtime property, not a provisioning-time assumption. Least privilege was designed for actors whose scope is known when access is granted. That assumption fails when the actor can decide which tool to call, which data to combine, and when to execute without human approval. The implication is not simply to add more policy. It is to rethink how privilege is defined for actors whose action path is not deterministic at provisioning time.

Named concept: AI identity blast radius. The useful lens here is the amount of damage an AI workflow can do before a human notices or a control stops it. When prompts, tools, data sources, and agents are all connected, the blast radius expands across identity, data, and workflow layers at once. Practitioners should use that lens to prioritise which AI paths require the strongest authorization, logging, and quarantine controls.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, 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.
• For a broader control model, see OWASP NHI Top 10 and assess where agent identity, tool use, and prompt injection converge.

What this signals

AI Security Platforms will only become operationally useful when they are tied to identity ownership. The programme risk is not whether a model can be filtered, but whether every model, agent, and retrieval path has a named owner, a policy boundary, and a log trail that can stand up to audit. With 80% of organisations already reporting out-of-scope agent behaviour, the control model has to assume drift rather than exception.

Shadow AI is becoming the same governance problem that unmanaged service accounts created for machine identity. The difference is that AI systems can combine content generation and execution, which means the potential blast radius is wider than a dormant credential. Teams that already use 52 NHI Breaches Analysis for machine-identity learning should extend the same inventory discipline to AI workflows.

AI identity blast radius: the practical question is how far an AI workflow can move before policy, logging, or quarantine stops it. That lens helps security teams prioritise which AI integrations need strict authorization gates, which need human review, and which should remain outside production until accountability is in place. For organisations mapping to OWASP Top 10 for Agentic Applications 2026, the issue is not whether AI is useful, but whether its autonomy is bounded well enough to govern.

For practitioners

• Define AI workflows as identity-bound execution paths Inventory each model, agent, retrieval source, and tool integration, then assign an accountable identity to every path that can read data or trigger an action. This makes it possible to apply policy at the same level where risk occurs.
• Authorize every AI tool invocation independently Require a policy decision before an agent can query databases, call external services, or write to operational systems. Do not rely on the initial prompt approval to cover later chained actions.
• Separate prompt inspection from data-access control Use prompt filtering to reduce obvious abuse, but enforce actual data and tool permissions with identity policy so that a safe-looking prompt cannot reach unauthorized resources.
• Log prompts, outputs, and denied decisions together Capture the full decision trail for every AI interaction so compliance teams can reconstruct what was asked, what was returned, and why a request was blocked.
• Test for shadow AI before scaling controls Discover unmanaged AI services and agent integrations first, then map them to owners and policy boundaries so that governance is not limited to approved applications.

Key takeaways

• AI security platforms are emerging because prompts, outputs, and tool calls have become identity events that conventional security stacks cannot govern cleanly.
• The evidence base is already strong enough to treat AI agent behaviour as an active risk, not a hypothetical one, with scope drift and blind spots showing up in real deployments.
• The practical response is to bind every AI action to identity, policy, and logs so that model behaviour becomes auditable before it becomes operationally dangerous.

Key terms

• AI Security Platform: A control layer that sits between AI users, models, and tools to enforce policy, logging, and data protection. It treats prompts, outputs, retrievals, and agent actions as security-relevant events that can be inspected and authorized in real time.
• Agentic AI: AI that can chain actions, choose tools, and pursue a goal with limited human intervention. In identity terms, it behaves like a non-human actor whose permissions must be evaluated continuously because its exact path is not fully known at provisioning time.
• Shadow AI: AI services, models, or agents in use without formal security visibility or ownership. The governance problem is discovery first, because an organisation cannot enforce policy or prove compliance if it does not know which AI workflows are operating on its data.
• AI Identity Blast Radius: The amount of damage an AI workflow can cause before a human notices or a control interrupts it. The concept helps teams compare AI use cases by the span of data, tools, and systems that one prompt or agent session can affect.

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

This post draws on content published by Cerbos: AI Security Platforms: How They Work and Why They Matter. Read the original.