Notifications
Clear all
Topic starter
21/08/2026 4:54 pm
TL;DR: Declarative AI security tools can harden configs and image supply chains, but ARMO argues they remain blind to the runtime behaviours that drive prompt injection, agent escape, and data exfiltration in production. The gap is most acute at inference, where behavioural monitoring matters more than static posture checks.
NHIMG editorial — based on content published by ARMO: AI Workload Security Tools: Runtime vs. Declarative Compared
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.
Questions worth separating out
Q: How should security teams evaluate AI workload security tools?
A: Evaluate them by lifecycle coverage, not by feature lists.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read ARMO's analysis of AI workload security tools and the runtime vs. declarative gap →
AI workload security tools: are declarative controls enough at runtime?
Explore further
21/08/2026 5:11 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI workload security tools: runtime vs. declarative blind spots
