Key facts.
- CISA's Secure by Design is a real US initiative built on three core principles, backed by a voluntary pledge that dozens of major software makers have signed. source
- The OWASP Top 10 for Agentic Applications, released December 9, 2025 by the OWASP Gen AI Security Project, names ten agent-specific risks (ASI01 Agent Goal Hijack through ASI10 Rogue Agents) that traditional app-sec never had to model. source
- Its mitigations are runtime and behavioral: treat agents as first-class identities with scoped privileges, sandbox code execution, authenticate inter-agent messages, add circuit breakers, and keep human oversight on high-impact actions. source
- Memory and context poisoning (ASI06) is a control class with no SDLC equivalent: one hostile write to long-term memory can steer behavior across future sessions until someone audits the store. source
Why doesn't a clean secure SDLC carry over to agents?
Secure SDLC assumes the program's behavior is fixed at build time. You threat-model the code, you review it, you ship it, and what runs is what you reviewed. An agent breaks that assumption on day one. Its behavior is decided at runtime by a model reasoning over inputs you do not control, including documents and tool outputs that can carry hostile instructions. A pre-ship review can certify the code around the agent, but it cannot certify the decisions the agent will make next Tuesday when an injected ticket changes its plan. The SDLC is necessary. It is no longer sufficient.
That is why the OWASP agentic list reads so differently from a code-security checklist. Goal hijack, tool misuse, memory poisoning, rogue agents: these are runtime behaviors, not coding defects. You cannot grep for them. You constrain them with controls that live around the agent while it runs.
What are the four patterns that extend the SDLC?
Least agency: give the agent the narrowest set of capabilities the task needs, and bound its goals so a hijacked objective cannot reach far. Tool scoping: gate every tool invocation, validate outputs, and sandbox execution so a misused tool cannot become remote code execution or a supply-chain entry. Memory integrity: isolate and version context, and audit long-term state so a single poisoned write cannot quietly steer every later session. Runtime guardrails: monitor behavior live, authenticate inter-agent messages, add circuit breakers against cascading failures, and keep a human gate on high-impact actions. None of these replace secure coding. They sit on top of it.
| Concern | Traditional secure SDLC | Agent-specific pattern |
|---|---|---|
| Excess capability | Least privilege on code paths | Least agency: bounded goals, scoped reach |
| External calls | Input validation | Tool scoping plus execution sandboxing |
| Persistent state | Database access control | Memory integrity and context isolation |
| Behavior over time | Fixed at build, reviewed once | Runtime guardrails and circuit breakers |
This is the work a Pattern Intelligence Layer is built to carry. Reliability and security at the pattern level mean least agency, tool scoping, memory integrity, and runtime guardrails are enforced as properties of how the agent runs, not promises about how the model behaves. You keep CISA's foundation and add the floors autonomy requires, and the whole stack survives your next model swap because the controls live in the pattern, not the model.
Frequently asked questions
Does a more capable model cover what secure-by-design misses?
Secure SDLC assumes code obeys its text; an agent acts on what it reads at runtime, so a stronger model still leaves the rework, since OSWorld puts the best at 12% to humans' 72%. (source)
Does secure-by-design still matter for agents?
Yes, fully. CISA's principles are the foundation. Agents add controls on top, they do not retire the SDLC. Keep both.
Which agent control has no SDLC equivalent?
Memory integrity. A poisoned long-term memory write persists across sessions and steers future decisions, a failure mode static code review was never built to catch.
Can a more capable model replace these controls?
No. The best models still complete a small fraction of real-computer tasks. The autonomy gap is wide, and the controls that bound it live around the model, not inside it.