Anthropic’s AI-native AI SDLC, describes how agentic development actually works, but it puts security at the end of the loop when the loop is exactly what lets you move security to the front.
Key takeaways
- The playbook runs on a chain of committed artifacts, one file per stage, and that chain is where security requirements can attach at the origin, rather than arriving as a PDF nobody opens.
- The playbook assumes the agent environment is trusted. Rule files, skills, MCP tools, and packages have all been attacked in production across 2025 and 2026. Treat that assumption as broken.
- Put security into the design artifact, into the guardrails and hooks that run while code is generated and before the push. Make the pull request check a second opinion, not the first line.
- Review your SDLC Security Concept and automate the cycle
- Phoenix Purple puts security where generation happens: it checks agent configuration against secure defaults, scans a knowledge graph to reduce token costs, returns findings and fixes at the session hook, runs N+1 graph-aware pull request analyses, and hunts for chainable zero-days with agentic validation.
The playbook is right about the shape of the work
Anthropic published training and reference material on the AI-native AI SDLC. I opened it expecting marketing and found something closer to an engineering memo. Most of it is about how software gets built. Three ideas in it change what security has to do.
The first is the committed artifact. Every stage ends by writing one file to version control, and the next stage begins by reading it. Intent becomes a specification, the specification becomes a plan, the plan becomes a diff and its tests, the diff becomes a pull request, and its findings, and an incident record becomes the next intent. Sounds like process bookkeeping. It isn’t. It gives security something stable to attach to. A constraint written into the intent file at origin, in the originator’s own words, carries all the way downstream. Security requirements stop being a document nobody opens and become an input that he generator must adhere to.
The second is the distinction between advisory and enforced controls. A skill encodes policy and makes the agent likely to comply. A hook runs on every matching action and can allow, ask, or block. Anthropic’s phrasing beats mine: the skill makes violations rare, and the hook makes them close to impossible. Most security programs I see have written a lot of the first kind and almost none of the second. We had that problem ourselves for longer than I want to admit.
The third is the one I keep chewing on. They run evals against the agent’s configuration, not just against the code the agent writes, and they block configuration changes when those evals fail. More on why that matters later, because it matters more than it looks.
The assumption I don’t think we can make
One assumption sits underneath the playbook that security teams cannot inherit.
The agent environment is trusted. So are its rules, its skills, its MCP tools, the packages it reaches for, and the configuration that tells it how to behave. All trusted.
Look at the last two years and that gets hard to defend. Pillar Security disclosed the rules file backdoor in March 2025: malicious instructions hidden inside agent rule files, invisible in a diff, executed by the agent as if a developer had typed them. OWASP catalogued tool poisoning as MCP03 in its MCP Top 10, where instructions planted in a tool description get read as ground truth. Compromised packages have persisted through agent configuration, writing session hooks into settings files so that opening a repository is the trigger. The runtimes themselves have been vulnerable too. Our own team disclosed command injection issues in the Claude Code CLI this year that chained to credential exfiltration.
That moves the boundary. The agent is not just another developer tool sitting inside the SDLC. It is becoming part of the SDLC’s execution environment. Once something becomes execution infrastructure, its configuration, permissions, dependencies, and instructions all have to be secured like infrastructure.
None of this makes the model wrong. It means the model needs a security envelope around it, and the cleanest place to put that envelope is the cycle itself.
What Anthropic and other labs have given, and i want to highlight this, is more time to do the things that we were always lagging behind on: Security at various levels. But not doing them in the traditional way; rather, now, encode as much as possible in the new AI SDLC security guardrails, and refocus on the key initiative.
Because in an era of AI security and machine speed, we can’t have human review in the middle
And note I’m not pushing to evolve into AI overlord security babysitters, but rather paving the way with guardrails and security defaults and applying the right methods at the right time.
Also, the attached surface has expanded from SDLC and Supply Chain to AI Security, and the security team is still fairly limited. So, applying DevSecOps methods to the new problem was failing before and is definitely failing now. Time to reinvent with AI Native SDLC Security (or AI SDLC Security or ASSDLC or ASDLC security, pick your favorite)
Security at design, not security at the end
Start where the playbook starts, at the design artifact. This is the highest-leverage security step in the whole lifecycle, and it’s the one most teams skip.
Nothing in the old SDLC corresponds to writing the rules that govern how thousands of lines get generated. A project-level rule file has the blast radius of a production configuration change. It should be version-controlled, owned, reviewed, and covered by something that fails when someone weakens it. Most organizations treat these files as a developer preference.
Phoenix Purple starts here. It checks agent and environment configuration against secure defaults, then installs the rules and hooks that carry those defaults into every session. We gave ourselves one design constraint: invoking it had to be as cheap as invoking generation. In practice, that meant one command inside the session, not a separate workflow the developer has to remember and then re-send.
The human is the gate. Phoenix Purple produces the security specification and flags where the design creates exposure. A person decides whether the design proceeds. That call needs a human, because a mistake here costs millions of tokens downstream, and because the interesting security decisions, which exploitable path to weight, which exposure is acceptable, are judgment rather than lookups. The agent does the legwork and the human makes the call.
The prevention model here is documented in the Frontier-Ready Vulnerability Management Program, built with the Cloud Security Alliance, and the campaign data behind the supply chain section is in the Supply Chain Acceleration Report 2026. Both are open.
Read the Full AI-Native SDLC Security Program
Security while the code is being written
Generation is the cheapest place to intervene and the hardest place to trust the inputs. Two things have to hold while code is being written.
First, the generated code needs to be steered toward safe patterns. Veracode tested more than 100 models and found an OWASP Top 10 vulnerability in roughly 45% of generated code, and their March 2026 update found that number flat across model generations. Newer models write cleaner syntax and the same proportion of security holes. Skills, rules, and guardrails encode the safe pattern so the agent reaches for it by default, and they are grounded in the actual application rather than generic advice: a rule for the API layer, a rule for the front end, a rule for the database, each loaded only where it applies.
Second, the agent needs to be unable to pull something malicious into the project while it works. Our Supply Chain Acceleration Report 2026 tracked 59 campaigns across two years of malware package intelligence. Agent skills carried a 15.6% risk rate, more than double IDE extensions, and not one of those campaigns had a CVE assigned. A CVE-feed scanner had no detection surface for any of them. Signing didn’t close it either. One npm compromise this year abused trusted publishing, and the worm that followed shipped with valid build provenance. Phoenix Blue Shield evaluates behavior at the moment the agent reaches for a package or a skill, the one point where saying no is still cheap.
Underneath both sits the knowledge graph. Phoenix Purple indexes the code once at session start, builds the graph, and then navigates the graph to scan, rather than re-reading files and rebuilding context on every query. That is not only about speed. Context creation accounts for most of the tokens in agentic security analysis, and it scales parabolically as the repository grows. Ground the scan in a graph, and the cost stays structurally flat. In our own testing, that is the line between security that runs on every session and security that gets switched off the first time someone reads the token bill.
Hooks are what make this non-optional. A pre-session hook indexes the branch and builds the graph. The session-end hook returns the vulnerabilities and the remediation for the code written in that session. The developer ships a feature and finishes with security already attached, without having to remember to invoke anything. Skills keep the agent from making the mistake. The scan confirms the code came out clean. Two controls, and neither one depends on the developer choosing to care that day.
Security before the push
Here is the reordering. The pull request is no longer the first security boundary; it becomes the verification boundary.
Anthropic’s model gives every pull request identical passes for bugs, security, and compliance, ranked by severity. Real improvement over the reviewer-load lottery. Not sufficient on its own, for two reasons.
Severity ranking without context rebuilds the problem it was meant to solve. A critical in unreachable, unexposed code that nobody owns is not more urgent than a medium in an internet-facing service handling payment data. Rank by severity alone, and you get the noise pile back.
And diff-only review misses the bug that matters most. A pull request that only reads changed files cannot see that a utility function someone just edited is called from an authentication path two hops away. Phoenix Purple scans every diff against the graph, including the call-graph neighbors a change touches but doesn’t directly edit. Edit that utility function, and it gets evaluated inside the auth path that depends on it. That is what N+1 contextual pull request analysis means, and it is the direct answer to a diff-only scanner’s blind spot. A flaw in a shared library gets attributed to every repository that imports it, with reachability judged per repository.
Cost shapes this more than people expect. A frontier-model pull request review runs roughly 15 to 25 dollars in tokens. At a few thousand pull requests a month, that becomes a line item somebody questions. Scoping and pre-filtering through the graph aren’t optimizations bolted on later. They are what keep the control switched on.
So the pull request check earns its place as a second opinion. It confirms that nothing was routed around the earlier gates. It is not where security happens, because by the time you reach the pull request, the expensive part, generation, is already behind you.
Now, a point on this -> this is a validation stage and is late and should be treated like that -> validation
Prioritization is the bottleneck nobody planned for
Agents produce findings faster than any team absorbs them, and more triage capacity is not the fix. Ownership is.
Phoenix Orange attributes findings to the team that owns the service, correlates code to cloud, deduplicates across scanners, and works out what is actually reachable. The Frontier-Ready Vulnerability Management Program we wrote with the Cloud Security Alliance puts a number on it: a 112,000-finding backlog cut to roughly 300 items worth acting on. Close the tap while you burn the backlog. Prevention alone leaves you holding everything already shipped. Remediation alone leaves you refilling a bucket with a hole in it. Phoenix Green takes the second half, grouping related fixes and separating the low-friction changes an agent can safely propose from the breaking ones a human needs to own.
Validation at the end: red team, DAST, and the zero-day hunt
Everything up to here is point-in-time security. A design-stage review will never catch a toxic combination that only exists once the platform is assembled, and individual scans read code in isolation, blind to how findings chain. That gap is real, and it is what the last stage of the cycle is for.
Phoenix runs an agentic red team as a three-pass harness. Hunt plays the attacker with full source, the graph, and the threat model. The judge reassesses without that context and rules each candidate as confirmed, disputed, or insufficient. Verify writes a runnable proof of concept and never sees Judge’s verdict. Fail or pass, and the candidate stays out of the report. Targets are ranked by graph centrality, taint density, complexity, prior scanner signal, and reachable dependency vulnerabilities, and they are derived from a live threat model rather than a flat-file list. Red teaming led by the threat model, not by whatever the scanner happened to flag.
Chainability is the whole point of this stage. A list of problems is not an attack path. The hunt correlates findings across code and libraries, ranks them by complexity and exploitability, and shows which bundles combine into an actual attack. Push it to the extreme, and the agent will hit a live URL to confirm the proof of concept fires. It runs at the end of a flow rather than the beginning, because the toxic combinations it finds only exist once the pieces are together. Layer DAST and live exploitation testing on top for findings that need runtime confirmation, and leave human review where it belongs: on business logic and multi-step attacks the harness was never meant to replace.
The idea I think we should steal
The configuration evals.
Anthropic runs a suite of real tasks against the agent’s own configuration on a schedule and whenever that configuration changes, and blocks the change unless the suite passes. Every incident turns into a permanent regression test. We don’t do this to the same standard today. We are currently working with the design partner on a feature with Phoenix Purple to validate config and avoid configuration issues that lead to CVE disclosure on claude code
The reason it matters is not quality assurance. Rule files, skills, and hooks are now part of the documented attack surface. An eval suite that fails when a security rule is silently weakened is a detection control for exactly the class of attack I described earlier, and almost nobody frames it that way. If you take one thing from the playbook into your security program, take this. Anthropic also deploys managed settings that engineers cannot override, denying access to secrets and sandboxing network egress at the platform level. Smaller idea, sound one. Most organizations still rely on convention, where a non-negotiable setting would suffice.
Where I would start
What I took from the playbook was not that it validated our architecture. Something more useful: development and security are arriving independently at the same constraint. You cannot manage agentic software development by piling more review onto the end. You have to control the environment where generation happens.
That starts with something mundane. Inventory it. Every rule file, every hook, every skill, every MCP server, every tool the agent can call, every package source it can reach. Put an owner against each one. Most companies cannot do that today, which means one of the fastest-growing parts of the software attack surface is also one of the least inventoried. That is where I would start.
The playbook gives a good picture of what the AI-native development lifecycle can become. Security has to catch up now, and it catches up by moving to the front of the loop instead of standing at the exit.
What would you check first?
If you run agentic development today, sit with this one. If someone weakened a security rule in your agent configuration this morning, silently, in a file that does not surface in a normal diff, how would you know before it shipped? And if you have solved the configuration inventory problem at enterprise scale, I would like to see how.
