Notifications
Clear all
Topic starter
18/08/2026 2:09 pm
TL;DR: Prompt injection defenses for AI agents decay quickly unless teams first build runtime observation and per-agent baselines, according to ARMO, while a UK AISI red-teaming challenge found 1.8 million attacks produced more than 60,000 policy violations across 22 agents. The practical issue is observation debt, because controls that depend on recorded behavior cannot be enforced safely until enough agent activity has been collected.
NHIMG editorial — based on content published by ARMO: How to Secure AI Agents Against Prompt Injection
By the numbers:
- The UK AISI red-teaming challenge ran 1.8 million prompt injection attacks against 22 frontier-model agents across 44 deployment scenarios.
- Only 44% of companies have implemented any policies to govern AI agents, even though 92% agree governance is critical.
Questions worth separating out
Q: What breaks when AI agents are exposed to prompt injection without runtime baselines?
A: The main failure is that the agent can still complete authorised actions even when the instruction is malicious.
Q: Why do AI agents complicate traditional IAM and PAM controls?
A: AI agents complicate IAM and PAM because they can make decisions, chain tools, and act faster than human review cycles can respond.
Q: How do organizations prove AI agent controls are actually working?
A: Organizations prove control effectiveness by showing which agents accessed which data, what actions they executed, and whether those actions stayed within approved task boundaries.
Practitioner guidance
- Build runtime observation before blocking Instrument agent execution to capture tool calls, destinations, spawned processes, and files accessed so you can derive a per-agent behavioural baseline from live activity rather than from a deployment manifest.
- Reduce residual completable capability Trim what each agent can finish by narrowing tool surfaces, removing unnecessary write paths, and replacing live credentials with dummy or brokered access where the workflow allows it.
- Apply audit mode before enforcement Run the full control logic in audit mode first, review unexplained deviations at the Deployment level, and promote to blocking only after the baseline has stabilised across a deployment cycle.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step observe-to-enforce workflow for AI agents running in Kubernetes and similar runtime environments
- The exact control breakdown for input filtering, credential swapping, Rule of Two, and per-agent audit mode
- The operational thresholds used to judge when an agent's behavioural baseline is stable enough to enforce
- The platform-level telemetry pattern for detecting unusual tool use, destinations, and execution drift
👉 Read ARMO's analysis of prompt injection controls and observation debt →
AI agent prompt injection: are your controls keeping up?
Explore further
18/08/2026 3:02 pm
Observation debt is the core governance concept this article surfaces. AI agents can reach production before enough of their own behaviour exists to support meaningful behavioural enforcement, which means the control gap is structural rather than accidental. That makes agent rollout a governance problem, not just a model-security problem. Practitioners should treat the time between deployment and baseline settlement as a first-class risk window.
A question worth separating out:
Q: Who is accountable when an AI agent performs an unauthorized action after injection?
A: Accountability follows the governance model that granted the agent its permissions and execution rights. The owner of the agent workflow, the approver of its tool scope, and the team operating the control plane all share responsibility. Frameworks such as OWASP-NHI and zero trust expect those boundaries to be explicit.
👉 Read our full editorial: Observation debt is the real control gap in AI agent security
