AI runtime security is exposing a gap posture tools miss

At a glance

What this is: This is an analysis of why AI security posture management stops short when AI systems act at runtime, especially as LLM-powered agents use APIs, tools and data in ways scanners do not capture.

Why it matters: It matters because IAM, PAM and NHI programmes need to govern what AI can do in motion, not just what was configured at deploy time.

Context

AI runtime security is the control gap between knowing what AI systems are deployed and understanding what they actually do once they start making decisions, calling tools and touching data. In identity terms, that is the point where posture data stops being enough and runtime authority becomes the real risk surface for agentic systems, MCP integrations and AI-enabled workloads.

Orca Security's argument is that configuration visibility still matters, but it only covers the static layer. Once an LLM-powered agent can access records, invoke APIs or trigger subprocesses, security teams need to understand which identity performed the action, what it touched, and whether the behaviour stayed inside approved bounds.

The article's core claim is typical of current AI-security programmes: they are built to inspect deployment state more easily than runtime behaviour. That makes the gap structural, not incidental, and it becomes more acute as MCP servers and AI tools are embedded directly into production applications.

Key questions

Q: What breaks when AI security stops at posture instead of runtime behaviour?

A: Security teams lose visibility into the actions that matter most, such as API calls, record access and tool use. Posture tools can show what was deployed and how it was configured, but they cannot prove what the AI system actually did once it started operating. That makes runtime governance and identity correlation essential.

Q: Why do MCP-based agents increase identity governance risk?

A: Because the agent can select tools and chain actions at runtime, which means authority is no longer fixed at issuance. Traditional IAM assumes a stable entitlement set, but MCP lets context change behaviour, so the real risk is authority drift across the session.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: What should organisations do when AI agents can access external APIs and internal systems?

A: Organisations should put non-LLM permission controls around agents, so the model can suggest an action but cannot exceed its authorised scope. They should also apply input validation, rule-based guardrails between agents, secure vendor checks for third-party APIs, and logging that tracks data flow and detects anomalies in real time.

Technical breakdown

Why posture tools miss AI runtime behaviour

Posture tools are built to answer configuration questions: what models exist, where they are deployed, and whether data and pipelines are misconfigured. Runtime AI security is different because the security-relevant event is the action sequence itself. When an LLM-driven system makes API calls, reads customer records or invokes tools, the risk is no longer a static misconfiguration but a live decision path. Traditional scanners can inventory assets, but they do not observe intent, tool choice or the order of execution after the system begins operating.

Practical implication: security teams need runtime visibility that ties each AI action back to the workload, identity and tool path that produced it.

Why MCP servers change the identity problem

MCP servers create a tool-and-data bridge between AI systems and enterprise applications. That matters because the security question is not just whether an AI model is deployed, but which tools it can reach and how its outputs are consumed. When a model or agent interacts through MCP, the effective control point shifts from the prompt to the integration layer, where legitimate requests can still produce risky access patterns, data leakage or unexpected workflow chaining.

Practical implication: govern MCP access as an identity boundary, not just as an application integration detail.

Why autonomous action breaks after-the-fact review

The article's deeper issue is that autonomous behaviour is not stable enough to be reviewed only after the fact. If an agent can decide when to act, which tool to use and what data to access, then the security model cannot rely on post-event logs alone. That is especially true in environments where the same prompt can produce different outputs. The governance assumption being broken is that observable behaviour is sufficiently durable for review cycles to catch it in time.

Practical implication: move governance closer to issuance and execution, where the action occurs, rather than depending only on retrospective review.

Threat narrative

Attacker objective: The objective is to use AI runtime trust to reach data and systems that would not be reachable through posture-only controls.

1. Entry occurs when an AI system or agent is given production access through legitimate APIs, prompts or MCP integrations.
2. Credential or authority abuse follows when the system uses that access to reach records, call tools or send requests that look like normal application traffic.
3. Impact occurs when the runtime action results in sensitive data exposure, risky workflow execution or a pivot into adjacent cloud resources.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• 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

Runtime AI security is now an identity problem, not just a cloud posture problem: once an AI system can call APIs, access records or invoke tools, the meaningful control boundary shifts from deployment state to live authority. Static inventory still has value, but it does not answer who or what actually exercised access. Practitioners should treat AI runtime behaviour as governed identity activity, not merely model telemetry.

The posture model assumes behaviour is inspectable after the fact, and that assumption is collapsing: review cycles were designed for access that persists long enough to be observed, certified and remediated. Autonomous or semi-autonomous AI actions can complete inside a short execution window, leaving logs but no stable governance state. The implication is that AI governance has to confront execution-time authority, not just retrospective review.

MCP creates a new identity blast radius when tool access and data access converge: the bridge between model, tool and application is where risk becomes operational. If the integration layer is not treated as part of the identity boundary, organisations will keep seeing prompt-level controls fail to explain actual system behaviour. Practitioners need to govern the path by which AI reaches business data, not only the model that issued the request.

AI security programmes will increasingly be judged by their ability to correlate cloud, workload and AI context: the article's architecture points in that direction. Security teams that cannot tie an AI action back to the originating workload, process and identity will struggle to assign accountability or contain blast radius. The field is moving toward cross-domain evidence, not siloed AI inventories.

Prompt-level detection is necessary but insufficient unless it is paired with action-level context: malicious prompts matter, but so do the downstream actions an AI system takes after receiving them. That is the difference between spotting a risky request and understanding whether the system actually accessed data, invoked a tool or changed state. The practitioner conclusion is to measure AI governance by observed behaviour, not by prompt review alone.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Runtime AI security now sits at the intersection of identity, cloud and application governance: teams that still treat AI as a posture problem will miss the moment when the model becomes an actor. The practical shift is to govern the path from prompt to tool use to data access, because that path is where blast radius is created.

MCP is becoming a named governance boundary, not just an integration pattern: once AI systems can reach enterprise tools through MCP servers, the question changes from whether the model is approved to whether the integration can be safely constrained. That is where identity security, API control and workload context converge.

Prompt review alone does not create a defensible AI control posture: organisations need evidence of the action taken after the prompt, especially where AI systems can touch customer records, cloud resources or sensitive workflows. Without that linkage, governance remains descriptive instead of enforceable.

For practitioners

• Map AI runtime identities and tool paths Inventory which workloads, agents and MCP servers can reach production data and which identities they use to do it. Treat every tool invocation as an access event that should be traceable to a workload, process and responsible team.
• Correlate prompts with downstream actions Do not stop at prompt logging. Record what the AI system did after the prompt, including API calls, accessed records, invoked tools and affected outputs, so governance decisions reflect behaviour rather than intent alone.
• Define policy boundaries for MCP usage Set separate rules for which MCP servers may connect to which applications, data sets and workflows, and require review of any integration that can move from prompt input to state-changing action.
• Establish ownership for AI runtime risk Assign clear accountability for AI behaviour in production across the AI, application and security functions so risky runtime activity has an owner who can respond when logs show unexpected access or tool use.

Key takeaways

• AI posture management is necessary, but it does not explain what LLM-powered agents do once they begin calling tools and accessing live data.
• The article's core warning is that runtime behaviour, not deployment inventory, determines whether AI activity stays inside policy.
• Security teams need to correlate prompts, tool use and identity context if they want AI governance to be enforceable rather than symbolic.

Key terms

• AI Runtime Security: AI runtime security is the set of controls that inspect, constrain, and respond to model behavior while the application is live. It includes detection, masking, policy enforcement, and response shaping, all aimed at reducing the blast radius of unsafe model interactions.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Runtime correlation: Runtime correlation is the practice of joining identity state changes with security activity while an investigation is still active. It lets teams evaluate whether access use matches expected behaviour, which is more useful than reviewing entitlement records after the fact.
• Prompt-Level Risk Analysis: Prompt-level risk analysis evaluates the content and intent of prompts for signs of sensitive data exposure, malicious instructions or policy violations. It is useful, but it is only one layer of control because the security outcome often depends on what the AI system does after the prompt is received.

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 building or maturing an IAM programme, it is worth exploring.