Six months ago your agents had write access. Now they have read-only. Somewhere between the first indirect prompt injection demo and the third board memo, the ambition got cut. "Because of the concern about agents behaving badly, we've scaled down the ambitions of what could be done with an agent." That's what a security lead at a title insurance company said on a sales call last week. We've heard the same sentence, in different accents, on four other calls this month.
The pattern is consistent. Agents are allowed to recommend changes. Humans execute them. Which means the agent saved the engineer thirty seconds of thinking and cost them ten minutes of copy-paste. The math stops working. Most teams quietly walk the agent back to dashboards and summarization.
There's a way to give agents the mutating actions back without giving them broad permissions. It's not new. SREs have been doing it with humans for fifteen years. It's called a runbook.
Why does a runbook make an agent safer than an API key?
A runbook is a parameterized script that lives in Git. It does one thing, takes named inputs, and ships through code review like anything else in the repo. When you hand an agent a runbook, you're not handing it production. You're handing it a function with a known signature and a reviewed body.
Compare the two shapes.
Broad permission: "agent can run any SQL against the analytics replica." The agent decides the query. The blast radius is the database.
Runbook as a tool: "agent can call refresh-user-cohort.sql with cohort_id=X and lookback_days=Y." The team decided the query. The blast radius is the function.
The second shape is what every senior engineer would write for a junior teammate on day one. We're not inventing a new control. We're recognizing that the same control that scales people also scales agents.
How does this actually work in the gateway?
Runbooks in Hoop are Git-backed. You point the gateway at a repository, branch, and credential. The gateway pulls the scripts in memory and exposes them as callable units. Each runbook has parameters, a target connection (a Postgres database, a Kubernetes cluster, an SSH host), and a permission rule.
The rule is the part most teams underestimate. A RunbookRule joins three things: which user groups can run it, which connections it can target, and which file paths in the repo it covers. The intersection is what an agent or a human gets. If the engineering group has the refresh-cohort script scoped to the analytics replica, that's the only place that script runs. The security group's rule might allow a wider set. The same script, different scopes, different audit trail.
When an agent calls a runbook through MCP, the call goes through the gateway. The gateway checks IsUserAllowedToRunRunbook against the agent's identity (which inherits from the human who created the session). If the rule matches, the script executes against the target connection. Guardrails still apply. Masking still applies. The session lands in the audit log with the human's name, the agent's name, the runbook called, and the parameters used.
You haven't given the agent write access to the database. You've given it write access to one shape of write.
What about the things runbooks don't cover?
Two honest gaps.
Runbooks are pre-meditated work. They handle the operations your team has already designed for. The 3 AM exploratory debug isn't a runbook. It's an agent reading logs, joining tables it hasn't joined before, asking questions nobody scripted. For that, you're back to read-only plus session review. Which is fine. Read-only is the right default for exploration.
The other gap is the runbook library itself. If your team has six runbooks, agents get six tools. The value compounds with the library. The teams getting the most out of this pattern are the ones that already had a scripts/ directory and just needed somewhere to publish it safely.
Where does this sit in the broader pattern?
Two things are happening in production access at the same time. AI agents are showing up next to engineers in the same pipes. And the policies meant to govern human access were already behind. Most teams don't have the headcount to write per-action rules. The ones who tried describe it as "permissioning the database fleet with a team of five for years and never finishing."
Runbooks invert the model. Instead of writing a policy that describes every mutating action an agent might take, you write the actions you want it to take. The rest is denied by default. The library becomes the policy.
That's the security team's leverage. Code review is the bottleneck. Code review is also the thing they trust.
What changes for the security team this quarter?
Stop asking "what should the agent be allowed to do." Start asking "what scripts should exist."
The first one is a policy problem with no end state. The second one is a backlog. Backlogs ship.
If you're using Hoop, runbooks ship today. They live next to guardrails and approvals in the same gateway. The agent calls them through MCP. The session looks the same as a human's. Your audit log doesn't care which it was.
Your agents got demoted because the trust model didn't fit. The trust model wasn't broken. The interface was.