The Agent Safety Gap Nobody Budgets For

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. Permission Creep Is The Real Attack Surface 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. Indirect Prompt Injection Turns Data Into Instructions 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 to