Tools Without Authority: Designing a Bounded Operations Agent

During an evening support shift, Priya sees one of two staging replicas become unready. A colleague suggests an AI-driven restart. The problem is the credential: the same diagnostic access that could read workload status could also expose secrets or mutate workloads.

Priya rejects the restart. Chapter 12 builds the alternative: an agent design that can look, cite what it saw, and propose a next step, without the authority to act.

Start Before the Agent: Answers With Evidence

Chapter 11 sets up the idea with something smaller. The operations-assistant searches approved runbooks, cites what it finds, and refuses when it can't support an answer.

Its scenario is instructive. An assistant cites a genuine runbook while recommending a restart, a scale-up, and a cache clear. The cited section contains only a checklist for comparing alert windows with deployment events. The citation was real; the answer wasn't grounded in it.

Two refusals in that chapter set the tone:

REFUSE: state-changing request: restart, scale. This assistant is read-only. ...
REFUSE: approved evidence does not support an answer. ...

The point isn't the keyword screen, which the book admits can't catch every phrasing. The stronger control is that the assistant has no tools and no credentials. Retrieval improves the evidence behind an answer, not the authority behind it.

An Agent Adds a Loop, and Risk With It

An assistant answers a request. An agent adds a loop: receive a goal, select a tool, observe a result, update its working state, and decide whether to stop. Every added step is another place where bad input or weak policy can steer behavior.

The book's position is direct. Teams often treat agent safety as a prompt-writing problem, but the stronger controls sit outside the prompt: identity, authorization, tool code, schemas, tests, and logs. A prompt can describe a boundary, but it can't enforce one.

Tools Are Capability Contracts

The chapter's operations-agent/ harness exposes three reads: deployment-status, events, and log-tail. Its gateway derives the allowlist from the same handler table used for dispatch, so the two can't drift apart. Before reading anything, it checks that the tool has a registered handler, the namespace is reference-staging, and the resource is reference-app.

There's no shell call, network client, Kubernetes client, credential, or fallback handler. A prompt may ask for a restart, but the dispatcher has no restart to call.

Every proposal it produces carries evidence, sets requires_human_approval to true and executable to false, and prints an audit record with mutation_executed: false.

Test the Refusals

Priya's original request becomes a test:

python3 operations-agent/src/agent.py rollout-restart

It returns {"status": "refused", "reason": "tool not allowlisted: rollout-restart"} and exits with status 3. A namespace escape, such as asking for events in production, is refused the same way.

That nonzero status is part of the interface, so automation can tell refusal from a successful diagnosis. And a safety test only passes when the request fails for the expected reason. Checking that "something failed" could hide a syntax error or a missing file.

The Five-Boundary Review

Before giving an agent any new capability, the book asks five questions:

• Identity: what can the process access without model cooperation?
• Tool: which operations can code dispatch?
• State: what can one run remember, repeat, or accumulate?
• Approval: what exact proposal can a person authorize?
• Evidence: can another engineer reconstruct the proposal?

There's no score. One failed boundary stops expansion, because the categories aren't interchangeable. Strong logging can't compensate for a credential that can delete production workloads.

The Honest Result

What makes the chapter useful is that it runs the review on its own harness and reports the failures. Tool and State pass. Identity is Unknown: the optional Kubernetes Role grants no writes or secret access, but pod, log, and event reads cover the whole namespace. Approval fails: emitted proposals have no proposal_id, and their actions don't match the approval schema's fixed action. Evidence fails: standard output isn't retained or correlated by run, proposal, or approval.

So the decision is to keep operations-agent/ proposal-only and add no AI selection or execution while approval binding fails. The required route runs offline against versioned fixture files, and passing it doesn't prove a live cluster adapter is safe.

The book's take: a read-only harness that refuses well is worth more than an autonomous agent whose actions can't be reconstructed. You can add capability later. Recovering trust after an unexplained change is much harder.

Build It Yourself

Chapter 11 builds the operations-assistant that cites evidence and refuses when it has none. Chapter 12 qualifies the operations-agent control harness, its eleven tests, and the worked Five-Boundary Review, with an optional identity check on a disposable cluster. Both run with Python and no live model; the code is in the companion repository at https://github.com/netbiz-ai/ai-native-devops-companion.