AI Agent Security: The Risks That Actually Matter and the Practices That Work

You can date the moment agent security became a mainstream discipline fairly precisely. On December 9, 2025, the OWASP GenAI Security Project announced a dedicated Top 10 for Agentic Applications for 2026, built with input from more than a hundred practitioners. Security taxonomies follow incidents, and OWASP doesn't spin up a new Top 10 for hypothetical problems.

The underlying shift is easy to state. A language model that only generates text can embarrass you. An agent holds credentials, calls APIs, writes to databases, sends messages, and chains dozens of actions without a human reading each one. The model became an actor, and actors need a security model. What follows is our practitioner's read: where the risk actually concentrates, and the practices that remove most of it.

Where agent risk concentrates

The OWASP list runs from ASI01 through ASI10, covering goal hijacking, tool misuse, identity and privilege abuse, supply chain, code execution, memory poisoning, inter-agent communication, cascading failures, exploitation of human trust, and rogue agents. It's a good checklist. Operationally, though, we find the ten collapse into four families, and thinking in families keeps the defenses coherent.

The first family is instruction-shaped attacks. Goal hijacking is prompt injection grown up: content the agent encounters (an email, a web page, a document, a tool result) contains instructions the agent mistakes for legitimate direction. The uncomfortable truth is that everything an agent reads is potentially executable, because reading is how agents receive instructions. Skills and third-party prompts belong in this family too, which makes them a supply chain concern as much as a convenience.

The second is credential and privilege abuse. Whatever the agent can touch, an attacker who steers the agent can touch. Most deployments make this far worse than it needs to be by giving agents ambient, over-scoped credentials: one service account with organization-wide permissions, shared across every task the agent performs.

The third is memory poisoning. Anything written into an agent's persistent memory becomes tomorrow's trusted context. An attacker who can plant one false fact today gets it recalled with full confidence next week, long after the injected message is gone. Memory turns a one-shot attack into a persistent one.

The fourth is compounding autonomy: cascading failures, runaway loops, agents delegating to agents. Individually small errors multiply across steps, and by the time a human looks, forty actions have already landed.

The practices that do the heavy lifting

The encouraging news is that a small number of practices, applied seriously, defuse most of the list. None of them are exotic. All of them are the boring disciplines this industry already knows, applied to a new kind of actor.

Scope credentials per tenant and per request, never ambiently. The agent process holds nothing; each request resolves the narrowest credential that serves it, from a vault, at call time. We wrote up the full pattern in our MCP multi-tenancy piece: identity travels in transport headers where the model can't see or mangle it, never in tool arguments, and scopes narrow at every hop. A read-only task run with an org-admin token is an incident with a scheduled release date.

Gate consequential actions with a verifier. Every irreversible effect (payments, deletions, external messages, production changes) passes an independent check before it commits: schema and policy validation, an LLM judge with a rubric, or a human approval for the highest stakes. This is the verifier-in-the-loop pattern, and it's the single control that most changes an agent's risk profile, because it converts "the model was fooled" from an incident into a blocked attempt. OWASP's own guidance points the same direction: interception before execution, not audit after.

Treat memory writes as untrusted input. Provenance on every stored fact, freshness metadata, tenant-scoped stores with no exceptions, and retrieval that surfaces where a memory came from. If you can't answer "who wrote this fact and from what source," you can't detect poisoning.

Budget and bound everything. Per-run spend ceilings, step limits, and rate limits on sensitive tools turn a runaway loop or a hijacked goal from a disaster into a throttled anomaly. The metering spine you built for cost control is also a security control; a compromised agent shows up in its usage pattern before it shows up anywhere else.

And instrument to the decision level. Traditional application logs can't answer the question incident response will actually ask, which is "why did the agent decide to do that?" You need full decision traces: every tool call, retrieval, and memory recall, walkable by ID from the user-visible outcome back to the instruction that caused it. Behavioral monitoring on those traces catches the deviations signature-based tooling never will.

Red-team the agent, then keep doing it. Prompt injection through every content channel the agent reads, privilege escalation through tool chaining, poisoning through memory. Agents change with every prompt edit and model upgrade, so this is a cadence rather than a milestone.

Security is an architecture property, and that's the good news

Notice what that list has in common. Almost none of it can be bolted on afterward, because the controls live in the platform layer: identity resolution, verification gates, memory scoping, metering, tracing. This is why we keep arguing that the framework is the easy 10% of an agent stack. A framework gives you the loop. Whether the loop is safe is decided by the infrastructure around it.

That architecture-first view is how we built Zytherum: per-tenant credential resolution, policy gates in front of every consequential action, scoped and provenance-tracked memory, budgets, and decision-level traces as defaults of the platform rather than options for each team to reinvent. Whatever stack you run, insist on those properties. The OWASP list will keep growing new entries, and the systems that hold up will be the ones where security was a property of the platform, so the answer to each new threat was already mostly in place.

If you're putting agents in front of real credentials and real customers and want a second pair of eyes on the design, talk to us.

ArthaVortex builds Zytherum, an agent platform with per-tenant identity, verification gates, and decision-level tracing built in rather than bolted on.