Things I got wrong about agent security
Agent security frameworks name risks in full but rarely validate the defense. Threat modeling and infrastructure matter more than this month's technique.
Disclaimer
This article is intended for informational purposes and reflects the state of published research and industry practice as of mid 2026. It is not professional security advice. Your specific environment, threat model, and regulatory obligations will shape how these principles apply to your situation.
For Security Leaders
Agentic AI security guidance is stronger at naming attack techniques than at proving which defenses stop them. A year of published research shows the same gap: the step with the most attention rarely decides whether an incident happens. A named risk is not a validated control.
What this means for your organization:
Named risk categories are not proof of a working defense. OWASP fully describes goal hijack and code execution, but the field’s most rigorous adjacent research still calls agent defenses immature.
Infrastructure decides breach impact more than attack sophistication. Credential scope, isolation, egress, and approval gates determine consequence, not the triggering technique.
Citing frameworks together can overstate confidence. OWASP, MITRE ATLAS, and NIST differ sharply in validated evidence.
What to tell your teams:
Stop treating prompt injection defense as the finish line. Audit the credential, container, and egress boundaries a hijacked agent could reach.
Separate naming from validation. Note whether a cited defense is validated or only named.
Ask which kill-chain step has never been tested end to end. Documentation is not evidence it works.
Treat approval gates and audit logging as primary controls, not fixes added after the main defense.
The technique that cannot be stopped got more attention than the infrastructure that contains it
My own book states plainly, in its opening chapter, that prompt injection is the one failure mode in its entire kill chain that no technical control eliminates, and that the surrounding controls only reduce the attack surface and limit the blast radius once it happens. Most of a year’s worth of writing gave the technique the bulk of the attention anyway, while the surrounding infrastructure, the part that actually decides whether a hijacked goal turns into an incident, got treated as the supporting cast.
That is the first mistake, and it connects to a second one. The frameworks the field leans on to classify agent risk name the exciting failure modes in exhaustive detail and say almost nothing about how validated the defenses against them actually are.
Both failures share a shape. The technique, the named risk category, the clever new headline, gets treated as the substance. The infrastructure underneath it, the scoping discipline, the validation depth, is where the real answer was sitting the whole time, and it is less interesting to write about, which is exactly why it kept losing the argument.
The infrastructure decides whether a hijacked goal becomes a breach
The first place this shows up is inside the kill chain itself. My book’s own architectural chapter names goal hijacking as the vulnerability that makes everything downstream possible: without it, credential extraction has no direction and container escape has no target. That sentence reads, on a first pass, like an argument for treating the hijack as the center of the problem. It is the opposite. A hijacked goal with nowhere to go is a non-event. What turns it into a breach is whatever the agent can subsequently reach: which credentials it can pull from environment variables, which container boundary it can cross, which egress path is open, whether a human approval gate would have caught the action or rubber-stamped it. The hijack is the spark. Threat modeling, the discipline of scoping in advance what an agent is even capable of reaching, and the infrastructure that enforces that scope, identity, credential architecture, isolation, egress control, audit logging, is what determines whether the spark goes anywhere.
A second, independent data point for this comes from a fictionalized breach narrative built earlier this year around a compromised developer tool. The finding that piece kept returning to was that detection tempo, how quickly the organization noticed something was wrong, drove more of the eventual damage than the sophistication of the technique that got the attacker in. A crude opening move against slow, under-instrumented infrastructure did more damage than a sophisticated one would have done against an organization watching its own credential and egress activity closely. The technique was almost incidental to the outcome. The infrastructure was not.
The same substitution shows up one level up, in the frameworks themselves
The corpus leans on three frameworks to classify risk: the OWASP top ten for agentic applications, MITRE ATLAS, and CSA MAESTRO. Checking the OWASP document directly, not a summary of it, confirms that agent goal hijack and unexpected code execution, the two categories a reader would reach for first, are both named with a full description, common examples, attack scenarios, and mitigation guidance running about two pages each. There is no missing category here, and that distinction matters: OWASP does not fail to name these risks.
OWASP’s completeness can make the risk feel fully mapped, but mapped and validated are not the same claim. NIST publishes a separate taxonomy of adversarial machine learning attacks, approved through its own formal editorial review process and co-authored with Northeastern University, Cisco, and the U.S. and U.K. AI Security Institutes. The document mentions agents briefly in passing while cataloguing general attack surfaces, and then gives them one dedicated section, titled plainly “Security of Agents,” that runs a single paragraph. No figure accompanies it, in a document that otherwise diagrams its predictive and generative AI risk categories in full. The paragraph itself states plainly that security research aimed specifically at agents is still early. Naming a risk in full, the way OWASP does across two pages per category, answers what the risk is called and how it can show up. It does not answer how mature the defense against it actually is, and that second question is the one NIST’s separately reviewed federal taxonomy admits, in its own text, is still open.
A regulator checking a deployed agentic system against this stack of frameworks can locate a named code for goal hijack or unexpected execution in minutes. What they cannot locate, anywhere in the same stack, is a comparable baseline for how much confidence any specific mitigation deserves, because the one document built to anchor that judgment says outright that it does not yet have one. The pattern is identical to the kill chain finding: the field, mine included, races to name the technique and moves slower on validating what actually contains it.
The fix is where the attention goes, not which techniques get covered
None of this argues for writing less about prompt injection, goal hijack, or any other named technique. What these two findings have in common is a question of where the weight goes, not whether the exciting material gets covered at all. Threat modeling, the work of scoping what an agent can reach before anything goes wrong, and the infrastructure that enforces that scope, deserve at least the attention the technique of the month gets, and the evidence from my own archive says they currently do not get it.
For the kill chain, that means treating goal hijack as the trigger it is, not the center of gravity. The center of gravity is the credential boundary, the container boundary, the egress path, and the approval gate the hijacked goal has to pass through before it becomes a consequence. Those are less interesting to write about than a new jailbreak technique and they are where the actual defense lives.
For the framework layer, the useful move is narrower than it sounds: stop citing the trilogy as a unified, settled baseline. OWASP and MITRE ATLAS name agent risk categories with real depth. NIST’s own agent section does not carry the same depth, and it says so. A reader building a control program off that citation deserves to know which layer is doing the naming and which layer is still admittedly forming, because the naming was never the hard part.
The through-line across both is that the interesting-sounding layer, the technique, the named category, kept getting treated as the substance, while the boring layer underneath it, the scope, the validation depth, was where the real answer was sitting. That is the correction this piece is making in public, and the test from here is whether the next piece of writing gives the scope and the validation depth as much room as the technique that raised the question in the first place.
Peace. Stay curious! End of transmission.
Fact-Check Appendix
Statement: The book’s kill chain names prompt injection and goal hijack as the one step among twelve where no technical control eliminates the failure mode outright; the surrounding controls reduce the attack surface and constrain the blast radius instead. | Source: The Agentic AI Security Stack (First Edition), https://www.nextkicklabs.com/p/agentic-ai-security-stack-book-release
Statement: The book’s architectural analysis describes goal hijacking as the vulnerability that makes subsequent credential extraction and container escape possible, positioning it as a precondition rather than the point of maximum consequence. | Source: The Agentic AI Security Stack (First Edition), https://www.nextkicklabs.com/p/agentic-ai-security-stack-book-release
Statement: A fictionalized breach narrative published this year concluded that detection tempo miscalibration drove more breach impact than attack technique sophistication. | Source: “The Three-Day Breach,”
Statement: OWASP’s Top 10 for Agentic Applications 2026 names Agent Goal Hijack and Unexpected Code Execution as full categories, each with a description, common examples, attack scenarios, and mitigation guidance. | Source: OWASP Top 10 for Agentic Applications 2026, https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
Statement: NIST’s Adversarial Machine Learning taxonomy devotes a single dedicated section, one paragraph long with no accompanying figure, to agent security, and states that research focused specifically on agents is still in its early stages. | Source: NIST AI 100-2e2025, https://doi.org/10.6028/NIST.AI.100-2e2025
Statement: MITRE ATLAS’s February 2026 update (v5.4.0, released 2026-02-05) added seven new techniques, including “Publish Poisoned AI Agent Tool” and “Escape to Host.” | Source: MITRE ATLAS changelog, https://github.com/mitre-atlas/atlas-data/blob/main/CHANGELOG.md
Statement: CSA MAESTRO was introduced in February 2025 as a seven-layer model built for agentic systems from the outset, rather than retrofitted. | Source: “Agentic AI Threat Modeling Framework: MAESTRO,” https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
Top 5 authoritative sources and studies
OWASP Top 10 for Agentic Applications 2026, OWASP Gen AI Security Project, December 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
NIST AI 100-2e2025, “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations,” NIST, March 2025: https://doi.org/10.6028/NIST.AI.100-2e2025
MITRE ATLAS, v5.4.0 (February 2026): https://github.com/mitre-atlas/atlas-data/blob/main/CHANGELOG.md
Cloud Security Alliance, “Agentic AI Threat Modeling Framework: MAESTRO,” February 2025: https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
The Agentic AI Security Stack (First Edition), July 2026: https://www.nextkicklabs.com/p/agentic-ai-security-stack-book-release