Key facts.
- Classic SDLC research finds a defect costs roughly 30x to 100x more to fix after release than at the design or requirements stage. The curve is steep and it points one way. source
- OWASP's Top 10 for LLM Applications 2025 ranks Prompt Injection as LLM01, the number one risk, and Excessive Agency as LLM06. Both are squarely agent problems. source
- The OWASP Gen AI Security Project also published a dedicated Agentic AI threat list in 2025, covering memory poisoning, tool misuse, and privilege compromise that single-prompt models never faced. source
- Indirect prompt injection hides instructions inside content the agent reads (a document, a web page, a ticket), and current models cannot reliably tell ingested data from a command. source
Why is retrofitting security so expensive for agents specifically?
Security is a design decision, not a patch; the model is no control, since attacks broke 12 defenses past 90% on a frontier system. (source)
Traditional software has a stable attack surface. An agent's surface moves. Every new tool you connect, every document it can read, every memory it writes becomes a new way in. When you add security late, you are not patching one component. You are re-deciding which tools the agent may call, what data each tool returns, how a tool result is trusted, and what gets logged. Those decisions reach into the agent's planning loop, its prompts, its tool schemas, and its data flow. Change them after launch and you are rebuilding the thing while it serves traffic.
Built in from the start, the same controls are cheap. Permission scoping is a config choice when you wire the first tool. A trace is a logging call you add once. Treating untrusted text as untrusted is a rule you set before the agent ever reads a customer email. None of that slows you down at design time. All of it is brutal to add at incident time.
What does "built in" actually look like?
Three concrete patterns separate the agents that pass a security review from the ones that get sent back. Scope every tool to the least privilege it needs, so one injection cannot reach the whole system. Treat all ingested content as data that may be hostile, never as instructions to obey. And capture a reconstructable trace of every decision and tool call, so when something does go wrong you can see what the agent did and why.
| Control | Built in at design | Retrofitted after launch |
|---|---|---|
| Permission scoping | Config on first tool wire-up | Re-audit every tool the agent can already reach |
| Injection handling | Untrusted-by-default rule set once | Rework prompts and data flow under live traffic |
| Audit trace | One logging layer, always on | Reconstruct history you never recorded |
This is where the Pattern Intelligence Layer earns its place. Reliability and security at the pattern level mean the controls live around the agent's behavior, not inside a single model you hope behaves. Scope, untrusted-input handling, and tracing become properties of the pattern, enforced the same way on every run, independent of which model you swap in next quarter. That is what survives a model upgrade, and it is what an incident review actually wants to see.
Frequently asked questions
Can't we just pick a more secure model?
No model is the control. Adaptive attacks broke a dozen published defenses against frontier agents. Security has to live in the pattern around the model, not be outsourced to the model.
We are pre-launch. When should security work start?
Now. The cheapest time to scope permissions, define untrusted inputs, and add tracing is while you are wiring the first tool. Every week you wait moves the same work up the cost curve.
Isn't this just slowing down the build?
The opposite. Built-in controls are config and one logging layer. Retrofitted controls are a rebuild under production load. Building in is the faster path to a shippable agent.