Mandate, Delegation and Autonomy Tools

This chapter serves one activity: deciding, in writing and in a form that a machine can enforce, what an AI agent may do. The tools that do this are mostly artefacts, written as code and kept in version control: mandate manifests (MND-*), delegation profiles (DLG-*), charters, decision-rights files and delegation registers. Around them stand three scales and rules that the series defines (usage modes, autonomy levels and action classes), one method that gives the levels a budget, and a small group of third-party formats for the instruction files that agents read (SKILL.md and AGENTS.md). The tools come from AI Platform and Security (Book 3), The Transformed Security Architect (Book 6), AI Boss (Book 7), AI Blue (Book 8), AI Purple (Book 9) and AI Operations (Book 10), with the scales taken from AI Red Team (Book 4) and the delegation register from AI Threat (Book 5). The chapter is a reference: it says what each tool is for, when to use it, what it contains and where the originating book gives the reasoning.

The mandate and the delegation profile are the series' two answers to the same question, and they are easy to confuse because five books use the identifiers MND-* and DLG-* with different scopes. The first section therefore compares them. The remaining sections treat the scales and rules, the mandate manifests, the delegation profiles and charters, the registers and reversibility tests, the autonomy budget and its consequences for promotion and demotion, the instruction files, and one script that checks the rules. The worked example is a delegation profile for an operations agent.

Mandate, delegation and budget: the scales and rules feed the delegation profile, which bounds the mandate manifest; a policy decision point outside the agent reads the mandate; an independent observer counts the errors that consume the autonomy budget

Figure 18.1: Mandate, delegation and budget. The policy decision point and the observer are drawn outside the agent; a named authority raises a level, and any stop holder lowers one at once.

How the books use MND-* and DLG-*

The series defines the degree of delegation once: five autonomy levels from Level 0 Advisory to Level 4 Autonomous, set per action and not per agent, with Level 3 Bounded defined by a codified playbook that a policy decision point outside the model enforces (4, Nordqvist, 2026). Each later book adds an artefact that records the levels for its own subject. The artefacts share a family of identifiers and a purpose, but they do not share a schema, and a reader who opens two books will find two different files under the same prefix. Table 18.1 records the differences as the books state them.

Book What MND-* is What DLG-* is Unit of an entry Level 4
AI Platform and Security (3) Not used. The analogues are the permission manifest (AgentPermissionManifest) and the agent configuration (AgentConfiguration), identified by AIDR numbers Not used One tool call, with an effect class (read, reversible-write) and conditions Not a field; the review agent's configuration blocks merge, approval and push outright
The Transformed Security Architect (6) MND-HM-01 (Hansa Mutual) and MND-NR-01 (Nordvik Region): the written mandate of the architect's agent team, one file for several agents Not used; the delegation register is named but defined in AI Threat One action per agent role, with a level never list includes act_at_level_4; default is nothing at Level 4
AI Boss (7) MND-HM-CLM-*: the mandate of the agents a manager directs, with the platform enforcing it DLG-NR-*, DLG-HM-*: one profile per system that touches management functions, per management function (M1 to M5) and action class, with deciders, agreement and stop path MND: an agent action. DLG: a function and action class M3 Consequence is never delegated; the manager's agents never act at Level 3 or 4
AI Blue (8) MND-HM-SOC-02, MND-NR-SOC-01: one agent, with playbook-bound Level 3 actions DLG-HM-SOC-01, DLG-NR-SEC-01: the team's profile, per function (B1 to B5), capability, mode, action class (AC-0 to AC-4) and level MND: an agent action. DLG: one line per capability and action The schema rejects it; none is granted
AI Purple (9) MND-NR-EMU-*, MND-HM-EMU-*: a loop agent, bounded by the rules of engagement (RoE-*) DLG-HM-LOOP-01, DLG-NR-EMU-01 and the profile inside LOOP-NR-2028-01: per stage (P1 to P5) or per function MND: an action class with a safety class (S1 to S4). DLG: a stage or function Forbidden for irreversible, out-of-scope, unauthorised personal data and named-person actions
AI Operations (10) MND-NR-OPS-*, MND-HM-OPS-*: one agent's scope, action classes and levels, approvals, credentials, budgets, breakers, separation and stop path DLG-*: one agent on one service, with ceilings for eleven action classes, the autonomy budget, the verifier and the stop; the same prefix also names the decision-rights file MND: an action class. DLG: an action class and its budget Four prohibitions; read and annotate are the classes at Level 4

Table 18.1: The same prefixes in six books.

Three readings follow, each from the books themselves. First, the mandate belongs to the agent and the delegation profile to the system, team or service: AI Purple states the division most plainly, saying that the rules of engagement belong to the exercise, the mandate manifest to the agent and the decision record to the decision, and that the lowest ceiling governs (9, Nordqvist, 2026). AI Operations uses the same division: the profile (Chapter 4) states the frame for one agent and one service, and the mandate (Chapter 16) is the enforceable detail (10, Nordqvist, 2026). Second, the books agree on the rules that hold across the schemas: an action not listed is undelegated; the lowest ceiling governs; a Level 3 entry names the playbook or runbook and the point that enforces it; raising a level is a recorded decision by a named authority; lowering one is immediate and needs no approval (8, Nordqvist, 2026). Third, the numbers differ where the subject differs, for example the stop target (120 seconds in the generic default of AI Red Team, AI Blue and AI Purple, 60 seconds for the emulation runner of AI Purple, and 5 minutes in AI Boss and AI Operations) and the default review interval. A reader who adopts a tool from one book should copy the numbers of that book with it, or record why they differ.

AI Operations is the only book that attaches an autonomy budget to the profile, and the only one that sets the ceilings across eleven action classes. AI Blue uses five classes (AC-0 Preserve to AC-4 Irreversible or external), which fit the effects of a response action; AI Boss uses the five management functions. The classes are not interchangeable, and an organisation that builds one toolbox (Chapter 24) must choose which set its profiles use.

Scales and rules

Five tools set the vocabulary that the artefacts of the later sections use. They are definitions, not files, with two exceptions (the decision record and the class table).

Usage-mode and autonomy-level scales
Kind Artefact (scales)
Origin AI Red Team, Chapter 6
Purpose Series scales for how AI is used (Mode 0 Ambient AI to Mode 5 Autonomous production agents) and how much it may do (Level 0 Advisory to Level 4 Autonomous).
Use when Before any delegation is written: every artefact in this chapter states a mode and a level.
Identifier family Mode 0 to 5; Level 0 to 4

The levels are: Level 0 Advisory, where the AI suggests and a person decides and acts; Level 1 Assisted, where the AI drafts and a person reviews and executes; Level 2 Supervised, where the AI executes after explicit approval of each action; Level 3 Bounded, where the AI executes pre-approved, reversible actions within a codified playbook and a person is informed and can stop it; and Level 4 Autonomous, where the AI selects and executes without per-action approval (4, Nordqvist, 2026). The mode says how the AI is deployed and whose identity it uses; the level says who decides each action. The book's own point is that the two constrain each other: Modes 1 and 2 normally sit at Level 0 or 1, Mode 3 agents stay in sandboxes, Mode 4 services at Level 0 to 2 because their identity is read-only, and Level 2 and Level 3 live in Mode 5. Giving a read-only triage service a write tool moves it from Mode 4 to Mode 5, which is a change of governance and not of configuration. A vendor feature that acts automatically (Mode 0) acts at a level the vendor chose; this is observable, and the decision for each such feature is to accept, constrain or switch it off, and to record which.

Assigning a usage mode and an autonomy level
Kind Method
Origin AI Red Team, Chapter 6 (practical guide)
Purpose Decide mode and level together for a security AI capability and record it.
Use when Before a capability is given any action, and on a change of model, action, incident or mode.

The method lists every action as a verb with an object, determines the mode from the deployment, assesses each action against five factors (reversibility, blast radius, confidence, exposure to attacker-controlled input and the decision tier) and starts at the lowest level that meets the need. It ends in the autonomy-level decision record below. The defaults the book offers are to be adapted: a first review 90 days after any increase, a stop target of two minutes to credential revocation, at least 200 evaluated cases with a precision of 0.9 or more before Level 3, and a review of any approver whose median approval time for estate-changing actions falls below five seconds (4, Nordqvist, 2026).

Autonomy-level decision record (AI Decision Record)
Kind Artefact
Origin AI Red Team, Chapter 6 and Appendix A
Purpose Assigns usage mode and autonomy level per action for a security AI capability, with oversight, review and works-council consultation.
Use when At every assignment or change of a level for a capability.
Identifier family AIDR-* (AIDR-0311 in the example)
Full template Yes, in Chapter 6 and Appendix A of the originating book

The record states the capability, its mode and identity, who owns it, who may raise the level within a ceiling and who set the ceiling, the level by action, the conditions of Level 3, what may never be autonomous, the stop path with a target in seconds, the evidence and the review triggers. The worked example, AIDR-0311, moves two reversible containment actions of Hansa Mutual's SOC investigation agent from Level 2 to Level 3 and keeps account disabling at Level 2. Note that the originating book is inconsistent about the record's kind: the chapter version carries kind: AIDecisionRecord with status proposed, and Appendix A carries kind: AutonomyDecision. Every later book cites AIDR-0311 as the decision behind the SOC agent's Level 3 actions, so the record is the root of the chain from decision to profile to mandate.

Eleven action classes and ceilings
Kind Artefact (table)
Origin AI Operations, Chapter 4
Purpose Names eleven action classes with their reversibility and default ceiling per level, as the basis of every DLG-* of that book.
Use when Writing or reviewing a delegation profile for an operations agent.

The classes are read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete and restore-overwrite. The default ceilings, inside an authorised window, are: Level 4 for read (limited by data class) and annotate; Level 3 for internal notification, for scale within quota and cost cap, for restart of a stateless service, and for deletion of temporary artefacts the agent created; Level 2 for reconfiguration, deployment and rollback (with a Level 3 exception for a pre-approved standard change and for an automatic rollback inside its own stop condition); Level 1 for fail-over across providers for a critical function, for external notification, for deletion of production data and for restore-overwrite. Outside a window or inside a freeze, every class that changes production has a ceiling of Level 2 at most. The ceilings are the book's recommendation, and an organisation sets its own in the profile (10, Nordqvist, 2026).

Setting a delegation ceiling

The ceiling for an action class on a service is the lowest of four written answers: reversibility (what can be undone, how fast, and whether the undoing has been rehearsed), blast radius (how far a mistake spreads), evidence (what record the agent has at the proposed level on this class) and window (whether the action falls inside an authorised window and outside a freeze) (10, Nordqvist, 2026). The method reuses the factors of AI Red Team and the rule of AI Blue, Chapter 4, that an unlisted action is undelegated and the lowest ceiling governs (8, Nordqvist, 2026). AI Blue adds that confidence is the input that does least: a model score changes whether an action is proposed, not what a wrong action costs, so it does not lift a ceiling.

Level 4 prohibitions and autonomy matched to reversibility

AI Operations names four cases in which Level 4 Autonomous is never used: an irreversible action on production data; an action outside an authorised change window or freeze on a critical function; an action that disables the observation or the stop path itself; and an action that decides about a named person's access to work (10, Nordqvist, 2026). AI Blue states two (an irreversible B4 Respond action, and an action that decides about a named person's access to work) and grants none in either fictional organisation; its method, autonomy matched to reversibility, assigns Level 3 only to AC-0 and AC-1 actions and caps the rest (8, Nordqvist, 2026). AI Purple forbids Level 4 for irreversible, out-of-scope, unauthorised-personal-data and named-person actions in emulation (9, Nordqvist, 2026). All three lists derive from the rule in AI Boss that AI may direct work but may not, on its own, decide about people (7, Nordqvist, 2026). The books do not conflict; the later lists are more specific to their function. A profile that adopts the longest list loses nothing.

Mandate manifests

A mandate manifest bounds one agent. It is read by the systems that enforce it (the identity provider, the policy decision point, the egress gateway), which is why every book that defines one insists that it be code in version control and that a pipeline test fail when an agent holds a scope the manifest does not grant. The manifests share a spine: purpose and scope, an identity of the agent's own, a level per action, a list of what the agent may never do, budgets, escalation, personal data and prohibited uses, a stop path, and a review date and expiry. They differ in what each book adds.

Mandate manifest (architect's agent team)
Kind Artefact
Origin The Transformed Security Architect, Chapter 13 and Appendix A
Purpose Per agent team or assistant: purpose, identities, usage mode, autonomy level, allowed actions, containment, oracles, records and stop path.
Use when Before the first agent of an architecture team runs.
Identifier family MND-HM-01, MND-NR-01
Full template Chapter 13 gives version 3 of MND-HM-01; Appendix A gives an excerpt

The manifest in Chapter 13 lists five agents (reviewer, threat modeller, policy author, evidence collector, researcher), each with its own workload identity and its actions at a stated level, and a never list that includes merging to the main branch, approving any pull request, changing its own mandate, modifying containment profiles or branch rules and acting at Level 4. Only the evidence collector acts at Level 3 Bounded, refreshing evidence links. The book's practical guide fixes defaults: task-scoped tokens valid for at most 30 minutes, Level 1 for drafts, Level 2 for executed actions outside the pull request, review each quarter and on any model change, and expiry after twelve months unless renewed by a recorded decision (6, Nordqvist, 2026). The Appendix A excerpt is shorter than the chapter version and omits the version, budgets and stop path; use the chapter version.

Mandate manifest for agents a manager directs
Kind Artefact
Origin AI Boss, Chapter 16 and Appendix A
Purpose States tasks, autonomy level, tools, data, approvals and the accountable manager for each agent a person directs; the platform enforces it.
Use when Before a line manager directs agents, and at every change of their tasks or budgets.
Identifier family MND-HM-CLM-*
Full template Yes, version 1.1.0 in Appendix A

The principle written into the file is that people manage agents and agents do not manage people. The never list forbids external correspondence without approval, changes to reserves or payments, allocation of claims to people, figures per handler and any action at Level 3 or 4. The file adds what the other manifests lack: a verification block with weekly routine, seeded cases, unassisted samples and numeric triggers for a mandate review (seeded-case catch below 0.85, rejection rate below 0.02 for four weeks, median letter approval under 30 seconds), and an employee_data block that limits reporting to the team level. Version 1.1.0 records the change made after the approval-time trigger fired (7, Nordqvist, 2026). The method behind it defaults to Level 1 for drafts, Level 2 for internal actions and anything that leaves the organisation, and no Level 3 in the first six months.

Mandate manifest for a SOC agent
Kind Artefact
Origin AI Blue, Chapter 13 and Appendix A
Purpose Sets tasks, tools, data, levels, approvals, budget and expiry for a SOC agent.
Use when Before a security operations agent is given a function; reviewed quarterly and on any model change.
Identifier family MND-HM-SOC-02 (investigation agent HM-SEC-001), MND-NR-SOC-01
Full template Yes, in Chapter 13 and Appendix A

The distinguishing feature is that every Level 3 action names the playbook that executes it (PBK-HM-ISOLATE-01, PBK-HM-REVOKE-01, PBK-HM-COLLECT-01), so the policy decision point refuses the call when the playbook's conditions do not hold, and a level_3_conditions block ignores model confidence, caps actions per hour, limits each action to one target and excludes servers, domain controllers, executives and break-glass accounts. The never list closes the routes by which the agent could change its own governance and includes decide_about_named_employee_access_to_work, kept although no listed tool does it, because a manifest that omits a prohibition invites a later change that adds the tool and forgets the prohibition (8, Nordqvist, 2026). It builds on the mandate manifest of The Transformed Security Architect.

Mandate manifest for an emulation agent
Kind Artefact
Origin AI Purple, Chapter 14 and Appendix A; Chapter 6 defines the division of documents
Purpose Bounds the tasks, tools, data, identity, levels, budget, expiry and accountable person of a loop agent.
Use when Before an emulation runner, planner or other loop agent runs; the mandate may be narrower than the rules of engagement and never wider.
Identifier family MND-NR-EMU-*, MND-HM-EMU-*
Full template Yes, MND-HM-EMU-01 version 1.0.0 in Appendix A

The manifest binds a scenario catalogue (signed, read-only, hash-checked) and a highest safety class, sets Level 3 only for S1 scenarios inside the scope with a verified clean-up step, Level 2 with white-team approval per run for S2 and for S3 in a mirror or range, and never executes S4. Its separation block forbids the runner to read detection content, held-out scenarios or the findings register, which makes the independence principle of that book a refusal rather than a hope. The stop holders are outside the red team by default (the white-team lead, a deputy and the SOC shift lead). A practical guide with ten steps ends with a test of the ceiling in the range, using a planted out-of-scope target, an out-of-window request and an expired token (9, Nordqvist, 2026). The emulation itself is authorised, scoped by the signed rules of engagement and ends in a defensive improvement; Chapter 11 treats those rules.

Mandate manifest for an operations agent
Kind Artefact
Origin AI Operations, Chapter 16, Appendix A.12 and Appendix B.9
Purpose Bounds an agent's scope, action classes and levels, approvals, credentials, budgets, breakers, separation of duties, prohibitions, verification, memory and stop path, with a named owner, operators and level authority.
Use when Before an agent is given an operations function; reviewed at the stated date and expires on the stated date.
Inputs Delegation profile, runbooks, containment profile, works agreement
Outputs mandates/MND-*.yaml and an AI Decision Record
Identifier family MND-NR-OPS-*, MND-HM-OPS-*
Full template Yes; quoted below from Appendix B.9 (the template with placeholders)

Appendix A.12 gives the filled example MND-NR-OPS-003, the runbook runner of Nordvik Region's citizen e-service portal, and the book states that the artefact must never contain delegation of deploy, delete or restore-overwrite, authority to change its own mandate or skills, a standing change credential, or a stop path the agent can reach. In the example every executable class (scale, restart, reconfigure for certificate renewal) is Level 2 Supervised, roll back and fail over are Level 1, and deploy, delete and restore-overwrite are undelegated. The template follows.

mandate: MND-XX-OPS-000
version: 1.0.0
status: active
decision: AIDR-0000
effective: 2029-01-01
review_by: 2029-04-01
expires: 2029-07-01
agent:
  id: XX-OPS-000
  role: runbook-runner
  usage_mode: 4
  identity: <workload identity URI>
  model: <declared model family on file>
owner: <name>
operators: [<name>, <name>]          # the rota may stop without approval
level_authority: <name>              # approves any rise in level
scope:
  services: [SVC-XX-000]
  environments: [production, staging]
  blackout_calendar: calendars/<file>.yaml
actions:
  read:       {level: 3}
  annotate:   {level: 3}
  notify:     {level: 3}
  scale:      {level: 2, runbooks: [RBK-XX-0000]}
  restart:    {level: 2, runbooks: [RBK-XX-0000]}
  reconfigure: {level: 2, runbooks: [RBK-XX-0000]}
  roll_back:  {level: 1}
  fail_over:  {level: 1}
  deploy: undelegated
  delete: undelegated
  restore_overwrite: undelegated
approval:
  approvers: [duty-manager, platform-lead]
  max_age_minutes: 15
credentials:
  issuer: <token service>
  lifetime_minutes: 10
  audience: ops-policy-decision-point
budgets:
  actions_per_hour_per_service: 6
  actions_per_day: 20
  autonomy_budget: {window_days: 28, tolerance: "per Level 3 class, as in Chapter 4", review_at_percent: 70, on_full_consumption: demote_one_level}
breakers: [same_component_3x_in_30min, no_metric_change_after_action, scope_over_catalogue]
separation: [does_not_write_runbooks, does_not_verify_own_result, does_not_edit_observer_config]
never: [change_own_mandate_or_skills, silence_alert, disable_probe_or_logging,
        act_in_freeze_on_tier1, delete_data, restore_over_existing, decide_person_access]
verification: {probe: OBS-XX-000, independent_of_agent: true}
memory: {between_runs: none, run_log: append_only}
stop:
  authority: [duty-manager, platform-lead, service-desk-lead]
  path: out-of-band revocation at token service; verified by drill
  last_drill: 2029-01-01

Quoted from Appendix B.9 of AI Operations (Nordqvist, 2026); the filled example in Appendix A.12 has the same fields. The never list carries the Level 4 prohibitions as refusals (silence_alert, disable_probe_or_logging, act_in_freeze_on_tier1, delete_data, restore_over_existing, decide_person_access), the separation list keeps the agent from writing the runbooks it runs or verifying its own result, and verification.probe points to an observer manifest that the agent does not own (Chapter 19). The template's usage_mode is 4 where the Hansa Mutual agent in the profile below is Mode 5: a Mode 4 application proposes a runbook and an orchestrator executes it, whereas a Mode 5 agent has its own write identity. Which of the two a mandate describes decides which identity the policy decision point checks (10, Nordqvist, 2026).

Mandate policy decision point rule
Kind Artefact (policy fragment, illustrative)
Origin AI Operations, Chapter 16 and Appendix A.12
Purpose A Rego rule showing the decision point outside the agent that enforces the mandate by level.
Use when Implementing the enforcement of a mandate manifest, and writing the test that tries a forbidden action.

The rule denies by default; allows a Level 3 action when the mandate is active, the token audience matches, the service and runbook are in scope, the service is not frozen and the budget has not run out; and allows a Level 2 action only when, in addition, an approval by a listed approver is recent enough. The book labels the Rego illustrative and did not run it against an engine; the notes of the inventory repeat the caveat. Open Policy Agent documents the Rego policy language (101, Open Policy Agent, n.d.); the series uses it as one way to write a decision point, and claims nothing about a given engine's behaviour. Test the rule against the planted conditions the practical guides prescribe before relying on it.

Operations mandate summary
Kind Artefact
Origin AI Operations, Chapter 1 (worked example)
Purpose One-page summary of who and what may act on one service (agents, mode, function, accountable people), summarising the mandate manifest.
Use when To show a board, a supervisor or a works council the state of delegation for one service on one date.
Identifier family Summarises MND-* (here MND-NR-OPS-003)

The summary lists each agent with its mode, the operations function it concerns, the maximum level and the level by action class, the classes at Level 4 in use (read and annotate only), the classes never available without a named person (delete, restore-overwrite and any alert or monitor change), the verification probe and the stop holders. It is a derived view, not a source: regenerate it from the manifests rather than editing it.

Writing a mandate manifest: four methods

The four books give a practical guide each. They agree on the order of work: start from what the agent is for and the runbooks or tasks it runs, never from its capabilities; give it an identity of its own; assign each action a level starting low; write the never list; set budgets that stop the agent rather than extend; name a stop path outside the agent and drill it before activation; then record the decision and set a review of no more than 90 days (AI Operations) or a quarter and expiry after twelve months (The Transformed Security Architect, AI Boss, AI Purple).

Method Origin Distinguishing step
Writing a mandate manifest The Transformed Security Architect, Chapter 13 Stage the introduction: shadow review at Level 0, then bounded stages, with evidence before action
Writing a mandate manifest for a team's agents AI Boss, Chapter 16 Record "not delegated" for each of the five management functions over the people in the team
Writing a mandate manifest for an emulation runner AI Purple, Chapter 14 Copy stage, scope, windows and abort conditions from the signed rules of engagement; test the refusal of three planted conditions
Writing a mandate manifest for a runbook-runner agent AI Operations, Chapter 16 Drop every runbook with an irreversible step; name a verification probe owned by the observer manifest, not the agent

Table 18.2: Methods for writing a mandate manifest.

Delegation profiles and charters

A delegation profile records the degree of delegation for a system, a team or a service, so that a supervisor, an auditor or a works council can read in one file what has been delegated and to what degree. Where the mandate is per agent, the profile is per subject. Chapter 22 treats the AI Boss profile and the contestation tools that go with it in the context of managing people; the entry below is kept here because the profile is the pattern the other books adopted.

Delegation profile (management functions)
Kind Artefact
Origin AI Boss, Chapters 4, 7, 9, 11 and 25 and Appendix A (DLG-NR-ROS-01)
Purpose States the degree of delegation (Level 0 to Level 4) per management function and action class for one system, with deciders, agreement and stop path.
Use when For every AI system that takes part in directing, evaluating, rewarding, developing or caring for people, before go-live or within three months for a system in use.
Identifier family DLG-NR-*, DLG-HM-* (DLG-NR-ROS-01, DLG-HM-CTA-01, DLG-HM-REC-01, DLG-HM-AB-01, DLG-NR-HCD-01, DLG-HM-SPS-01)
Full template Yes, DLG-NR-ROS-01 version 1.0.0 in Chapter 4 and version 1.1.0 in Appendix A

The five functions are M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care; a function that is not delegated is written as not_delegated, in a testable form. The profile of Nordvik Region's rostering system keeps M1 offers of open shifts at Level 3 only because acceptance and sick-leave history are excluded as inputs, and protective blocks under M5 at Level 3 because they only protect. The method behind it asks for at most fifteen action classes, the degree recorded as observed from fifty recent actions and not as intended, a comparison with the default ceilings, and agreement with the representatives before go-live. No justification is accepted for Level 4 on M3 Consequence, nor for an adverse consequence decision above Level 1 (7, Nordqvist, 2026). The team charter of AI Boss (TCH-HM-CLM-01) is a related artefact for a team of people and agents: it divides the work into people-only, supervised and reserved-for-learning parts, separates the figures kept for people and for agents, sets handover allowances in minutes and attaches to the decision record that authorises the agents. Its own method is a practical guide of the same book; Chapter 22 and Chapter 21 hold the people-side tools it feeds.

Delegation profile (blue team) and team charter
Kind Artefact (profile) and artefact (charter)
Origin AI Blue, Chapter 4 and Appendix B.2
Purpose Sets the degree of delegation per function and action class with reversibility ceilings (profile); states the team's mandate, decision rights and autonomy level per function and action class (charter).
Use when In one working session at the start, as the book's practical guide prescribes; reviewed every six months and on triggers (model change, incident with a finding on delegation, change of mode or identity, new instrument, failed reversibility test).
Identifier family DLG-HM-SOC-01, DLG-NR-SEC-01; charter ROLE-HM-SOC-01 (file team/charter.yaml)
Full template Worked examples with full YAML in Chapter 4; the inventory records the profile and charter without a template, which is a gap in the inventory and not in the book

The profile is a list of entries, one per capability and action, with function, capability identifier, mode, action, class (AC-0 to AC-4), level and the person or record that answers for it; the header carries the charter, owner, grant authority above Level 2, unlisted_actions: not delegated, level_4: none granted and the ceilings by class. Six rules make it enforceable: an unlisted action is not delegated; the lowest ceiling governs; Modes 1 to 3 stay at or below Level 2, because the AI uses a person's identity; Level 3 names its enforcement; levels above 2 have a named grant authority; Level 4 is not an entry, and the schema rejects it. The Nordvik Region profile adds the entries that record what the Region cannot see: provider AI whose level is not established, with the interim control that stands in for it, and a feature left off. The charter stores the bright line itself: its not_delegable block states that Level 4 is never used for an irreversible B4 Respond action or for a decision about a named person's access to work, its stop_and_restart block lets four roles stop and one restart, and its people block records that oversight metrics are aggregate only (8, Nordqvist, 2026).

Loop charter and loop delegation profile
Kind Artefact (charter) and artefact (profile)
Origin AI Purple, Chapter 4 and Appendix A; Chapter 14 for DLG-NR-EMU-01
Purpose The minimum charter of the loop with mandate and delegation profile (LOOP-*); the degree of delegation per stage P1 to P5 and action class (DLG-*).
Use when Before the first loop agent runs; the practical guide asks for a stop drill once before sign-off and a freeze rule in numbers.
Identifier family LOOP-NR-2028-01; DLG-HM-LOOP-01; DLG-NR-EMU-01
Full template Yes, in Appendix A; DLG-HM-LOOP-01 is quoted below

The practical guide puts four questions to each class (is it reversible, does it stay inside the signed scope, does it touch personal data beyond the authorisation, does it name a person), caps a class at Level 2 or below when the answers say so and forbids Level 4, and makes closure of a finding a person's signature that is never a delegated class. It also requires the independence declaration: every row where AI sits on both sides of a check states the kinds of separation shown, the incentive rule and the proofs available (9, Nordqvist, 2026). The Hansa Mutual profile is quoted from Appendix A.

# Illustrative: Hansa Mutual, loop delegation profile (agents fixed in Chapter 14)
kind: DelegationProfile
id: DLG-HM-LOOP-01
decision: AIDR-0852
effective: 2028-03-15
owner: {role: group-ciso-office, white_team_lead: required_for_P2}
stages:
  P1: {agent: MND-HM-EMU-02, ceiling: 1, human: Mareike Hartmann}   # scenario curator
  P2:
    - {agent: MND-HM-EMU-01, class: S1-in-scope, ceiling: 3, enforced_by: policy-decision-point}
    - {agent: MND-HM-EMU-01, class: above-S1, ceiling: 2, approver: white-team-lead}
  P3: {agent: MND-HM-EMU-03, ceiling: 1, mode: read-only}           # observation correlator; the book ceiling is 3, Hansa has not yet evidenced it
  P4: {agent: MND-HM-EMU-07, ceiling: 1, merge: Lena Vogel}         # detection drafter (HM-SEC-002); drafts only
  P5: {agent: MND-HM-EMU-06, class: REG-cases, ceiling: 3, scope: run-and-record, closure_signed_by: head-of-detection-engineering}   # re-test runner records; a person signs
critic: {agent: MND-HM-EMU-04, ceiling: 0, model_family: second}
independence: {statement: IND-HM-2028-Q1, incentive_rule: finding_quality_owner_is_not_closure_owner, unshown_kinds: treated-as-shared}   # Chapter 15
freeze_when: {seeded_gap_catch_rate_below: 0.80, stop_drill_over_seconds: 60}   # runner of HM-SEC-004; Chapter 6
evidence_expiry_days: {priority_techniques: 90, others: 180}
level_4: {forbidden_for: [irreversible, out_of_scope, personal_data_beyond_authorisation, named_person]}

Quoted from Appendix A of AI Purple (Nordqvist, 2026), Chapter 4 section; the same text appears in the chapter. The profile is per stage and per agent, the mandates it cites are the MND-HM-EMU-* family, and the freeze_when block turns the freeze of further delegation into a number. Nordvik Region's DLG-NR-EMU-01 uses another shape, allocating eight functions (emulation runner, scenario curator, emulation planner, observation correlator, detection drafter, finding triager, retest runner, critic) to a person, a contracted tester or an AI at a level, because the Region has no emulation agent. The same Nordvik delegation appears in two forms in the book: as DLG-NR-LOOP-01, the profile inside LOOP-NR-2028-01, and as DLG-NR-EMU-01; the findings file for this chapter records the overlap.

Delegation profile for an operations agent
Kind Artefact
Origin AI Operations, Chapter 4, Appendix A.18 and Appendix B.2
Purpose States for one agent and one service what the agent may do, per action class and level, how much of the allowance it has kept (the autonomy budget), what verifies it and who stops it.
Use when Before an agent acts on a service, and at every review (every 90 days by default).
Inputs Service record, mandate, action-class catalogue, observer manifest, works agreement
Outputs delegation/DLG-*.yaml and an AI Decision Record; lowering a ceiling is immediate and raising one is a named authority's decision
Identifier family DLG-* (DLG-HM-OPS-001 in Chapter 4, DLG-NR-OPS-001 in the book's naming)
Full template Yes; quoted below from Appendix B.2 
delegation_profile: DLG-XX-OPS-000
status: proposed                 # proposed, active, suspended, retired
version: 0.1
date: 2029-01-01
decision_record: AIDR-0000
agent: {id: <agent id>, mode: "Mode 5", mandate: MND-XX-OPS-000}
service: {id: SVC-XX-000, tier: 1, cif: true, slo: SLO-XX-000, rto: PT4H, rpo: PT15M}
accountable: {agent_owner: "<name>", raise_authority: "<name>"}
policy_decision_point: {location: outside_agent_platform, deny_by_default: true}
window_rule: "outside an authorised window or inside a freeze, ceiling is Level 2 with named approver"
action_classes:
  read:               {ceiling: "Level 4", condition: "redacted personal data"}
  annotate:           {ceiling: "Level 4"}
  notify:             {internal: "Level 3", external: "Level 1"}
  scale:              {ceiling: "Level 3", condition: "within quota and monthly cap"}
  restart:            {stateless: "Level 3", stateful: "Level 2", runbook: RBK-XX-0000}
  certificate_renew:  {ceiling: "Level 3", runbook: RBK-XX-0000}
  reconfigure:        {ceiling: "Level 2", alerts_thresholds_monitors: "Level 0"}
  deploy:             {ceiling: "Level 2"}
  roll_back:          {ceiling: "Level 2"}
  fail_over:          {ceiling: "Level 1", approver: incident_commander}
  delete:             {temporary_artefacts: "Level 3", production_data: "Level 1"}
  restore_overwrite:  {ceiling: "Level 1", approver: "named person"}
  anything_unlisted:  "undelegated"
autonomy_budget:
  window_days: 28
  tolerance: {<class>: "<rate of actions or count of faulty actions>"}
  customer_visible_effect: "consumes 100 per cent at once"
  review_at_percent: 70
  counted_by: OBS-XX-0001
  on_full_consumption: "class falls one level; raising needs raise_authority"
verification: {observer: OBS-XX-0001, independent_of: [model, data, authorship, vendor, time]}
stop: {holders: [incident_commander, agent_operator, platform_engineer_on_call],
       path: "outside agent platform", target_minutes: 5, drill: quarterly}
employee_representation: "<works agreement id> agreed before command logging is used"
review: {every_days: 90, next: 2029-04-01}

Quoted from Appendix B.2 of AI Operations (Nordqvist, 2026).

Worked example. Hansa Mutual's profile DLG-HM-OPS-001 (version 0.3, status proposed, dated 2028-10-24 and recorded as AIDR-0950) fills the template for its IT-operations agent HM-OPS-001 on the claims core system SVC-HM-001. It is illustrative. The values that differ from the template are these.

Action class Ceiling in DLG-HM-OPS-001 Condition or note
read, annotate Level 4 Redacted personal data for read
notify Level 3 internal, Level 1 external
scale Level 3 Within quota; EUR 6,000 per month cap
restart Level 3 stateless, Level 2 stateful Runbook RBK-HM-0001
certificate renewal Level 3 Runbook RBK-HM-0002
reconfigure Level 2; Level 0 for alerts, thresholds and monitors
roll back Level 2 Candidate for Level 3 after two quarters of evidence
fail over Level 1 Approver: incident commander
delete Level 3 for temporary artefacts, Level 1 for production data
restore-overwrite Level 1 Approver: a named person
anything unlisted Undelegated

The budget keeps a 28-day window and a tolerance of 1.5 per cent of actions for restart, one faulty action for certificate renewal and two for scale; a customer-visible effect consumes it at once, a review is held at 70 per cent, the observer OBS-HM-0001 counts, and on full consumption the class falls to Level 2 until the raise authority decides otherwise. The stop is held by the incident commander, the agent operator and the platform engineer on call, runs outside the agent platform and has a five-minute target and a quarterly drill; the agreement KBV-IT-2024-OPS-03 is cited as the precondition for command logging; the next review is 2029-01-22. The book's practical guide for writing such a profile has ten steps. Its distinctive ones are to strike every action class the profile will not name after reading the agent's technical permissions from the identity provider and not from the design document, to count a class as reversible only if the reversal was rehearsed in a non-production environment and the time recorded, and to test the policy point by attempting a listed action outside its window and an unlisted action and recording that both are refused (10, Nordqvist, 2026).

Decision-rights file with checker
Kind Artefact (YAML file) with a Python checker
Origin AI Operations, Chapter 22 and Appendix A.18
Purpose Assigns each decision of a bad night a holder, two deputies, a response time, an evidence standard, a record and an AI ceiling; the checker enforces the rules the file must satisfy.
Use when Before the agents run on a service, so that the decisions around them (declare, hand over, stop, emergency change, fail over, restore-overwrite, break a freeze, classify for reporting, communicate externally, declare recovery) have named people.
Identifier family DLG-HM-OPS-02 (the profile of the decision-rights file); DRF-NR-001 (Nordvik Region's smaller version, with risk acceptances)
Full template Yes, in Appendix A.18

The file shares the prefix DLG- with the profile above but is a different artefact: it describes decisions, not action classes. The checker, a short Python function over the parsed YAML, reports a decision right without a holder or without two deputies, a stop that needs approval, a stop with no holder reachable out of hours, a stop mechanism that runs on the agent platform and a stop drill older than 90 days. The book states the artefact must never contain a stop that needs approval, a stop on the agent platform or a decision right without two deputies. The Nordvik Region version is illustrative and carries a risk acceptance that expires at the first passing re-test (10, Nordqvist, 2026). Chapter 19 treats the stop path and the drill.

Registers and reversibility tests

A profile shows what has been decided; a register shows the sum. The concept comes from AI Threat, Chapter 26, which concluded that small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists, and that the remedy is a register of what has been delegated together with reversibility tests, with further delegation frozen where a test fails (5, Nordqvist, 2026).

Delegation register entry with reversibility test
Kind Artefact
Origin AI Threat, Chapter 26 (worked example)
Purpose Records a delegated function, its owner and the result of a test of working without the AI.
Use when For each delegation to an AI system whose loss would affect a critical service or people's rights; the test at least yearly and after any step that removes human review.
Identifier family DEL-*, RVT-* (DEL-NR-BEN-01, RVT-NR-2027-01)
Full template Yes, in Chapter 26

The entry names the function, system, mode, decision records, the remaining human role, the owner, the links to the threat register, the reversal path with legal constraints, and the test: scenario, form, acceptance criteria, abort rule and result (passed, passed_with_conditions or failed), with findings, conditions with owners and dates, a freeze on further delegation until the conditions are met, and the next test. The example's findings are the instructive part: a manual checklist that referred to a form retired two years earlier, two staff who had never triaged unranked claims, and a unit-wide capacity short by about a week of work a month (5, Nordqvist, 2026).

Delegation register and reversibility test (applied)

The Transformed Security Architect (Chapter 11) applies the register to the architect's work and gives the method for running a reversibility test on a delegation: select functions from the register, write scenario, period and acceptance criteria beforehand, start with a desk exercise and then a live exercise for at least a working week, name who applies the abort rule, measure throughput, backlog, errors and hidden dependencies (such as a fallback that calls the same provider), classify the result, freeze further delegation until a failed test passes on re-run, and turn each finding into a change. Its defaults are to test every critical function at least yearly and to keep at least two people per shift who performed the procedure in the last six months (6, Nordqvist, 2026). The book has no register template of its own; it defers to AI Threat.

Delegation register of management functions and of the blue team
Kind Artefact
Origin AI Boss, Chapters 4 and 25 and Appendix A (management/delegation-register.yaml); AI Blue, Chapter 4 and Appendix B.3
Purpose One versioned register of all delegation profiles with reversibility tests, ceiling and review-date checks (AI Boss: the pipeline rejects M3 Consequence at Level 4 and profiles past their review date); holds every delegation profile of the blue team with reversibility tests (AI Blue).
Use when After the second profile exists: the sum is what a profile cannot show.
Identifier family management/delegation-register.yaml; team/delegation-register.yaml
Full template AI Boss: yes, two registers in Appendix A. AI Blue: no full template; a table of Level 3 entries in Chapter 4

AI Boss adds to each entry the number of systems that touch each function per team, the last reversibility test and the oversight-quality metric for each Level 2 class. AI Blue reads its register four ways: how many delegations stand at each level, in which functions they cluster, how many depend on the same platform or model (a shared dependency makes two delegations one), and how many people can still do the delegated work by hand. Its example observes that three of five Level 3 delegations depend on one agent identity, so revoking that identity falls back three at once (8, Nordqvist, 2026). The Nordvik Region register of AI Boss is quoted below (version 1.3.0, November 2027, an illustrative extension of the version in Chapter 25).

# management/delegation-register.yaml (Nordvik Region, illustrative)
register: delegation-register
organisation: nordvik-region
version: "1.3.0"                   # illustrative extension; 1.2.0 in Chapter 25
owner: role:hr-director            # Ingrid Halvorsen
adopted_by: AIDR-0629
profiles:
  - {id: DLG-NR-ROS-01, version: 1.1.0, system: ShiftWise, highest: {M1: Level 3 Bounded, M5: Level 3 Bounded}}
  - id: DLG-NR-HCD-01
    version: 1.0.0
    system: home-care dashboards, time per visit and route
    functions: {M2_Evaluation: Level 0 Advisory}
    individual_figures: unit manager only, access logged
    excluded_uses: [pay, discipline, dismissal]
    open_decision: whether individual figures are kept (plan measure N3)
  - {id: DLG-NR-SA-01, version: 1.0.0, system: staff assistant and embedded assistant pilot}
paused_or_discovered:
  - {system: recruitment screening module, status: paused, record: AIDR-0601}
agents_directed_by_managers: none until supervision capacity exists   # AIDR-0610
sum_by_team:
  strandvik-home-care:
    M1_Direction: {highest: Level 3 Bounded, class: offer_open_shift}
    M2_Evaluation: {highest: Level 0 Advisory}
    M3_Consequence: {highest: not_delegated}
    M4_Development: {highest: not_delegated}
    M5_Care: {highest: Level 3 Bounded, class: protective blocks for rest and travel time}
reversibility_tests:
  - id: RVT-NR-ROS-2027-01
    scenario: ShiftWise unavailable for four weeks in home care
    run: {from: "2027-04-05", to: "2027-04-16"}
    result: passed_with_conditions
    conditions_met: "2027-06-30"
    freeze: lifted 2027-06-30; shift-swap feature stays off
    next_test: "2028-04"
reported_to: regional-executive-committee, with the report under AIDR-0600

Quoted from Appendix A of AI Boss (Nordqvist, 2026), section 25_CODE_REGNR. Note that this book has two identifier families for reversibility tests: RVT-NR-2027-01 in AI Threat and RVT-NR-ROS-2027-01 in AI Boss, for tests of the same Region that are in different registers.

The autonomy budget

A ceiling states what the agent may do; a budget states how much of that allowance it may keep. The concept, introduced in AI Operations, Chapter 4, is borrowed from the error budget of the site reliability engineering tradition (24, Alvidrez, 2017) and applied to delegated action. It belongs to the profile (the autonomy_budget block above) and is echoed in the mandate.

Autonomy budget
Kind Method
Origin AI Operations, Chapter 4 (and used in Chapters 10, 15 and 20)
Purpose Tolerance for faulty actions per window and Level 3 class, with review at 70 per cent and demotion by one level at 100 per cent, counted by the observer.
Use when For every class at Level 3, from the day it is granted.

Each Level 3 class carries a tolerance for faulty actions per window. An autonomy error is an action that had to be reversed, that the independent observer found had not had its intended effect or had made the service worse, that the policy decision point refused as outside the mandate (an attempt counts), or that had a customer-visible or regulator-visible effect. The observer counts, not the agent. Each faulty action counts once; splitting an action does not reduce the count; the default window is 28 days; unused tolerance is not banked; and a customer-visible or regulator-visible effect consumes the whole tolerance at once. The tolerance is a rate for a class that runs hundreds of times in a window (Hansa Mutual's restarts are allowed 1.5 per cent) and a count for a rare class. The book describes the tolerances as a design choice and not a measurement, and warns that a budget can become a target to be gamed (10, Nordqvist, 2026). It also gives the person who holds the stop a quantity to watch: a class that has spent half its budget in the first third of the period is a signal for review, and a budget never touched in a year is a signal that the class sees little use or that the observer is not counting.

Autonomy-budget review checklist
Kind Artefact (checklist)
Origin AI Operations, Chapter 4 and Appendix B.18
Purpose Checklist for reviewing consumption of a class's autonomy budget.
Use when At the review date of each delegation profile (90 days by default) and whenever the budget is exhausted or a near miss is recorded.
Full template Yes, ten numbered checks in Appendix B.18

The ten checks cover the profile's identification, the use of only listed classes, the absence of any Level 4 in the four prohibited cases, the budget parameters and the independence of the counting observer, the count per class with consumption as a percentage, the review and demotion thresholds, the age of the evidence for any rise, the stop drill within 90 days, the stability of seeded-fault and held-out results since the last change to the model, skill, tool or runbook, the representatives' agreement on logging, and the next review date with a short decision record (10, Nordqvist, 2026).

Promotion and demotion

The tools above state the ceiling; the evidence that moves an agent towards it, or away from it, is held by the promotion and demotion policy (PRM-*) and the shadow-period method of AI Operations, Chapter 16. Those artefacts are catalogued in Chapter 19, because their evidence is produced by observers, seeded faults and drills. This chapter records only the rules that every delegation tool in this chapter relies on.

Raising a level is slow and lowering it is immediate. Raising is a decision by a named authority, recorded as an AI Decision Record and resting on offline evaluation against held-out cases written by someone other than the agent's author, a shadow period (at least 30 days and at least 50 proposals per runbook by default), a seeded-fault exercise, and a drilled stop; the evidence has an age of at most 90 days. Lowering can be done by the agent owner, an agent operator or the incident commander, and the stop is cheaper to use than the permission to continue, as AI Threat, Chapter 30, concluded (5, Nordqvist, 2026). Four events demote: consumption of the autonomy budget (one level for the class); a near miss that the independent probes, not the agent, detected (pending review); a change of model, hosting, skill or tool not covered by the evaluation; and expiry of evidence, so that a mandate nobody reviews decays to Level 0. The same books add the human side. AI Operations attaches a manual practice clause to the mandate, at a default interval of 90 days with the agent off. AI Blue gives the same idea a form in its degraded-mode drill, which stops one agent in one shift and the team in another, with four degraded states (class paused, agent stopped, team stopped, platform down) and a measure of the classes that no analyst on shift could handle unassisted (8, Nordqvist, 2026). The Transformed Security Architect gives the staged introduction: shadow review at Level 0 for six to eight weeks, drafting at Level 1 for a quarter, and only then Level 2 and, where the design authority records a decision, one Level 3 playbook (6, Nordqvist, 2026).

Method Origin Purpose
Introducing an agent team in three stages The Transformed Security Architect, Chapter 13 Shadow review at Level 0, then bounded stages, with evidence before action
Reversibility test on a delegation The Transformed Security Architect, Chapter 11 Show a delegated function can be performed without AI for a defined period
Degraded-mode drill AI Blue, Chapter 13 Work with AI off or untrusted in four degraded states

Table 18.3: Methods that test whether a level can be withdrawn.

Instruction and configuration files for agents

A mandate does not tell an agent how to do its work. Files that do, and the formats that carry them, belong beside the mandate and must not be confused with it. AI Operations states the distinction that this section keeps: a skill says how to perform a task and does not grant permission; the mandate, enforced outside the agent, grants permission. Instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences (10, Nordqvist, 2026).

Agent skill, and the Agent Skills and AGENTS.md formats
Kind Artefact (worked example) and third-party standards
Origin AI Platform and Security, Chapters 8 and 11 (the skill motor-fnol-checklist); The Transformed Security Architect, Chapters 12, 13 and 16 (formats); AI Operations, Chapters 16 and 18 (skills as versioned files)
Purpose A packaged set of instructions, and optionally scripts and reference files, that an agent loads when a task calls for it.
Use when To give an agent procedural knowledge that is reviewed and versioned like code.
Identifier family SKILL.md
Full template Yes, a skill with front matter and steps in AI Platform and Security, Chapter 11

The Agent Skills specification defines a skill as a directory containing at least a SKILL.md file with YAML front matter followed by Markdown; name (at most 64 characters, lower-case letters, numbers and hyphens, matching the directory name) and description (at most 1,024 characters) are required, and license, compatibility, metadata and an experimental allowed-tools are optional (102, Agent Skills Contributors, n.d.). Agents load skills progressively: the metadata at start-up, the body when the skill is activated and further files as needed. The specification does not make a skill a source of permission, and the series does not treat it as one. The skill in Book 3 carries an owner, a version and the decision record in metadata, steps that stop and hand over where the facts are missing, and a Never list; a pipeline check that every tool a skill mentions is granted in the manifest catches a skill that instructs an agent to use a tool it cannot reach. AI Operations adds five rules for operations: a person other than the author reviews the instructions and every script; every skill has an owner; skills are released by tag with a version, a digest and a signature, and the mandate pins a version range, so that a change to a skill is a change to the agent handled as a change record; a skill edited to include a step beyond the mandate fails at the policy decision point; and external skills are vendored and pinned, never fetched at run time (10, Nordqvist, 2026). AI Operations cites the vendor's documentation of Anthropic Agent Skills for the advice that they come only from trusted sources and that bundled files be audited; that is the vendor's statement, and Chapter 20 treats the supply-chain risk.

AGENTS.md repository configuration for coding agents
Kind Artefact (worked example) and third-party format
Origin AI Platform and Security, Chapter 11
Purpose A repository file giving coding agents checks, rules and off-limits areas.
Use when In any repository where coding agents work, beside the controls that make the rules binding.
Identifier family AGENTS.md
Full template Yes, in Chapter 11

The AGENTS.md site describes the format as a simple, open, Markdown-based format for guiding coding agents, a "README for agents" that holds build steps, tests and conventions that would clutter a human README (103, AGENTS.md Contributors, n.d.). The Hansa Mutual example has five sections (what the repository is, checks, rules for changes, off limits, when unsure) and says: work on a branch; do not edit decision records with status Accepted; never put customer data in code, tests, prompts or commit messages; leave .github/workflows/, policies/ and CODEOWNERS to human changes. The book's own caution is the one that matters: AGENTS.md carries instructions and not enforcement, so Hansa pairs it with branch protection, code-owner approval and a runner policy that gives the agent a repository-scoped token and denies network access by default (3, Nordqvist, 2026).

Catalogue entry for a skill or agent
Kind Artefact
Origin AI Platform and Security, Chapter 8
Purpose An entry in the governed catalogue of skills and agents.
Use when When a skill or agent is published for use by others.
Identifier family catalogue_entry (for example skill.consultation-response-summary)
Full template Yes, in Chapter 8

The entry carries kind, version, digest, owner and accountable role, risk tier, permitted tools, code-execution and network posture, review status and date, evaluation results, consumers and dependent agents, distribution scope and a signature bundle. It is the record that lets an administrator install a skill from a catalogue only; the pipeline generates the digest, signature and evaluation fields (3, Nordqvist, 2026).

Agent configuration (complete, and review agent)
Kind Artefact
Origin AI Platform and Security, Chapter 11 (complete agent configuration agents/*/agent.yaml) and Appendix A (agents/architecture-reviewer.yaml)
Purpose The complete configuration of an agent with allow-list and policy decision point (Chapter 11); the complete configuration of a review agent with scoped permissions, approvals and audit settings (Appendix A).
Use when To assemble everything the runtime needs to run an agent, including how it stops.
Identifier family AgentConfiguration (AIDR-0024, AIDR-0052)
Full template Yes, in Chapter 11 and Appendix A

Book 3 is the series' earlier answer to the mandate question and uses no MND-* identifier. The configuration pins the model route and version, lists skills by version, gives the agent a service identity with a short token lifetime and a required acting user, lists each tool by server and name, sets budgets (steps, cost, wall-clock time), and has a stop block with a kill switch operated by named roles, stop conditions (budget exhausted, three policy denials, same tool called with the same arguments three times, tool output flagged by an injection classifier) and a safe state. The review agent's configuration blocks merge, approval, push and edit outright, because a reviewer that can also merge is no longer a reviewer, and lets one state-changing action, applying a high-risk label, wait for a code owner (3, Nordqvist, 2026). Its neighbour in the same chapter, the permission manifest, is catalogued in Chapter 20.

Agent role set and Architect agent system prompt
Kind Artefact (role set) and artefact (system prompt)
Origin Architecture as Code, Chapter 20
Purpose The multi-agent operating model of eight roles (Project Manager, Architect, Requirements Analyst, Designer, Developer, Quality Control, Editor, Graphic Designer); a prompt encoding the Architect agent's responsibilities and review output.
Use when As the earliest statement in the series of agent roles and of the human decisions that agents never take.

Architecture as Code states the guardrails in prose and not as a manifest: architectural commitments with long-term consequences, stakeholder communication, security and compliance decisions and conflict resolution stay with named humans, and agents draft while humans approve. The Architect prompt lists five responsibilities and a four-step review that ends in a structured output (summary, concerns, recommendations, required ADRs) (1, Nordqvist, 2025). It is a prompt, not a boundary. The later books turn the guardrails into mandates, which is the progression this chapter follows.

Other tools named in this chapter's slice

The slice also names third-party coding agents. They appear in a comparison table in AI Platform and Security, Chapter 15, which lists provider-agnostic agents, open source except Crush, that can use a self-hosted model; OpenCode is the worked example of Chapter 2 and Chapter 15 of that book. Their documentation, not this book, is the authority for their permission and configuration features.

Tool Origin One-line purpose in the series
Aider AI Platform and Security, Chapter 15 Open-source coding agent compared in a table of provider-agnostic agents
Cline AI Platform and Security, Chapter 15 Open-source coding agent compared in the same table
Codex CLI AI Platform and Security, Chapter 15 Open-source coding agent compared in the same table
Continue AI Platform and Security, Chapter 15 Open-source coding agent compared in the same table
Crush AI Platform and Security, Chapter 15 Source-available coding agent (Functional Source License, converting to the MIT licence after two years) compared in the same table
Goose AI Platform and Security, Chapter 15 Open-source coding agent compared in the same table
OpenCode AI Platform and Security, Chapters 2 and 15 Provider-neutral coding agent used as the worked example

Table 18.4: Coding agents named in the slice. The limit of the series' claim is that these agents exist and can be bounded by the instruction files and controls above; it makes no claim about the built-in permission model of any one of them.

The validation script validate_artefacts.py
Kind Own tool (script given as a code block to be saved by the reader)
Origin AI Purple, Chapters 4, 11 and 17 and Appendix A
Purpose A Python script that loads every YAML and JSON block of Appendix A and checks the closure rule, expiry and the Level 4 ban; exit status 1 on failure.
Use when In the content pipeline of an organisation that keeps its artefacts as code, to prove that no delegation reaches Level 4 and that evidence is in date.

It is not a file in the repository's scripts/ directory; the reader saves it from the appendix and runs it as python3 validate_artefacts.py <file> [as-of date]. Its Level 4 rule is the one relevant here: no ceiling, level, maxLevel or restart_level equals 4, every level_4 entry forbids at least the irreversible and named-person classes, and every MND- or DLG-NR-EMU record with a never list contains act_at_level_4. The book notes that the script checks consistency with the rules and does not replace the re-test, the signature or the judgement of the person who closes a finding (9, Nordqvist, 2026). The same check is easy to adapt to the schemas of the other books, with one caution from Table 18.1: the key names differ, so a checker written for one book's files will not find another's.

Across the degrees of delegation

Each tool in this chapter is the same at every level; what changes is which entries it contains. The table shows what the artefacts of this chapter say at each level, with the example that each originating book gives.

Level What the tools above record Example from the books
Level 0 Advisory The AI suggests and a person acts; the default for alerts, thresholds and monitors, for the researcher agent, and for any action no evidence supports Reconfiguration of alerts, thresholds and monitors in DLG-HM-OPS-001; the critic agent at Level 0 in DLG-HM-LOOP-01
Level 1 Assisted The AI drafts and a person reviews and executes; the ceiling for irreversible and external actions External notification and fail-over across providers in DLG-HM-OPS-001; AC-4 actions in DLG-HM-SOC-01
Level 2 Supervised The AI executes after approval of each action; the ceiling for classes that change production without a runbook Every executable class in MND-NR-OPS-003; account disabling in MND-HM-SOC-02
Level 3 Bounded The AI executes within a codified playbook or runbook enforced by a decision point outside it; needs a budget, an observer and a stop outside the agent Restart, certificate renewal and scale in DLG-HM-OPS-001; workstation isolation in MND-HM-SOC-02; S1 emulation in MND-HM-EMU-01
Level 4 Autonomous Reading and annotating only, where used; never for the cases in the prohibitions Read and annotate in the operations tools; no Level 4 granted in the blue team or loop profiles

Table 18.5: Degrees of delegation across the tools.

The usage mode adds a second axis. Modes 1 to 3 stay at or below Level 2 in AI Blue because the AI acts under a person's identity; Mode 5 agents carry mandates with their own workload identity; Mode 0 features carry no mandate at all, only a decision to accept, constrain or switch off, which is why the profiles of AI Blue and AI Operations contain entries for the provider's AI.

Nordvik Region and Hansa Mutual

Nordvik Region has no autonomous production agent in operations (no Mode 5). Its runbook runner NR-OPS-003 is a Mode 4 application under MND-NR-OPS-003 (AIDR-0916, effective 2028-11-14), with every executable class at Level 2, and its decision-rights file DRF-NR-001 (AIDR-0922, illustrative) names the duty manager and platform lead as stop holders with a backstop of the regional director. In the people domain its rostering profile DLG-NR-ROS-01 keeps M2 Evaluation to M4 Development undelegated; in the security domain DLG-NR-SEC-01 records provider AI levels as not established; in the loop domain it has a charter (LOOP-NR-2028-01) and a profile with no emulation agent. The pattern is of writing down what cannot be enforced.

Hansa Mutual runs Mode 5 agents in five domains and therefore holds the most profiles: DLG-HM-OPS-001 for the IT-operations agent (AIDR-0950, with a promotion policy PRM-HM-OPS-001 under AIDR-0966 and the decision-rights file DLG-HM-OPS-02 under AIDR-0972), MND-HM-SOC-02 and DLG-HM-SOC-01 for the SOC, MND-HM-EMU-01 and DLG-HM-LOOP-01 for the loop, MND-HM-01 for the architect's team, and MND-HM-CLM-01 and DLG-HM-CTA-01 for the claims team. Its Level 3 classes are the narrow reversible ones: restart, certificate renewal and scale in operations; workstation isolation, session revocation and evidence collection in the SOC; S1 emulation in the loop. Its open exposure, as the delegation register of the SOC shows, is that three Level 3 delegations depend on one agent identity.

Summary

The mandate and the delegation profile together answer what an agent may do and to what degree. The mandate is per agent and the profile per system, team or service; the books use the same prefixes with different schemas, and a reader should adopt the numbers of the book whose file they copy. All the files obey the same rules: an unlisted action is undelegated, the lowest ceiling governs, Level 3 needs a codified playbook and a decision point outside the agent, a rise is a recorded decision by a named authority and a fall is immediate. The autonomy budget turns the ceiling into a quantity that an independent observer counts, and the register and the reversibility test show whether a delegation can be withdrawn. Instruction files such as SKILL.md and AGENTS.md say how to work and are never a source of permission. The chapter's own conclusion is that the tools form a chain, from scale to decision record to profile to mandate to enforcement point to observer to budget to register, and that a break at any link, such as a Level 3 entry that names no enforcement or a budget counted by the agent itself, leaves a label without a control.

The chapter treats 60 of the 76 inventory entries assigned to it, in entries or in family tables; the other 16 belong to other chapters and are listed in the findings file for reassignment. Appendix A holds every entry, including those not treated here.

Sources

  1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
  2. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
  3. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
  4. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (5, Nordqvist, 2026)
  5. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
  6. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
  7. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
  8. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
  9. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
  10. Alvidrez, M. Embracing Risk. (24, Alvidrez, 2017)
  11. Open Policy Agent. Policy Language. (101, Open Policy Agent, n.d.)
  12. Agent Skills Contributors. Agent Skills Specification. (102, Agent Skills Contributors, n.d.)
  13. AGENTS.md Contributors. AGENTS.md: a simple, open format for guiding coding agents. (103, AGENTS.md Contributors, n.d.)