AI workload security tools: runtime vs. declarative blind spots

At a glance

What this is: This is an analysis of AI workload security tooling that compares declarative controls with runtime detection and concludes that inference-stage threats create the biggest visibility gap.

Why it matters: It matters because IAM, PAM, and AI security teams need to know where static policy ends and runtime identity and behaviour risks begin, especially for agents, tools, and privileged workloads.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 38% have automated certificate lifecycle management in place.

👉 Read ARMO's analysis of AI workload security tools and the runtime vs. declarative gap

Context

AI workload security still fails when teams treat posture scanning as if it were behavioural detection. Static tools can find misconfigurations, vulnerable images, and policy drift, but they cannot see prompt injection, agent misuse, or tool-mediated exfiltration once a model is live. That gap matters because the most damaging AI risks emerge at runtime, where access, identity, and execution intersect.

For identity and access teams, the issue is not just AI safety. It is the governance of machine credentials, service accounts, and privileged integrations that let models and agents call tools, query APIs, and move data. Once those identities are active in production, security depends on observing what they actually do, not only what the manifest says they are allowed to do.

Key questions

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: Why do declarative controls miss many AI attacks?

A: Declarative controls inspect static artefacts, so they can find bad configs but not live misuse. AI attacks often happen when a prompt changes agent behaviour, a tool call crosses a privilege boundary, or data moves through an allowed API in an unsafe way. Those signals only exist at runtime.

Q: What breaks when AI security stops at model scanning?

A: Model scanning helps identify tampering and unsafe dependencies before deployment, but it does not address runtime misuse. Once the system is live, prompt injection, unsafe tool use, and manipulated responses can still drive harmful behaviour. Without runtime controls, the most important security decisions happen after the pre-check has already passed.

Q: How can organisations tell whether AI runtime monitoring is working?

A: A working programme can explain which AI-driven actions were observed, which service identities enabled them, and whether those actions stayed inside approved operational scope. If the team only sees dashboards and not the behaviour chain from input to tool use to effect, the control is too shallow to rely on.

Technical breakdown

Why declarative tools stop short in AI inference

Declarative tools evaluate static artefacts such as manifests, policies, container images, and code. That works for finding misconfigurations before release, but inference is a live interaction layer where users, models, tools, and APIs exchange context in real time. Prompt injection, model extraction, and tool misuse are behavioural attacks, which means the exploit is in the sequence of actions and outputs, not in a file the scanner can inspect. If a model can call privileged services, the attack surface sits in runtime decisions and data flows, not just configuration state.

Practical implication: pair pre-deploy scanning with runtime telemetry for model outputs, tool calls, and API use.

How runtime-first controls detect AI workload abuse

Runtime-first tools watch processes, network activity, file access, and sometimes application-layer events as AI workloads execute. In Kubernetes and cloud environments, eBPF-based sensors can build baselines for what a training job, serving pod, or agent normally does, then flag deviations such as unexpected binaries, unknown outbound connections, or unusual API access. This is especially important for AI agents, because the identity of the workload is inseparable from its behaviour. A service account may be valid, yet the action it authorises may still be malicious if prompt manipulation drives it.

Practical implication: define behavioural baselines for each AI workload and alert on deviations from expected tool and data access.

AI-BOM drift and the gap between declared and actual state

An AI-BOM, or AI Bill of Materials, is only useful if it reflects what is actually running. Declarative inventories describe planned frameworks, models, tools, and dependencies, but runtime observation often reveals extra helper binaries, unexpected RAG sources, or API integrations that never appeared in the manifest. That drift creates governance risk because access reviews and change control are then based on an incomplete picture. For identity teams, the key issue is whether the workload is using the same secrets, service accounts, and permissions that were approved, or whether the runtime path has expanded beyond the original trust boundary.

Practical implication: reconcile declared AI inventories with observed runtime behaviour before relying on access approval or audit evidence.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate AI workload and its credentials into a trusted execution path for data theft or unauthorized action.

1. Entry occurs when an attacker uses prompt injection or crafted inputs to influence an AI agent at inference time.
2. Escalation follows when the agent invokes tools, APIs, or privileged services that the attacker has effectively steered through the prompt.
3. Impact occurs when the agent leaks data, extracts model behaviour, or performs unintended actions such as exfiltration or destructive operations.

NHI Mgmt Group analysis

Declarative-only AI security is a posture control, not a runtime control. It can reduce obvious misconfigurations, but it cannot observe the live exchanges that create most AI-specific compromise paths. That distinction matters because prompt injection and tool misuse are behaviour problems, not static configuration problems. Practitioners should treat declarative tools as one layer in a broader detection stack, not as a complete AI workload security model.

AI workload identity is now a behavioural problem as much as an access problem. The article shows that once a model or agent can invoke tools, its permissions become meaningful only in context. That makes machine identity, service account scope, and runtime authorisation inseparable from model security. In governance terms, the critical question is whether the workload can do the thing, not merely whether it is allowed on paper.

Inference-stage visibility is where the named concept of runtime blind spot governance becomes operationally important. This is the gap between what a security programme can inventory and what it can actually see as the system behaves. The matrix framing is useful because it forces teams to map observation to lifecycle stage instead of assuming one control plane covers all AI risk. The practitioner conclusion is simple: if you cannot observe inference, you do not have AI workload security, only AI workload posture.

Identity and AI security will converge around observed behaviour, not declared intent. Runtime-derived evidence will increasingly decide whether a service account, tool integration, or agent workflow is trustworthy enough to keep operating. That changes governance, audit, and response workflows because approval evidence must include behavioural data, not just manifests and policy checks. Teams should expect more pressure to prove how AI systems behaved in production, not just how they were configured.

What this signals

Runtime blind spot governance: AI programmes will increasingly be judged on whether they can prove what agents and workloads actually did, not just what they were configured to do. That pushes teams toward observed-behaviour evidence, especially where service accounts and tool permissions are involved.

For identity leaders, the practical shift is toward correlating AI runtime data with access governance, audit trails, and secret handling. A model or agent that looks compliant in configuration can still be unacceptable if its live behaviour crosses data or privilege boundaries.

For practitioners

• Map AI controls by lifecycle stage Separate training, deployment, and inference in your control matrix so you can see where declarative scanning ends and runtime monitoring must begin. Use this to identify where prompt injection, tool misuse, and exfiltration would remain invisible today.
• Baseline agent and workload behaviour Record normal tool calls, API destinations, file access, and process activity for each AI agent or serving pod, then alert on deviations from those patterns. Behavioural baselines give you the reference point that static manifests cannot provide.
• Review privileged service accounts used by AI systems Inventory every service account, token, and secret that an AI workload can reach, then verify whether each one is still required during live execution. Remove standing privileges that are never exercised in production workflows.
• Reconcile declared and observed AI inventories Compare the AI-BOM from manifests with runtime-discovered components such as helper binaries, external RAG sources, and unexpected API integrations. Any mismatch should trigger an access and change-control review before the workload is trusted again.

Key takeaways

• Declarative AI security reduces configuration risk, but it cannot see the runtime behaviours that drive prompt injection, tool misuse, and data exfiltration.
• The evidence gap is structural: static posture checks cover training and deployment better than inference, where live interactions create the highest-impact threats.
• AI security programmes now need behavioural telemetry, lifecycle mapping, and identity governance for the service accounts and secrets that agents use.

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-First Security: Runtime-first security focuses on what a workload actually does while it is running. It monitors process activity, network flows, tool calls, and application behaviour so teams can detect misuse, abnormal actions, and unexpected data movement that static checks would never see.
• 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 Risk: Inference risk is the possibility that a system derives sensitive or useful conclusions from benign-looking data. The output may not be classified as secret, yet it can still reveal thresholds, behaviour, or authority patterns that enable manipulation or control bypass.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• Hands-on comparisons of runtime-first sensors versus declarative scanning across AI training, deployment, and inference.
• The AI Security Detection Matrix structure that teams can reuse in vendor evaluations and architecture reviews.
• Implementation examples for behavioural baselines, eBPF visibility, and runtime-derived AI-BOM drift detection.
• A fuller walkthrough of how ARMO maps observed behaviour to detection and response in production AI workloads.

👉 ARMO's full post covers the AI Security Detection Matrix, lifecycle comparisons, and runtime detection examples in more detail.

Deepen your knowledge

The 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 access control, lifecycle governance, and runtime risk across modern security programmes.