I keep hearing teams say they'll "add security later" when it comes to their agentic systems. I have said it myself, early on. I get the appeal: you are moving fast, the agent mostly works, and proper security feels like something you layer on once the thing is stable.
That reasoning is wrong for regular web services. For agents, it is actively dangerous.
Table of Contents#
- The OWASP List You Probably Haven't Read Yet
- Why Tool Outputs Are Attack Surfaces
- The 82:1 Problem
- The Regulatory Clock Is Running
- What Practical Defense Actually Looks Like
- Where to Start
- Five-Item Security Checklist for Your Next Sprint
- How I Would Run This in Production
- What I Would Measure
- Where This Connects
- FAQ
The core problem is this: agents do not just sit there processing requests. They take actions. They write to databases. They call external APIs. They execute code, send emails, trigger Slack notifications, modify files. A compromised web endpoint leaks data. A compromised agent can create cascading failures across your entire production system, and do it automatically, at scale, before any human notices.
That is a fundamentally different risk profile, and most teams are treating it like it is not.
The OWASP List You Probably Haven't Read Yet#
In December 2025, OWASP published their Top 10 for Agentic Applications. It is worth reading in full, but here are the five categories that keep me up at night.
Goal hijacking is when adversarial input in tool outputs or user messages redirects what the agent is trying to accomplish. Not a crash, not an error. The agent just starts doing something different from what you intended. Silently.
Memory poisoning targets the persistent memory that self-improvement loops read from. If an attacker can write to your agent's memory store, they can influence its behavior across every future session, not just the current one.
Cascading failures are what happen in multi-agent systems when one compromised agent propagates errors downstream. The others keep working, processing poisoned information, acting on it.
Identity abuse means agent credentials being used to authenticate malicious requests. Your agent has an API key or a service account. If that token gets used by something other than your agent, you probably will not notice for a while.
Over-permissioning is the quiet one. Palo Alto and CyberArk research puts it at 90% of deployed agents. Nine out of ten agents in production have more permissions than they need for their actual job.
That last number is worth sitting with. It means the blast radius of any of the above attacks is, for most systems, much larger than it needs to be.
Why Tool Outputs Are Attack Surfaces#
Traditional web security has a clear mental model: protect the endpoint, validate user inputs, prevent injection. The boundary is at the edge of your system.
With agents, that boundary does not exist in the same way.
When an agent reads from a database, the database result is external input that goes straight into the agent's context. When it calls an external API, the response shapes what the agent does next. If an attacker can influence what is in those database rows or those API responses, they can influence the agent's next actions without ever touching your endpoint directly. This is prompt injection via tool results, and it is genuinely different from what security engineers have been trained to think about.
The same logic applies to memory stores. If your agent has persistent memory that gets read back into context at the start of every session, that memory is an attack surface. Poison it once, and you've affected every future session until someone catches it.
The 82:1 Problem#
Here is what changes the calculus the most. In some enterprise deployments, autonomous agents already outnumber human operators 82 to 1. I do not think people have absorbed what that number means for security.
A single forged command in a human-operated system affects one interaction. In a system where agents outnumber humans 82:1, a single poisoned input can propagate through dozens of automated workflows before any person sees it. A poisoned trace in a self-improvement pipeline like LangSmith Engine does not just affect the current session, it affects the codebase changes the system proposes to itself. One bad trace, interpreted as a failure pattern, can steer the agent's own improvement direction.
That is a new attack vector. It did not exist before self-improving agents. It requires integrity checking on the trace data feeding into improvement pipelines, which almost no team has implemented yet.
The Regulatory Clock Is Running#
I want to be direct about the timeline here, because "we'll do this later" is no longer a valid plan for a lot of teams.
The EU AI Act's high-risk obligations took effect August 2026. Colorado's AI Act came into force June 2026. If you are running agents that touch regulated data or make consequential decisions, you are already operating in a regulated environment. "We prioritized shipping" is not a compliance defense.
This is not hypothetical future regulation. It is now.
What Practical Defense Actually Looks Like#
The good news: the defenses are not exotic. They require engineering rigor and discipline more than specialized knowledge.
Least-privilege tokens. Your agent should not have a general-purpose service account. It should have a token scoped exactly to what that specific agent needs for its specific task. If the agent reads from one database table and writes to one other, it should have credentials for those two operations, nothing else.
Tool-use auditing. Log every tool call, including the reasoning that led to it. Not just "the agent called the payments API" but "here is what the agent was thinking when it decided to call the payments API." Anomalous tool calls, an agent accessing resources it has never touched before, should trigger alerts before anything else happens.
Input validation at tool boundaries. Treat database results and API responses as untrusted external input. Sanitize before injecting into agent context. The fact that the data came from your own database does not make it safe.
Memory integrity checks. If your agent uses persistent memory, validate that memory entries haven't been modified between sessions. A checksum or a signed envelope on memory records is not complex engineering, it is the kind of thing you'd do automatically for any other data store that affects system behavior.
SBOM tracking for agent-added dependencies. When your agent modifies code and installs packages, those packages need to appear in your dependency manifest. The agent adding an import is the same as a developer adding an import, it needs to go through the same supply chain verification.
Signed commits for agent-authored changes. Know which changes came from agents and which came from humans. This is basic provenance, and it will matter enormously when you need to audit what happened after something goes wrong.
Escalation gates for high-risk actions. Any write operation, financial transaction, or external communication should require additional verification or human approval. Not every action, that would defeat the purpose of automation. But the high-stakes ones. Define what high-stakes means for your system before something bad forces you to define it.
Where to Start#
Microsoft open-sourced their Agent Governance Toolkit in April 2026. It provides runtime security including permission sandboxing, tool-use auditing, and escalation gates. If you do not have a dedicated AI security team, this is a practical starting point rather than building from scratch.
Five-Item Security Checklist for Your Next Sprint#
Teams I respect use sprint-based security reviews, treating security as a repeating commitment rather than a one-time audit. Here is what I would put on the list for your next sprint if you are running agentic systems in production.
-
Audit token scopes. Pull the credentials your agents use and verify each permission is actually required for the agent's current task. Remove what is not needed.
-
Add tool-use logging with reasoning context. Every tool call should log what the agent was trying to accomplish, not just what it called. Set up a simple alert for tool calls to resources the agent hasn't touched in the past 30 days.
-
Sanitize at tool boundaries. Pick one tool your agent calls most frequently and add explicit input validation on the output before it enters agent context. Then do the next one.
-
Verify memory integrity. If you are using persistent memory, implement a checksum or signed record for memory entries. Verify on read, before anything goes into context.
-
Map your escalation gates. Write down, for every consequential action your agent takes, what triggers human review. If you cannot write it down, you do not have escalation gates.
None of this requires months of work. A focused sprint with clear scope can address most of it. The goal is not perfect security, that does not exist. The goal is reducing blast radius and building visibility so you know when something goes wrong before it cascades.
Agents that do real things need security that treats them as what they are: systems with the ability to cause real harm at machine speed. The sooner teams stop treating this as a future concern, the better.
How I Would Run This in Production#
I would start by writing down what the agent can do, not what the application can do. Agents inherit risk through tools. A harmless chat interface becomes a high-risk system the moment it can send emails, query customer records, run shell commands, approve refunds, or update production data.
The first control is permission scoping. Give the agent the narrowest tool set required for the task, with read and write operations separated. A read-only research agent should not have access to mutation tools. A support agent that drafts refunds should not also approve them.
The second control is tool output validation. Prompt injection often enters through retrieved documents, web pages, tickets, or tool responses. Treat tool output as untrusted input. The agent should not blindly follow instructions found inside data it fetched.
The third control is a sandbox for actions. File access, network access, shell commands, and database writes need boundaries. If you would not give a junior engineer unrestricted production credentials, do not give them to an autonomous loop with weaker judgment and higher speed.
What I Would Measure#
Track over-permissioned agents, blocked tool calls, policy violations, high-risk action approvals, prompt-injection detections, memory-write events, and audit completeness. Security dashboards should describe behavior, not just infrastructure posture.
I would also test blast radius with tabletop exercises. If the agent receives a malicious tool result, what can it touch? If memory is poisoned, how long does the bad instruction persist? If a tool credential leaks, how quickly can you revoke it?
The practical goal is not zero risk. It is bounded risk with evidence. When something goes wrong, you should know what the agent saw, what it decided, what it did, which policy checks ran, and how to stop the same path from recurring.
Where This Connects#
This post is one piece of the production agent lifecycle. The adjacent pieces matter because the failure usually does not stay inside one layer. A tracing problem becomes an eval problem. An eval problem becomes an ownership problem. A routing problem becomes a cost and security problem if nobody can see what changed.
- An AI Agent Deleted a Production Database: Why Agent Permissions Are the New Security Boundary
- Securing AI-Assisted Development: The Enterprise Guardrail Playbook (2026)
- Why Your Traces Are Lying to You
- 10 Lessons From Production AI Agents
- Why You Need Offline and Online Evals
If you are using this as a checklist, read those posts as dependencies rather than as optional background. The stack only becomes reliable when the evidence loop, the release loop, and the security loop all point at the same production behavior.
FAQ#
Why is agent security different from web security?#
Agents can interpret instructions, call tools, remember context, and chain actions. That makes tool access, memory, prompts, and retrieved content part of the security boundary.
What is the first security control to add?#
Start with scoped permissions. Separate read and write tools, remove unused capabilities, require approval for high-impact actions, and make every tool call auditable.
How does prompt injection reach an agent?#
It can enter through web pages, documents, tickets, emails, tool responses, memory, or user messages. Any text the agent reads can contain instructions that try to override the system goal.
Should agents have production database access?#
Only through narrow, audited tools with strict validation and approval for risky mutations. Direct broad database access is rarely justified for autonomous agents.
What should go into an audit trail?#
Record the prompt version, model version, user request, sanitized context, tool calls, arguments, policy checks, approvals, outputs, and final action. The trail should support incident review.
How do I test agent security?#
Use adversarial prompts, poisoned documents, malicious tool outputs, permission-boundary tests, and simulated credential failures. Security tests should run before deployment and after tool changes.
Implementation Review Checklist#
Before I would call this production-ready, I would ask five questions in the review. First, does the team know which artifact changed because of this lesson? A trace field, eval case, prompt file, routing rule, dashboard, or security policy should be visible in the repo or the runbook. If the only output is agreement, the lesson has not landed yet.
Second, can the team reproduce the failure mode in a lower environment? Production AI work gets messy when the only evidence is a screenshot, a Slack thread, or a vague user complaint. A reproducible example gives the team something concrete to test against after the fix.
Third, does the fix have an owner after the first merge? Most agent systems decay slowly. Datasets go stale, prompts drift, routing rules stop matching traffic, and permissions expand. The owner is the person who notices that drift before it becomes an incident.
Fourth, is rollback obvious? If a prompt, model, parser, evaluator, or security rule makes behavior worse, the team should know how to return to the last known-good version without rewriting the system under pressure.
Fifth, did the incident or improvement strengthen the loop? A good production process compounds. The trace becomes an eval. The eval becomes a gate. The gate becomes a safer release. That is the practical standard I would use for every idea in this series.
I would also ask whether the change makes the system easier to explain to a new teammate. Production AI stacks fail when the important behavior lives in someone s memory. If the reason for a prompt rule, routing threshold, eval example, or tool permission is not written down, the next person will eventually delete it while cleaning up what looks like accidental complexity.
The review should include one negative example. Show the input that used to fail, the trace or eval result that made the failure visible, and the current behavior after the change. This keeps the team grounded in evidence. It also stops the review from becoming abstract, which is where AI engineering discussions often drift.
For agent systems, I would check the cost impact and the quality impact together. A fix that improves quality by calling a frontier model three extra times may be correct for a regulated workflow and wrong for a low-margin support workflow. A cost reduction that removes useful context may look good for a week and then show up as worse user outcomes. The trade-off has to be explicit.
The last check is operational ownership. If the change creates a new dashboard, who looks at it? If it creates a new eval, who updates it? If it creates a new permission boundary, who approves exceptions? The difference between a strong production practice and a temporary cleanup is usually whether the maintenance path is obvious.
None of this needs to be heavy. A short pull request note, one linked trace, one eval case, and one owner are enough for many changes. The point is to leave a trail that future engineering work can build on. That is how AI systems become more reliable over time instead of slowly collecting unexplained rules.