Secure by Design: The Next Chapter of the Secure SDLC

Your system's behavior used to be a property of your code. Read the source, run the tests, and you knew what it would do. Put a model, a prompt, retrieved data, or an agent in it and that stops being true. A provider swaps a model snapshot. Someone edits a tool description in a config file. A document lands in the index. The code is byte-identical and the system does something new. Review before merge was built for the old case.

So we changed how we build. Our projects follow four phases, Discover, Architect, Build, Enable, and none of them asks your team to work differently. We're putting it into practice on our own work first.

Discover: define the problem with the people who own it

We start with the people who own the problem: the workflows, the users, the decisions, the data, and the boundaries. For anything with a model or an agent in it, we also write down what good looks like for each interaction. Those expectations become its evaluations, and the boundaries become the security requirements the build is checked against.

Architect: challenge the design, then decide the safeguards

An independent reviewer questions the design before we build it: the assumptions, the failure modes, the security gaps, and what each model and agent is allowed to touch. Its job is to find what breaks, and the team defends the decisions that matter. A named person who isn't building it signs off. Then, still before any code, we decide the safeguards: the threat model, the protections the system needs with drafted tests, and evaluations for the key model interactions. During the build, tests get filled in, not invented.

Build: every change checked and evaluated

Pull requests run tests, scans, a check for leaked secrets, a dependency check, a review from a model that didn't write the code, and the evaluations for the components they touch. You'll only see this in your normal code review. A common version of the failure this catches: an agent passes code review, then a prompt change a month later lets it call a tool nobody approved. So a change to a prompt, a model, a tool description, or retrieval logic takes the same path as a change to code, because it changes behavior the same way.

Evaluation is its own step. Model interactions are tested against what Discover said good looks like: correctness, safety boundaries, grounding, tool selection, structured output, and cost where it matters. Failures from production go back into the suite, so it gets stronger as the system runs.

Before release, a different reviewer confirms the build is what was approved, the safeguards have passing tests, the evaluations meet their thresholds, and each agent runs with the access it was given. The same named person signs the release.

Enable: run it, and own it

We put it into production and set up what it takes to run it: monitoring, logging, runbooks, documentation, and the evaluation process. We work alongside the team that will own it, on how it was designed, how to troubleshoot it, and how to change it safely. At handoff your people become the approvers, and they keep the patterns, controls, and operating model for the next system.

Three rules, all the way through

1. We don't rely on AI to check its own work. We prefer to build with one vendor's AI and review with another's, so a blind spot in one is less likely to be a blind spot in the other.
2. What an agent can do should be a deliberate decision, and one you can reverse.
3. Model interactions get their own evaluations. They run as the system changes, and production failures feed them.

One file, if you want it

Everything above leaves a record: what we built, what was found and what we did about it, the evaluation results, who approved what and when, and the level each agent runs at. If anyone on your side wants to see it, it's one file. It describes how we work, not a certification of your system. Most projects never need it. The ones that do find the questions already answered.

Before there is code to secure

This is how we build whether or not anyone asks. The decisions that matter most, what a system may touch and what it may do, are best made before there's any code to secure.