The Agent Safety Gap Nobody Budgets For

OWASP released a dedicated Top 10 for Agentic Applications in December 2025, highlighting that agent safety is a distinct discipline from application security. The article, written by a developer, argues that the primary gap is not disagreement but a lack of budgeting for safety work, leading to permission creep and indirect prompt injection risks. It recommends starting agents with zero permissions, requiring human approval for high-impact actions, and monitoring tool call distributions to detect successful injections.

When a chatbot hallucinates, a person reads the answer and catches it. When an agent hallucinates, it may have already run the query, sent the email, or changed the config before anyone looks. That single difference is why agent safety is its own discipline rather than a subsection of application security, and it is why OWASP shipped a dedicated Top 10 for Agentic Applications in December 2025 instead of folding the problem into the existing LLM list. Most teams I talk to are not missing this because they disagree. They are missing it because the safety work never got a line in the plan. The agent shipped, it worked, and the access model that came with it on day one is still the access model on day ninety. The incidents that actually happen are boring. An agent gets built to summarize documents. Two sprints later somebody needs it to write a summary file, so it gets write access. Then it needs to post the summary, so it gets an API token. Nobody sat down and approved a document summarizer with filesystem and network write access, but that is what exists now, and the access model was never revisited because nothing broke. Least privilege is easy to agree with and boring to maintain, which is exactly why it fails. The useful version is a rule rather than a principle: every agent starts at zero permissions, and every capability you add triggers a re-read of the whole permission set rather than an append to it. Prompt injection is still OWASP's number one risk for LLM applications, and it gets meaningfully worse in an agentic context because the payoff is no longer a misleading answer, it is a real action. The direct version, where a user types something that overrides the system prompt, is the one everybody tests for. The version that gets people is indirect: the malicious instruction sits inside a web page, a support ticket, a PDF, or a database row that the agent was told to go read. The agent has no way to distinguish content it was asked to process from instructions it was asked to follow, so it follows them. This is why permissions and injection are the same problem rather than two problems. An agent that can only read is a bad day. An agent that can read a poisoned page and then act on it is an incident. No single control is enough, so the useful pattern is layers that fail independently: Scope tools, not just data. An agent with a "send email" tool that can only send to internal addresses is a different risk profile from one holding a general SMTP credential. Put a human in front of the short list. Financial transactions above a threshold, production infrastructure changes, external communications, and access control changes should require approval, and the approval screen should show the agent's reasoning next to the proposed action so the human is deciding rather than rubber stamping. Validate between agents. In a multi agent pipeline, agents that trust each other's messages without checking them turn one compromised step into ten bad outputs. Watch the decisions, not just the errors. Most agent monitoring counts failures. The more useful signal is the distribution of what the agent chose to do, because a slow drift in which tools get called is what a successful injection looks like from the outside. Pick one agent already running in production and write down every permission it holds and who approved each one. In most teams that document does not exist yet, and producing it is usually enough to find at least one capability nobody remembers granting. From there, the sequence that works is: revoke what is not needed, put approval in front of the actions you would never want done wrong, and add logging that records the tool calls rather than only the failures. The full breakdown, including the threat categories, the governance side, and the compliance picture as the EU AI Act enters full enforcement for high risk systems in August 2026, is here: https://www.autolearningagents.com/ai-agent-safety/ https://www.autolearningagents.com/ai-agent-safety/ The teams that do this early are not being cautious. They are avoiding the retrofit, which costs far more than the original work would have.