A cooling agent is assigned Act-within-bounds. The design doc says so. The architecture diagram has it in the right band, the runbook describes its envelope, and the team agrees the boundary is enforced outside the agent. Then an incident review, months later, finds three things. The agent had been authenticating to the building management system with a shared service account that also held write access to the power controls. The envelope check was a function the agent itself called - and could skip under a code path nobody tested. And no log exists that can reconstruct which of three agents issued the setpoint change that preceded a thermal event. The band assignment was real on paper. Nothing on the wire enforced it.
This is the quiet failure underneath the whole series, and the numbers say it is the common case, not the edge case. The 2026 CISO AI Risk Report found that 71 percent of enterprises say AI tools already reach core systems like Salesforce and SAP, yet only 16 percent govern that access effectively, 92 percent lack full visibility into their AI identities, and just 5 percent are confident they could contain a compromised agent. Separately, 88 percent of organisations confirmed or suspected an agent-related security incident this year. Read those together: almost everyone has wired agents into production, almost no one can see what the agents can reach, and almost no one could stop one that went wrong. The band assignments are on paper. The enforcement is not on the wire.
This is Part 7, the close of the series. The previous six articles built and applied the Operational Authority Gradient (OAG): the four-band model - Observe, Advise, Act-within-bounds, Closed-loop - and placed cooling, agentic SRE, workload placement, power and grid, and the multi-agent buildout on it. From different directions, those articles kept reaching one instruction: enforce the boundary outside the agent - and Part 6 sharpened it, showing that in a multi-agent system the boundary that matters is one no single agent can even see. This article is about AgentOps, the thing that does the enforcing - and why, without it, everything the series argued is a diagram and not a control.
The thesis: a band assignment is a comment until something enforces it
Across six articles, one rule recurred so often it became the series' spine: the boundary between bands must be enforced outside the agent, never by the agent's own judgement. Cooling's envelope was computed outside the agent. SRE's gate was on reversibility, evaluated outside the agent. Placement verified the checkpoint outside the agent. Power authored the tariff into constraints outside the agent. The buildout's coordinator owned the composite band outside every agent.
Here is the claim this final article owns: that recurring phrase, "outside the agent," names a system that the series never built - and that almost no one has built. First, a distinction, because two different things sit outside the agent. One is the domain control plane the earlier parts leaned on - the building-management fail-safe that clamps a cooling setpoint, the rate limiter, the regulatory constraint at the grid boundary. That layer enforces what a correct action looks like in the physical world, and much of it predates agents entirely. The other is AgentOps: the identity, audit, isolation, and signing layer that enforces which agent may act at all, and makes what it did reconstructable afterward. This article is about the second one, because it is the half the series named on every page and never built. AgentOps is what the identity-and-provenance half of "outside the agent" is made of. It is not a band on the gradient and not another use case; it is the enforcement layer - audit logging, workload isolation, signed skills, and access control - that turns a band assignment from a sentence in a design doc into a constraint on the wire. And the central, uncomfortable finding is that without it, the entire gradient is decorative. A band is a claim about what an agent is allowed to do. AgentOps is the only thing that makes the claim true. The 5-percent-can-contain-a-compromised-agent statistic is the measurement of how often the claim is currently false.
The series argued, over and over, that the agent's self-judgement cannot be trusted to hold the boundary. AgentOps is the admission that something else has to, and the specification of what that something is.
Why this matters: the gap is measured, and it is enormous
It would be easy to treat this as a security footnote. The data says it is the main event.
Start with the access surface. Agentic systems are a permission attack surface: they authenticate against APIs, read from databases, write to control systems, trigger workflows, and invoke other agents. In most early deployments, permissions are over-provisioned, because it is faster to give an agent broad access than to scope exactly what it needs. That over-provisioning is the direct negation of the bands. An agent assigned Observe that holds write credentials to the power controls is not at Observe in any sense that matters; it is one prompt injection or one untested code path away from Closed-loop on a system it was never supposed to touch. The 92-percent-no-visibility figure means most operators cannot even enumerate which of their agents are in this state.
Then the speed. The reason this is worse for agents than for human users is that the agent can move faster than the control plane if the token is too broad or too durable. A human with over-broad access is bounded by human reaction time; an over-credentialled agent acting at machine speed can traverse a privilege path and exfiltrate or actuate before any human-paced review fires. This is not hypothetical: a recent breach exposed 1.5 million AI agent keys at once, and in a separate incident attackers used stolen cloud credentials to hijack frontier models running on a managed inference service. When the credential is the perimeter and the credential leaks, the blast radius is everything the agent could reach - which, given over-provisioning, is usually far more than its band.
And the orphans. Teams deploy agents without centralised governance; when workflows change or projects end, agents remain active with unmanaged credentials, and these orphaned agents create persistent access paths into the infrastructure. Every prior article in this series assumed an agent with a known band and a known scope. AgentOps is what makes "known" true over time, against the entropy of a real environment where agents are spun up, repurposed, and abandoned. Without it, the careful band assignments of Parts 2 through 6 decay silently into a population of unaccountable agents holding credentials nobody is tracking.
AgentOps' four controls, and the series obligation each one discharges
Part 1 named AgentOps as four controls: audit logging, workload isolation, signed skills, and access control. Seen from the end of the series, each one is not a generic security best practice - it is the mechanism that makes a specific promise from the earlier articles real.
Access control is what makes a band a band. A band is a statement about what an agent may do; access control - least-privilege, per-agent identity, runtime authorization - is the enforcement of exactly that statement at the credential layer. The discipline the field has converged on is identity-first: each agent gets a unique non-human identity distinct from the human who triggered it, governed by least-privilege from the moment of deployment, with authorization evaluated per action rather than granted standing. Runtime authorization - real-time evaluation of each agent action to enforce least privilege and context-aware approval - is the literal implementation of "the control plane decides, not the agent" that every article invoked. An agent at Observe should hold credentials that can only read. That is not a policy written in a doc; it is a credential that physically cannot write, brokered fresh per action and expiring fast.
Audit logging is what makes the band checkable after the fact. Every article assumed you could tell what an agent did; AgentOps is what makes that assumption true. The standard to aim for is audit-grade provenance: a traceable record of what the system saw, decided, and executed - prompts, the inputs, the policy decision, and the resulting action - so an investigator can reconstruct the decision chain. The opening failure had none of this: three agents, one setpoint change, no way to attribute it. Provenance is also what lets you measure the band-violation rates this series kept asking for - the SRE false-positive rate, the placement false-deadline rate, the composite-violation rate - because you cannot compute a violation rate over actions you did not log. The audit trail is not paperwork; it is the instrument.
Workload isolation is what bounds the blast radius when a band is breached anyway. The OAG assigns authority by blast radius; isolation is what makes the blast radius a physical fact rather than an assumption. An agent compromised or misbehaving inside a properly isolated workload can damage only what its isolation boundary contains - which is the engineering substance behind "the worst case of this band is bounded." Without isolation, a breach anywhere is a breach everywhere, and the band's blast-radius assignment is fiction. The 5-percent-can-contain figure is, precisely, a measurement of missing isolation: containment is what isolation buys, and 95 percent do not have it.
Signed skills are what guarantee the agent is running the logic you authorized. Every envelope, every gate, every coordinator in this series was a piece of code or policy the agent was supposed to be running. Signed skills - verifying the integrity and provenance of the tools and skill definitions an agent loads - are what stop a tampered or spoofed skill from quietly replacing the cooling envelope with one that has no floor, or the SRE gate with one that always returns "reversible." If an attacker can swap the skill, the band assignment is meaningless because the thing enforcing it has been replaced. Signing is what makes the enforcement logic itself trustworthy.
The wrong way: the band lives in the prompt
The naive deployment - and, the data suggests, the common one - encodes the band as an instruction to the agent and authenticates with broad standing credentials.
# The seductive, wrong shape: the band is a string in the system prompt,# the credential is broad and standing, and nothing logs the decision.SYSTEM = """You are a cooling agent. You are at Act-within-bounds.Only adjust setpoints within safe ranges. Do not touch power systems."""agent = Agent( system_prompt=SYSTEM, credentials=SHARED_BMS_SERVICE_ACCOUNT, # also has power-system write tools=load_skills("./skills/"), # unsigned, unverified)await agent.run(incident) # no per-action gate, no logEvery control is missing, and the band is purely aspirational. The authority is a sentence in SYSTEM that the model is asked, politely, to respect - the exact self-enforcement the entire series said never to rely on. The credential grants far more than the band allows, so the moment a prompt injection or an unanticipated reasoning path leads the agent to attempt a power-system write, nothing stops it. The skills are loaded unsigned, so a tampered envelope is indistinguishable from the real one. And there is no per-action authorization and no log, so the action is neither gated nor reconstructable. This is a band assignment that exists only in the prompt, which is to say it does not exist at all. It is the opening failure, in code.
The right way: the band is a property of the credential and the gate
The correct deployment makes the band physically true: a scoped per-agent identity that cannot exceed it, runtime authorization on every action, signed skills, and audit-grade logging of every decision.
# The band is enforced by the infrastructure, not requested in the prompt.# Identity is scoped, authorization is per-action, skills are verified, all logged.identity = nhi.issue( # unique non-human identity agent="cooling-agent-7", band=Band.ACT_WITHIN_BOUNDS, scope=Scope(read=["bms.telemetry"], write=["bms.setpoints"]), # NOT power credential_ttl="5m", # short-lived standing credential, not a persistent secret)skills = load_signed_skills("./skills/", verify=TRUSTED_SIGNING_KEY) # or refuseagent = Agent(identity=identity, tools=skills, isolation=Sandbox("cooling-7"))async def act(proposal: Action) -> Result: decision = await authz.evaluate( # runtime authorization, per action identity=identity, action=proposal, policy=ENVELOPE_POLICY, # the envelope, outside the agent ) await audit.record( # audit-grade provenance saw=proposal.context, decided=decision, will_execute=decision.permitted, ) if not decision.permitted: return blocked(decision.reason) # the credential cannot exceed scope result = await agent.execute(proposal, broker=identity) await audit.record(executed=result) # and what actually happened, after return resultThe band is now a fact about the system, not a request to the model. The identity is scoped so the credential physically cannot write to power, regardless of what the agent reasons or is tricked into attempting - the Observe/Act-within-bounds distinction is enforced in the credential, not the prompt. Authorization is evaluated per action against the envelope policy that lives outside the agent, exactly as cooling, SRE, and the rest required. Skills are verified against a signing key or refused, so the enforcement logic cannot be swapped. Isolation bounds the blast radius to the sandbox. And every decision is logged with what the agent saw, what was decided, and what executed - the provenance that makes the band checkable and the violation rates computable. Each of the series' "outside the agent" promises now corresponds to a line that enforces it.
The Enforcement Gap
The pattern across the data and the series deserves a name, because it is the gap between the diagram and the deployment.
Call it the Enforcement Gap: the distance between the authority an agent is assigned on paper and the authority its infrastructure actually constrains it to. A band assignment with no AgentOps behind it has a maximal Enforcement Gap - the agent is nominally at Observe and effectively at whatever its broadest standing credential permits, which is usually far higher. The gap is invisible in the architecture diagram, where the band looks enforced, and it is invisible in normal operation, where the agent happens to stay in band. It becomes visible only on the bad day - the prompt injection, the leaked key, the untested path, the orphaned credential - which is exactly when you cannot afford to discover it. The 5-percent containment figure is the Enforcement Gap measured at fleet scale: for 95 percent of organisations, the gap between assigned and enforced authority is wide enough that a compromised agent cannot be contained.
The Enforcement Gap reframes the whole series as a single instruction. Every band assignment in Parts 2 through 6 was a target. AgentOps is the only thing that closes the distance between the target and reality. A cooling envelope is an Enforcement Gap until access control scopes the credential to setpoints. A reversibility gate is an Enforcement Gap until runtime authorization evaluates it per action. A coordinator's composite band is an Enforcement Gap until two things hold: the coordinator can evaluate the composite - cross-agent visibility and a band assigned to the combined blast radius - and access control gives it custody of what the sub-agents may execute. Credential custody enforces which agent acts; it does not, by itself, decide whether the composite was authorised. As Part 6 argued, that composite evaluation is a new dimension, not access control alone - AgentOps is necessary there, but not sufficient. The gradient describes where the boundaries should be. AgentOps is whether they are anywhere but the diagram.
Where each AgentOps control sits in the deployment sequence
Unlike the earlier articles, AgentOps is not placed on the gradient - it is what makes placement on the gradient mean anything. But its controls still have an adoption order, and it is the inverse of how most teams proceed: most wire the agent to production first and add governance later, which is why the gap statistics look the way they do.
Identity and access control come first, before the agent touches anything real. Every agent gets a unique non-human identity and least-privilege scope from the moment of deployment, not retrofitted after an incident. This is the control that makes every band assignment in the series enforceable, and it is the one most often deferred. Issue the scoped identity before the first production action, or the band is fiction from the start.
Audit logging comes with the first action, not after the first incident. If the agent can act, every action it takes must be recorded with audit-grade provenance from action one - because the log you need to reconstruct an incident is the log you were keeping before you knew there would be one. This is also the prerequisite for every measurement the series recommended; you cannot improve a violation rate you never recorded.
Isolation is provisioned per band, sized to the blast radius. An Observe agent and a Closed-loop agent do not get the same isolation boundary, because they do not have the same blast radius; isolation is how the band's blast-radius assignment becomes physical. Size the sandbox to the worst case the band permits, and the band's "bounded worst case" stops being an assumption.
Signed skills are enforced before any agent loads a skill that gates a real action. The moment a skill encodes an envelope, a gate, or a coordinator policy - which is to say, the moment AgentOps is doing the series' work - that skill must be signed and verified, or the enforcement logic is forgeable. Verify from the first gated action, not after a tampering event.
The Enforcement Gap checklist
Before an agent takes its first production action, confirm each control is on the wire - not in the design doc:
- Scoped identity issued. The agent has a unique non-human identity whose credential physically cannot exceed its band. Test it: an Observe agent's credential should fail a write, not be trusted to decline one.
- Per-action authorization live. Every action is evaluated against a policy that lives outside the agent, brokered fresh, with a short credential TTL - no standing secret.
- Audit-grade logging from action one. Each action records what the agent saw, what was decided, and what executed - enough to attribute a setpoint change to a single agent after the fact.
- Isolation sized to the band. The sandbox bounds the blast radius to the worst case the band permits, so a breach is contained by construction, not by hope.
- Skills signed and verified. The agent refuses any skill that fails signature verification, so the envelope or gate cannot be swapped for a permissive fake.
If any box is unchecked, the band is a comment. Close that box before you call the boundary enforced.
A boundary nothing enforces is not a boundary
Through six articles, the Operational Authority Gradient gave a way to answer the question the data center boom forces: how much authority should an agent have, given what it can break. Cooling earned Act-within-bounds inside an envelope. SRE's value lived in the diagnosis bands. Placement's reversibility was borrowed. Power's ceiling was jurisdiction. The buildout's authority did not compose. Each was a careful argument about where a boundary belongs.
This final article is the argument that a boundary belongs nowhere until something enforces it. AgentOps - access control that scopes the credential, audit logging that records the decision, isolation that bounds the blast radius, signed skills that protect the enforcement logic - is the machinery that turns the entire gradient from a way of thinking into a way of operating. The recurring instruction of the series, enforce the boundary outside the agent, has an address: it is the AgentOps layer, and the measured fact that only five percent of organisations could contain a compromised agent is the measured fact that almost no one has built it yet.
So the series closes on its own foundation. The gradient tells you where the boundaries go. Epistemic restraint - the discipline that runs underneath all of it - is the recognition that the agent cannot be trusted to hold those boundaries itself, and must be held to them from outside. And AgentOps is the outside: the unglamorous, mostly-unbuilt layer of identities and logs and sandboxes and signatures that determines whether everything else in this series is engineering or just a very well-drawn diagram. Build the gradient. Then build the thing that enforces it - because a boundary that nothing enforces is not a boundary. It is a comment.
References
The enforcement gap, measured
- "AI Agents Expose Identity Governance Shortfall" - Let's Data Science (2026). Source for the 2026 CISO AI Risk Report figures (71% reach core systems, 16% govern effectively, 92% no visibility, 5% can contain a compromised agent), the Gravitee 88%-incident figure, and the three controls (posture management, lifecycle governance, runtime authorization).
- "AI Agent Audit: The Complete 2026 Governance and Compliance Guide" - Indext Data Lab (Apr 2026). Source for agentic systems as a permission attack surface, over-provisioning in early deployments, and oversight scaling with autonomy.
Identity, access control, and runtime authorization
- "AI Agent Orchestration: Identity Control Plane" - Okta (Apr 2026). Source for unique per-agent non-human identity distinct from the triggering human, and orphaned-agent persistent access paths.
- "When is it crucial to implement least-privilege access for AI agents?" - NHI Management Group (May 2026). Source for least-privilege from deployment onset, the agent-moves-faster-than-the-control-plane point, and the OWASP NHI Top 10 / NIST AI RMF alignment.
- "Runtime Security for AI Agents: An Identity Governance Perspective" - SoftwareAnalyst (Mar 2026). Source for per-tool-call governable actions, kill-switch controls, and short-lived runtime-brokered credentials replacing standing secrets.
Audit provenance, breaches, and compliance
- "AI agent audit logging exposes the gap in identity governance" - NHI Management Group (May 2026). Source for audit-grade provenance (what a system saw, decided, executed), the Moltbook 1.5M-agent-key breach, and the LLMjacking-on-Bedrock incident.
- "AI Agent Governance: Policy and Compliance 2026 Guide" - Digital Applied (2026). Source for SOC 2 CC6 (least-privilege access) and CC7 (monitoring) mapping to agent identities, OWASP LLM06 Excessive Agency, and the EU AI Act Article 73 15-day incident-reporting obligation activating August 2 2026.
- "Agentic AI in the Factory - NVIDIA Enterprise AI Factory Design Guide" - NVIDIA (2026). Source for the AgentOps definition: auditing, isolation, signed skills, and controlled access to live environments.
Related Articles
- Authority Doesn't Compose: Why Coordinated Agents Need a Coordinator With Its Own Band
- Cooling Is the Most Mature Agentic Use Case. That Is Exactly Why It Is the Most Misread.
- Agentic AI in the Data Center Boom: A Unified Map of Where Agents Actually Run the Building
- At the Grid Boundary, Being Right Doesn't Grant Authority