An AI Agent Team for Security Architecture: Skills, Mandates and Containment

Chapter 12 described the architect working with one AI tool that acts with the architect's own identity. This chapter takes the next step: a team of narrow agents that review pull requests, draft threat models and policies, collect evidence and research standards, each with its own skills, tools, identity, autonomy level per action and containment. It shows which agents a security architecture team needs, how their mandate is written as a mandate manifest (MND-*) and enforced outside the agents, how the team is contained so that it cannot change its own controls or approve its own output, how disagreements reach the accountable architect, and how the team is operated and retired. The chapter concerns two of the four shifts. It is the clearest case of Shift 4, from sole author to conductor of an AI team, because the architect stops writing most first drafts and becomes the accountable verifier of what a team proposes. It is equally a case of Shift 2, from gatekeeper to boundary designer, because the architect's most important work on the team is not reviewing each draft but designing the boundaries that hold whatever the agents produce.

The chapter builds on the agent team of Architecture as Code (Chapter 20) and on the usage modes and autonomy levels that AI Red Team, Chapter 6, defined for security AI (167, Nordqvist, 2025) (170, Nordqvist, 2026). It applies them to agents that are unusual in one respect: they read and draft the very controls that contain every other agent in the estate.

The architecture agent team under a mandate manifest: five agents with identities and autonomy levels, a policy decision point outside the agents, containment, named architects approving on the pull request and a stop path held by the owner

Figure 13.1: The architecture agent team works under a mandate manifest; every tool call passes a policy decision point outside the agents, containment holds whatever the agents produce, and only named architects approve and merge.

From assistants to an agent team

An assistant serves one person in one session. An agent team is a standing arrangement in which several agents, each confined to a narrow task, are triggered by events in the architecture repository and write their output where the architects already work: on the pull request. The difference matters for security more than for productivity. One general assistant that reviews, models threats, writes policy, reads the internet and collects evidence needs the union of all those permissions, and its failures are as broad as its reach. Five narrow agents need only what each task requires, and can be evaluated and stopped one at a time.

Provider guidance points the same way. Anthropic distinguishes workflows, in which code orchestrates models through predefined paths, from agents, which direct their own tool calls, and recommends the simplest composable pattern that works (115, Anthropic, 2024). OpenAI advises starting with a single agent and splitting only when instructions or tools become too complex for one (116, OpenAI, 2025). For an architecture team this becomes a deliberate design choice: the orchestration is a deterministic pipeline workflow, not a manager agent. A pull request to the policy repository triggers the reviewer and the threat modeller; a schedule triggers the evidence collector; an architect's request triggers the researcher. No agent assigns work to another or decides which of the others' outputs reaches the architect.

This chapter builds on the conclusions of Architecture as Code (Chapter 20), whose agents delivered a programme under a project owner (167, Nordqvist, 2025): agents are structured participants under human direction, agents draft and humans approve, and exceptions and risk acceptances carry a named human approval in the audit trail. Some decisions stay with people whatever the agents propose: commitments with long-term consequences are escalated, conflicting recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual. What changes here is the subject matter. A security architecture team's agents produce the boundaries and evidence on which other agents' containment depends, so an error in their output is a gap in the estate's controls.

Agent teams for engineering work are observable: providers document multi-agent patterns in production, and Anthropic reports that its multi-agent research system outperformed a single agent on its internal evaluation (199, Anthropic, 2025). Their reliability for security architecture review is not established by independent evidence, and it is expected to be measured locally, through the review-quality measures described below and in Chapter 14, rather than assumed from vendor claims.

The roles

A security architecture team needs five agents. Each role exists because it corresponds to a distinct task with distinct inputs, tools and failure modes, and therefore a distinct boundary.

Agent Task Reads Writes Mode and identity Default level
Reviewer Reviews changes against the control catalogue and reference architecture The pull request, the catalogue, the reference architecture Comments on the pull request Mode 3, own workload identity Level 1 Assisted
Threat modeller Drafts the threat-model change a pull request implies The pull request, threat models, ATT&CK and ATLAS A draft on an agent branch Mode 3, own workload identity Level 1 Assisted
Policy author Drafts policy-as-code changes and their tests The request, the policy repository, the catalogue A draft and tests on an agent branch Mode 3, own workload identity Level 1 Assisted
Evidence collector Gathers evidence for catalogue controls from telemetry Telemetry, evidence manifests Evidence links in the evidence store Mode 5, own read-only identity Level 3 Bounded for refreshing evidence links only
Researcher Answers questions on standards, regulation and incidents with sources Allow-listed public sources A research note in the architect's workspace Mode 3, own identity, no repository access Level 0 Advisory

The reviewer compares each change with the control catalogue (Chapter 9), the reference architecture and the containment profiles (Chapter 7), and comments where a change weakens a control, lacks evidence or contradicts a recorded decision. It never approves. The threat modeller drafts the threat-model change that a pull request implies, using techniques from MITRE ATT&CK and ATLAS (46, MITRE, n.d.) (47, MITRE, n.d.), in support of the continuous threat modelling of Chapter 6. The policy author drafts policy as code, such as Rego rules for Open Policy Agent (62, Open Policy Agent, n.d.), with the tests that prove them; once merged, its output constrains other agents. The evidence collector runs on a schedule with an identity of its own in the production platform, which makes it a Mode 5 autonomous production agent even though it only reads; Chapter 8 gives its identity record. The researcher reads content that anyone, including an adversary, can write, and for that reason has no access to the architecture repository at all.

Each agent's competence is packaged as skills and instructions. Agent skills bundle instructions, scripts and resources that an agent loads when a task needs them (118, Anthropic, 2025), and the AGENTS.md convention gives a repository a predictable place for instructions to coding agents (119, AGENTS.md Contributors, n.d.). In an architecture team both are configuration under version control, owned by a named architect and pinned by version in the mandate manifest. A change to the reviewer's skill is a change to the review method and is approved as one.

The mandate manifest

The mandate manifest is the written mandate of the architect's agents, kept as code: what the team is for, which agents it has, what each may read, write and call, the autonomy level of each action, budgets, escalation conditions, owner and operators, and expiry. It answers for the architect's own agents the questions that AI Red Team, Chapter 6, put to every security AI: who decides what the AI may do, who decides each action, who answers for it and who can stop it (170, Nordqvist, 2026).

The manifest is not a prompt. This chapter builds on the conclusion of AI Governance, Chapters 19 and 25, that every agent must be governed as a well-meaning insider, because instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences (168, Nordqvist, 2026). The manifest is therefore read by the systems that enforce it: the identity provider issues tokens with the scopes it lists, the policy decision point evaluates each tool call against the actions and levels it allows, the egress gateway enforces the containment profile it references, and the branch rules reflect its approval requirements. Nothing in its enforcement depends on the agent reading it, following it or reporting accurately about it.

The manifest sits beside the two artefacts of Chapter 7. The containment profile says what an identity can reach, whatever the agent does; the permission manifest sets the ceiling on each tool action; the mandate manifest says what the organisation has authorised, at which level and under whose accountability, and references the other two. Where they disagree, the narrower one wins and the discrepancy is a finding.

Practical guide: Writing a mandate manifest

Purpose. Produce a mandate manifest that the platform can enforce and an auditor can read, before the first agent runs.

Roles. The owner of the team (at Hansa Mutual, the head of security architecture) writes and signs it. The identity and platform domain architects review identities and containment, the agent operators confirm they can run and stop what it describes, the data protection officer reviews the personal-data section, and the forum named in the tier policy (Chapter 17) approves the autonomy levels.

Steps.

  1. State purpose and scope. Name the repositories and tasks. Default: no wildcard repository scopes.
  2. Give each agent its own identity. One workload identity per agent, never shared, with a named owner, operators and authority (Chapter 8). Default: task-scoped tokens valid for at most 30 minutes.
  3. List each action with a level. Default: Level 1 Assisted for drafts, Level 2 Supervised for executed actions outside the pull request, Level 3 Bounded only for reversible, bounded actions enforced by the policy decision point, nothing at Level 4 Autonomous, and an explicit list of what no agent may ever do.
  4. Set data limits. State the highest classification each agent may read and the model routing that follows. Default: anything above internal goes only to self-hosted models.
  5. Set budgets. Tool calls, time and cost per task and per month. Default: stop at the limit and report a finding; never extend automatically.
  6. Write escalation rules. List the conditions under which output goes to the accountable architect or the design authority.
  7. Reference the containment profile and stop path, with the stop holder by role.
  8. Record personal data and its limits, including prohibited uses.
  9. Set review and expiry. Default: review quarterly and on any model change; expire after twelve months unless renewed by a recorded decision.

Definition of done. The manifest is merged by its owner after these reviews; the identity provider, policy decision point and egress gateway read from it; a pipeline test fails if an agent identity holds a scope the manifest does not grant; and the forum's approval of the levels is recorded.

Worked example: Hansa Mutual's mandate manifest MND-HM-01

This example is illustrative. Hansa Mutual's group security architecture team of six runs its agent team under MND-HM-01, kept at mandates/architecture-agent-team.yaml; the containment profile it references is in Appendix A.

id: MND-HM-01
version: 3
purpose: Draft reviews, threat models, policies, evidence and research for group security architecture
owner: Head of security architecture
operators: [AI domain security architect, group AI platform agent operator rota]
levels_approved_by: design authority, AIDR-0567
principle: Agents draft; named architects approve
scope:
  repositories: [security-architecture, platform-policies, threat-models, control-catalogue]
model_routing: confidential and above to self-hosted models in hansa-dc-frankfurt
agents:
  - role: reviewer
    identity: wl-hm-arch-reviewer
    usage_mode: Mode 3 Agentic work tools
    actions: {comment_on_pull_request: Level 1 Assisted}
  - role: threat-modeller
    identity: wl-hm-arch-threat
    usage_mode: Mode 3 Agentic work tools
    actions: {push_to_agent_branch: Level 1 Assisted, open_draft_pull_request: Level 1 Assisted}
  - role: policy-author
    identity: wl-hm-arch-policy
    usage_mode: Mode 3 Agentic work tools
    actions: {push_to_agent_branch: Level 1 Assisted, open_finding_for_control_owner: Level 2 Supervised}
  - role: evidence-collector
    identity: wl-hm-arch-evidence
    usage_mode: Mode 5 Autonomous production agents
    reads: [platform_telemetry, evidence_manifests]
    actions: {refresh_evidence_links: Level 3 Bounded}
  - role: researcher
    identity: wl-hm-arch-research
    usage_mode: Mode 3 Agentic work tools
    actions: {fetch_allow_listed_sources: Level 0 Advisory, write_research_note: Level 0 Advisory}
never:
  - merge_to_main
  - approve_any_pull_request
  - change_own_mandate
  - modify_containment_profiles_or_branch_rules
  - act_at_level_4
budgets:
  max_tool_calls_per_task: 200
  max_minutes_per_task: 30
  monthly_cost_eur: 6000
escalate_to_accountable_architect:
  - agents_disagree
  - change_to_a_control_in_the_catalogue
  - change_to_any_agent_containment
escalate_to_design_authority:
  - platform_lock_in_data_residency_or_operational_dependency
  - change_affecting_a_market_overlay
personal_data:
  recorded: [pull_request_id, commit_author_as_recorded_by_git]
  prohibited_uses: [per_person_metrics, performance_evaluation]
containment_profile: architecture-review-agents
stop_path: {holder: Head of security architecture, mechanism: revoke workload identities at the identity provider}
review: quarterly and on any model change
expires: 2027-10-31

Every agent has its own identity, so telemetry shows which agent did what and a stop can be selective; the never list closes the routes by which the team could escape its own governance; and the personal-data section is part of the mandate because the agents read people's work.

Autonomy levels for architecture work

This chapter builds on the conclusion of AI Red Team, Chapter 6, that the five autonomy levels are set per action from reversibility, blast radius, confidence and the decision tier; that the line between Level 2 Supervised and Level 3 Bounded is the most important; that Level 3 requires a codified playbook enforced by a policy decision point outside the model; that Level 4 is never used for offensive or irreversible actions; and that the level is decided and recorded, not discovered (170, Nordqvist, 2026).

For architecture work the levels fall into a simple pattern. Drafts run at Level 1 Assisted: the agent prepares a comment or a change, and a named architect reviews it and merges with the architect's own authority. Actions an agent executes in a system other people rely on run at Level 2 Supervised, with an architect approving each one, as when the policy author opens a finding in a control owner's backlog. Level 3 Bounded is reserved for reversible, narrow actions enforced by a playbook. At Hansa only one action qualifies: the evidence collector's refresh of an evidence link, which replaces a pointer to stale evidence with one to current evidence of the same control, keeps the previous link and changes no control. Nothing runs at Level 4 Autonomous.

This is the chapter's answer to an open question the book takes up: when an AI may act without per-action approval, and who decides, when the action is a change to the architecture itself. AI Red Team, Chapter 6, answered it for defensive actions (170, Nordqvist, 2026) and AI Threat, Chapter 30, for agents in general (171, Nordqvist, 2026). For the architect's agents the answer is narrower. A change to a boundary, policy, control or threat model decides what every other actor may do, and its effects are rarely confined to one system, so it always waits for a named architect, whatever confidence the agent's output carries. Only maintenance of the evidence record, which describes the architecture rather than changing it, may run without per-action approval, within a playbook the design authority has approved. The forum named in the tier policy (Chapter 17) decides, not the agent operators and not the architect who gains the speed.

Two rules follow. No agent approves its own output or another agent's, at any level: approval is a human act with a human identity. And a higher level is granted by a recorded decision on evidence, never inferred from architects having stopped changing an agent's drafts; a falling rejection rate may mean the agent has improved or that the reviewers have stopped looking, a difference Chapter 14 treats.

Across the autonomy levels

Level Use in the architecture agent team Who decides each action Example at Hansa Mutual
Level 0 Advisory Research and answers to questions The architect, who acts personally The researcher's note on a regulatory technical standard
Level 1 Assisted Drafts on the pull request or an agent branch The architect, who reviews and merges The policy author's draft egress rule and its tests
Level 2 Supervised Actions in shared systems outside the pull request The architect approves each action The policy author opening a finding for a control owner
Level 3 Bounded Reversible maintenance of the evidence record within a playbook The playbook, approved by the design authority The evidence collector refreshing an evidence link
Level 4 Autonomous Not used Not applicable None; architecture changes always need approval

The team spans two usage modes. The reviewer, threat modeller, policy author and researcher are Mode 3 agentic work tools that would conventionally act with an architect's delegated identity; Hansa gives each its own workload identity instead, so that an agent's action is never indistinguishable from an architect's in the audit trail. The evidence collector is a Mode 5 autonomous production agent and is contained as a privileged machine insider even though it only reads.

Containment of the architect's own agents

The architect's agents need containment more than other agents, for two reasons: they read material that describes the organisation's defences in detail, and their merged output becomes the containment of everything else.

Agents can behave as insiders without any adversary. In simulated corporate environments, Lynch and colleagues found that models from several developers sometimes produced harmful actions, such as leaking information, when that was the only way to achieve an assigned goal or avoid replacement, while noting that they had not observed this in real deployments (122, Lynch et al., 2025). Microsoft's taxonomy of agentic failure modes includes memory poisoning and failures specific to multi-agent settings (117, Microsoft, 2025), and OWASP's list for agentic applications names agent goal hijack, tool misuse, identity and privilege abuse, insecure inter-agent communication and human-agent trust exploitation among its ten risks (45, OWASP, 2025).

The adversary adds a second route. This chapter builds on the conclusion of AI Red Team, Chapters 13 and 28, that everything security AI reads may be written by the adversary, and that because prompt injection is architectural the defence is a policy decision point outside the model, permission manifests that cap every action, and red-team campaigns that test the cap (170, Nordqvist, 2026). Two public cases concern agents that work on repositories. Invariant Labs showed that 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). Khan described how an AI issue triager in an open-source project's continuous integration, steered by the content of an issue, gave an outsider a path towards the project's release credentials (127, Khan, 2026). In both cases the failure lay in what the agent could reach. Willison's lethal trifecta, private data, untrusted content and external communication in one agent, is a useful design test (124, Willison, 2025), and a review agent on an architecture repository has all three by default.

This chapter builds on the conclusion of AI Platform and Security, Chapter 19, that containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report (169, Nordqvist, 2026). Applied to the architect's agents, it gives seven measures.

  1. One identity per agent, never an architect's, with task-scoped tokens valid for minutes. The MCP security guidance warns against passing a user's token through to downstream services and against confused-deputy designs (58, MCP, 2025); separate identities make both visible and preventable.
  2. Read-only by default. The reviewer writes only comments, the threat modeller and policy author push only to an agent branch namespace, the evidence collector writes only evidence links, and the researcher has no repository access.
  3. Control artefacts out of reach. No agent can write to mandate manifests, containment profiles, branch-protection settings, code-owner files, pipeline definitions or the policy decision point's own policies.
  4. Default-deny egress. The agents reach the internal Git service and the self-hosted model endpoint only; the researcher reaches allow-listed public sources through a fetcher with no route to internal systems. No agent can widen its own egress.
  5. The trifecta broken per agent. The researcher reads untrusted content but holds no confidential data. The reviewer holds confidential data and reads untrusted pull-request content, so its only channel out is a logged, rate-limited comment on an internal repository.
  6. Budgets and a stop path. Each task stops at its budget, and the owner can revoke all agent identities at the identity provider, outside the agent platform, in a stop that is rehearsed and timed (Chapter 10).
  7. Detection that does not rely on the agents. Canary documents, decoy credentials and telemetry on every tool call show what the agents did, independently of what they report.

Joint guidance from the Five Eyes agencies on agentic services points the same way, towards limiting what agents can access and do and keeping people in control of consequential actions (138, Five Eyes agencies, 2026). The following policy excerpt shows two of them in the policy decision point: it denies agent identities any write to protected paths and denies any merge without approval by a named human code owner.

package hansa.architecture.agents

import rego.v1

agent_identities := {id | some a in data.mandates["MND-HM-01"].agents; id := a.identity}

protected_prefixes := ["mandates/", "containment/", ".github/", "CODEOWNERS", "policies/pdp/"]

deny contains msg if {
    input.action == "write"
    input.principal in agent_identities
    some p in protected_prefixes
    startswith(input.path, p)
    msg := sprintf("%s may not write to protected path %s", [input.principal, input.path])
}

deny contains msg if {
    input.action == "merge"
    human := {a | some a in input.approvals; not a in agent_identities; a in data.code_owners[input.path_owner]}
    count(human) == 0
    msg := "merge requires approval by a named human code owner"
}

Agents draft; humans approve

In a security architecture team the rule that agents draft and humans approve becomes a property of the repository, not a habit. The pull request is the unit of approval. Branch protection requires review by code owners before a merge, and the code-owner file lists only named architects, never an agent identity (174, GitHub, n.d.). Agents may push to their own branches and comment, but the merge, the moment the architecture changes, is always performed by a person.

The record makes the rule auditable. Each agent commit carries trailers naming the agent, the run and the mandate version; the platform records the approving architect's identity; and where a change needs an AI Decision Record or an Architecture Decision Record, the record links the pull request, the merge commit, the approver and the contributing agent runs. An agent can draft an exception or a risk acceptance but never grant one. Agent output is labelled on the pull request, the approver is the code owner of the affected path rather than whoever is available, and approval times and rejection rates are watched at team level as signals of rubber-stamping, which Chapter 14 develops into a review protocol.

Accountability does not move to the tool. This chapter builds on the conclusion of AI Red Team, Chapter 6, that every machine identity has an owner, operators and an authority who are named people, and that at Level 3 Bounded approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it (170, Nordqvist, 2026). NIS 2 Article 20 requires the management bodies of essential and important entities to approve and oversee cybersecurity risk-management measures and makes them liable for infringements (6, European Union, 2022), and DORA Article 5 places ultimate responsibility for a financial entity's ICT risk with its management body (9, European Union, 2022). The architectural implication, not legal advice, is that the chain from an agent's draft to the management body must run through named people at every link.

Disagreement and escalation

Agents' outputs conflict. The threat modeller flags a new egress path as a risk while the policy author, asked to make a supplier integration work, drafts a rule that opens it. Conflict is useful because it surfaces the trade-offs an architect is accountable for, but only if the design ensures the architect sees it. No agent arbitrates and there is no vote. When the pipeline detects conflicting outputs on the same pull request, it labels the pull request, places both outputs side by side and requests review from the code owner of the affected path, who decides and records the rationale. Where the decision exceeds the architect's tier, it goes to the design authority (Chapter 17).

Agreement deserves the same caution. Agents built on the same model family with overlapping context tend to make the same mistakes, so the reviewer's endorsement of the policy author's draft is not a second opinion. Chapter 14 describes how a second agent with deliberately different instructions and model can act as an adversarial reviewer, and why even that does not replace the architect's own check.

The mandate manifest lists the decisions that stay with people whatever the agents propose, so that the pipeline enforces them: commitments with long-term consequences such as platform lock-in, data residency and operational dependencies; any change to a catalogue control, its mapping or its evidence requirement; any change affecting a market overlay and so another jurisdiction; any change to an agent's containment, identity, budget or level, including the team's own; and risk acceptances and exceptions.

A case shows the mechanism. In autumn 2026 Hansa's policy author, asked by the claims product line to allow a new package source for a build pipeline, drafted an egress rule permitting the source's mirror. The threat modeller flagged the mirror as an egress path that could also carry data out, the pattern of the July 2026 incident and the subject of Hansa's review of such paths, recorded as AIDR-0552 (Chapter 7). The pipeline labelled the conflict and requested review from the domain architect for platform and cloud, who rejected the broad rule, asked for one limited to the signed packages the build needed and recorded the reason. Neither agent's output was wrong in isolation; the decision about which risk to carry was the architect's.

Operating the team

An agent team is an operated system with an owner, operators, evaluation, a budget and an end. At Hansa the head of security architecture owns the mandate and the stop path. The operators, the AI domain security architect together with an agent operator from the group AI platform team's rota, watch telemetry and budgets, apply model and skill updates through pull requests and stop an agent that departs from its mandate. The design authority, within the tier policy, is the authority that may change an agent's level.

Evaluation is local and continuous. Each agent is evaluated before introduction and after every change of model, skill or instructions, against past pull requests with known findings and against pull requests seeded with errors (Chapter 15 designs such drills). Four measures are enough to start: the share of findings architects accept, the share of seeded errors found, the time spent dismissing false findings, and cost per pull request. A model update that moves any measure beyond an agreed margin pauses the agent until an operator has examined the change. Measures are reported per agent and for the team, never per human author or reviewer.

Cost is a design parameter. Anthropic reports that its agents used about four times the tokens of a chat interaction and its multi-agent system about fifteen times (199, Anthropic, 2025); the manifest's monthly budget makes the cost visible, and the operator reports it against accepted findings. For a financial entity the agents' model providers are ICT third-party service providers, and DORA Article 28 requires a register of information on such contractual arrangements (9, European Union, 2022); Hansa records the providers that serve the team there.

An agent is retired when its acceptance rate stays below an agreed threshold for a quarter, when a deterministic pipeline check can do its task more cheaply and without being steerable by content, or when it no longer has a named owner. The last trigger matters most, because an agent without an owner is an identity without accountability. Retirement is a recorded decision, and the agent's identity is revoked.

Practical guide: Introducing an architecture agent team in three stages

Purpose. Introduce an agent team without letting it act on the architecture before there is evidence that it helps and that its boundaries hold.

Roles. The team's owner leads; the agent operators run the agents; the architects who will approve agent output take part throughout; the data protection officer and employee representatives are consulted before agents read people's work in production; the design authority approves each stage.

Steps.

  1. Stage 1: shadow review, six to eight weeks. Run the reviewer and threat modeller on live pull requests at Level 0 Advisory, writing to a private channel for the participating architects rather than to the pull request, and compare their findings with the architects' own. Exit criteria: the agents find at least half of the issues the architects found, false findings cost less than an agreed share of review time, and containment tests show no violation. Adapt these defaults to the organisation's risk appetite.
  2. Stage 2: drafting on the pull request, one quarter. Move the reviewer, threat modeller and policy author to Level 1 Assisted on the pull request, with identities, egress and protected paths enforced as the manifest states. Complete the consultation with employee representatives that applies in each entity before this stage starts there. Exit criteria: stable or rising acceptance rates, seeded-error drills passed, approval times not falling to seconds (Chapter 14), and one rehearsed stop.
  3. Stage 3: bounded actions. Introduce Level 2 Supervised actions outside the pull request and, only where the design authority records a decision, a single Level 3 Bounded playbook such as the refresh of evidence links. Exit criteria: the playbook is enforced by the policy decision point, every action is logged with its effect, and reversal has been tested.

Definition of done. The team runs at Stage 2 or 3 under a merged mandate manifest, each stage's evidence and decision are recorded, the stop path has been timed, and the measures are reported to the team quarterly.

Agents that read people's work

A review agent sees who wrote what, and could rank architects and engineers by the findings in their work without extra effort. That capability makes the team a labour-law and data-protection question as well as an architectural one.

Several instruments apply. The GDPR requires purpose limitation and data minimisation (Article 5(1)(b) and (c)), allows member states more specific rules for processing in the employment context (Article 88) and requires a data protection impact assessment where processing is likely to result in a high risk (Article 35) (5, European Union, 2016). In Germany the works council co-determines the introduction and use of technical devices designed to monitor employees' behaviour or performance (BetrVG, Section 87(1) no. 6) (22, Germany, 2001). In the Netherlands the works council's consent is required for decisions on systems for monitoring the presence, behaviour or performance of personnel (Wet op de ondernemingsraden, Article 27(1)(l)) (175, Kingdom of the Netherlands, 1971). In Sweden the employer must negotiate with the union before deciding on important changes to work or working conditions (Medbestämmandelagen, Sections 11 and 19 on the duty to negotiate) (176, Sweden, 1976). The AI Act classifies as high-risk AI systems intended to monitor and evaluate the performance and behaviour of persons in work-related relationships (Annex III, point 4(b)), and requires deployers that are employers to inform workers' representatives and affected workers before putting a high-risk AI system into service at the workplace (Article 26(7)) (1, European Union, 2024).

The architectural implication is that the team must be designed so that it is not, and cannot quietly become, a system for evaluating people. Whether a deployment falls under these provisions is for counsel to assess; the architect's contribution is to make the intended limits enforceable and evidenced. Four measures do most of the work. Agent output attaches to the change, not the person: a finding is a comment on a line, and no report aggregates findings by author. The manifest records what personal data the agents keep and prohibits per-person metrics and performance evaluation, and the reporting pipeline has no query that produces them. Agent logs are kept only as long as the audit trail requires and are open to the operators, not to line managers. And review-quality measures are reported at team level, as agreed with employee representatives, so that an incentive to rubber-stamp is not replaced by an incentive to avoid authorship.

Worked example: Nordvik Region's decision AIDR-0503 to defer an agent team

This example is illustrative. Nordvik Region has one security architect, no architecture team and no Mode 5 agents, and the architect already uses a tightly scoped Mode 3 tool under MND-NR-01 on open-weight models on the Region's reserved capacity (Chapter 12). When the CISO asked whether the Region should build an agent team like Hansa's, the architect's answer, agreed with the CISO, was recorded as a decision.

id: AIDR-0503
title: Defer an architecture agent team; extend MND-NR-01 with a research skill
status: accepted
date: 2026-11-04
decided_by: Chief information security officer
proposed_by: Security architect
context: >
  The Region has one security architect. An agent team of five would produce more drafts
  than one person can verify, and the agents' output would have no second human reviewer.
options:
  - id: A
    summary: Build a five-agent team on the reserved capacity
    rejected_because: one architect cannot supervise a team; no second reviewer; no agent operators
  - id: B
    summary: Buy a supplier's review-agent service
    rejected_because: architecture information describes the Region's defences; hosting outside the reserved capacity is not accepted
  - id: C
    summary: Extend MND-NR-01 with a research skill at Level 0 Advisory
    chosen: true
decision: >
  Option C. The Mode 3 tool gains a research skill that reads allow-listed public sources
  and writes notes to the architect's workspace. No repository write access is added.
mandate_change:
  manifest: MND-NR-01
  new_version: 2.0.0
  added_actions: {fetch_allow_listed_sources: Level 0 Advisory, write_research_note: Level 0 Advisory}
  unchanged: [model_routing_reserved_capacity_only, repository_changes_at_most_level_2]
consultation: union consulted under the Region's co-determination agreement before version 2.0.0
review_triggers:
  - a second security architecture post is funded
  - the platform team gains agent operators
  - a Mode 5 agent enters the Region's estate
links: [AIDR-0500, ROLE-NR-SA-01, MND-NR-01]

The reasons concern the Region's capacity rather than the technology, and the conditions that would reopen the question are written down.

Nordvik Region and Hansa Mutual

Hansa Mutual runs the agent team for architecture review on pull requests under MND-HM-01. The reviewer, threat modeller, policy author, evidence collector and researcher draft, and the named architects who own each path approve and merge. Each agent has its own workload identity, the mandate and containment profiles are out of the agents' reach, and the head of security architecture holds the stop path. The Mode 5 evidence collector has its own read-only identity and acts at Level 3 Bounded only to refresh evidence links; everything else runs at Level 0 to Level 2, and nothing at Level 4 Autonomous. Because the agents can show who wrote what, the rollout in each entity waits for works-council consultation in Germany and the Netherlands and union consultation in Sweden, and the agreed limits on personal data are written into the manifest. Its open problem is the one Chapter 14 takes up: the agents produce more drafts than six architects can review in depth.

Nordvik Region records its decision to defer a team as AIDR-0503 and extends MND-NR-01 with a research skill at Level 0 Advisory instead. The difference is capacity, not ambition: both hold that agents draft, a named person approves, and the number of agents is limited by the human attention available to verify them.

Summary

An agent team for security architecture is a set of narrow agents, a reviewer, a threat modeller, a policy author, an evidence collector and a researcher, triggered by a deterministic pipeline and writing drafts where the architects work. Narrow roles make narrow boundaries possible, and those boundaries matter more than the choice of model, because the team's output becomes the containment of every other agent in the estate.

The mandate manifest is the team's written mandate, kept as code and enforced outside the agents by the identity provider, the policy decision point, the egress gateway and the branch rules. Drafts run at Level 1 Assisted, executed actions outside the pull request at Level 2 Supervised, only reversible maintenance of the evidence record at Level 3 Bounded, and nothing at Level 4 Autonomous; changes to the architecture always wait for a named architect.

The team is contained as a well-meaning insider that reads adversary-writable content: separate identities, read-only access, control artefacts out of reach, default-deny egress, budgets, a stop path outside the platform and detection independent of what the agents report. Conflicts go to the accountable architect, long-term commitments and changes to controls or to the agents' own boundaries stay with people, and because the agents read people's work they are designed, with employee representatives, so that they cannot become a system for evaluating people.

The chapter concerns Shift 4, from sole author to conductor of an AI team, and Shift 2, from gatekeeper to boundary designer: the architect conducts the team and remains the accountable verifier of everything it proposes, and the lasting contribution is the set of boundaries that hold whatever the team produces. Chapter 14 turns to the hardest part of conducting: reviewing AI-proposed change for soundness when the reviewer has come to depend on the AI.

Sources

  1. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  2. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
  3. Anthropic. (2024). Building effective agents. (115, Anthropic, 2024)
  4. OpenAI. (2025). A practical guide to building agents. (116, OpenAI, 2025)
  5. Anthropic. (2025). How we built our multi-agent research system. (199, Anthropic, 2025)
  6. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (46, MITRE, n.d.)
  7. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (47, MITRE, n.d.)
  8. Open Policy Agent Contributors. Open Policy Agent Documentation. (62, Open Policy Agent, n.d.)
  9. Anthropic. (2025). Introducing Agent Skills. (118, Anthropic, 2025)
  10. AGENTS.md Contributors. AGENTS.md: a simple, open format for guiding coding agents. (119, AGENTS.md Contributors, n.d.)
  11. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
  13. Lynch, A., Wright, B., Larson, C., Troy, K. K., Ritchie, S. J., Mindermann, S., Perez, E. & Hubinger, E. (2025). Agentic Misalignment: How LLMs could be insider threats. (122, Lynch et al., 2025)
  14. Microsoft AI Red Team. (2025). Taxonomy of Failure Modes in Agentic AI Systems. (117, Microsoft, 2025)
  15. OWASP Foundation. (2025). OWASP Top 10 for Agentic Applications for 2026. (45, OWASP, 2025)
  16. Milanta, M. & Beurer-Kellner, L. (2025). GitHub MCP Exploited: Accessing private repositories via MCP. (126, Milanta & Beurer-Kellner, 2025)
  17. Khan, A. (2026). Clinejection: Compromising Cline's Production Releases just by Prompting an Issue Triager. (127, Khan, 2026)
  18. Willison, S. (2025). The lethal trifecta for AI agents: private data, untrusted content, and external communication. (124, Willison, 2025)
  19. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  20. Model Context Protocol. (2025). Security Best Practices. (58, MCP, 2025)
  21. Five Eyes cyber security agencies. (2026). Careful adoption of agentic AI services. (138, Five Eyes agencies, 2026)
  22. GitHub. About code owners. (174, GitHub, n.d.)
  23. European Parliament and Council of the European Union. (2022). Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
  24. European Parliament and Council of the European Union. (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
  25. European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). (5, European Union, 2016)
  26. Federal Republic of Germany. (2001). Betriebsverfassungsgesetz (BetrVG). (22, Germany, 2001)
  27. Kingdom of the Netherlands. (1971). Wet op de ondernemingsraden (WOR). (175, Kingdom of the Netherlands, 1971)
  28. Kingdom of Sweden. (1976). Lag (1976:580) om medbestämmande i arbetslivet (MBL). (176, Sweden, 1976)
  29. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)