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, whose document I have read in full at his request. It is in use on insurance products at Ageas in Belgium. Ageas cleared being named; I have not seen that clearance and did not ask the company.

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. Nothing in the rule runs that check. It is a sentence addressed to a person until somebody puts it in the pipeline, and the pipeline belongs to the next rule.

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. Some of those eight stop work on their own: a secret scan that fails, an approval nobody has given, a version that is not pinned. The rest are things a reviewer has to notice, which makes them criteria rather than controls.

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.

Added on 26 September 2026, two days after this was published: the drawing below, and a section at the end setting the framework against four others it does not cite.

1. D1

   Document the context

   Write the context document, headed with the data class, the trust boundaries and what the tool may see and touch.

   Stops here until answered

2. A2

   Anchor to the source of truth

   Name the one artefact that wins per question, and check every new dependency against the registry and the approved list.

3. H3

   Hold the guardrails

   Run the guardrails that are already code, and hold anything irreversible until a person has approved it.

   Stops here until answered

4. N4

   Narrow the loop

   Cut the work to one change that ends in something runnable, inside a sandbox whose permissions die with it.

5. I5

   Inspect twice

   Run the scripted checks, then have a person read the diff. Never only the model that wrote it.

   Stops here until answered

6. N6

   Name what is not true yet

   Declare the placeholders and the stubs in the deliverable, and log each one with an owner and an expiry date.

↩ The declared gaps and the debt register are the written context the next loop starts from, which is the only thing that makes this a loop and not a list.

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. The registry check has a name and a number somewhere else, and none of the five documents is where; it is further down.

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 another framework is simply stronger

Five documents are the ones the author picked. Four more are worth the comparison, and the first of them fixes the hole in the A rule.

MITRE ATLAS is a catalogue of what adversaries actually do to AI systems, built like ATT&CK: sixteen tactics, a hundred and twenty techniques before you count sub-techniques, forty mitigations and seventy-three case studies in the 2026.09 release. It requires nothing of anybody, which is the point — it is a list of attacks, not a standard you comply with. And it contains, by name, the thing the SLSA citation was reaching for. AML.T0062, Discover LLM Hallucinations: an adversary prompts models until it finds package names with no real-world source. AML.T0060, Publish Hallucinated Entities: it registers them and waits. There is a case study, AML.CS0022, and ATLAS notes that different models produce the same hallucinations, which is why the attack scales. The A rule's registry check is the defence against a named technique with an identifier. Cite that.

ATLAS also has the mechanism DAHNIN offers as a stance. AML.M0030, Restrict AI Agent Tool Invocation on Untrusted Data, asks that tool invocation be "restricted or limited when untrusted data enters the LLM's context", blocking automatic invocation or demanding confirmation, and always demanding it where the consequence is high. "The model reads it, it does not obey it" is the same idea with the configuration left out.

And one entry reads like a warning addressed to the H rule. AML.CS0041 records Pillar Security poisoning the rules files that configure coding assistants, using invisible Unicode to make the assistant write backdoors, and distributing the poisoned files through public repositories. DAHNIN puts its guardrails in the repo so they are not in a wiki, which is right. It does not say that the guardrail file is itself context, and therefore untrusted input under its own first rule. It is.

Google's Secure AI Framework has twenty-four named controls, several of them DAHNIN's rules with the verb changed. Agent Permissions makes least privilege the ceiling on what an agent may touch, which is the H rule. Agent User Control requires a person to approve any action that alters data or acts on the user's behalf, which is the H rule again. Two controls have no counterpart in DAHNIN at all. Agent Observability requires an agent's actions, tool use and reasoning to be logged and auditable. Output Validation and Sanitization requires insecure model output to be blocked or sanitised before it reaches an application. Generated code is model output, and DAHNIN's only answer to insecure output is a person reading it.

Microsoft's SDL is worth a line for one practice and then worth putting down. Ten practices, and one of them is "Secure the engineering environment" — the thing the N rule spends a quarter configuring, promoted to a first-class practice instead of a precondition nobody costed. Its AI additions are threat modelling for AI, AI memory protections, agent identity and RBAC, and they are about AI systems Microsoft builds rather than software written with one. They also live in a company blog post of 3 February 2026 and not in the practice list, which tells you what they are.

The EU AI Act is the one people will raise, and the chapter they raise is addressed to the wrong party. Article 53 binds providers of general-purpose AI models. So does the General-Purpose AI Code of Practice, published on 10 July 2025, which is voluntary and signed by model providers. An insurer writing its own software with somebody else's model has no Article 53 duty and cannot sign that code. It does have Article 4, which is short and lands squarely: providers and deployers of AI systems must ensure "a sufficient level of AI literacy" among staff and others operating those systems on their behalf. A written method with a context document per change is the most defensible evidence of Article 4 anybody has put in front of me. That is a narrower claim than the one people want, and it is a real one.

One thing the Act hands the A rule for free. Article 53(1)(b) makes the model's provider document the model for the developers building on it. The A rule names four sources of truth and none of them is the documented limits of the tool doing the writing. There should be five.

ISO/IEC 42001 is the obvious candidate for the auditability gap, being a management system standard with a certificate at the end rather than a method with a convention at the end. It is paid, iso.org refused this desk, and it was not read. Nothing above rests on it and this desk cannot tell you whether it closes the gap.

The comparison does not run one way. Nine documents in, nobody except DAHNIN asks you to mark generated code as generated, and nobody has an artefact that lists the untrue things in a shipped deliverable by name, with an owner and a date. SAIF has a vulnerability management control and ATLAS a vulnerability scanning mitigation; neither has a register of the things that were never true in the first place. That is the framework's own contribution and it survives the comparison intact.

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, and drawing the loop made it sharper: of the six rules it is the one that reads most like a control and it is not one. 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.

What a stronger version takes from them

Three changes, and none of them is a seventh letter.

The rule that has to become a gate. Replace "the model reads it, it does not obey it" with a setting. When a loop's context contains anything the team did not write — a ticket raised from outside, a pasted document, a fetched page, a guardrail file pulled from a public repository — the assistant's tools are off, or every invocation asks a person first. ATLAS calls this AML.M0030 and scales it to the consequence of the action. It is the difference between a stance and a control, and it is the only change here that makes the D rule apply to the H rule's own file.

The artefact that has to exist. A loop log, generated rather than typed: prompts, tool calls, files touched, the diff, and which identity ran it. SAIF calls it Agent Observability and asks for actions, tool use and reasoning "transparent and auditable through logging"; ATLAS calls it AI Telemetry Logging and extends it to installation commands and the identity of the agent. Every artefact DAHNIN has today is written by hand by somebody with a release on Thursday, which is the whole of the soft part above. This one is written by the machine. It is the only evidence in the method that nobody has to remember to produce, which is why it is the first thing to build and not the last.

The check that has to run in CI. Two jobs. One fails the build when an entry in the debt register has an expiry date in the past, which is what turns the sixth rule into the control it already looks like. The other fails the build when a dependency in the lockfile is absent from the registry or from the approved list, which is the A rule's instruction taken away from the person who was going to remember it. The technique that check defends against is AML.T0060, and ATLAS marks it demonstrated rather than theoretical.

Two settings and two pipeline jobs. If the answer to the Thursday question is still that the rules hold because they are written down, the framework has not been installed. It has been circulated.

Added 23 October 2026: the framework has a second half now

A month after this ran, the author published SIEVE, and DAHNIN is inside it. The six rules are no longer a framework; they are the loop half of one, and five further practices — size, instrument, escalate, verify, expire — sit above them at what the document calls the portfolio scale. It is public, under a Creative Commons licence, at github.com/true-altruist/sieve.

The premise is one sentence and it is the right one: generative tools made producing things almost free and did nothing to the cost of checking them, so the limit on an operation is no longer how much it can make but how much one answerable person can stand behind. That is a sharper observation than anything in the version reviewed above, and it answers the question this piece ended on — the Thursday question, whether the rules hold because somebody remembers them. Two of the five practices are about making the answer stop depending on memory.

This desk is not going to review it, and the reason belongs on the page rather than in a footnote. The evidence section of that document is built from this publication's own operating figures — how many pieces its desk had not read, how many generated images it rejected before anybody asked why, an automated edit that damaged four files because the check that cleared it was read through head -32. And the document itself was drafted with the same tooling that writes these articles. A review would be this publication assessing a framework it supplied the evidence for and helped write, which is not a conflict a disclosure line fixes. The honest version is to say so, point at the repository, and let somebody else mark the homework.

What stands from the review above is unchanged: the citations were checked one at a time, one of them did not hold, and no measured outcome was ever supplied. None of that is affected by the framework growing a second half.