Is access enough? Auth patterns for Claude Managed Agents

TL; DR 

Background agents run independently and can be triggered by events, making them a good fit for on-call work. Claude Managed Agents are one example, and MCP tunnels give them access to the environment they're making decisions over, reaching it, and authenticating. But access is just the starting point. An agent that can reach and log into every system still isn't automatically one you'd trust to run on-call. 

Why do background agents fit on-call work? 

Background agents differ from interactive assistants in one key way: they run on their own schedule, triggered by an event (e.g., a page, an alert) rather than by someone typing a prompt. This difference is what makes them an ideal fit for on-call ops work, where nobody has to be sitting at a keyboard when performance degrades. 

Background agents persist. They pick up an event, run for as long as the investigation takes, from seconds to hours, and can be triggered again later on the same thread. Cole Murray, the creator of Open-Inspect, walks through this distinction in detail, and it's worth watching: the architecture decisions that make sense for a chat assistant don't automatically transfer to something that runs unattended. 

Claude Managed Agents provide a similar instantiation: their sessions persist in the cloud, execute over time, and can be triggered by automated events.  Anthropic's own walkthrough of managed agents covers the mechanics and shows how to build an SRE incident response agent.

For on-call work, this approach is helpful in two ways. For reactive workflows, it ensures that whoever prompts the agent has the same setup and that the agent has the necessary access to assist with the investigation. More importantly, for proactive workflows, the agent can be triggered by events and start and end the investigation before an on-call engineer gets out of bed.  

Recently, at Code with Claude in London on May 19, 2026, Anthropic shipped two features that improve the performance of these agents when running them against production systems. Self-hosted sandboxes (public beta) and MCP tunnels (research preview). Together, they let a cloud-run agent reach a private Kubernetes cluster or an internal Prometheus instance without opening an inbound port, closing a gap that had been blocking some on-call use cases on security review alone. These welcomed improvements make this approach much more practical. It also surfaces the next key question: once the agent has access, does it have the context it needs to resolve the problem? 

Reaching your infrastructure is (mostly) a solved problem 

A managed agent runs in Anthropic's cloud; your cluster, your metrics, and your logs run in your environment. The agent never touches them directly. It calls MCP servers that do. Your cluster exposes a Kubernetes MCP server, your metrics stack exposes a Prometheus MCP server, and the agent calls both as tools. It never gets a raw kubeconfig or a database connection string.  

The first wall anyone hits is that a cloud agent can't reach localhost or a private API server. For local development or a kind cluster, a tunnel like cloudflared's quick-tunnel mode gets you unblocked in minutes. This works for a proof of concept, but not for running production traffic. The production answer is native MCP tunnels. A lightweight gateway inside your network opens a single outbound connection; there's no inbound port and no public MCP endpoint for a scanner to find. This is a general property of cloud-run agents, not something specific to Claude. Any agent platform running outside your perimeter has to solve the same reachability problem, and outbound-only tunneling is the shape the industry, including AWS and Google, has converged on this year. 

How do you authenticate an agent to systems it can now reach? 

The Managed Agents MCP connector sends one thing to your server: an Authorization: Bearer header. Credentials live in a vault matched by the MCP server's URL, not configured on the server entry itself. This means the hard part of auth isn't the agent side, it's getting your existing auth approach to work with that model. 

Three cases show up in practice, in roughly escalating difficulty: 

No auth. A Kubernetes MCP server behind a tunnel with cluster-level RBAC as the only gate. Fine for a kind cluster or a low-stakes internal tool; not something to run against a production API server without at least a bearer token in front of it. 

Static bearer token. A Grafana service-account token, stored in a vault and matched to the MCP server's URL. This is the common case for read-only observability queries. Prometheus, Loki, and Grafana all support long-lived service-account tokens, and the vault handles rotation. 

OAuth client-credentials → JWT. The hard case, since most internal APIs weren't built expecting a bearer-only connector. It sends Authorization: Bearer and nothing else, so the vault has to complete the OAuth exchange up front and hand back a plain bearer token. Sending the client secret as a separate field instead produces a 400 unknown field error, since the connector's schema only expects the one header. For a straightforward approach to handling this see the repo at the end of this post.  

The generalizable rule holds regardless of which of the three cases you're in: the connector's interface is Authorization: Bearer. Anything more complex belongs in the vault, not in the agent's configuration. 

Once that's wired up and authenticated, the reachability problem is addressed, and the real work can begin.  

Access isn't understanding 

An agent with full read access to Kubernetes, Prometheus, and your log pipeline still reasons poorly about the system it is investigating. Even the richest telemetry does not come with a model of what depends on what, or more specifically, what can cause what. Metric series, multiple alerts firing, log lines, and even traces provide the agent with rich data to investigate and reason with, but the access to this data is not structured in a way that makes it effective. 

Give an agent kubectl, a PromQL endpoint, and a log query tool, and it can retrieve almost anything but retrieval isn't diagnosis. This is not a knock on the underlying telemetry. OpenTelemetry's semantic conventions exist precisely to make spans, metrics, and logs consistent enough to reason over but consistent data isn't the same as a causal model of the system that produced it.  

We've written before about why LLMs alone hallucinate root causes for the same underlying reason: pattern-matching over telemetry isn't the same as reasoning over a dependency graph. The distinction between monitoring, knowing something is wrong, and observability, knowing why, makes a related point from a different angle. An agent that can query telemetry has solved the first problem. Solving the second requires encoding dependency and causality structure somewhere: in a semantic layer, a service graph, or an explicit causal model, so the agent has something to reason against, not just something to query. 

FAQ 

How do I connect a cloud AI agent to infrastructure it can't reach directly? Deploy an MCP server for the system you want the agent to reach, then bridge it with an outbound-only tunnel. For local development or a kind cluster, a quick tunnel like cloudflared works in minutes. For production, use native MCP tunnels: a gateway inside your network opens a single outbound connection, so no inbound port or public MCP endpoint is ever exposed. 

Does giving an agent more system access make it more reliable? Not by itself. Raw access to Kubernetes, Prometheus, and logs lets an agent retrieve data, but that doesn't mean it can diagnose. Without an encoded model of service dependencies and event ordering, an agent can't reliably tell a root cause from a downstream symptom. It can query more, not reason better. Access solves reachability; understanding requires a separate structural layer. 

What's the difference between an agent reaching a system and an agent understanding it? Reaching a system means the agent can call an MCP server and retrieve metrics, logs, or cluster state. Understanding means the agent can tell which of those signals is the cause and which are downstream effects, something that requires a dependency graph or causal model, not just a wider set of tools to query. 

How do I authenticate a managed agent to an internal API that uses OAuth? Resolve the OAuth client-credentials flow inside your credential vault, not in the agent's configuration. The Managed Agents MCP connector only ever sends an Authorization: Bearer header matched to the server's URL. It won't perform a token exchange or accept additional OAuth fields, so the vault has to mint the JWT and return a plain bearer token. See the reference repo below for code examples.  

What to do next 

Read the three-auth-pattern, kind-runnable reference repo to see all three cases running end to end with a Claude managed SRE agent accessing a real cluster. The open question this setup raises is whether adding a causal or semantic layer on top of raw telemetry access measurably changes how well an agent investigates an incident. We're running a reproducible, measured comparison on this next. Stay tuned.