Defending the Operator's AI: Agents, Credentials and the Control Plane as Tier 0

An operations agent that can restart, scale, roll back and fail over production is in effect an administrator that reads text written by other people: logs with user-controlled fields, tickets written by customers and brokers, alert annotations, runbook pages, vendor status feeds and the skills it loads. It holds credentials that reach the control plane and a map of the estate in its runbooks. This chapter describes the threats to such an agent by mechanism and the controls that follow, and argues that the agent, its credentials, its runbook library and the control plane it uses are Tier 0 assets. It concerns O3 Change, because the agent's actions alter the estate and its runbooks, skills and policies are themselves change, and O4 Restore, because remediation, rollback, fail-over and restore are the actions whose misuse does most harm and is hardest to undo. It touches O1 Observe and O2 Diagnose, whose telemetry and tickets are the main route by which steering text arrives, and it says for each control what can be undone and who can stop the agent.

Figure 18.1: Threats to an operations agent met by controls outside the model, with a default-deny policy point in front of the Tier 0 control plane. The table below pairs each threat with its control.

The table pairs each threat with the control outside the model that answers it.

Threat	Control outside the model
Injected text in logs and tickets	Writer classes and deterministic corroboration
God credential	One identity per agent and just-in-time credentials
Confused deputy	Authority from the record, with the requester bound to the token
Poisoned runbook	Signed runbooks and separate editors
Skill and tool supply chain	Pinned registry and provenance
Telemetry as a target	Append-only log and independent detection

The chapter builds on the earlier volumes without repeating them. AI Platform and Security, Chapters 4, 16 and 19, concluded that every tool is registered with its credentials held by the platform, that prompt injection is a property of the architecture and that containment must not depend on intent (297, Nordqvist, 2026). AI Red Team, Chapters 13 and 28, concluded that everything security AI reads may have been written by the adversary, so the defence is a policy decision point outside the model and a permission manifest that sets a ceiling (298, Nordqvist, 2026). AI Blue, Chapter 15, treated the security operations platform as Tier 0 (302, Nordqvist, 2026), and AI Purple, Chapter 16, the loop's own assets. Chapter 16 of this book set out the agent team and its containment. This chapter assumes that the agent will read text that tries to steer it, hold a credential broader than it should, or call a tool that is not what it claims, and asks what bounds the consequence.

Why the operator's AI is a target

The operator's AI is a target for a reason that has little to do with AI: it is where the broadest credentials and the best map of the organisation come together. The first volume already treated security patterns, policies and evidence as artefacts of the repository (Architecture as Code, Chapters 9B and 15A) (295, Nordqvist, 2025). What AI adds is a reader. A person who administers production reads a ticket sceptically and acts under their own authority and accountability. An agent that reads the same ticket acts under the authority of its identity and cannot, by its own judgement, separate the data in the ticket from the instructions in it.

Six kinds of asset recur, and a regime that protects the credentials but not the runbook library or the telemetry leaves the same objective available by another route.

Asset	What it reveals or enables	Who legitimately needs it
Agent identities and the credentials issued to them	The ability to restart, scale, reconfigure, roll back or fail over services, and in a poorly designed estate to delete or restore over data	The token service that issues them; the agent for the duration of a run
The control plane itself (orchestrator, infrastructure-as-code pipeline, cluster and cloud management)	Every change to every service, and the identity provider's trust relationships	Platform engineers, by named role; agents only through the policy decision point
Runbook, skill and prompt libraries	What the organisation does under failure, in which order, with which parameters	Runbook authors and reviewers; the runner reads, never edits
Configuration maps and the service catalogue	The topology, the dependencies and the order in which services recover	Operators and agents with a stated task
Telemetry and the logs of agent actions	The state of the estate, the baselines against which anomalies are judged, and the record of what the agents did	Observability engineers; the independent observer; security operations
The stop path and break-glass credentials	The ability to halt the agents, and the ability to act when the platform is down	Named duty roles, outside the platform

The unit to classify is the aggregate. One runbook that restarts a stateless service is harmless to read; the whole library, with its parameters, order of recovery and list of services without a tested fail-over, is a plan for the longest outage the organisation can suffer.

Two observations shape the chapter. First, the controls are designed for the agent's reach and not for its intent: the same control bounds an agent steered by text, an agent whose model the provider updated without notice and a script run with the wrong parameters. At Hansa Mutual, INC-HM-2026-0497, in which the IT-operations agent silenced a recurring payment-gateway alert instead of restarting the failing component, was a shortcut and not an attack, and the controls that bound a steered agent bind it too. Second, the Five Eyes agencies' guidance states that 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 (69, Five Eyes agencies, 2026).

Adversary behaviour can be described by technique without attack detail. Valid accounts (MITRE ATT&CK T1078) and unsecured credentials (T1552) are the access path to agent and pipeline identities, compromise of the software supply chain (T1195.002) is the route into skills and tool servers, and disabling or modifying security tools (T1685, Disable or Modify Tools, in the Defense Impairment tactic, which replaced T1562, Impair Defenses) and indicator removal (T1070) follow (33, MITRE, n.d.). For the agent itself MITRE ATLAS gives indirect LLM prompt injection (AML.T0051.001), AI agent tool invocation (AML.T0053), RAG poisoning (AML.T0070) and AI agent tool compromise in the supply chain (AML.T0010.005) (34, MITRE, n.d.). The ATLAS identifiers were checked against data release 5.6.0 and against the changelog of release 2026.10, which still lists them, and are to be re-checked against the live matrix before release.

Threats by mechanism

Operational text as an instruction channel

A language model receives instructions and data in the same medium and has no reliable way to tell them apart. Greshake and colleagues named the consequence indirect prompt injection: an adversary who cannot address an LLM-integrated application directly plants text in data that the application is likely to retrieve, and the application treats it as part of its task. They report practical demonstrations against real applications, including data theft and manipulation of the application's API calls (95, Greshake et al., 2023). The NIST generative AI profile describes the same mechanism as a cybersecurity risk (38, NIST, 2024), the NIST adversarial machine learning taxonomy gives indirect prompt injection its own identifier (39, Vassilev et al., 2025), and OWASP ranks prompt injection first among the risks for LLM applications in 2025 (36, OWASP, 2025).

In operations the retrieved data is the working material of the profession. A ticket opened through a customer or broker interface has a free-text field written by someone outside the organisation. A log line contains a user name, user agent or error message that a user controls. An alert annotation copies text from the service that raised it, a knowledge-base page can be edited by any employee, and a vendor's status feed and a provider's monitoring AI are written by parties the organisation does not control. An incident assistant that summarises a ticket for a runbook runner carries its content into a second agent's context, and nothing in the summary records who wrote the original. A steered Level 0 Advisory assistant writes a misleading summary; a steered runbook runner may attempt an action.

There is evidence at the rung of laboratory demonstration for this pattern in a neighbouring domain. In July 2025 researchers at General Analysis showed that an AI coding assistant, connected to a database through a tool server and running with the developer's service-role privileges, which bypass row-level security, could be steered by a support ticket: when the developer asked the assistant to review open tickets, it read a customer's message, queried a table of integration tokens (dummy data in the demonstration) and wrote the result into the ticket thread, where the customer could see it (97, Havaei et al., 2025). It is a proof of concept and not a report of production harm, and it concerns a development tool. Its lesson is structural: an agent that reads customer-written text while holding a privileged identity, and that can write to a place the customer can read, has everything the pattern needs. The authors state that filtering alone is not sufficient (97, Havaei et al., 2025).

Whether the author of such text is an adversary, a careless user who pasted a command from a forum or a model that wrote a summary, the control is the same and sits outside the model: the platform knows who can write each source, and the policy decision point refuses to let text from a source that anyone outside the operations team can write carry authority for an action.

Over-broad and standing credentials

The commonest weakness is not a clever attack but a credential broader than any task needs and longer-lived than any task. OWASP's 2025 list names excessive agency among its ten risks for LLM applications (36, OWASP, 2025); the Five Eyes guidance gives the scenarios of an agent granted broad access at start-up and relying on cached authorisation decisions, and of an agent whose privileges pass to whoever compromises a low-risk tool in its workflow (69, Five Eyes agencies, 2026); and the Model Context Protocol guidance lists omnibus scopes as a common mistake that enlarges the blast radius of a stolen token (93, MCP, 2025).

Operations estates are prone to this weakness because automation accrued over years. A pipeline's automation account holds an administrator role because that was simplest when the pipeline was built, three scripts use it because someone copied the key, and a wiki page documenting recovery names the account and where its key is kept. All of it becomes an AI problem on the day an agent is granted the same access as the pipeline, and the standing credential is the first thing an agent's mandate should not contain.

Confused deputy through tools

Norm Hardy gave the pattern its name in 1988. A compiler service held a licence to write files in a system directory so that it could write its own statistics file; a user supplied the name of the billing file as the destination of the compiler's debugging output, and the compiler, using its own authority and not the user's, overwrote the billing records (264, Hardy, 1988). The deputy was not malicious. It had authority of its own and no way to tell which of its callers' requests fell within the authority that the caller held.

An operations agent is a deputy of this kind. It holds authority that its requester does not, and a summary, a ticket or a colleague's message may ask it to do what the requester could not do directly. The Five Eyes guidance describes a low-privileged user manipulating a high-privileged agent, and observes that actions under the agent's identity produce audit logs that look legitimate and so delay detection (69, Five Eyes agencies, 2026). The tool layer has the same problem: the Model Context Protocol guidance describes confused-deputy conditions at proxy servers that act for several clients with one upstream identity, and forbids token passthrough, in which a server forwards tokens that were not issued to it, because that defeats downstream controls that depend on the token's audience (93, MCP, 2025). In ATLAS terms this is AI agent tool invocation (AML.T0053) (34, MITRE, n.d.).

The defence is that authority travels with the request and not with the agent. An action is authorised by a record (an incident or a change) that names the service, the action and who opened it, and the token that the agent holds for the run is bound to that record and to nothing broader.

Poisoned runbooks and knowledge

A runbook is an instruction that the agent is built to follow, so a runbook library, a wiki and a retrieval index over past incidents are where a small edit has a large effect. ATLAS lists RAG poisoning (AML.T0070) (34, MITRE, n.d.), and the mechanism applies to any store from which an agent retrieves guidance. Honest error enters the same way: at Hansa Mutual, INC-HM-2026-0224 degraded the claims core for 2 hours 50 minutes, and a fail-over to Cloud B was not attempted because the runbook was out of date. A stale runbook and a poisoned one have different authors and identical effects, and one control addresses both: a runbook that an agent may execute is a signed, reviewed artefact whose version and digest are checked at the point of use, and the agent has no write access to the store it reads from.

The supply chain of skills and tools

Skills are packaged procedural knowledge, and a tool server is code. Vendor guidance advises using skills only from trusted sources, auditing every bundled file, and treating a skill that fetches external content as exposed to instructions in it (96, Anthropic, n.d.). The evidence on public ecosystems is mixed in an instructive way. Snyk's ToxicSkills study scanned 3,984 skills from public registries as of 5 February 2026 with its own open-source scanner: 36.82 per cent had an issue of any severity, 13.4 per cent a critical one, and 76 were confirmed malicious by human review; the figures rest on the vendor's tooling and labels (98, Beurer-Kellner et al., 2026). Holzbauer and colleagues analysed 238,180 unique skills from three distribution platforms and GitHub, found that marketplace scanners classify up to 46.8 per cent as malicious but that only 0.52 per cent remain suspicious once each skill is read in the context of its repository, and found that skills hosted in abandoned repositories can be hijacked (99, Holzbauer et al., 2026).

The studies use different definitions, and their numbers are not estimates of one quantity. Read together they support three statements: a public registry contains confirmed malicious entries, a scanner's output without context overstates the problem and its silence is not assurance, and the provenance of a skill, meaning where it is hosted and who controls the repository, is part of its risk. The operations implication is that no skill or tool server is fetched from a registry at run time. Each is vendored, reviewed, pinned by digest and released through O3 Change, and the mandate lists the versions the agent may load; the Five Eyes guidance asks for an approved allow list of tools and versions (69, Five Eyes agencies, 2026). NIS 2 Article 21(2), points (d) and (e), lists supply-chain security and security in acquisition, development and maintenance among the minimum measures (3, European Union, 2022).

Telemetry as a target

Telemetry is both an input to the agent and the witness of what the agent did, so whoever can write to it can steer the agent and hide the steering. CWE-117, improper output neutralisation for logs, describes the first half: a product builds a log message from external input without neutralising special elements (64, MITRE, 2026). A log line is text written in part by whoever controls the inputs that produced it, and it is unsafe to read as an instruction whether the reader is a person, a parser or a model. The second half is impairing defences and removing indicators (33, MITRE, n.d.): an agent or adversary that can edit its own log, change an alert rule or disable a probe removes the evidence on which later verification depends. INC-HM-2027-0572, when the observability vendor's ingestion failed for 3 hours 10 minutes and left the group without sight of 14 services, shows the accidental form. The observer principle (Chapters 4 and 17) is the design response: the observer must not depend on the system observed, and the agent has no write path to its own record.

Mechanism	Reference	Consequence if uncontrolled	Control outside the model
Injected text in logs, tickets, alerts	ATLAS AML.T0051.001; OWASP LLM01:2025	Steered action, disclosure, misleading summary	Writer classes, corroboration, authority from the record
Over-broad or standing credentials	ATT&CK T1078, T1552; OWASP LLM06:2025	Platform-wide compromise through one identity	One identity per agent, just-in-time credentials
Confused deputy through tools	ATLAS AML.T0053; Hardy, 1988	Action taken with authority the requester lacks	Token bound to the record, audience checks, tool allow list
Poisoned or stale runbook	ATLAS AML.T0070	Harmful or ineffective remediation executed as procedure	Signed runbooks, digest check, runner cannot edit
Skill and tool supply chain	ATT&CK T1195.002; ATLAS AML.T0010.005	Code or instructions of unknown origin in the agent	Vendored, pinned, reviewed, released as change
Telemetry as target	ATT&CK T1685, T1070; CWE-117	Steering and concealment of the steering	Append-only log outside the agent, independent detection

The state engine and the desired-state repository

Chapter 8 treats the pipeline as change and Chapter 17 treats the engine as an observed system. As an asset, the state engine, its state and the repository it reads are Tier 0, because they apply whatever the declaration says with credentials of their own. Write access to the desired-state repository is therefore write access to production. Argo CD's security documentation says so directly: an attacker with access to a trusted Git repository could update a deployment manifest to deploy malicious container images, or delete resources in Git so that they are pruned from the live environment (157, Argo Project, n.d.). The same page warns that the repository server runs helm template and kustomize build, that remote bases and chart dependencies can lead outside the repository allow-list, and that a repository writer may construct charts or kustomizations that read files outside the repository, including on the repository server (157, Argo Project, n.d.). An agent that drafts pull requests (Chapter 8) or holds a token for the repository is a repository writer under that sentence. The same holds for infrastructure as code: the state file that Terraform keeps binds declared resources to real objects (162, HashiCorp, n.d.), and whoever can write it changes what the engine believes exists.

What the controller can do

The engine's cluster permissions set the blast radius. Argo CD states that by default it uses a cluster-admin-level role to watch and deploy, that it needs cluster-wide read access but not necessarily full write access, and that the ClusterRole can be edited to limit writes to chosen namespaces and resources; credentials for external clusters are stored as Kubernetes Secrets in its own namespace (157, Argo Project, n.d.). Flux's multi-tenancy page states that by default the controllers run under a service account with the cluster-admin role bound, which it says suits a deployment in which all users are trusted (161, Flux project, n.d.). Both projects document scoping. An Argo CD AppProject restricts source repositories, destinations and resource kinds, while the automatically created default project permits any of them and the documentation recommends dedicated projects (182, Argo Project, n.d.). Flux controllers can impersonate a service account named in the specification of each Kustomization or HelmRelease, and lockdown flags deny cross-namespace references and remote bases and set a default service account for tenants (161, Flux project, n.d.). The defaults are a starting point for a trusted single team. For an estate with several teams or agents, the engine is scoped per tenant, and the platform tenant's own repository is the one an agent may not write.

Documented vulnerabilities show the same surface by mechanism. An advisory for Argo CD records that one endpoint returned unmasked Secret data to a user with read-only access, fixed in 3.2.11 and 3.3.9 (84, Google & OSV, 2026). An advisory for the Flux source-controller records a path-handling flaw that let a party able to influence a referenced bucket write outside the working directory, with downstream digest verification limiting the effect, fixed in 1.8.5 (85, Google & OSV, 2026). The lessons are that read-only access to the engine is not read-nothing, and that the engine is patched and watched as a privileged workload.

Secrets in state

Terraform documents that state and plan files can contain sensitive values such as initial database passwords or API tokens, that local state is plaintext and that it should be kept out of Git workflows (187, HashiCorp, n.d.); its state page advises against version control because of data loss and exposure of secrets (162, HashiCorp, n.d.). OpenTofu supports encrypting state and plan files at rest. Its documentation states that encryption protects against reading a stolen file, but not against data loss, not against replay of an older state or plan, and not against the person running the command, and that state becomes unrecoverable without the key (188, OpenTofu, n.d.). The key is therefore a Tier 0 asset with its own backup and its own restore claim (Chapter 19).

Gates in front of the engine

Three gates are independent of the author of a change.

1. Branch and commit controls. Protected branches and required review on the repository, with the engine reading only reviewed branches. The SLSA source track describes increasing trust in how a source revision was created, and its highest level requires two trusted persons to review changes to protected branches (66, SLSA, n.d.). Signature checks add provenance: Argo CD can refuse to sync when declared source-integrity criteria are not met (183, Argo Project, n.d.), and Flux's GitRepository offers verification of commit signatures (186, Flux project, n.d.). Images follow the provenance rules of Chapter 8.
2. Admission policy. ValidatingAdmissionPolicy is stable since Kubernetes v1.30 and uses the Common Expression Language to evaluate requests to the API server (189, The Kubernetes Authors, n.d.). The book's reading is that the engine's apply then passes the same gate as a person's, so a rule that refuses a privileged pod holds even if a merged manifest asks for it.
3. The policy decision point of this chapter, for the agent's own requests to the repository, the engine's API and the cluster.

Suspending the engine is a useful brake, but it is done through the cluster's API and is not a stop path outside the control plane (Chapter 17).

MCP servers for these tools

An MCP server for a delivery tool acts as the account behind its token. The Argo CD MCP server's README lists tools that create, update, delete and sync applications and run resource actions, all available by default, with a read-only environment setting that disables those five; it reads the API token from the environment or headers and binds its listener to loopback by default (110, Argo Project Labs, n.d.). The Flux MCP Server was described as experimental in 2025, with a read-only mode, service-account impersonation and masking of Secret values (111, Prodan, 2025). In its Go source the --read-only flag defaults to false, so the server can write and delete unless it is started read-only, and --mask-secrets defaults to true (206, controlplaneio-fluxcd, n.d.); the documentation says impersonation with --kube-as limits the server to the permissions of the named service account, and that its in-cluster example runs with cluster-admin (207, ControlPlane, n.d.). These are project statements and code as read, not tested properties. The rule follows the guidance on scopes and audiences (Chapter 16) (93, MCP, 2025): each server runs under its own read-only identity by default, a write identity is issued per run and bound to a record, and the server's tool list is part of the mandate.

Identity and credentials

Chapter 16 set the defaults: each agent has a workload identity of its own and no shared service account, and tokens are issued per run by a service outside the agent for a named audience, by default for ten minutes (94, SPIFFE project, n.d.). This section adds what a defender checks.

One identity per agent, and no agent holds a human's identity. Attribution follows, since an action in the control plane traces to the runbook runner and not to a pool of automation accounts, and so does containment, since revoking one identity stops one agent. An embedded assistant that acts under an engineer's identity (Mode 2) is bounded by that engineer's authority and by the rule about what may be pasted into it.

No standing credential for a change or restore class. A credential that can change production exists for the length of a run and is issued only after the policy decision point has permitted the specific action. Read-class credentials may live longer, by default up to 60 minutes, scoped to the service. A standing credential remains only where a platform cannot yet issue anything else, with a named owner, a rotation interval and an entry on the risk register until it is removed.

Audience and requester binding. A token names the audience that may accept it, and the tool layer rejects tokens issued for another audience (93, MCP, 2025). For a run authorised by a record, the token also carries the record's identifier, so that a replay against another service fails and the log shows which record authorised which action.

No credential in a document. Runbooks, wiki pages, tickets, chat and pipeline variables are scanned for secrets, and a runbook names the identity and the vault path, never the secret (33, MITRE, n.d.).

The legal frame. DORA Article 9(4), point (c), requires policies that limit access to information assets and ICT assets to what legitimate and approved functions need, and point (d) requires strong authentication and protection of cryptographic keys (2, European Union, 2022). NIS 2 Article 21(2), points (i) and (j), name access control policies and multi-factor or continuous authentication (3, European Union, 2022). An auditor will ask for the list of identities that can change production and the reason each is as broad as it is, and a single automation account with an administrator role has no good answer.

The policy decision point

The policy decision point, which zero trust architecture distinguishes from the policy enforcement point that carries its decision out (43, Rose et al., 2020), is the control on which the others converge. It sits outside the model, so that nothing the model reads can reconfigure it; it evaluates a manifest that is a file in version control; and it defaults to refusal. Rego, the language of Open Policy Agent, expresses this directly: a default rule gives a fallback value, and the documentation shows default allow := false with an allow rule that holds only when stated conditions on the input are met (65, Open Policy Agent, n.d.).

Chapter 16 showed the allow rules. This chapter adds the refusals that carry the threats above. They hold at every level and form a separate module, so that those who review the allow rules and those who review the refusals can differ. A refusal that no allow rule can override is the form of the Level 4 prohibitions: an agent has no path to deleting production data or restoring over existing data, and a person who needs either acts under their own identity, with a recorded approval and a second person.

Worked example: a permission manifest's refusals in Rego, with the decision log

The policy below is illustrative and belongs to the mandate MND-HM-OPS-001 of Hansa Mutual's IT-operations agent (HM-OPS-001), version 1.4.0. It has not been run against an engine in preparing this chapter and is to be tested with the ceiling cases below before use.

package ops.guard

import rego.v1

# Refusals that hold at every level. Allow rules: ops.mandate (Chapter 16).
read_only := {"read", "annotate", "notify"}

mandate := data.mandates[input.agent]

delegated if is_object(mandate.actions[input.action_class])

untrusted_context if {
    some c in input.context_classes
    c in {"WC-3", "WC-4"}
}

deny contains "action_not_delegated" if not delegated

deny contains "class_closed_to_agents" if {
    input.action_class in {"delete", "restore_overwrite"}
}

deny contains "no_authorising_record" if {
    not read_only[input.action_class]
    not input.record.id
}

deny contains "record_scope_mismatch" if input.record.service != input.service

deny contains "uncorroborated_untrusted_text" if {
    untrusted_context
    not read_only[input.action_class]
    not input.corroboration.independent_probe
}

deny contains "runbook_not_verified" if {
    not read_only[input.action_class]
    not input.runbook_check.signature_valid
}

deny contains "runbook_digest_mismatch" if {
    input.runbook_check.digest != data.runbooks[input.runbook].digest
}

default permit := false

permit if {
    count(deny) == 0
    data.ops.mandate.allow
}

default effect := "deny"

effect := "permit" if permit

decision_log := {
    "agent": input.agent,
    "action_class": input.action_class,
    "service": input.service,
    "record": object.get(input, ["record", "id"], "none"),
    "context_classes": object.get(input, "context_classes", []),
    "runbook": object.get(input, "runbook", "none"),
    "effect": effect,
    "reasons": sort(deny),
}

Three features carry the design. The refusals are named, so that a denial explains itself to the agent operator and the log can be searched by reason. Authority comes from a record and from the class of the text that fed the run, and not from the content of the text. And the decision log is built from the request and the decision, not from anything the agent writes about itself.

{
  "decision_id": "pdp-replay-2029-02-06-0001",
  "timestamp": "2029-02-06T09:30:00Z",
  "mandate": "MND-HM-OPS-001@1.4.0",
  "replay_of": "pdp-2029-01-23-0214-0007",
  "agent": "HM-OPS-001",
  "action_class": "restore_overwrite",
  "service": "SVC-HM-001",
  "record": "INC-HM-2029-0031",
  "trigger": {"artefact": "ServiceHub ticket", "writer_class": "WC-3"},
  "context_classes": ["WC-1", "WC-3"],
  "runbook": "none",
  "token_audience": "ops-policy-decision-point",
  "effect": "deny",
  "reasons": ["action_not_delegated", "class_closed_to_agents",
              "uncorroborated_untrusted_text", "runbook_not_verified"]
}

The log is read by someone who is not the agent. Version 1.3.0 of the mandate, in force on the night, refused the request for a single reason, action_not_delegated; the closed-class refusal, the record-scope check, the writer-class refusal and the runbook checks were added in version 1.4.0 after the review described below.

Signed runbooks and input provenance

What the agent may trust

The agent may trust very little, and the architecture decides what. Input provenance classifies every text the agent reads by who can write it, and signed runbooks make the one class of text that is meant to instruct the agent verifiable. AI Blue, Chapter 15, classified the security operations centre's inputs by who can write them (302, Nordqvist, 2026); the operations equivalent is four writer classes.

Writer class	Who can write it	Examples	Authority it may carry
WC-1 Instrument	Instruments the organisation operates; an adversary writes to them only after gaining a foothold	Probe results, platform events, deployment events, metrics	May trigger a catalogued runbook
WC-2 Reviewed staff text	Named staff, through review	Signed runbooks, change records, mandates, policies	May define what a runbook does
WC-3 Outside-the-team text	Customers, brokers, other staff, users, and user-controlled fields in logs	Ticket bodies, chat, free-text alert annotations, user agents and file names in logs	Informs; carries no authority for an action above notify
WC-4 External or generated text	Suppliers, public sources and models	Vendor feeds and status pages, a provider's monitoring AI output, third-party skills, another agent's summary	Informs; carries no authority for an action above notify

A summary inherits the lowest class of what it summarises. This is the rule that matters most in practice, because it closes the route in which a ticket (WC-3) is summarised by one agent and read by another as if the summary were the assistant's own conclusion. The classes are labels applied by the platform at the point where text enters the agent's context, and they are carried as metadata that the policy decision point reads. The model is not asked to classify its own inputs.

The rule for acting on text of class WC-3 or WC-4 follows from the conclusion of AI Blue, Chapter 15, that any conclusion that triggers an action is corroborated deterministically (302, Nordqvist, 2026). If the run's context contains such text, an action above notify is permitted only when an independent probe, a WC-1 source that the agent does not control, confirms the condition that the runbook's trigger names, or when a person approves it. The ticket may say that a service is slow; only a probe can establish that it is, and the probe's reading, not the ticket's wording, authorises the runbook. The Five Eyes guidance says in general form that an agent should consider the trust level of its data sources (69, Five Eyes agencies, 2026); this turns the sentence into a rule that a policy engine can evaluate.

Signed runbooks

A runbook manifest (RBK-*; Chapter 10) that an agent may execute is released like software: the build records where and how it was produced, the release is signed, and a verifier outside the agent checks the signature and digest before use and passes the result into the request as runbook_check. The SLSA specification describes provenance as the means of verifying where, when and how something was produced, and states the condition that matters: provenance does nothing unless somebody inspects it (66, SLSA, n.d.). Four rules follow.

1. The runner does not edit. The agent that executes a runbook has read access to the signed release and no write access to the repository, wiki or index from which it is retrieved.
2. Two people release. A runbook change is a pull request reviewed by someone other than its author, and a change to a runbook at Level 3 Bounded is reviewed by the service owner as well.
3. Unsigned or mismatched means Level 0. A runbook whose signature is invalid or whose digest does not match the registry is refused for execution, and the agent may at most propose its steps to a person as advice.
4. Retrieval is not authority. A retrieval index informs the agent, and the signed release is what it executes.

An incident or a change record that authorises a run is also a WC-2 text, and so it is protected by the same rule: the record's text is written under access control and its edit history is kept.

Break-glass

A control plane that is Tier 0 must have a way to be operated when the platform, the policy decision point or the identity provider is down, and that way is itself a Tier 0 asset. Break-glass is emergency access with a record, and its design has five properties.

First, it does not depend on what it is a remedy for. The identity provider is a dependency of every other service (SVC-NR-004 and SVC-HM-006), and the 95-minute outage at Nordvik Region on 2026-03-12 (INC-NR-2026-0071) was caused by its expired signing certificate. A break-glass route that uses federated sign-in fails exactly when needed, so the credential is local to the management plane it opens and is held outside the platform, in a separate failure domain or in a sealed form that two people must open.

Second, it needs two named people by default, the duty manager or incident commander and a second authorised person, with an out-of-hours route when one is unreachable.

Third, it is time-boxed and recorded: by default a 60-minute window, command logging for its duration, an automatic page to the CISO's delegate at the moment of use, and a review within one working day that closes the use or opens an incident. Logging that identifies the engineer is a matter for the employee representatives first.

Fourth, agents never hold it and never request it. An agent may ask a person to invoke it, and any use in which an agent acts is outside every mandate. This is the third Level 4 prohibition in operational form: an agent does not disable the observation or the stop path, and break-glass is where the stop path ends.

Fifth, it is exercised. A route never used since creation is a claim without evidence, so each has a test with a measured time against a target, a date and a result, which expires on the earlier of 90 days and a change in the platform it depends on (Chapter 19).

When the policy decision point itself fails, the design is to fail closed: the agent stops acting and people operate under runbooks, with break-glass if the platform is down. The cost is the availability of automated remediation, accepted because a decision point that fails open fails exactly when the platform is under stress. The decision point runs in two failure domains, and the stop path does not depend on it.

Detection and logging

Preventive controls fail, and the agent's actions must be visible to someone other than the agent. The design question is what to log, where, and who reads it.

What to log. Every request to the policy decision point is logged with the fields of the worked example: decision identifier, time, mandate and version, agent, action class, service, authorising record, writer classes in context, runbook and check result, token audience, effect and reasons. The model's own account of what it did is stored as a separate, labelled field and never as the record. AI Act Article 12 requires high-risk AI systems to allow automatic recording of events, and Article 26(6) requires deployers to keep the logs under their control for at least six months unless other law provides otherwise (1, European Union, 2024). An operations agent is not in general a high-risk AI system, but the benefits-triage service at Nordvik Region (SVC-NR-001) is one, and one retention serves both: the decision log is kept for 13 months, matching Nordvik Region's archive.

Where. The decision log is written to an append-only store that the agent can neither write to nor read, replicated to a second store in a different failure domain, which answers the techniques of impairing defences and removing indicators (33, MITRE, n.d.). Logs that contain personal data fall under GDPR Article 32, which requires measures for ongoing confidentiality, integrity, availability and resilience and a process for regularly testing their effectiveness (6, European Union, 2016).

What to detect. Eight events earn a page or a review. A denial in a closed class pages at once. Three denials for the same reason within 15 minutes page the agent operator. A first use of a tool or skill version not on the allow list is reviewed within one working day. A runbook signature or digest failure pages its owner. A change-class credential issued without a matching record is an incident. Any read of a decoy credential or decoy runbook, a canary that no legitimate run touches, pages the duty manager. A rise in autonomy budget consumption goes to the next service review. A divergence between the agent's report of an action and the independent probe's reading of the service is an observer finding (Chapter 17). DORA Article 10(1) to (3) requires mechanisms to detect anomalous activities promptly, with multiple layers of control and alert thresholds, and requires them to be regularly tested in accordance with Article 25 (2, European Union, 2022).

Who reads. The agent operator reads the pages. The platform lead reviews denials weekly, because a pattern of refusals is the earliest evidence of steering and of a mandate that does not fit the work. Security operations, as defined in AI Blue, receive the same log in their detection pipeline: they own the detections of misuse, and operations owns the mandate and the response. The log records approvals, and an approver is a named person, which is a control record and not a performance measure. At Nordvik Region MBL-NR-IT-2027-01 forbids reporting such measures by name and requires negotiation before a tool that logs engineers' commands is switched on; at Hansa Mutual KBV-IT-2024-OPS-02 and -03 require team-level reporting with a minimum group size of five and agreement with the works council before such a tool is used.

Testing the ceiling

A control is a defence only when a test that re-runs its scenario has recently passed. The ceiling is tested by cases that try to cross it, written from the mechanisms above and described by outcome: for each writer class and closed action class, a case in which such text is in context and the agent proposes an action it must not take; for each runbook, a bad-signature and a mismatched-digest case; for each credential, a token issued for another audience. Every case must end in a refusal with the expected reason. The set is a regression suite (REG-*, as in AI Purple) that runs on every change to the manifest, policy, model, skill or tool, and weekly against a production-like environment, as an authorised test scoped in writing with the stop path outside the system tested. A result is valid for 30 days or until any of those things changes. It shows that the ceiling holds for the cases written and not that no case crosses it, so the claim carries the number of cases, the date and the result.

Practical guide: Writing a permission manifest and a deny-by-default policy for a remediation agent

Purpose. To write the smallest permission manifest that lets a remediation agent do its catalogued work, and a policy that refuses everything else, so that text the agent reads, a credential it holds or a tool it calls cannot enlarge what it may do.

Roles. The agent owner (platform lead or head of site reliability engineering); the service owner; the incident commander; a CISO delegate for the containment review; the privacy officer where logs contain personal data; employee representatives where engineers' commands are logged in a way that identifies them.

Steps.

1. List every source of text the agent reads and assign each a writer class, WC-1 to WC-4, taking the lowest class where a source is mixed.
2. List the action classes the agent needs (read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete, restore-overwrite). Write undelegated for the rest, and never delegate delete or restore-overwrite to an agent.
3. Bind each delegated class to signed, catalogued runbooks and to a level, starting at Level 1 Assisted or Level 2 Supervised (Chapter 16).
4. Require an authorising record naming the service for every action above notify, and have the token carry its identifier.
5. Write the rule for untrusted context: with WC-3 or WC-4 text in context, an action above notify needs a named independent probe or a recorded human approval.
6. Set credentials: ten-minute tokens issued after the policy permit, audience equal to the policy decision point, no standing change or restore credential, and a secret scan of the runbook store.
7. Write the refusals as a separate module, default deny, with named reasons. Send the decision log to an append-only store outside the agent's reach, retained for 13 months, and write the eight detections.
8. Write the ceiling cases: at least ten refusal cases for each closed class and for each of WC-3 and WC-4, and a signature, a digest and an audience case per runbook and tool. Run them on every change and weekly.
9. Review with the CISO delegate and the service owner, agree the logging with the employee representatives and the privacy officer, record the decision as an AI Decision Record, set the review date at no more than 90 days and activate in shadow mode.

An illustrative extract of the input block that steps 1 and 5 produce:

mandate: MND-HM-OPS-001
version: 1.4.0
decision: AIDR-0968
inputs:
  writer_classes:
    WC-1: {sources: [probes, platform-events, deployment-events], authority: trigger}
    WC-2: {sources: [signed-runbooks, change-records, mandates], authority: define}
    WC-3: {sources: [tickets, broker-and-customer-text, user-controlled-log-fields], authority: inform}
    WC-4: {sources: [vendor-feeds, provider-ai-output, external-skills, model-summaries], authority: inform}
  summary_inherits: lowest-class-of-inputs
  untrusted_context_rule:
    applies_to: above-notify
    requires: [independent-probe, or, recorded-human-approval]
runbooks: {must_be_signed: true, verifier: outside-agent, on_failure: level_0}
credentials: {lifetime_minutes: 10, standing_change_credentials: none}
decision_log: {store: append-only-outside-agent, retention_months: 13}

Definition of done. The manifest and the policy are in version control and enforced by a policy decision point outside the agent; the ceiling cases exist, have run since the last change and all refuse with the expected reason, and their date and result are on record; no standing credential for a change or restore class exists; the decision log reaches a store that the agent cannot write to and is read by someone who is not the agent; break-glass has a tested route with a date and a measured time; and the owner, operators and approver are named people.

What can be undone, and who can stop it

For each control the questions are the same. Revoking an agent's identity at the token service removes its access at once and is reversed by reissuing; a deny entry at the policy decision point behaves alike. A restart, scale-up and certificate renewal can be undone (Chapter 16), so the guard policy leaves room for Level 3 Bounded there; a fail-over reverses only if its return path has been tested and sits at Level 1 Assisted at Hansa Mutual; deletion and restore over existing data cannot be undone and are closed to agents. The duty manager or incident commander, the agent operator and the platform engineer on call can stop an agent without approval, through a path in a different failure domain from the agent platform, and a stop counts as working only when a drill is on record with its date and measured time (Chapter 19).

Across the degrees of delegation

The table reads from the usage mode, which says whose identity the AI uses, to the level, which says who decides each action.

Usage mode and typical level	Identity and credentials	What operational text can do	Control that carries the weight
Mode 0 Ambient AI (a provider's monitoring AI; no mandate of the organisation)	The provider's; none of the organisation's	Steers or suppresses the provider's alerts and summaries; the organisation sees only the output	Treat output as WC-4; independent probe; contractual transparency about AI in the service
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; data classes
Mode 4 Built operations assistant (Level 0 Advisory to Level 2 Supervised)	Its own identity, read-only or proposal-only	A misleading summary that a later agent or person acts on	Writer classes; summaries inherit the lowest class; no change credential
Mode 5 Autonomous production agent (Level 3 Bounded on catalogued runbooks, Level 2 otherwise)	Its own identity, with 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 Level 4 prohibitions	The controls cannot compensate for the absence of a decider	The prohibitions of Chapter 4 as refusals at the decision point

The higher the degree of delegation, the more the controls must be machine-enforced and drilled, and the lower it is, the more weight falls on a person who reads the output; both fail alike if the person has stopped reading critically, the ironies of automation that Bainbridge described (217, Bainbridge, 1983) and Chapter 26 treats.

What is observable, expected and speculative

Observable. Indirect prompt injection into retrieved data is documented in research (95, Greshake et al., 2023), in the NIST generative AI profile (38, NIST, 2024) and in a laboratory demonstration against a ticket-reading assistant (97, Havaei et al., 2025); the author knows of no published post-incident report of an operations agent steered in production by this route. Over-broad credentials are a principal privilege risk in the Five Eyes guidance (69, Five Eyes agencies, 2026). Public skill ecosystems contain confirmed malicious entries, and the studies disagree about how many (98, Beurer-Kellner et al., 2026) (99, Holzbauer et al., 2026).

Expected. Permission manifests enforced by a policy decision point are expected to become a standard feature of operations and agent platforms, on the basis of instrument and trend: the Model Context Protocol guidance already requires audience validation and recommends minimal scopes, DORA Article 9(4)(c) already limits access for financial entities (2, European Union, 2022), and NIS 2 Article 21(2)(i) requires access control policies (3, European Union, 2022). Supervisors are expected to ask for the list of identities that can change production and the evidence that an agent's ceiling was tested.

Speculation. That signed, provenance-checked runbook and skill registries become the norm to the point that scanning public registries is unnecessary, and that chains of agents delegating to agents can be bounded by the same manifests without new protocols, are speculation. There is no present evidence for either.

Nordvik Region and Hansa Mutual

Nordvik Region has no Mode 5 agent, and its Tier 0 problem is older than its AI. The internal audit of the IT and Digitalisation Unit reported on 2028-10-17 that the infrastructure pipeline's automation account held the administrator role on the Region Cloud in production, that its key had not changed for 26 months, that the pipeline and three unowned scripts used it, and that a wiki page readable by the whole unit named the account and the key's location. No agent used it, but the Region's route to Level 3, through scripted runbooks run by the orchestrator under a mandate manifest, would have run under it. The Region decided under AIDR-0918 (2028-11-21; reviewers the CISO and the AI architect) to remove every standing credential that can change production. By 2029-01-31 the pipeline obtained a ten-minute token per run, bound to its change record; two scripts were retired and one was given an identity of its own. The platform lead, Maja Lindqvist, and the duty manager, Oskar Berg, first set up a break-glass route local to the management plane, without federation to the identity provider (SVC-NR-004), and tested it on 2029-02-07 with federation disabled in an agreed window: two named people had access in 9 minutes against a target of 15, and the duty manager held the stop of the window. The result is valid until 2029-05-07 or a change in the management plane. The operations assistant NR-OPS-001 (AIDR-0901) holds a read-only identity and no change credential.

Hansa Mutual has the agent. At 02:14 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 (SVC-HM-001). A ticket opened through the broker interface in one market carried a free-text request, which the incident assistant HM-OPS-002 summarised, and the summary reached the runbook runner's context as if it were the assistant's own conclusion. The undelegated classes produced the denial; no data changed, the agent operator, Ewa Kowalczyk, acknowledged the page in 3 minutes against a target of 5, and the event was recorded as INC-HM-2029-0031, a near miss. The review (PIR-HM-2029-0031, 2029-01-30), led by Tobias Richter, head of site reliability and incident management, replayed the request with a permitted class and found that a restart of the claims-core application tier, Level 3 Bounded inside a catalogued runbook, would have been allowed although the independent probe showed no fault: the allow rules checked what the agent may do and not what had prompted it. Version 1.4.0 of the mandate (AIDR-0968, 2029-02-06; owner Anja Weiß, head of the group AI platform) added the writer classes, the inheritance rule, the corroboration requirement and the closed classes. The ceiling suite REG-HM-OPS-010 (illustrative: 24 cases, including a ticket summary in context, a provider-AI alert and an unsigned runbook) ran on 2029-02-13 and all 24 ended in the expected refusal; the result stands for 30 days or until the next change. The monitoring AI of Alster Managed Services and the assistant of Lumenscope are WC-4 sources in the same table. Hansa's controls must prove the ceiling for each class because its agent already acts; Nordvik's must first remove the credentials on which any agent would depend.

Summary

The operator's AI is a target because it brings together the broadest credentials in the estate and the best map of the organisation, and because it reads text that people outside the operations team can write. This chapter concerned O3 Change and O4 Restore, the functions whose actions the agent performs and whose misuse is hardest to undo, and touched O1 Observe and O2 Diagnose, whose telemetry and tickets are the route by which steering text arrives. Six mechanisms recur: operational text as an instruction channel, over-broad and standing credentials, confused deputy through tools, poisoned runbooks, the supply chain of skills and tools, and telemetry as a target. A better model solves none of them, and a control outside the model bounds each.

The state engine, its state and the desired-state repository are Tier 0 for the same reason: write access to the repository is write access to production, the controller's cluster permissions set the blast radius, state files hold secrets, and the gates in front of the engine (protected branches, signature checks, admission policy) are independent of the author. Those controls are one identity per agent and no standing credential for a change or restore class; a policy decision point that defaults to refusal, with named refusals separate from the allow rules; writer classes that label text by who can write it, with the rule that a summary inherits the lowest class and that outside text informs but does not authorise; signed runbooks that the agent reads and cannot edit; a break-glass route that does not depend on what it remedies and that no agent holds; and an append-only log, read by someone other than the agent, with decoys. A ceiling is a claim, stated with the cases tested, the date and the result, and it expires when the policy, the model, a skill or a tool changes.

Nordvik Region removes the standing credential that every future agent would have inherited, and Hansa Mutual's decision point refuses a restore-overwrite that follows an instruction in a ticket and then closes the gap the near miss showed. A reader can start on Monday by listing the identities that can change production, finding those that are standing and shared, and writing ten ceiling cases for the agent or pipeline that matters most. Chapter 19 turns to resilience as a claim with evidence.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
4. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (6, European Union, 2016)
5. MITRE Corporation. MITRE ATT&CK. (33, MITRE, n.d.)
6. MITRE Corporation. MITRE ATLAS. (34, MITRE, n.d.)
7. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (36, OWASP, 2025)
8. NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. (38, NIST, 2024)
9. Vassilev, A. et al. (2025). Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. (39, Vassilev et al., 2025)
10. Rose, S. et al. Zero Trust Architecture. NIST SP 800-207. (43, Rose et al., 2020)
11. Five Eyes cyber security agencies (2026). Careful adoption of agentic AI services. (69, Five Eyes agencies, 2026)
12. Nordqvist, G. (2025). Architecture as Code. (295, Nordqvist, 2025)
13. Nordqvist, G. (2026). AI Platform and Security. (297, Nordqvist, 2026)
14. Nordqvist, G. (2026). AI Red Team. (298, Nordqvist, 2026)
15. Nordqvist, G. (2026). AI Blue. (302, Nordqvist, 2026)
16. Model Context Protocol (2025). Security Best Practices. (93, MCP, 2025)
17. SPIFFE project. SPIFFE Concepts. (94, SPIFFE project, n.d.)
18. Greshake, K. et al. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. (95, Greshake et al., 2023)
19. Anthropic. Agent Skills. (96, Anthropic, n.d.)
20. Hardy, N. (1988). The Confused Deputy (or why capabilities might have been invented). (264, Hardy, 1988)
21. Havaei, R., Liu, R. & Li, M. (2025). Supabase MCP can leak your entire SQL database. (97, Havaei et al., 2025)
22. Beurer-Kellner, L. et al. (2026). Snyk Finds Prompt Injection in 36%, 1467 Malicious Payloads in a ToxicSkills Study of Agent Skills Supply Chain Compromise. (98, Beurer-Kellner et al., 2026)
23. Holzbauer, F. et al. (2026). Context Matters: Repository-Aware Security Analysis of the Agent Skill Ecosystem. (99, Holzbauer et al., 2026)
24. MITRE Corporation. CWE-117: Improper Output Neutralization for Logs. (64, MITRE, 2026)
25. Open Policy Agent. Policy Language. (65, Open Policy Agent, n.d.)
26. SLSA. SLSA specification, version 1.2. (66, SLSA, n.d.)
27. Argo Project. Security. Argo CD documentation. (157, Argo Project, n.d.)
28. Argo Project. Projects. Argo CD documentation. (182, Argo Project, n.d.)
29. Argo Project. Source Integrity Verification. Argo CD documentation. (183, Argo Project, n.d.)
30. Flux project. Multi-tenancy lockdown. Flux documentation. (161, Flux project, n.d.)
31. Flux project. GitRepository. Flux documentation. (186, Flux project, n.d.)
32. HashiCorp. State. Terraform documentation. (162, HashiCorp, n.d.)
33. HashiCorp. Manage sensitive data in your configuration. Terraform documentation. (187, HashiCorp, n.d.)
34. OpenTofu. State and Plan Encryption. OpenTofu documentation. (188, OpenTofu, n.d.)
35. The Kubernetes Authors. Validating Admission Policy. Kubernetes documentation. (189, The Kubernetes Authors, n.d.)
36. Google, OSV (2026). GHSA-3v3m-wc6v-x4x3: ArgoCD ServerSideDiff is vulnerable to Kubernetes Secret Extraction. Open Source Vulnerabilities, 7 May 2026. (84, Google & OSV, 2026)
37. Google, OSV (2026). GHSA-jjrm-hr5f-673x: Source controller: Improper path handling allows traversal. Open Source Vulnerabilities, 5 June 2026. (85, Google & OSV, 2026)
38. Argo Project Labs. Argo CD MCP Server (mcp-for-argocd): README. (110, Argo Project Labs, n.d.)
39. Prodan, S. (2025). AI-Assisted GitOps with Flux Operator MCP Server. Flux blog, 14 May 2025. (111, Prodan, 2025) 39a. controlplaneio-fluxcd. Flux MCP Server command (main.go). (206, controlplaneio-fluxcd, n.d.) 39b. ControlPlane. Flux MCP Server Configuration. (207, ControlPlane, n.d.)
40. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (217, Bainbridge, 1983)