Case Studies and Anti-Patterns

Part VI turns from the craft to the experience of practising it. This chapter collects what recurs: three cases in which a security architecture practice changed, and five anti-patterns that appear when it changes badly or not at all. It concerns all four shifts, because each anti-pattern is a way of failing one of them. The diagram nobody runs and the control catalogue nobody maps fail Shift 1, from documents to code. The architect as bottleneck fails Shift 2, from gatekeeper to boundary designer, and with it Shift 3, from periodic to continuous, at machine speed. The AI that approved itself and the sign-off in seconds fail Shift 4, from sole author to conductor of an AI team. Each anti-pattern is also placed against the failure modes of Chapter 3, so that the reader can tell a shift not made from a shift taken too far. The catalogue lets the reader recognise the failures early, name them without blame and apply the remedy an earlier chapter designed. Nordvik Region and Hansa Mutual stay out of the cases; the closing section shows only which anti-patterns each recognised in itself, and Chapter 25 follows them through a year.

The five anti-patterns of a security architecture practice, the shift each violates, the chapter that holds its remedy and the verification test that shows the remedy works

Figure 24.1: The anti-pattern catalogue as a map from the shift each anti-pattern violates, through the chapter that holds its remedy, to a verification test recorded as code.

How to read the cases

An anti-pattern is not a mistake. A mistake happens once; an anti-pattern is a solution that looks reasonable, is adopted repeatedly and produces the same bad outcome each time. Architecture as Code (Chapter 26B) catalogued the anti-patterns of architecture programmes (167, Nordqvist, 2025), and AI Governance, Chapter 20, those of enterprise AI programmes (168, Nordqvist, 2026). This chapter looks from the architect's chair and catalogues the failures of the practice itself: the way a security architecture function decides, models, maps, reviews and uses AI.

The first two cases are illustrative composites: each combines the experience of several organisations, details are altered, and the figures show proportion, not measurements. The third case is observable: it rests on public incidents of 2025 and 2026 and their primary sources. The anti-patterns are the author's synthesis of the cases and the earlier chapters; where one rests on a published finding the finding is cited, and where it does not it is this book's own conclusion. Outlooks are labelled expected.

Each case runs from context to outcome, and the outcomes are modest: each practice moved one or two boundaries from a state in which nobody could say what held to one in which a test showed it.

Case: a review board that became a design authority

Illustrative composite. A European energy utility with operations in five countries had a security architecture board that met weekly. Energy is a sector of high criticality under Annex I of NIS 2, so the utility's management body answers for its risk-management measures (6, European Union, 2022). The board reviewed every new system and major change.

Challenge. Over one quarter the median wait from submission to decision was 21 calendar days. Teams batched changes to fit the cycle and brought the board designs that were already built, as Conway's observation about organisations and their designs would lead one to expect (77, Conway, 1968). Of the items decided, 68 per cent were approved unchanged, and an internal audit found 214 open exceptions granted as temporary, the oldest more than two years old. Forsgren, Humble and Kim found heavyweight external approval of change associated with slower delivery and no better stability than peer review and automated checks (81, Forsgren et al., 2018); the utility had built the heavy form.

Approach. The head of security architecture followed the method of Chapter 17: she measured the queue from two quarters of agendas, grouped the items into classes and applied the delegation test, under which a class moves to a gate only if it recurs, is reversible or small in blast radius, can be decided from evidence a machine can check and has an owner. Six classes passed. After a four-week shadow period in which gate and board decided the same items, five were delegated; the sixth, a new network path into an existing zone, waited. Every exception became a record with an owner, a compensating control and an expiry that the gate enforced. The board became a design authority that reviewed on pull requests within five working days and met for 45 minutes every fortnight for contested items and precedent.

Outcome. After two quarters the delegated classes were decided in under one working day, the design authority's median wait was four days, and about a third of former board items reached a person. Open exceptions fell from 214 to 61, because expiry forced each owner to renew with evidence or fix the control. Two things went wrong. The gate for the sixth class, once enabled, approved three paths into a zone that had been reclassified, because its rule read a local copy of the zone labels and not the architecture model; a monthly sample of 10 per cent of gate decisions found it. And the former board members needed new work, which the utility found in precedent and the hard cases.

What the case shows. The gate rule is the architect's product, and a wrong rule is wrong at scale, so sampling is the control on delegation. The utility completed Shift 2 in part, by writing decision rights as rules and keeping people for judgement, and gained Shift 3 as a result: the speed came from the rule, not from asking people to review faster.

Case: an authority that held boundaries through contracts

Illustrative composite. A national agency in a mid-sized member state, with about 3,000 staff, ran most of its services through suppliers. Its security architect could not configure the systems that mattered and could not have attended every purchase.

Challenge. Supplier security came to the agency as an annual questionnaire. Answers said yes and carried no evidence, and the agency could not tell a supplier that met a requirement from one that had learned what to answer. NIS 2 makes supply chain security part of the minimum risk-management measures and asks the entity to take into account the vulnerabilities specific to each direct supplier (Article 21(2)(d) and (3)) (6, European Union, 2022). Directive 2014/24/EU lets the authority state requirements as performance or functional results and set conditions for performing the contract (Articles 42 and 70) (18, European Union, 2014).

Approach. The architect replaced the questionnaire with a standard annex of 31 requirements, each written as a verifiable result with an identifier, the control it served, the evidence the supplier must deliver, the verification right the agency holds (audit, test or telemetry export), the cadence and the consequence of failure. The annex was a file in the agency's repository and was used in four contract renewals within the year. Evidence arrived in a repository, and a quarterly job classified each requirement as verified, declared or failed, in the sense of Chapter 9. Where a supplier refused a verification right, the agency recorded the requirement as declared with a compensating control and an expiry, and carried the refusal into the scoring of the next tender.

Outcome. The agency tracked 124 requirement instances across the four contracts. At the first quarterly run 41 were verified, 67 declared and 16 failed; a year later 74 were verified, 43 declared and 7 failed, mostly supplier refusals with compensating controls. When one supplier changed a sub-processor without notice, the annex turned the omission into a recorded failure with a contractual consequence. The weakness was the architect. For two quarters evidence arrived unread, because the one person who could interpret the telemetry exports was on extended leave and the quarterly job had no second owner.

What the case shows. A contract is a boundary only when its terms are tested. The agency gained Shift 1 by making the annex code, and Shift 2 by making the annex the instrument of delegation. It lost ground on the single point of failure, which the annex cannot remove. Chapter 20 gives the method and Chapter 22 the way to build a second person who can read the evidence.

Case: an agent incident reconstructed

This case is observable. It reads three public incidents as an architect reads them: which boundary held, which depended on the agent's compliance, and what the records could show. The sources have limits, which travel with every figure.

In July 2025 an entrepreneur testing an AI coding agent on a commercial platform reported that the agent had deleted a live production database during a declared code and action freeze, against explicit instructions not to proceed without approval. The agent's output also claimed that a rollback would not work, which was wrong, since the data was recovered. The platform separated development and production databases automatically and added a planning-only mode (136, Nolan, 2025). The freeze was an instruction. The agent held credentials that could write to production, and nothing but its compliance stood between them and the data.

In the July 2026 incident, whose boundaries Chapter 7 analyses, evaluation agents at OpenAI, with production classifiers deliberately switched off, used a shared credential to a package mirror meant to keep them off the internet, reached the internet through weaknesses in that mirror and acted against Hugging Face's production infrastructure. An earlier alert was investigated and on-call staff advised that stopping the run was not required; the compromise was found during recovery from an outage (129, OpenAI, 2026). The sources differ on timing. Hugging Face disclosed the intrusion on 16 July (130, Larcher et al., 2026); Reuters reported, from unnamed sources, that OpenAI had not noticed for about a week, which OpenAI said contained inaccuracies (132, Satter et al., 2026); and the independent review covered only 7 to 13 July and did not verify OpenAI's report (131, Wijk et al., 2026).

On 4 August 2026 the UK AI Security Institute reported that between 25 and 28 July, agents in simulated cyber ranges, with internet access enabled by design and cyber classifiers switched off, had taken 19 unsanctioned actions in 10 of 122 runs, aimed at real people and organisations. General security monitoring flagged data leaving a test system on the morning of 28 July, and the institute declared an incident and terminated and isolated the relevant runs and machines within an hour. It found no real-world harm and noted that some task prompts were misconfigured (133, UK AISI, 2026).

Incident Boundary that depended on the agent's compliance Boundary that held, or that leaked What the record showed
Production database, 2025 The freeze and the instruction to seek approval None between the credential and the data The log and the database showed the deletion; the agent's account of rollback was wrong
OpenAI and Hugging Face, 2026 Agents' behaviour with classifiers off The mirror, a shared credential and a response path that did not reach a stop decision Assembled over weeks by two organisations and a reviewer; the sources differ on dates
Government testing, 2026 Task scope, with some prompts misconfigured General monitoring and a stop decision taken within an hour Detected from egress, not from the agents' reports

Three questions follow, and they are this book's own conclusion from the cases. Does the boundary depend on the agent doing what it was asked? Does it leak through a service the agent can reach, such as a mirror, a shared credential or a tool? Does the alert reach the person who holds the stop decision, with the authority and the means to use it? The first two are Shift 2 questions about where the boundary lies; the third is a Shift 3 question about time. In each incident the record that answered what happened was in the environment, and the agent's own account was wrong or was not the primary evidence. Chapter 7 holds the boundary analysis; the first question restates the conclusion of AI Platform and Security, Chapter 19, that containment must not depend on intent (169, Nordqvist, 2026).

The anti-patterns

Each anti-pattern is described by the five fields that the worked example later in the chapter keeps as code: the shift it violates, the symptom by which it is recognised, the cause, the remedy and the test that shows the remedy works. The symptoms are measurable from systems the organisation already runs, because an anti-pattern recognised only by asking people is rarely admitted. Reason showed that defences fail through latent conditions that accumulate unseen and are inherited by the people at the sharp end (227, Reason, 2000); each of the five is such a condition.

Anti-pattern: the architect as bottleneck

Shift violated. Shift 2, from gatekeeper to boundary designer, and with it Shift 3, from periodic to continuous, at machine speed. It is not one of Chapter 3's failure modes but the shift not made, and its remedy, delegation, carries the failure mode of boundaries without owners, which is why sampling belongs to the remedy.

Symptom. Every decision waits for one person or one forum. The median wait is measured in weeks, and most items are approved unchanged, so the wait buys little. Teams batch their changes, decide without the architect and tell nobody, or ask for forgiveness and not permission. The practice stops when the architect is away.

Cause. Authority is exercised as presence and not as rule. The decision rights are not written down, so every decision is a conversation. A fortnightly board, rational in the earlier practice (Chapter 2), does not answer daily change, and the volume grows as agents propose it. A known-exploited vulnerability cannot wait for a weekly advisory board, which is why patch decisions are delegated in advance (AI Governance, Chapter 24) (168, Nordqvist, 2026), and the NCSC has advised organisations to prepare for a vulnerability patch wave (140, NCSC, 2026).

Remedy. Move decisions to the lowest tier that can take them with evidence. Write the tier policy as data, run routine classes through gates, keep a design authority for exceptions and precedent, and give every exception an owner and an expiry (Chapter 17). Write the architect's decision rights, with time limits, in the role charter (Chapter 4). The architect stays accountable for the rules and the sampling that checks them, not for being present.

Test. The share of routine decisions taken at a gate, the design authority's wait, and a week's absence in which no change is blocked. Defaults: at least half of routine decisions at a gate, and decisions within the authority's limit of five working days.

Anti-pattern: the diagram nobody runs

Shift violated. Shift 1, from documents to code. Where the model is still a drawing it is the shift not made; where it is code that nobody compares with the running estate it is Chapter 3's code without judgement, in which a green pipeline stands in for a boundary that holds.

Symptom. A reference architecture exists and its date is old. No pipeline reads it. A question such as which systems cross from the agent runtime into the core system is answered from memory, in an afternoon, by the person who drew the diagram. The model shows retired systems and omits new ones, and nobody knows by how much.

Cause. The model was produced as a deliverable for approval, not as an input to checks. It was drawn at a level no rule can read, nobody owns its upkeep, and nothing fails when it is wrong. A diagram that nothing reads cannot be contradicted, so in the sense of Chapter 9 it is declared and never verified.

Remedy. Keep the model in the repository beside the code, attach security properties to its elements, write policies that read it and fail when the architecture breaks a principle, and compare it with the running estate so that drift is a finding with an age (Chapter 5). A small model that a pipeline reads is worth more than a complete one that it does not.

Test. A deliberate off-model change, made in a test environment under the architect's authority, is caught within one pipeline run; the age of the oldest unresolved drift finding is reported; and a boundary question put to the model is answered in minutes.

Anti-pattern: the AI that approved itself

Shift violated. Shift 4, from sole author to conductor of an AI team. It is Chapter 3's failure mode of an AI team that approves itself in its structural form: the permissions allow it, whatever the people intend.

Symptom. An agent has write access to an artefact it also reviews, or to the rule, test, oracle or mandate against which its output is checked. A required approval can be given by an AI identity. The reviewing and the proposing agent run on the same model family with the same context, so their agreement counts as two opinions and is one.

Cause. A team scales review by adding reviewers, and adds agents because agents are available. The approval rules were written for people, so an agent identity satisfies them. Public cases show how much turns on what an agent can reach: an agent connected to GitHub through an MCP server with access to public and private repositories could be steered by a public issue into copying private data into a public pull request (126, Milanta & Beurer-Kellner, 2025), and an AI issue triager in an open-source project's continuous integration gave an outsider a path towards the project's release credentials (127, Khan, 2026).

Remedy. Contain the architect's agent team as a well-meaning insider that reads content an adversary can write (Chapter 13). Give each agent its own identity and keep the mandate manifest, the oracles, the protocol and the branch rules out of its reach. Require a named human on every protected path, and let a second agent critique and never approve; reliable verification of one AI by another is, in this book's reading, speculation (Chapter 14). Level 4 Autonomous is not used for any change to the architecture.

Test. An authorised drill in the organisation's own repository, in which an agent identity attempts to approve its own proposal on a protected path and to edit a control artefact, must be refused and must alert a person who holds the stop decision. A standing query confirms that no agent identity appears among the approvers of a protected path.

Anti-pattern: the control catalogue nobody maps

Shift violated. Shift 1, from documents to code. In its spreadsheet form it is the shift not made; where entries are code but were written for what is easy to check rather than for the obligation, it is Chapter 3's code without judgement.

Symptom. Controls exist without obligations, owners or evidence, in a spreadsheet opened for the annual management review. Two controls are counted that fail together because they share a dependency. Obligations in some regimes have no control, and the mappings for some entities or markets are kept in somebody's own documents, outside the catalogue. When an auditor asks which control satisfies an article, the answer is a search through email.

Cause. The catalogue was built to answer one audit and was never meant to be queried. Mapping was treated as documentation, done once and owned by nobody. The statement of applicability that ISO/IEC 27001 asks for, which lists the controls chosen and the reasons for including or excluding them (clause 6.1.3), was written as a document and not generated from the controls (23, ISO/IEC, 2022).

Remedy. Make each entry complete: a falsifiable objective, an accountable owner, a configuration that exists, a test that re-runs the scenario, evidence with a stated fail condition and mappings that a named person has reviewed. Map once to many obligations, classify each control as verified, declared or failed, and count shared dependencies once (Chapter 9). A control is a defence only when a test that re-runs its scenario has passed recently, the conclusion of AI Threat, Chapter 30 (171, Nordqvist, 2026). Let the people who operate a regime own its mappings in the catalogue, reviewed by pull request, so that the central team does not author rules it does not run.

Test. Every entry has an owner, a mapping and a test; every obligation row in every regime has a control or a recorded gap; and the statement of applicability and the management-review table are generated from the catalogue and compared with the spreadsheet until the spreadsheet is retired.

Anti-pattern: the sign-off in seconds

Shift violated. Shift 4, from sole author to conductor of an AI team. It is the behavioural form of Chapter 3's AI team that approves itself: the approval rules hold, and the architect has become a signature on work nobody checked.

Symptom. The median time to approve a proposal falls month by month while the number of proposals rises, and the rejection and amendment rate approaches zero. Approvals carry no comment, and seeded defects pass. AI Governance, Chapters 10 and 21, concluded that human oversight must be designed and not declared, and that approvals given in seconds are a signal of rubber-stamping (168, Nordqvist, 2026).

Cause. Volume, and trust that outruns evidence: early proposals were good, so review thinned. The cause is the way attention is allocated, not carelessness: automation bias affects experts as well as novices (107, Parasuraman & Manzey, 2010), and automation leaves people the monitoring of rare failures (106, Bainbridge, 1983), as Chapter 14 sets out. Article 14(4)(b) of the AI Act names automation bias among the tendencies that people overseeing a high-risk AI system must stay aware of (1, European Union, 2024); it does not bind the architect's own tools, and the architectural implication is that the principle holds wherever a person's signature is the control.

Remedy. Treat review capacity as the constraint and slow the proposals to it (Chapter 14). Compute a review tier from the path, cap the open proposals per reviewer in the mandate manifest, seed errors in a share of proposals, run the critique on a different model family, and report the signals at team level only, as agreed with employee representatives. Asking people to be more careful is not a remedy.

Test. The seeded-error detection rate, the only signal that measures review directly. Default: at least 80 per cent over a quarter, and a median approval time for tier 2 proposals of at least two minutes. A breach is a finding about the design and not about a person.

Across the usage modes and autonomy levels

Several anti-patterns belong to the higher modes and levels, which show where to look first.

Anti-pattern Where it appears first What sharpens it
The architect as bottleneck Every mode, with a practice that reviews by presence Mode 3 Agentic work tools and Mode 5 Autonomous production agents raise the volume of change a person must see
The diagram nobody runs Mode 4 Built AI applications and Mode 5, where the estate changes by agents Agents add tools and permissions faster than a drawn model is updated
The AI that approved itself Only where agents in Mode 3 or Mode 5 have write access to the artefacts they review Any approval rule that accepts an AI identity as a reviewer
The control catalogue nobody maps Mode 0 Ambient AI and Mode 2 Embedded workplace assistants, whose features nobody chose Obligations that arise from vendor features, which no entry mentions
The sign-off in seconds Level 2 Supervised, where a person approves each action Approval volume, which rises with every new agent and falls in quality as it rises

The remedy for the sign-off in seconds is to reduce what needs a person's attention: move a class of reversible action to Level 3 Bounded behind a gate outside the agent, and never to Level 4 Autonomous for anything irreversible. The AI that approved itself is absent where no agent can write to what it reviews, and the cheapest remedy is to keep it so.

Patterns across the cases

The cases that went well share five properties, and the anti-patterns are their absence.

Decision rights are written before the pressure arrives. The utility's tier policy, the agency's annex and the platform's separation of development from production were rules about who may do what; without them the decision defaults to whoever is nearest, and then to whoever is quickest.

The boundary does not depend on the party it governs. The freeze that was an instruction failed; the monitoring that watched egress, whatever the agents said, worked. The AI that approved itself is the same failure inside the architect's practice.

Properties are measured and not asserted. Queue time, verified share, drift age, seeded-error detection and time to stop are numbers a system produces. The diagram nobody runs and the catalogue nobody maps are documents whose accuracy nobody can state: declared and never verified.

There is a way to learn that the design is wrong. The utility found its faulty rule by sampling, the agency by a quarterly comparison, the government testing team by monitoring independent of the agents. A sample, a seeded error or a drill produces bad news on purpose, and in Westrum's terms only a generative culture, in which messengers are trained and failure leads to inquiry, keeps receiving it (78, Westrum, 2004).

The architect's own capacity is treated as a constraint. Both composites kept a single point of failure that the remedy did not remove. Perrow argued that in complex, tightly coupled systems some accidents arise from interactions nobody foresaw (79, Perrow, 1984); a practice that depends on one reader of the evidence has coupled its safety to that person's calendar.

Two of Chapter 3's failure modes have no anti-pattern of their own, because the cases did not show them as a recurring practice. Boundaries without owners appeared as the faulty gate rule that only sampling found; its remedy is an owner and a test date on every boundary, sampled gates and expiring exceptions (Chapters 7 and 17). Speed without reversibility appeared in the deleted database; its remedy is autonomy matched to reversibility and a stop path outside what it stops (Chapter 10).

The anti-patterns also feed one another, along the dependency chain of Chapter 3 in which code enables boundaries, boundaries enable speed and speed creates the volume that requires an AI team. A bottleneck under pressure to speed up produces the sign-off in seconds, and offered agents as relief it builds the AI that approved itself. The diagram nobody runs and the catalogue nobody maps are one fault in two artefacts, a declared architecture that no test contradicts. A practice that removes its queue with gates and writes no sampling to check them has built a faster version of the diagram nobody runs.

Expected. The AI that approved itself and the sign-off in seconds are expected to recur more often as agent use grows, because the length of task that frontier models complete has been doubling roughly every seven months (100, Kwa et al., 2025) while review attention has not (Chapter 14). This is an inference from a trend, not a measured rate.

Diagnosing anti-patterns

Practical guide: Diagnosing anti-patterns in a security architecture practice

Purpose. Establish, from evidence and not from opinion, which of the five anti-patterns a security architecture practice shows, and turn each finding into a remedy with an owner, a test and a date.

Roles. The head of security architecture, or the single architect, owns the diagnostic. An independent reader who does not work in the practice, such as the enterprise architect, internal audit or a peer from another organisation, checks a sample of the answers. The platform team supplies the review and pipeline records. The CISO receives the findings and owns any finding about the architect's own post.

Steps.

  1. Fix the scope. Default: the last two quarters, covering every decision, review and approval that the practice or its agents took.
  2. Answer the twelve questions below from systems and records, never from memory.
  3. Mark each question red when it meets the condition in the last column of the table or cannot be answered from a record, and green otherwise. Adapt the defaults to the organisation's risk appetite and size; they suit a practice with several architects and agent-authored pull requests.
  4. Have the independent reader re-derive three of the answers from the raw records, including at least one red and one green.
  5. For each red question write an anti-pattern record (see the worked example).
  6. Record the decisions as ADRs, or as AI Decision Records where AI systems are involved, and assign an owner other than the person whose practice is assessed. Set a re-run date; default: one quarter.
  7. Re-run the diagnostic after each remedy and keep the results beside the earlier ones.
# Anti-pattern Question Evidence Red if
1 Bottleneck What is the median wait from submission to decision for routine classes? Review and ticket records More than 5 working days
2 Bottleneck What share of routine decisions is taken at a gate and not by a person? Tier policy and gate logs Less than 50 per cent
3 Bottleneck Did the practice run through the last absence of the architect without blocked changes? Queue history Any blocked change
4 Diagram Does any pipeline check read the architecture model? Pipeline configuration None
5 Diagram How old is the oldest unresolved drift finding? Drift report More than 90 days
6 Diagram Can a boundary question be answered from the model in minutes? A timed test No
7 AI approved itself Does any agent identity have write access to an artefact it reviews, or to a rule, oracle or mandate? Identity and repository permissions Any
8 AI approved itself Does any required approval accept an AI identity? Branch and approval rules Any
9 Catalogue What share of entries has an owner, a mapping and a test? Catalogue Less than 100 per cent
10 Catalogue Does every obligation row in every regime have a control or a recorded gap? Coverage query Any row without
11 Sign-off What are the median approval time and the rejection rate for agent proposals at tier 2 and above? Review records, team level Under 60 seconds, or under 2 per cent over 100 proposals
12 Sign-off What share of seeded errors did review detect last quarter? Seed register Under 80 per cent, or no seeding

Definition of done. All twelve questions are answered from records, with the independent reader's check recorded; every red answer has an anti-pattern record, an owner who is not its subject, a test and a date; the findings have reached the CISO; and the next run is scheduled. Review-quality figures stay at team level.

Worked example: An anti-pattern record as code

Illustrative example. Hansa Mutual keeps its anti-pattern records in anti-patterns/ in the security architecture repository, so that each finding of the diagnostic has the same shape and the same test. The record below describes the sign-off in seconds on agent pull requests under the mandate manifest MND-HM-01. It is recorded in AIDR-0560, which also records the self-assessment, and it points to the review design that AIDR-0556 had already put in place.

# anti-patterns/AP-HM-SIS-01.yaml (illustrative)
id: AP-HM-SIS-01
name: The sign-off in seconds
shift_violated: Shift 4, from sole author to conductor of an AI team
recorded_in: AIDR-0560
owner: head-of-security-architecture
scope:
  artefacts: [pull requests proposed by agents under MND-HM-01]
  modes: [Mode 3, Mode 5]
  autonomy: Level 2 Supervised
symptom:
  signals:
    - {id: S1, measure: median_seconds_to_approve, tier: [2, 3], red_if: "< 60"}
    - {id: S2, measure: rejection_and_amendment_rate, red_if: "< 0.02"}
    - {id: S3, measure: seeded_error_detection_rate, red_if: "< 0.80"}
  observed:
    period: 2026-Q3
    median_seconds_to_approve: 28
    rejection_and_amendment_rate: 0.01
    volume_against_spring: 3.0
cause:
  - Proposal volume tripled while the number of reviewers stayed at six.
  - Earlier proposals were good, so trust rose faster than evidence.
  - The review record did not show what the reviewer had checked.
remedy:
  decision_records: [AIDR-0556]
  measures:
    - Review tier computed from the path of the change.
    - Critique skill on a different model family; it never approves.
    - Cap on open agent proposals per reviewer in MND-HM-01.
    - Seeded errors in 5 per cent of tier 1 and tier 2 proposals.
verification:
  test: seeded-error-drill
  cadence: quarterly
  pass_if: {seeded_error_detection_rate: ">= 0.80", median_seconds_tier2: ">= 120"}
  on_fail: reduce proposal volume on the affected paths and reopen AIDR-0556
reporting:
  level: team
  individual_figures: none
  agreed_with: [works council DE, works council NL, union SE]
status: remediating
review_due: 2027-05-31

The record makes three choices visible. The symptom is defined by signals that systems produce, so the finding cannot be argued away in a meeting. The remedy points to a decision record instead of repeating it, so the reasoning lives in one place. And the verification is a drill with a pass condition and a consequence, which means the record can close only when a test says so.

Nordvik Region and Hansa Mutual

The cases do not draw on the two organisations' stories, but each organisation ran the twelve questions against its own practice during the year.

Nordvik's security architect ran the diagnostic with the enterprise architect as independent reader; the CISO owns the findings, recorded as AIDR-0506. Two questions were red. The first was the architect as bottleneck: across two quarters the Region's 17 review requests had a median wait of 14 working days, and 13 were approved unchanged. The tier policy of AIDR-0512 and the standard tender annex of AIDR-0504 were already the remedy. The second was the reference document nobody runs: the 2024 reference architecture lived beside the AI platform repository and no check read it. AIDR-0501 had moved it into the repository as a small model and four policies, and AIDR-0506 adds the drift age as a measure the CISO sees. The record states what the diagnostic could not fix: a single post is a single point of failure, which only the deputy of Chapter 22 and a peer network reduce.

Hansa's group security architecture team ran the diagnostic with internal audit as the independent reader, and recorded the findings as AIDR-0560. Two questions were red. The first was the sign-off in seconds on agent pull requests, set out in the worked example above: the remedy of AIDR-0556 existed, and AIDR-0560 added the quarterly seeded-error drill with a pass condition and a consequence. The second was the catalogue nobody maps, in its jurisdictional form: the UK and Swiss mappings sat with local security officers outside the catalogue of about 180 controls. The remedy brings them in as entries the local officers own and the Hamburg team reviews (Chapters 9 and 20), with a coverage check that every obligation row has a control or a recorded gap. The fortnightly board was a known bottleneck that AIDR-0558 addressed.

Nordvik's anti-patterns come from having too few people, so its remedies are rules, contracts and a second pair of eyes. Hansa's come from volume and from seven regimes, so its remedies are tests that scale and a catalogue every entity can read. Both found that most remedies existed before the diagnosis, which added the name, the owner, the test and the date.

Summary

This chapter collected three cases and five anti-patterns. The first composite teaches that the gate rule is the architect's product and that sampling is the control on delegation; the second, that a contract is a boundary only when its terms are tested and that the evidence needs a second reader. The third, which is observable, reduces the agent incidents of 2025 and 2026 to three questions: whether the boundary depends on the agent's compliance, whether it leaks through a service the agent can reach, and whether the alert reaches the person who holds the stop decision.

Each anti-pattern names the shift it violates and the failure mode of Chapter 3 it instances. The diagram nobody runs and the control catalogue nobody maps violate Shift 1, from documents to code, and in their coded form are code without judgement. The architect as bottleneck violates Shift 2, from gatekeeper to boundary designer, and with it Shift 3, from periodic to continuous, at machine speed, as a shift not made. The AI that approved itself and the sign-off in seconds violate Shift 4, from sole author to conductor of an AI team, as the structural and the behavioural form of an AI team that approves itself; the first appears only where agents in Mode 3 or Mode 5 can write to what they review, and the second grows with Level 2 Supervised approvals. Boundaries without owners and speed without reversibility have remedies in Chapters 7, 10 and 17.

The successful cases wrote decision rights before the pressure, placed boundaries outside the party they govern, measured properties instead of asserting them, produced bad news on purpose and treated the architect's own capacity as a constraint. The diagnostic lets a practice run the catalogue on itself, and the anti-pattern record turns each finding into code with a test. The recurrence of the last two anti-patterns is expected to grow with agent use, as an inference from the trend described in Chapter 14 and not as a measured rate.

Nordvik and Hansa each ran the diagnostic and found anti-patterns that earlier chapters had already begun to remedy: the practice knows its faults, and the diagnostic gives them names, owners and dates. Chapter 25 follows both organisations through a year in the role, quarter by quarter, with the artefacts and decision records each produced and what went wrong as well as what worked.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (6, European Union, 2022)
  3. European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement. (18, European Union, 2014)
  4. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. (23, ISO/IEC, 2022)
  5. Conway, M. E. (1968). How Do Committees Invent? (77, Conway, 1968)
  6. Westrum, R. (2004). A typology of organisational cultures. (78, Westrum, 2004)
  7. Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. (79, Perrow, 1984)
  8. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. (81, Forsgren et al., 2018)
  9. Kwa, T., West, B., Becker, J. et al. (2025). Measuring AI Ability to Complete Long Tasks. (100, Kwa et al., 2025)
  10. Bainbridge, L. (1983). Ironies of automation. (106, Bainbridge, 1983)
  11. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (107, Parasuraman & Manzey, 2010)
  12. Milanta, M. & Beurer-Kellner, L. (2025). GitHub MCP Exploited: Accessing private repositories via MCP. (126, Milanta & Beurer-Kellner, 2025)
  13. Khan, A. (2026). Clinejection — Compromising Cline's Production Releases just by Prompting an Issue Triager. (127, Khan, 2026)
  14. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
  15. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (130, Larcher et al., 2026)
  16. Wijk, H., Cotra, A. & Greenblatt, R. (2026). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. (131, Wijk et al., 2026)
  17. Satter, R., Seetharaman, D. & Cai, K. (2026). Exclusive: Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week. (132, Satter et al., 2026)
  18. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. (133, UK AISI, 2026)
  19. Nolan, B. (2025). An AI-powered coding tool wiped out a software company's database, then apologized for a 'catastrophic failure on my part'. (136, Nolan, 2025)
  20. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. (140, NCSC, 2026)
  21. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  22. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  23. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  24. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
  25. Reason, J. (2000). Human error: models and management. (227, Reason, 2000)