Claude Routines Need a Governed Home: Centralizing What Your AI Agents Can Reach

This article is part of our guide to Agentic Infrastructure.

Key points:

• Claude Routines are a great automation primitive - prompt, repo, and connectors, triggered on a schedule, by an API call, or by a GitHub event, running on Claude's infrastructure instead of your laptop.
• But a trigger is not a guardrail. The rules that decide what an agent can reach on the network are configured per engineer and per project.
• Decentralized network rules are the real enterprise risk. Any individual can widen access. Multiply that across a team and you have an attack surface nobody controls centrally.
• The fix is not to ban the automation. It's to give it a governed home - one place where the platform team sets the network rules, not each engineer.

The scary part of an autonomous agent is not the code it writes. It's what it's allowed to reach.

An agent that can only touch your repo and open a pull request is easy to reason about. An agent that can also call an arbitrary HTTP endpoint, pull a file from a storage bucket, and execute whatever it finds there is a different animal. The first is a productivity tool. The second is a remote code execution path wearing a friendly name.

This is the lens I want to put on Claude Routines. I like the feature a lot. But the more teams adopt it, the more one question matters: who controls what those Routines can reach?

What Claude Routines actually are

A Routine is a Claude Code automation you configure once - a prompt, a repo, and connectors - and then run without sitting in front of it. There are three ways to fire one:

• Scheduled - "Every night at 2am, pull the top bug from Linear, attempt a fix, and open a draft PR."
• API - every Routine gets its own endpoint and auth token. Your CD pipeline POSTs after a deploy, Claude runs smoke checks and posts a go/no-go.
• Webhook - subscribe to GitHub events. Claude opens a session per matching PR and runs your checklist.

The important detail: Routines run on Claude Code's web infrastructure, so nothing depends on a laptop being open. This is genuinely useful. It turns Claude Code from an interactive assistant into a piece of always-on automation - the kind of thing you used to glue together with cron jobs, a server, and a pile of MCP tooling.

So this is not a "Claude Routines bad" article. Routines are one of the better agent automation primitives shipping right now. The gap I want to talk about is somewhere else.

Triggers aren't governance

Here is the thing a trigger does not give you: a centralized, admin-controlled answer to "what is this agent allowed to reach?"

In practice, that answer is assembled per engineer and per project. Each person configures the tools their agent can use and the domains it's allowed to call. That works fine for one developer on one repo. It stops working the moment you have a team.

Walk through what decentralized network rules actually mean:

• Anyone can widen access. An individual can add a broad domain rule to get something working - and now an agent can reach a service nobody else reviewed.
• Broad access compounds. Give an agent read access to a storage location and you've trusted everything in that location. Object stores hold whatever gets written to them, including content an attacker controls. A "just let it read the logs" rule can become "let it fetch and run an arbitrary script."
• There's no single place to look. Network rules live with each engineer's setup, so there is no admin view of what every agent across the org can touch, and no central audit of the calls they make.

None of this is unique to Claude Routines. It's the default reality of any per-developer agent setup - every engineer could already run an agent in YOLO mode on their machine with no guardrails. Routines just make the automation persistent and easy, which makes the governance question harder to ignore.

The trade-off is real: the same decentralization that makes Routines fast to adopt is what makes their blast radius hard to bound.

Give your Routines a governed home

The fix is not to ban the automation. It's to move the rules off the individual and into one place the platform team controls.

That's what a governed runtime - a Remote Development Environment, in Qovery terms - is for. Instead of each engineer deciding what their agent can reach, the network rules become a centralized, admin-restricted policy that every agent inherits:

• Domain allowlists and an outbound HTTP proxy - every outbound request from every agent passes through one place. The platform team decides what's reachable, not each developer.
• DLP filters that catch API keys and secrets before they leave.
• A kill switch to stop all outbound traffic instantly when something looks wrong.
• Network isolation so an agent's workspace can't quietly reach the rest of your network.
• RBAC - the platform team defines who, and which agent, can do what and where. The agent operates strictly within those boundaries.
• A full audit trail - every action attributed and logged, exportable to your SIEM.

This is the same governance triad we apply to every agent action in Qovery's MCP server for infrastructure: RBAC, budgets, and audit. The point is to make the rules a property of the environment, set once by the people accountable for security, rather than a property of each engineer's local config. (We go deeper on the network-control side in what an agentic infrastructure platform is.)

Routines + a governed runtime

This is where I want to be clear, because it's easy to read the above as "Routines vs. RDE." It isn't. They solve different problems and they fit together.

A Routine is the trigger layer - the thing that decides an agent should run nightly, or on every PR, or when your pipeline calls it. A governed runtime is the home that run executes in. Put a great trigger on top of a governed environment and you get the best of both: persistent automation that can't reach anything the platform team didn't approve.

You don't have to choose. You have to decide where your Routines live.