AI workload security tools: runtime vs. declarative blind spots

At a glance

What this is: ARMO's analysis says declarative AI security tools are useful for posture and supply-chain checks, but they leave a major blind spot for runtime threats at inference.

Why it matters: This matters because IAM, AI security, and platform teams need telemetry that matches how agents, tools, and users actually interact in production, not just how systems are configured.

Context

AI workload security is split between static posture controls and runtime observation. Declarative tools can verify configurations, images, and dependencies before a workload runs, but they do not see how models, agents, and tools behave once live traffic starts flowing. That creates a governance gap when the real risk is no longer misconfiguration alone but behaviour that emerges only during execution.

The identity angle is increasingly important because AI agents and model-serving services do not just process data, they invoke tools, call APIs, and act through machine identities. Once those identities are in production, access scope, behavioural drift, and delegated action all become part of the security model, not just model content or infrastructure posture.

Key questions

Q: What fails when AI security tools only check declarative posture?

A: They miss the behavioural layer where prompt injection, tool misuse, and agent escape actually happen. Static checks can confirm what was planned or deployed, but they cannot see how a model behaves once users, tools, and APIs interact at runtime. That means the most dangerous threats remain invisible until an attacker has already influenced execution.

Q: Why does runtime behaviour matter more at AI inference than during deployment?

A: Inference is where live prompts, tool calls, and downstream actions intersect, so the threat is defined by execution rather than configuration. A model or agent can appear safe in deployment and still become dangerous when real inputs change its decisions. Runtime behaviour is therefore the signal that reveals whether the workload is being manipulated.

Q: How should security teams evaluate AI workload security tools?

A: Evaluate them by lifecycle coverage, not by feature lists. A useful stack must show what it can see during training, deployment, and inference, and it must prove whether it can detect behavioural abuse in real time. If the tool only finds misconfigurations, it is a posture tool, not a runtime defence.

Q: How do machine identities change AI workload risk?

A: Once agents or model services act through service accounts, tokens, or API credentials, identity scope becomes part of the attack surface. Excess access can turn a harmless-looking prompt into an internal data request or tool invocation. Teams need to govern those credentials as production identities, not as incidental configuration.

Technical breakdown

Why declarative controls stop at runtime

Declarative security tools reason over desired state. They inspect manifests, policies, image contents, and code before execution, which is valuable for catching known misconfigurations and vulnerable dependencies. But they do not observe live process behaviour, network flows, or application-layer exchanges once a training job, model server, or agent starts operating. That makes them structurally unable to detect attacks that only exist as sequences of runtime actions, such as malicious tool invocation or abnormal data access. The problem is not that the tools are weak at posture management. It is that posture data ends where behaviour begins.

Practical implication: Use declarative controls for pre-runtime assurance, but do not treat them as evidence that AI workload behaviour is covered.

Why inference is the critical blind spot

Inference is where users and attackers directly interact with models and agents. Prompt injection, tool misuse, model extraction, and agent escape are all behavioural threats, which means their indicators appear only in the runtime chain of prompts, model decisions, tool calls, and network activity. A static policy cannot determine whether an allowed API call is legitimate or attacker-driven without context from execution. That is why inference-stage security depends on application-layer telemetry and behavioural baselines, not just policy checks or image scanning. This is also where AI systems start to resemble identity systems, because the security question becomes who or what is acting through the agent at that moment.

Practical implication: Prioritise runtime monitoring for inference endpoints that can reach sensitive data, APIs, or downstream tools.

How runtime-derived AI-BOMs change deployment visibility

A manifest-based inventory tells you what was intended for deployment. A runtime-derived inventory tells you what actually loaded, executed, and connected in production. That distinction matters when AI workloads pull models, RAG sources, helper binaries, and external APIs into memory after deployment. Runtime observation can expose drift between declared and actual behaviour, including unexpected service calls or permissions that were never exercised in testing. In governance terms, this is the difference between control-on-paper and control-in-operation. For AI workload security, that gap is often where the exposure begins, especially when machine identities and service credentials are reused across environments.

Practical implication: Compare declared AI components and permissions against observed runtime behaviour before you assume the deployment state is trustworthy.

Threat narrative

Attacker objective: The attacker wants to convert a normal AI interaction into unauthorized tool use, data access, or operational abuse without triggering static posture controls.

1. Entry occurs when an attacker submits a crafted prompt or abuses a legitimate inference request against a production AI agent.
2. Credential access or privilege abuse follows when the agent invokes tools or APIs that are technically allowed but not behaviourally expected.
3. Impact occurs when those actions lead to data exfiltration, model manipulation, or unintended access to downstream systems.

Breaches seen in the wild

• ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.
• 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

Static AI security is now a control boundary problem: posture tools still matter, but they do not define the full security boundary of an AI workload. Once models and agents start acting through APIs, tools, and service accounts, the governing question shifts from what was deployed to what the workload actually did. Practitioners should treat runtime visibility as a separate control plane, not a supplement to posture management.

Inference-stage behaviour is the new identity layer for AI systems: the article shows that AI workloads cannot be governed safely if access is judged only by configuration. The real risk sits in delegated action, where an agent or model can exercise machine identities in ways that were not obvious at design time. That makes identity-scoped telemetry central to AI governance, especially for customer-facing or data-reach agents.

Behavioral blind spots create detection debt: the longer an organisation relies on static checks alone, the more likely it is to accumulate environments that look compliant but fail under live use. This is not a tooling gap in the abstract, it is a lifecycle mismatch between what the control measures and when the threat appears. NHI Mgmt Group's position is that security teams should name this as detection debt and resolve it before AI systems reach broad production use.

AI Security Detection Matrix: the useful concept here is lifecycle-matched visibility: the article's strongest contribution is the idea that controls must be evaluated by the stage of the workload they can actually observe. That gives practitioners a cleaner way to separate training and deployment posture from inference-time behavioural risk. The practical conclusion is to stop buying AI security coverage as a single category and instead map each control to the lifecycle stage it truly sees.

Machine identity governance becomes unavoidable once AI agents are live: when an agent can call tools, reach databases, or operate through service credentials, identity controls become part of the AI security model. The boundary between AI security and IAM is therefore not theoretical. Practitioners need to govern the identities used by workloads as carefully as the model itself, or runtime abuse will outpace static assurance.

What this signals

Lifecycle-matched visibility is the control gap that matters here: AI workloads need controls that are matched to the stage where the threat appears, because training, deployment, and inference produce different evidence. A posture-only stack can look healthy while missing the behavioural layer that decides whether an agent is being manipulated in production.

Detection debt accumulates when AI systems are monitored like static infrastructure: the article's core warning is that the wrong telemetry creates confidence without coverage. For practitioners, that means the security programme needs to move from configuration review to observable action review wherever agents can call tools or reach data.

Identity controls must extend into AI execution paths: when agents operate through service credentials, the question is no longer just whether access exists, but whether the runtime behaviour matches the intended authority. That is the point where IAM and AI security converge, and it is where governance either keeps pace or falls behind.

For practitioners

• Map controls to AI lifecycle stages Separate training, deployment, and inference in your control inventory so each security product is tested against the stage it can actually observe.
• Instrument runtime telemetry for inference paths Capture prompts, tool calls, API traffic, process activity, and network egress for agents that can reach sensitive systems or data.
• Compare declared and observed AI-BOMs Review the frameworks, models, RAG sources, helper binaries, and external APIs that are declared against what runtime evidence shows in production.
• Review machine identity scope for agents Check whether service accounts, tokens, or API credentials used by agents have more access than the live workload actually needs.

Key takeaways

• AI workload security fails when teams equate configuration checks with full coverage, because the most serious threats only emerge during execution.
• The article's main framework is a lifecycle model that separates training, deployment, and inference, which helps expose where declarative tools stop seeing risk.
• Practitioners should pair posture controls with runtime telemetry for agent behaviour, especially where machine identities can reach data or APIs.

Key terms

• Declarative Security: Declarative security evaluates systems from their static configuration, manifests, policies, and code before execution. It is effective for finding misconfigurations and known weaknesses, but it cannot observe live behaviour, so it often misses attacks that only emerge once an AI workload starts acting in production.
• Runtime telemetry: Observation of what a system actually does while it is executing. In agentic CI/CD, this means seeing which commands, files, tools, and credentials an agent touched so security teams can detect misuse that static workflow review will miss.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Inference Phase: The inference phase is the point at which an AI model receives live input and generates an output or action. In security terms, this is where permission scope matters most, because excessive access can lead to data leakage, unauthorized actions, or privilege escalation during normal use.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions that shape modern workloads.