They keep reappearing because the underlying primitives stay available: untrusted input, retrieval, prompt manipulation, and automatic actions. When those primitives remain in the architecture, attackers can rebuild the same chain in a different platform with minor changes. Fixing one product does not eliminate the technique family.
Why This Matters for Security Teams
AI agent attacks keep resurfacing because vendor fixes often close one exploit path without removing the attack primitive itself. If an agent can still ingest untrusted input, retrieve external content, interpret instructions, and act automatically, attackers can rebuild the same chain in a slightly different product or workflow. That is why this is not just a patch-management problem. It is an architectural problem shaped by autonomous behaviour and tool access, as reflected in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.
NHIMG’s research on AI LLM hijack breach and OWASP NHI Top 10 shows the same pattern across environments: once an attacker finds a reliable way to steer retrieval, poison context, or trigger automatic actions, the technique travels well. In practice, many security teams encounter repeat compromises only after a new agent deployment reuses the same unsafe workflow, rather than through intentional review of the underlying control gaps.
How It Works in Practice
The repeatability comes from the fact that many AI systems share the same mechanics. A vendor may patch prompt filtering or tighten one tool connector, but if the agent still has broad permissions and can chain tasks across systems, the attacker can shift tactics rather than stop. That is why current guidance increasingly treats agent security as a runtime control problem, not a static application-hardening problem.
Practical defenses usually combine four layers. First, reduce the blast radius of the agent by using least privilege and short-lived access. Second, make authorisation context-aware so the system checks what the agent is trying to do at request time. Third, isolate retrieval and tool execution so untrusted content cannot silently become instruction. Fourth, use monitoring that can detect when an agent begins to deviate from its expected task path.
- Use workload identity for the agent, not shared service accounts, so each execution can be traced and constrained.
- Issue just-in-time credentials only for the task at hand, then revoke them immediately after completion.
- Evaluate policy at runtime with policy-as-code rather than relying only on pre-defined role mappings.
- Log tool calls, retrieval results, and downstream actions so a replayed attack chain is visible.
This aligns with the threat patterns documented in MITRE ATLAS adversarial AI threat matrix and the implementation guidance in CSA MAESTRO agentic AI threat modeling framework. It also reflects the operational reality described in NHIMG’s 52 NHI Breaches Analysis, where identity misuse and overbroad access remain durable attack enablers. These controls tend to break down when the agent is allowed to act across multiple SaaS platforms with inherited trust and no per-action policy evaluation, because the attacker only needs one permissive hop to reassemble the chain.
Common Variations and Edge Cases
Tighter controls often increase integration overhead and can slow legitimate automation, so organisations have to balance resilience against operational friction. That tradeoff is real, especially when multiple vendors, legacy APIs, and human-in-the-loop approvals all sit inside the same workflow.
There is no universal standard for every agent pattern yet, so best practice is evolving. Some environments can tolerate strict human approval for high-risk actions, while others need automated, context-aware limits to keep latency acceptable. In high-volume environments, the safer design is often to classify actions by sensitivity and apply stronger checks only where tool use can change state, exfiltrate data, or expand privileges.
Another edge case is vendor-managed agents. A product fix may reduce one attack path, but the customer may still inherit the same trust relationships, data access, and API scope. The right question is not whether the vendor patched a specific prompt injection issue, but whether the agent still has the ability to interpret untrusted content and act on it with durable credentials. That is why NHIMG recommends mapping recurring agentic risks against both Top 10 NHI Issues and the CISA cyber threat advisories so teams can separate product-specific defects from repeatable technique families.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic prompt and tool abuse recur when the same primitives remain exposed. |
| CSA MAESTRO | T1 | MAESTRO models repeatable agent attack chains across tools and workflows. |
| NIST AI RMF | GOVERN | Repeat attacks show governance gaps, not just isolated product defects. |
Assign ownership, document agent risk decisions, and review control drift regularly.
