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.
The table pairs each threat with the control outside the model that answers it.
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.
Primary topics explored
- Why the operator's AI is a target
- Threats by mechanism
- The state engine and the desired-state repository
- Identity and credentials
- The policy decision point
- Signed runbooks and input provenance
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 18: Defending the Operator's AI: Agents, Credentials and the Control Plane as Tier 0 in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Operator's Own AI” and is one of 35 drawn from the manuscript.