Loss of Intent as a Failure Mode in OWASPs Agentic AI Risks (2026)

OWASP recently released the Top 10 Vulnerabilities for Agentic Applications (2026). One thing this list makes clear is that agentic systems fail differently than traditional applications or even simple LLM integrations. The failure mode is not that the model produced a bad output but is that the system took a valid action for the wrong reason. Unlike SQL injection or XSS, which produce deterministic and observable failure, agentic failures are probabilistic and contextual making it hard to distinguish from normal system behavior.

Photo by Lukas on Unsplash

At a high level, these vulnerabilities fall into three buckets:

• loss of intent and alignment
• excessive agency or too much power
• unchecked blast radius

I will cover all three across multiple posts. In this first part, I want to focus on loss of intent, what it means in real systems, and mitigations.

Conceptually, loss of intent means the agent is no longer reliably working toward the goal it was originally given, even though it appears to be functioning correctly. This happens because the system lacks a mechanism to continuously validate that actions still align with the original objective.

In the OWASP Top 10 list, three vulnerabilities roughly fall into this category:

• ASI-01: Agent Goal Hijack
• ASI-06: Memory and Context Poisoning
• ASI-10: Rogue Agents

Before discussing any of these, let's consider a Incident Response and Remediation Agent. This agent can assist on-call engineers during production incidents. Its purpose is to reduce mean time to recovery while operating within explicit safety constraints. It's responsibilities to ingest tickets, alerts, metrics, logs, and traces, correlate signals across services, recommend remediation actions, and execute a small set of pre-approved actions after human approval.

ASI-01: Goal hijack

This happens when the agent begins to favor actions that satisfy the metric but violate the goal (Optimization Drift). Human-in-the-loop often accelerates this. E.g. an exhausted on-call engineer might approve a service restart because it worked in the past, even if the root cause is a memory leak that requires a rollback. The agent learns this bias, reinforcing a cycle of superficial fixes.

Basically, the agent begins favoring actions that resolve/close the system fastest and not the correct ones.

ASI-06: Memory poisoning

Agentic memory is a stateful feedback loop. When the agent ingests Slack threads or quick fix runbooks, it eventuallt starts treating temporary workarounds as permanent truths. Without a time-to-live or a human-reviewed knowledge base, the agent's long-term memory becomes a repository of technical debt and workarounds.

ASI-10: Rogue behavior

In the OWASP context, ASI-10 refers to agents executing unauthorized or off-script actions because of complex tool-calling chains. For example may be the restart was safe last month but may be harmful today due to a new downstream dependency (Stale logic). The agent operates on an outdated model of the infrastructure. Without updated capability discovery, the agent becomes a "rogue agent" simply by executing past best practices on the current architecture.

Mitigations

In addition to traditional security, the following mitigations can help.

• Intent must be explicit and enforceable. May be ranked too. "Reduce alerts" and "restore correctness" are not interchangeable. If the system cannot tell the difference, it will optimize the cheaper signal.
• Memory must expire by default. Most things learned during an incident are temporary and should expire automatically. Long-term knowledge should only stick when someone deliberately promotes it. Treat memory like cache (L1 - short term - context from current session, L2 - validated - human approved actions, L3 - cold - historical logs)
• Trust and authorization must be renewed. Like IAM

In the next post, I will talk about the second bucket, "agents with too much power".