Defending the Agent: Identity, Credential and Protocol Tools
This chapter serves the activity of securing the agent itself: giving it an identity of its own, issuing it credentials that cannot be kept, bounding what it can call and reach, and treating the estate in which the operator's AI runs as the most privileged workload there is. Its tools are of three kinds. The artefacts are records and manifests in version control that an agent cannot write: the agent identity record, the credential profile, the permission manifest, the containment profile, the tool registry entry, the containment catalogue and the Tier 0 checklists. The methods are short procedures for designing and testing them. The third-party tools are open standards and open-source software that the series names as the plumbing of agents: the Model Context Protocol, SPIFFE, OAuth 2.0 token exchange, the Agent2Agent protocol, Agent Skills, and the permission settings of coding agents. They come from AI Governance (2, Nordqvist, 2026), AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026), AI Blue (8, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), with one tool from Architecture as Code (1, Nordqvist, 2025).
Two questions organise it: which identity and protocol standards do agents rely on, and which controls make the operator's AI Tier 0. The series' answer to the second is a design stance, not a product. A Tier 0 asset is one whose compromise gives control over the estate; AI Operations, Chapter 18, argues that an operations agent with write access to production, its runbook library, its observability pipeline and the control plane behind it are Tier 0 because the broadest credentials and the best map of the organisation meet there, and because what AI adds is a reader that cannot by its own judgement separate the data in a ticket from the instructions in it (10, Nordqvist, 2026). The controls that follow are designed for the agent's reach and not its intent, a conclusion of AI Platform and Security, Chapter 19: the same control bounds an agent steered by text, one whose model the provider updated without notice, and a script run with wrong parameters (3, Nordqvist, 2026). The Five Eyes agencies' guidance, as AI Operations cites it, states that the privileges assigned to an agent directly determine the risk it can introduce and recommends constructing each agent as a distinct principal with its own cryptographically anchored identity (254, Five Eyes agencies, 2026). Chapter 19 treated the tools that test whether these bounds hold; Chapter 18 treated the mandates that say what an agent may do. This chapter treats the records and standards that make the bounds enforceable.
Figure 20.1: Agent identity and containment. The identity record, permission manifest, containment profile and tool registry entry are files the agent cannot write. A credential broker, a policy decision point and a tool gateway outside the agent runtime read them, and the stop path acts on the broker and the runtime and not on the agent's cooperation.
The slice holds 58 inventory entries: 29 artefacts, 9 methods and 20 third-party tools and standards. The chapter treats 47 of them and lists the other 11 for reassignment in data/findings/chapter_20.md. Appendix A holds all 58.
Agent identity and workload identity
An agent that borrows a person's credentials, or a shared service account, cannot be attributed, bounded or stopped without stopping others. The series' rule is one identity per agent, issued outside the agent's runtime, short-lived, scoped to a task and revocable within a minute. The tools in this family are the record that registers the identity, the profile that fixes how credentials are issued from it, the token that carries a delegation, and the standards beneath them.
| Tool | Kind | Origin | One-line purpose |
|---|---|---|---|
| Agent identity record | Artefact | The Transformed Security Architect, Chapter 8 | Registers an agent identity with owner, operator, authority, scope, lifetime and revocation |
| Agent credential profile | Artefact | AI Red Team, Chapter 14 | Task-scoped, short-lived credential profile for the SOC investigation agent, issued outside the agent runtime |
| Delegated token claims | Artefact | AI Platform and Security, Chapter 12 | Claims of a delegated-authority token that carries user and agent identity |
| Call-back rule | Artefact | The Transformed Security Architect, Chapters 8, 25 and 26 | Rule requiring out-of-band confirmation of a change, so that approvals resist synthetic media |
| Registering an agent identity | Method | The Transformed Security Architect, Chapter 8 | Ensure each agent has a registered, scoped, time-limited, revocable identity |
| Hardening approvals against deepfakes | Method | AI Red Team, Chapter 14 | Harden payment and privileged-access approvals against synthetic media |
Agent identity record
| Kind | Artefact |
| Origin | The Transformed Security Architect, Chapter 8 |
| Purpose | Registers an agent identity with owner, operator, authority, scope, lifetime and revocation; Appendix B of the source calls it a delegated-authority record. |
| Use when | Before any credential is issued to an agent, and at each review, which the record schedules. |
| Inputs | The decision record that grants the level, the workload identity, the people who answer for the agent, the scopes with their autonomy levels. |
| Outputs | A merged record from which the broker issues, a revocation test, and an expiry that disables the identity if a review is missed. |
| Identifier family | Per agent (HM-EVC-001 in the example) |
| Full template | The Transformed Security Architect, Chapter 8 (quoted below) |
The example in the source is Hansa Mutual's evidence-collection agent, a Mode 5 agent that has read-only access and acts at Level 3 Bounded only to refresh evidence links, which is reversible because a link can be restored from the previous manifest. The broker and the policy checks read the same file, so the record the authority approved is the record that is enforced (6, Nordqvist, 2026).
# Illustrative: Hansa Mutual, identity record for the evidence-collection agent
identity: HM-EVC-001
decision_record: AIDR-0565
workload_identity: spiffe://hansa.group/architecture/evidence-collector
mode: 5
issuer: group-credential-broker # outside the agent runtime
people:
owner: head-of-security-architecture
operators: [agent-operator-rota-hamburg, agent-operator-rota-polish-service-centre]
authority: group-ciso
shared_with: []
token:
type: delegation # impersonation is refused
max_lifetime_minutes: 15 # at first; 5 after the stop drill of Chapter 10
bound_to: [task_id, entity]
sender_constrained: true # key-bound, DPoP style
scopes:
- action: read
resources: [telemetry.platform, repo.catalogue, repo.evidence-manifests]
autonomy_level: 1
- action: refresh_evidence_link
resources: [repo.evidence-manifests]
autonomy_level: 3 # playbook EVP-REFRESH-01, reversible
limit: {per_run: 40, restore_from: previous_manifest}
denied: [catalogue.control.write, catalogue.exception.approve, iam.roles.assign, policy.rules.write]
revocation:
stop_path_holders: [agent-operator-rota-hamburg, group-ciso]
takes_effect_within_seconds: 60
review: {every_months: 6, on_change: [model, tools, scope], on_missed: disable}
log: {every_issue_and_use: true, destination: group-evidence-store}
The comment on max_lifetime_minutes refers to The Transformed Security Architect, Chapter 10, whose first stop drill cut task-scoped tokens from fifteen to five minutes. Watch the denied list: the permissions an attacker who steers the agent would want first (writing the catalogue it serves, approving exceptions, assigning roles) are denied by name.
Agent credential profile
AI Red Team, Chapter 14, gives the credential profile for Hansa Mutual's SOC investigation agent HM-SEC-001 (profile hm-sec-001-credentials, AIDR-0311). It states a workload identity in the SPIFFE form, an issuer outside the agent runtime (the group credential broker), no ambient authority, a sharing list that is empty, a token with a fifteen-minute maximum bound to task, case and entity, four scopes with autonomy levels (read telemetry at Level 1; revoke session and isolate workstation at Level 3; disable account at Level 2), a denied list (role assignment, credential reset, writing detection rules), an entity binding that refuses and alerts on a mismatch, and revocation of all tokens within sixty seconds by people outside the runtime (4, Nordqvist, 2026). It overlaps the identity record above; the identity record registers who answers for the agent, and the credential profile fixes how its tokens are bound. The source is explicit that the profile is read by the broker and never by the agent. The template is not quoted here, to stay within the limit of full templates; its fields are those listed.
Delegated token claims, call-back rule and the two methods
The delegated token of AI Platform and Security, Chapter 12, is a short JSON claim set in which the gateway has exchanged an officer's token for one issued to the AI service: sub names the service identity, an act claim preserves the officer's identity and assurance level, and the token carries an audience, a scope, a purpose and an expiry of five minutes, so that the system of record can check the person and the service separately and the audit log records both (3, Nordqvist, 2026). The pattern is the application of OAuth 2.0 token exchange, listed below.
The call-back rule (CBR-*, example CBR-NR-BEN-01) addresses a different identity problem, the approver. A change to a model version, an integration credential or an administrator list is confirmed through a contact fixed at contract signature, by a second approver who did not receive the request, recorded in the change ticket system with a phishing-resistant key, after a cooling-off period of 24 hours that only the CISO may shorten (6, Nordqvist, 2026). The method Hardening approvals against deepfakes of AI Red Team, Chapter 14, makes the same move for payment and privileged-access approvals: a control that depends on people recognising a forgery degrades as forgeries improve, whereas one that makes the forgery useless does not (4, Nordqvist, 2026). The method Registering an agent identity is the procedure that produces the identity record: nothing is issued without a record, attestation checks what is asking, issuance is task-scoped, revocation is fast and rehearsed, and retirement ends identities when their purpose ends, with a missed review disabling the identity (6, Nordqvist, 2026).
Credentials and secrets
The series' stance on secrets is that an agent should not hold them. Architecture as Code (Chapter 9) names HashiCorp Vault and cloud secret managers such as AWS Secrets Manager as services for the lifecycle of secrets from generation through distribution, rotation and retirement (1, Nordqvist, 2025). The mention is passing. HashiCorp's own introduction describes Vault as a service that centralises secret management, including static secrets and database credentials issued to clients (247, HashiCorp (n.d.), n.d.); it does not, on that page, describe rotation or revocation, so this chapter does not attribute them to Vault. The AWS documentation describes AWS Secrets Manager as managing, retrieving and rotating credentials, tokens and API keys throughout their lifecycles, with an automatic rotation schedule (248, AWS, n.d.). Later volumes replace distribution of long-lived secrets by issuance of short-lived tokens by a broker: no standing credential for a change or restore class, read credentials that last longer than write credentials, audience and requester binding, and no credential in a document (10, Nordqvist, 2026).
The enforcement of these rules is a policy decision point outside the model. Two policy artefacts in the slice are written in Rego, the language of Open Policy Agent, whose documentation shows default allow := false with an allow rule that holds only when stated conditions on the input are met (101, Open Policy Agent, n.d.). The agent workload-identity authorisation policy (package ai.agents.authz, AI Platform and Security, Chapter 17) authorises agent tool calls by workload identity (3, Nordqvist, 2026). The agent permission manifest and refusals of AI Operations (Appendix A.14) classifies what an agent reads by who can write it and states deny-by-default refusals that hold at every level, with a replayable decision log; the source states that the Rego is illustrative and must be tested with the organisation's policy engine, and that the artefact must never contain an allow rule in this package, untrusted text acting above notify without an independent probe, or a decision log held by the agent (10, Nordqvist, 2026). The enterprise Rego policy for security and multi-factor authentication of Architecture as Code, Chapter 10, is a policy-as-code artefact for Chapter 5.
Agent protocols
An agent calls tools and other agents through protocols, and each protocol is a boundary the series treats as security-relevant. The protocols are third-party standards and software, described here only as the series uses them and from the primary documentation in the bibliography. A series-level fact that bears on all of them: a client setting is a convenience and not a control. AI Platform and Security, Chapter 15, argues that enforcement belongs outside the client, with default-deny egress and a gateway that accepts a request only when the workspace identity may reach the requested model (3, Nordqvist, 2026) (6, Nordqvist, 2026).
| Tool | Kind | Origin | What it is and how the series uses it | Limit of the claim |
|---|---|---|---|---|
| Model Context Protocol (MCP) | Open protocol | AI Platform and Security, Chapters 11, 12, 15 and 16; AI Red Team, Chapters 2 and 9; The Transformed Security Architect, Chapters 6, 7, 8, 13 and 24; AI Boss, Chapter 17; AI Purple, Chapter 12; AI Operations, Chapters 8, 16, 18 and 32 | A protocol connecting applications that run a model to servers that expose tools and context (104, Anthropic, 2024). Its security guidance says a server must not accept tokens not issued for it and that scopes should be minimal (105, MCP, 2025). The series registers each server, pins its version and digest, and treats a server's tool list as part of the mandate | The protocol carries calls; it does not decide who answers for them. The inventory holds the protocol six times, once per book that names it; they are one tool |
| Agent2Agent Protocol (A2A) | Open protocol | AI Boss, Chapter 17 | A protocol for agent-to-agent tasking, in which a client agent communicates a task, a remote agent acts on it and agents advertise capabilities in an Agent Card (110, Google, 2025). The series uses its launch example, a hiring workflow, to show a chain of agents inside a consequential function | Nothing in the protocol keeps a person in charge; the design decides who answers |
Agent Skills (SKILL.md) |
Open format | AI Platform and Security, Chapters 8 and 11 | A packaged procedure, a directory with a SKILL.md file whose front matter gives a name and description, loaded when a task calls for it (102, Agent Skills Contributors, n.d.). The series limits a skill's allowed tools to a subset of the agent's own permissions |
The allowed-tools field is described in the source as an experimental part of the specification |
| Claude Code and Codex permission and sandbox settings | Vendor documentation | The Transformed Security Architect, Chapters 7, 12 and 17 | Examples of per-tool permission rules, approval modes and sandboxes for agentic coding tools (244, Anthropic, n.d.) (245, OpenAI, n.d.). Used as evidence that controls are moving from the agent's compliance to the environment | Living pages; a setting in the client is not the enforcement point |
| Argo CD MCP server | Open-source software | AI Operations, Chapters 16 and 18 | A server giving a model-driven agent access to Argo CD; its README lists tools that create, update, delete and sync applications, and a read-only environment setting disables the write tools (239, Argo Project Labs, n.d.) | A project statement, not a tested property |
| Flux MCP Server | Open-source software | AI Operations, Chapters 8, 16 and 18 | A server for Flux Operator, described as experimental in 2025, with a read-only mode, service-account impersonation and masking of Secret values (246, Prodan, 2025); its --read-only flag defaults to false (241, controlplaneio-fluxcd, n.d.), and impersonation with --kube-as limits it to the permissions of the named service account (240, ControlPlane, n.d.) |
Read as project text and code, not tested |
| Kubernetes MCP server | Open-source software | AI Operations, Chapter 16 | A server whose read_only and denied_resources settings the README calls best-effort guardrails (242, containers, n.d.) |
RBAC on the server's identity is the access control to rely on |
The series draws one rule from the MCP servers in particular: a read-only switch in a tool is a convenience, and the hard limit is the permission of the identity behind the server. A generic server that can create or delete any resource is wider than any single runbook, so the runner calls a narrow wrapper, reviewed and pinned by the platform team, and generic servers are kept for roles that only read (10, Nordqvist, 2026).
Tool registry entry
| Kind | Artefact |
| Origin | AI Platform and Security, Chapter 11 |
| Purpose | Registers an MCP server with owner, scopes and trust. |
| Use when | Before any agent may connect to a tool server; the agent pipeline refuses a manifest that names a server or tool absent from the registration. |
| Inputs | The server's owner, security review, threat model, endpoint, authentication method, data classification and its tools with their effect. |
| Outputs | A registration in the architecture repository; the pipeline check that every irreversible tool in a manifest carries an approval requirement. |
| Identifier family | tool-registry/*.yaml (kind ToolServerRegistration) |
| Full template | AI Platform and Security, Chapter 11 |
In the source's example the server fronts Hansa Mutual's claims system and classifies each tool as read, reversible-write or irreversible; one irreversible tool (reserve.set) is marked agentUse: prohibited, so that no manifest can grant it, and the registration requires the acting user's identity, which the server enforces with OAuth token exchange (3, Nordqvist, 2026). The effect classification is the field the rest of the design depends on.
Identity standards
| Tool | Kind | Origin | What it is and how the series uses it |
|---|---|---|---|
| SPIFFE and SPIRE | Open standard and reference implementation | AI Platform and Security, Chapter 17; AI Red Team, Chapters 14 and 18; The Transformed Security Architect, Chapter 8; AI Operations, Chapters 8, 16 and 18 | A specification for workload identity (the SPIFFE ID and its verifiable document) with SPIRE as one implementation of it (106, SPIFFE project, n.d.) (107, SPIFFE Project, n.d.). The series uses spiffe:// identifiers in identity records and credential profiles to give each agent a short-lived identity of its own. The inventory holds four entries, one per book, three for SPIFFE and one for SPIFFE and SPIRE together; they are one tool |
| OAuth 2.0 Token Exchange (RFC 8693) | Open standard | AI Boss, Chapter 17; The Transformed Security Architect, Chapter 8 | Distinguishes impersonation from delegation, with an actor claim that records the chain of acting parties (108, Jones et al., 2020). The series refuses impersonation for agents and issues delegation tokens that name both the subject and the actor |
| OAuth 2.0 Rich Authorization Requests (RFC 9396) and DPoP (RFC 9449) | Open standards | The Transformed Security Architect, Chapter 8 | Rich authorisation and sender-constrained tokens (109, Lodderstedt et al., 2023) (111, Fett et al., 2023). The identity record's sender_constrained: true is annotated "key-bound, DPoP style" |
The inventory carries RFC 9396 and RFC 9449 together with RFC 8693 in one entry of The Transformed Security Architect, and RFC 8693 again from AI Boss; both are listed above.
Containment and permission manifests
The last family carries the boundary itself. Two artefacts divide the work, and the series takes care to keep them apart. The permission manifest states what the agent may do: purpose, identity, tools, argument constraints, approvals, budgets and prohibited actions. The containment profile states what the platform guarantees whatever the agent attempts: isolation, reach, egress, protected artefacts, decoys, logging and the stop path. The manifest is the agent's declared intent and the profile the platform's commitment, so the profile must be at least as strict as the manifest and must not depend on the manifest being obeyed. Both are files in version control, reviewed by pull request and unwritable by the agent (6, Nordqvist, 2026). The inventory carries many variants, because every book from AI Governance onwards adapts the pair to its own agent.
| Artefact | Origin | Agent and setting | What distinguishes it |
|---|---|---|---|
| Agent permission manifest | AI Governance, Chapters 18 and 20 | Maintenance-planning agent, before and after hardening | Version-controlled manifest with a cost budget, an approval threshold, an idempotency key and a rule that the agent may not assign named people |
| Agent permission manifest and tool allow-list | AI Platform and Security, Chapter 11, Appendix A | Maintenance-planning agent | Deny by default, with identity, tools with argument constraints, approvals, budgets, data scopes and MCP servers pinned by version and digest (quoted below) |
| Deny-by-default permission manifest for an IT-operations agent | AI Platform and Security, Chapter 11 | Hansa Mutual IT-operations agent | The same pattern for a remediation agent |
| Agent containment profile | AI Platform and Security, Chapter 19 | Hansa Mutual IT-operations agent | Platform-enforced limits on tools, egress, secrets, budgets and stop paths: micro-VM runtime per incident, token per call, egress default deny, protected artefacts, a honeytoken decoy, 5-minute maximum token life |
| Agent permission manifest (SOC investigation agent) | AI Red Team, Chapter 18, Appendix A | Hansa Mutual SOC agent | Reads, two Level 3 actions, denied tools, default-deny egress, a budget and a stop path through gateway revocation |
| Agent containment profile | AI Red Team, Chapter 4 | SOC investigation agent | Places security AI on the platform's controls |
| Containment profile | The Transformed Security Architect, Chapter 7 and Appendix A | Hansa Mutual IT-operations agent | Ceiling of identity, egress, data, blast radius, stop holders and verification tests (quoted below) |
| Permission manifest | The Transformed Security Architect, Chapters 3, 7, 8 and 9 | Per agent | Cap on tool calls evaluated by a policy decision point outside the model; listed in Appendix B together with the containment profile |
| Containment profile | AI Blue, Chapters 13 and 15 | Hansa Mutual SOC agent | The permission manifest of a SOC agent as the series' containment profile: action classes with levels and approvers, level-3 conditions, a never-list, budgets, circuit breakers, stop path |
| Permission manifest | AI Blue, Chapters 13 and 15 | SOC agents | Technical ceiling on tools and action classes per identity; the source records that the pattern is defined in AI Platform and Security, Chapter 19, and AI Red Team, Chapter 18 |
| Agent permission manifest and refusals | AI Operations, Chapter 18, Appendix A.14 | Operations agent | Writer classes for what an agent reads, deny-by-default refusals that hold at every level, replayable decision log |
| Containment catalogue | AI Red Team, Chapter 21 | SOC agent | Catalogue of bounded, reversible containment actions with levels, budgets, exclusions, reversal handles and a stop path |
The naming overlaps: The Transformed Security Architect and AI Blue use CP-* for the containment profile, AI Platform and Security has none, and AI Blue calls its profile the permission manifest of the SOC agent. Chapter 25 records the overlap. The reader who needs one pattern should take the pair of AI Platform and Security and The Transformed Security Architect, which the later volumes adapt.
Agent permission manifest and tool allow-list
| Kind | Artefact |
| Origin | AI Platform and Security, Chapter 11 and Appendix A (11_CODE_AGENT) |
| Purpose | Deny-by-default declaration of the tools, data, identity, budgets and approval gates an agent may use. |
| Use when | For every agent before it runs; the runtime enforces it and an auditor can read it. |
| Inputs | The decision record, the registered tool servers, the data classes and regions allowed, the approvers. |
| Outputs | A manifest in version control, read by the policy decision point and the pipeline. |
| Identifier family | agents/*.yaml (kind AgentPermissionManifest) |
| Full template | AI Platform and Security, Appendix A (quoted below) |
The example in the source is a maintenance-planning agent in a manufacturing group, the setting of a case study in AI Governance, Chapter 18. The later volumes extend the pattern, for instance with the writer classes of AI Operations. The source states that anything not listed is denied (3, Nordqvist, 2026).
# agents/maintenance-planner.yaml
apiVersion: ai-architecture.example.eu/v1
kind: AgentPermissionManifest
metadata:
id: maintenance-planner
version: 1.4.0
owner: plant-operations-platform
aidr: AIDR-0031
spec:
identity:
principal: spn-maintenance-planner
authentication: workload-identity
actsOnBehalfOf: delegated-user # user identity propagated to every tool call
maxDelegationDepth: 1
model: {gatewayRoute: internal/engineering-tier, allowedModels: [eu-hosted-llm-70b@2026-02]}
tools:
defaultPolicy: deny
allow:
- name: read_work_orders
server: mcp-cmms
scopes: [workorders:read]
argumentConstraints: {plant_id: {allowedValues: [SE-01, SE-02, FI-01]}}
- name: schedule_downtime
server: mcp-cmms
scopes: [schedule:write]
requiresApproval: true
approvers: [shift-supervisor]
argumentConstraints: {duration_hours: {maximum: 8}}
- name: order_spare_part
server: mcp-procurement
scopes: [purchase:request]
requiresApproval: true
approvers: [maintenance-manager]
argumentConstraints: {amount_eur: {maximum: 5000}}
deny: [delete_work_order, modify_safety_interlock, send_external_email]
mcpServers:
- name: mcp-cmms
endpoint: https://mcp.internal.example.eu/cmms
version: 2.1.3
digest: sha256:3f1c9e5a7d2b4c6e8a0f1b3d5c7e9a2b4d6f8a0c2e4b6d8f0a2c4e6b8d0f2a4c
authentication: mutual-tls
dataScopes: {allowedClassifications: [internal, confidential], allowedRegions: [EU]}
budgets:
maxToolCallsPerRun: 40
maxCostEurPerRun: 2.50
maxWallClockMinutes: 15
onBudgetExceeded: stop-and-escalate
loopProtection: {identicalToolCallLimit: 3, noProgressIterations: 4}
audit: {logEveryToolCall: true, retentionDays: 365, sink: "otel://collector.internal.example.eu"}
humanOversight:
pattern: human-on-the-loop
killSwitch: feature-flag://agents/maintenance-planner/enabled
Note that the template lists only one of the two MCP servers it allows under tools (mcp-procurement is used but not pinned in mcpServers); the book's text says the servers are pinned by version and digest, so the entry is incomplete as a template. Chapter 25 records the gap. The kill switch is a feature flag outside the agent, which is the series' answer to where the stop path runs.
Containment profile
| Kind | Artefact |
| Origin | The Transformed Security Architect, Chapter 7 and Appendix A (07_CODE_CONTAIN) |
| Purpose | Per workload or agent ceiling of identity, egress, data, blast radius, stop holders and verification tests. |
| Use when | Before the agent receives any real credential; the pipeline rejects a manifest grant the profile's ceiling does not cover. |
| Inputs | The six questions of the design method below, the manifest, the correlated-controls review, the stop holders. |
| Outputs | A profile in version control, owned by a named person, with a classification (verified, declared or failed) set by the last test result and not by the owner. |
| Identifier family | CP-* (CP-HM-ITOPS-01) |
| Full template | The Transformed Security Architect, Chapter 7 (quoted below) |
The profile for Hansa Mutual's IT-operations agent restricts it to reversible writes in three production namespaces, denies egress by default, admits no relays (after a review, AIDR-0552, removed the package and model mirror from the agent's reachable destinations), caps the blast radius at four write actions and twenty minutes, names stop holders and the three ways they act, and attaches two tests that run from outside the agent's network (6, Nordqvist, 2026).
# boundaries/itops/containment-profile.yaml - Hansa Mutual, illustrative
id: CP-HM-ITOPS-01
decision_records: [AIDR-0027, AIDR-0552]
owner: platform-domain-architect
manifest: agents/itops/manifest.yaml # read-only to the agent
ceiling: # the profile must cover every manifest grant
environments: [production-eu]
namespaces: [claims-web, claims-api, document-service]
writes: reversible-only
network:
egress_default: deny
allow: [tool-gateway.hansa.internal, ai-gateway.hansa.internal]
relays: none # package and model mirrors are not reachable
blast_radius:
statement: >-
Worst case, up to three claims services unavailable for at most 20 minutes,
all changes reversible, no data read or written.
max_write_actions: 4
max_wall_clock: 20m
dependencies: # for the correlated-controls review
credentials: per-call, 5m, not shared
audit_sink: append-only, separate account, agent has no write path
alert_route: on-call-engineer # also holds the stop decision
stop:
holders: [on-call-engineer, duty-manager]
acts_by: [revoke-credentials, terminate-runtime, cut-egress]
verification:
control: CTRL-AGT-002
tests:
- {id: egress-probe, runs_from: outside-agent-network, cadence: weekly}
- {id: stop-path-drill, series: SPT-HM-ITOPS, cadence: quarterly}
classification: verified-declared-failed # set by the last test result, not by the owner
The dependencies block is the part to read twice. It lists what the profile's controls share, so that two controls that fail together are not counted as two; AI Governance, Chapter 19, analysed an incident of that kind, with a shared credential, a package mirror that was also an exit and an alert that reached people who did not hold the stop decision (2, Nordqvist, 2026).
Methods and further artefacts for containment
| Tool | Kind | Origin | Purpose |
|---|---|---|---|
| Designing a containment profile in six questions | Method | The Transformed Security Architect, Chapter 7 | Produce a containment profile before an agent receives a credential: what may it change, which legs of the trifecta does it hold, where may it send things, what does it borrow, how much can it do before a person sees it, who stops it |
| Containment that does not depend on intent | Method | AI Red Team, Chapters 4, 12, 14, 18 and 21 | Task-scoped credentials, default-deny egress, policy outside the model, budgets and an out-of-band stop path |
| Containment sandbox, overreach detection and response guides | Artefact (practical guides) | AI Platform and Security, Chapter 19 | Practical guides to build a sandbox, detect overreach and respond |
| Containment test plan (agent escape paths) | Artefact | AI Red Team, Chapter 13 | Plan to test whether an agent can escape its containment, including the stop path; identifier HM-SEC-*-CT-*, kind ContainmentTestPlan |
| Canaries | Method | AI Blue, Chapter 15 | Decoy tickets, credentials and tools that reveal a manipulated agent |
| Practical guide: Writing a permission manifest and a deny-by-default policy for a remediation agent | Method | AI Operations, Chapter 18 | Writes the smallest permission manifest for a remediation agent and a policy that refuses everything else |
| Tier-0 checklist for the operator's AI | Artefact | AI Operations, Chapter 18 and Appendix B.13 | Controls for remediation agents, runbook libraries, observability pipelines and configuration maps: classification, access, segregation, supply chain, content classes and the ceiling suite |
| Tier-0 checklist for the findings register and emulation agents | Artefact | AI Purple, Chapter 16 and Appendix B.16 | Controls for classification, access, segregation, supply chain and handling of findings in hosted AI tools |
The containment test plan is the one place in this chapter where an offensive activity is described, and the source frames it as the series always does. The test runs in an AI test range against a replica of the agent's manifest, under written rules of engagement, to find whether the agent can escape its containment; its objectives name a credentials, control-artefacts, detection and stop-path hypothesis each, for example that the operator stop revokes all agent credentials within five minutes while a task runs. In the source's example it found one escape path (a deployment service account that could read an adjacent environment's secrets store, undetected because the security monitoring did not collect those reads) and the closing controls were a dedicated task-scoped identity and a detection for any read by an agent identity (4, Nordqvist, 2026). The test ended, as the series requires, in a defensive improvement. AI Red Team says that boundary tests weigh more than behavioural tests for agents, because a boundary does not know it is being tested.
AI Operations' practical guide on permission manifests has nine steps. It assigns every source of text the agent reads a writer class from WC-1 (platform events and probes, which may trigger) to WC-4 (vendor feeds, provider AI output, external skills and model summaries, which inform only); it lists the action classes, writes undelegated for the rest and never delegates delete or restore-overwrite to an agent; it binds delegated classes to signed, catalogued runbooks; it requires an authorising record for every action above notify; it makes an action above notify with WC-3 or WC-4 text in context need an independent probe or a recorded human approval; it sets credentials at ten minutes with no standing change credential; it writes the refusals as a separate module with a decision log outside the agent's reach; it writes ceiling cases, at least ten refusal cases per closed class and per writer class, run on every change and weekly; and it reviews with the CISO delegate and sets a review date of at most 90 days (10, Nordqvist, 2026). Its extract of the mandate input block is the most compact statement of the idea that what an agent reads has an authority level of its own.
Worked example: a coding agent
The outline of this chapter proposed a permission manifest for a coding agent. The earlier volumes do not give a manifest for one; they give a pair, an instruction file that says what is expected and platform controls that make what is forbidden impossible. AI Platform and Security, Chapter 11, shows the first as an AGENTS.md file, an open and vendor-neutral convention for guiding coding agents (103, AGENTS.md Contributors, n.d.), for Hansa Mutual's claims assistant repository (illustrative).
# AGENTS.md - claims-assistant repository (Hansa Mutual, illustrative)
## What this repository is
The claims assistant: a retrieval-augmented system for claims handlers.
Decision record: decisions/AIDR-0021. Risk class: limited-risk.
## Checks
Run before proposing any change: `make lint test eval-smoke`
## Rules for changes
- Work on a branch and open a pull request; never push to `main`.
- Do not edit files under `decisions/` that have `status: Accepted`.
- Changes to `prompts/`, `rag/` or `gateway/` must add or adjust
evaluation items in `eval/`.
- Never put customer data, credentials or internal hostnames in code,
tests, prompts or commit messages.
## Off limits
- `.github/workflows/`, `policies/` and `CODEOWNERS`: human changes only.
## When unsure
Stop and ask in the pull request. Do not guess at policy or thresholds.
The source states the limit: the file carries instructions, not enforcement. Hansa Mutual pairs it with branch protection on main, approval by the model-risk team through CODEOWNERS for prompts/ and eval/, and a runner policy that gives the agent a repository-scoped token and denies network access by default (3, Nordqvist, 2026). The boundary that matters is the second; the file is guidance. A practitioner who needs a manifest for a coding agent therefore writes the AgentPermissionManifest above for the agent's identity and tools, the containment profile for its runner, and keeps AGENTS.md for the conventions. The vendor settings of Claude Code and Codex are the client-side layer of the same stack (244, Anthropic, n.d.) (245, OpenAI, n.d.).
Across the usage modes
The same artefacts apply in every mode, but the identity under which the AI acts, and so the control that carries the weight, changes. The table follows AI Operations, Chapter 18, and the usage modes of AI Platform and Security, Chapter 2 (10, Nordqvist, 2026).
| Usage mode and typical level | Identity and credentials | What operational text can do | Control that carries the weight |
|---|---|---|---|
| Mode 0 Ambient AI | The provider's; none of the organisation's | Steers or suppresses the provider's alerts and summaries | Treat output as WC-4; independent probe; contractual transparency |
| Mode 2 Embedded workplace assistants (Level 0 Advisory to Level 1 Assisted) | The engineer's own | Steers a draft or discloses what the engineer can read | The engineer's authority; the rule on what may be pasted |
| Mode 3 Agentic work tools | The user's or a sandbox credential | Edits files and runs commands within client permissions | Sandbox, repository protection, scoped token; AGENTS.md guides but does not enforce |
| Mode 4 Built applications (up to Level 2 Supervised) | Its own identity, read-only or proposal-only | A misleading summary a later agent or person acts on | Writer classes; no change credential |
| Mode 5 Autonomous production agents (Level 3 Bounded on catalogued runbooks) | Its own identity, run-scoped tokens | Attempts an action; the blast radius is the mandate | Policy decision point, signed runbooks, corroboration, stop path, ceiling cases |
| Any agent at Level 4 Autonomous | Not available for the prohibited classes | The controls cannot compensate for the absence of a decider | The prohibitions as refusals at the decision point |
The protocols do not change with the mode. MCP and A2A are plumbing, and the mode decides who holds the credentials at the other end.
Labels for the future
It is observable that agents exceed their mandates in documented incidents and that developers have moved controls from the agent's compliance to the environment (6, Nordqvist, 2026). It is expected, on the trend of agents with write access to production, that supervisors under NIS 2 and DORA will ask to see tests of the boundary; DORA Article 9(4), points (c) and (d), requires policies that limit access to what approved functions need and strong authentication, and NIS 2 Article 21(2), points (i) and (j), names access control policies and multi-factor or continuous authentication (197, European Union, 2022) (198, European Union, 2022). Neither mentions agents; the reading, that agent identities belong in the same access-rights register and reviews as human ones, is an architectural implication and not legal advice. Whether today's containment patterns will hold against substantially more capable agents is speculation; the series' design response is to test continuously, which is Chapter 19.
Nordvik Region and Hansa Mutual
Hansa Mutual has four Mode 5 agents, the claims-triage, IT-operations, SOC investigation and evidence-collection agents, each with an identity record, named owner, operators and authority, and rotas that follow the sites; task-scoped tokens were fifteen minutes at first and became five after the first stop drill, and AIDR-0553 retired credentials shared across workloads, with recorded and time-limited exceptions. On 2029-01-23 the policy decision point refused a request from the IT-operations agent HM-OPS-001 to restore a backup over the claims core database, after a ticket summary reached the runbook runner's context as if it were the incident assistant's conclusion; no data changed, and version 1.4.0 of the mandate added the writer classes and the closed classes (6, Nordqvist, 2026) (10, Nordqvist, 2026).
Nordvik Region has no Mode 5 agent, so its work is on the credentials any agent would depend on. An internal audit reported that the infrastructure pipeline's automation account held the administrator role on production with a key unchanged for 26 months; AIDR-0918 removed every standing credential that can change production, the pipeline now gets a ten-minute token per run, and a break-glass route local to the management plane was tested with two named people reaching it in 9 minutes against a target of 15. The Region adopted the call-back rule CBR-NR-BEN-01 for changes to its benefits-triage system, and confines the architect's Mode 3 tool under MND-NR-01 to a sandbox credential scoped to the architecture repository (6, Nordqvist, 2026) (10, Nordqvist, 2026).
Coverage of the slice
Of the 58 entries assigned to this chapter, 47 are treated here. Eleven are listed for reassignment in data/findings/chapter_20.md: the enterprise security Rego and multi-factor identity policy and the hardening of source control and CI (Chapter 5); the prompt injection playbook as code, rebuild from declared state, and the four classes of AI incident with the containment ladder (Chapter 13); the safety-class table, the safety classes for scenarios and the testing authorisation and legal-basis checklist (Chapter 11); the decision-rights table and the decision-rights file (Chapter 18); and the C2PA content credentials (Chapter 23). Appendix A holds every entry.
Summary
The chapter's conclusions are the book's own. First, an agent is a principal: one identity per agent, issued by a broker outside its runtime, short-lived and bound to a task, with a record that names the people who answer for it and a revocation that works within a minute. Second, the permission manifest and the containment profile are two artefacts with two jobs, the agent's declared intent and the platform's commitment, and the profile must hold whether or not the manifest is obeyed. Third, an instruction file for a coding agent, a read-only switch in a tool server and a setting in a client are conventions and conveniences; the control is the permission of the identity behind the server and the policy decision point outside the model. Fourth, the standards that agents rely on, MCP, A2A, Agent Skills, SPIFFE and OAuth token exchange, carry calls and identities; none decides who answers for what the calls do, and each is registered, pinned and bounded by the records of this chapter. Fifth, the operator's AI is Tier 0 because credentials, runbooks, telemetry and the stop path meet there, and its controls are designed for reach and not intent. Sixth, the series' variants of the same artefacts overlap in names and fields, which Chapter 25 records, and the practitioner takes the pair of AI Platform and Security and The Transformed Security Architect as the base pattern.
Sources
- Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
- Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
- Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
- Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
- Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
- Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
- Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
- Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
- Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
- Open Policy Agent. Policy Language. (101, Open Policy Agent, n.d.)
- Agent Skills Contributors. Agent Skills Specification. (102, Agent Skills Contributors, n.d.)
- AGENTS.md Contributors. AGENTS.md: a simple, open format for guiding coding agents. (103, AGENTS.md Contributors, n.d.)
- Anthropic. Model Context Protocol Specification. (104, Anthropic, 2024)
- Model Context Protocol. Security Best Practices. (105, MCP, 2025)
- SPIFFE project. SPIFFE Concepts. (106, SPIFFE project, n.d.)
- SPIFFE Project. Secure Production Identity Framework for Everyone (SPIFFE) specifications and the SPIRE reference implementation. (107, SPIFFE Project, n.d.)
- Jones, M., Nadalin, A., Campbell, B., Bradley, J. OAuth 2.0 Token Exchange. (108, Jones et al., 2020)
- Lodderstedt, T., Richer, J. OAuth 2.0 Rich Authorization Requests. (109, Lodderstedt et al., 2023)
- Google. Announcing the Agent2Agent Protocol (A2A). (110, Google, 2025)
- Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M. OAuth 2.0 Demonstrating Proof of Possession (DPoP). (111, Fett et al., 2023)
- European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (197, European Union, 2022)
- European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (198, European Union, 2022)
- Argo Project Labs. Argo CD MCP Server (mcp-for-argocd): README. (239, Argo Project Labs, n.d.)
- ControlPlane. Flux MCP Server: Transport Modes and Security Configurations. (240, ControlPlane, n.d.)
- controlplaneio-fluxcd. Flux MCP Server command (main.go). (241, controlplaneio-fluxcd, n.d.)
- containers. Kubernetes MCP server (README). (242, containers, n.d.)
- Anthropic. Configure permissions. (244, Anthropic, n.d.)
- OpenAI. Agent approvals & security. (245, OpenAI, n.d.)
- Prodan, S. AI-Assisted GitOps with Flux Operator MCP Server. (246, Prodan, 2025)
- HashiCorp. What is Vault?. (247, HashiCorp (n.d.), n.d.)
- Amazon Web Services. What is AWS Secrets Manager?. (248, AWS, n.d.)
- Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. Careful adoption of agentic AI services. (254, Five Eyes agencies, 2026)