Six rules for building software with an AI assistant, in use at a Belgian insurer. The security sits inside each rule, which is the good idea and the expensive part.

The premise is one sentence, and it is the best thing in the framework: an AI assistant behaves like a fast, confident junior with no memory.

Everything else follows. A junior like that gets written context, fixed points of reference, hard limits, small tasks, two people looking at the work, and no licence to call something finished when it is not. That is DAHNIN, a framework for building software with AI assistance by Ussama Dahnin.

Six rules, six letters, and the author is explicit that the acronym does not grow. "A framework that grows a new letter each time a concern appears loses credibility, and security that sits in its own box tends to be skipped." So there is no seventh rule for security. Each of the six carries a security layer instead.

What it achieves, and the line where it stops

It gives you a repeatable loop with a written artefact at each end, and it makes the security question part of the work rather than a gate at the end of it. That is the whole of it, and it is worth having.

It does not make you compliant with anything. The author says so himself, and I am repeating it because somebody will otherwise put a slide up. NIS2, and DORA for financial entities, expect documented risk management and traceability across the software supply chain. Running a good development practice is evidence you can point at when a supervisor asks. It is not the answer to the question, no supervisor has endorsed this or any other framework, and the distance between "we follow a disciplined method" and "we meet Article whatever" is where the follow-up questions live.

It also does not audit your existing code, and nothing in it will find the mocked login screen you shipped eighteen months ago. It starts at the next change.

What it costs before you start

Four things, and only one of them is a tool.

A data classification you can actually apply. The first rule refuses to start a loop unless the context document carries a header naming the data class, the trust boundaries, and exactly what the tool may see and touch. No classification, no loop. Writing the first such header takes an afternoon. Writing the twentieth takes ten minutes. The long end is not the header, it is discovering that nobody in the room can say whether this data is internal or confidential, which is a governance question with an owner in two departments and an answer in neither.

Guardrails that are already code. Pre-commit hooks, secret scanning, a dependency policy check. A day if your pipeline exists and somebody owns it. A fortnight if the first failing check has to go through an exception process that has not been written yet.

Somewhere to run a loop that is not production, with permissions that can be granted and revoked per loop. This is the line in the framework that is easiest to write and hardest to configure. "Network allowlist" is four syllables and a quarter's work, because the allowlist that lets an agent install a dependency is already most of the internet by the second transitive hop.

And the recurring cost, which is review. The scripted eye is minutes of pipeline. The human eye is not: twenty to forty minutes for a two-hundred-line diff that crosses an authentication boundary, if it is genuinely read. A third reviewer for high-risk changes is not minutes at all, it is latency, because you are waiting for a calendar. On a team closing five loops a day that is a couple of hours of senior attention, daily, for ever. Those are my figures, from watching reviews get done, not the author's; he supplied none.

The loop, in six moves

D, document the context first. Every loop starts from something written down, never from memory, and if the context does not say, the work stops and asks — because an assistant with no memory will otherwise invent the missing half confidently. The header carries the classification. The reasoning is that context is an attack surface: READMEs, tickets, pasted documents and web pages can carry instructions aimed at the model, so context is treated as untrusted input. The model reads it; it does not obey it.

A, anchor to the source of truth. One artefact wins per question — spec for wording, library for colour and type, board for the journey — because two sources of truth is a decision nobody made. Disagreements get written down. On the security side the lockfile wins for dependencies, the vault wins for credentials and the code never does, the threat model wins for trust boundaries. The concrete instruction: check every new dependency against the registry and the approved list before it lands, because assistants suggest packages that do not exist and people register those names.

H, hold the guardrails. Spec wording verbatim, accessibility to WCAG AA, no personal data, mobile first — living in the repo beside the code, because a guardrail in a wiki is a suggestion. Four more are security: no secrets in prompts or code; least privilege for agents, read-only by default and never production credentials; human approval for anything irreversible; pinned dependencies.

N, narrow the loop. One change at a time, ending in something runnable, because a small diff can be reviewed and a three-thousand-line dump cannot. Each loop runs in a sandbox and any elevated permission dies with it. The unit of risk is blast radius.

I, inspect twice. A scripted check and a human look, because they fail at different things. The scripted eye runs static analysis, dependency audit and secret scanning, and produces an SBOM. The human eye takes authentication, authorisation, data flows and anything crossing a boundary. High-risk changes get a third look from someone outside the loop. The model that wrote the code is never the only reviewer.

N, name what is not true yet. Placeholders, simulated steps, proposals outside the spec and known gaps are declared in the deliverable itself, and a security debt register lists the mocked authentication, the stubbed encryption, the disabled check and the temporary permission, each with an owner and an expiry date. Generated code is marked as generated so provenance survives. The reasoning is the one sentence every reader here has lived: "we'll add real auth later" is how a prototype becomes a breach.

The citations, checked

The author maps each rule to an external standard. I opened them.

The SLSA mapping is the one to fix. SLSA's build track is about whether the artefact you are running came from the source you think it did. Its own specification says the level of an artefact is independent of the level of its dependencies, that no single level covers an artefact and its transitive dependencies together, and that code quality and producer intent are out of scope. Neither the retired v1.0 page nor the current v1.2 page addresses dependency selection, pinning, or checking that a package name exists in a registry — which is precisely the control the A rule describes. Cite SLSA for provenance of what you build. Cite the registry check to something else.

One more, offered rather than corrected. NIST published SP 800-218A in July 2024, an SSDF community profile for generative AI. It is about building models safely, not about using one to write ordinary software, so the framework is right to cite plain SSDF. Expect somebody in a review to raise it anyway.

• OWASP Top 10 for LLM Applications2025 edition

  What goes wrong in an application with a model inside it.

• NIST SSDFSP 800-218 v1.1

  Whether your development process has the practices, whoever performs them.

• NIST SP 800-218Agenerative AI profile

  Whether you built the model safely.

• SLSAbuild track, v1.2

  Whether the artefact came from the source you think it did.

• NIST AI RMF 1.0govern, map, measure, manage

  Whether the organisation governs its AI risk and can show it.

None of them asks whether the code you shipped was written by a model, or requires you to be able to answer that afterwards.

Where it is soft

Every rule rests on somebody writing something down, and the framework has no answer for the week nobody does. The context document, the disagreement log, the guardrail file, the debt register: six rules, four artefacts, all of them maintained by hand by people under a deadline. A method whose only failure mode is human diligence has the same failure mode as the thing it replaced.

The debt register is the sharpest case. An expiry date is set by the person who created the debt and honoured by the same person. Nothing fails when it passes. Make the expiry a test that goes red on the date and the register becomes a control; leave it as a column in a document and it becomes a wall of sticky notes with last quarter's dates on them.

And "the model reads it, it does not obey it" is the line most likely to be quoted and least likely to be true. It is a stance, not a mechanism. Nothing in the loop enforces it, the model has no reliable way to separate the context it was given from an instruction hidden inside that context, and the framework is honest enough to call context an attack surface while offering discipline as the mitigation. Discipline is what you have when you do not have a control. It should be written down as an accepted risk in the register, which is a rule the framework already has.

Then the deadline, which is the real test. Each rule has an obvious way to skip it and none of them looks like skipping. The classification header gets pasted from the last loop. The third reviewer becomes the second reviewer saying it looks fine. The debt entry gets an expiry date in the next quarter, which is the polite form of never. Ask the author, or whoever proposes this to you, what their answer is for the Thursday before a release. If the answer is that the rules hold because they are written down, you have found the soft part.

How you know it worked, and how to back out

Three things you can check without anyone's cooperation. Open the last ten merged changes: does each one point at a context document with a classification header, and does that header differ between the ten? Open the deliverables: does any of them carry a debt register with an entry whose expiry has passed? Grep for a secret. If all three come back clean after a quarter, something is being done. That is not an outcome measure and I am not offering it as one — no defect rates, incident counts or before-and-after figures were supplied for this piece. I asked. There are none.

Backing out is cheap, which is the best argument for trying it. Five of the six rules are conventions and a template; stop applying them and the loop reverts to what your team did before, with the artefacts still in the repo as a record. Only the guardrails-as-code and the sandbox cost real money to install and real work to remove, and those are things a reviewer would want anyway. The expensive commitment is not the framework. It is the two hours a day of senior review time that make the I rule mean anything, and that cost is the same whether or not the acronym stays at six letters.