Scout: The Coding-Agent Control Plane Productizes — What the Claude Apps Gateway Standardizes

Summary

Between late June and early July 2026, the operational tier that sits in front of a coding agent became a first-party, customer-hosted product. It is not the first thing to carry the name — GitHub shipped what it explicitly called “your agent control plane, a suite of enterprise governance features” into public preview for Copilot on October 28, 2025, with consolidated administration, enterprise policy, session visibility, agentic audit logs, and MCP controls (GitHub Changelog). What is new is the shape: GitHub’s runs in GitHub’s cloud, and this one runs in yours. Anthropic shipped the Claude apps gateway on June 29 — a self-hosted service that holds the upstream credential, signs developers in against a corporate OIDC provider, enforces per-group model access, delivers managed settings, relays OpenTelemetry usage metrics to the organization’s own collector, and caps spend by user, group, or org. Google Cloud published a Cloud Run deployment on July 1 and AWS an ECS/EKS/EC2 one on July 8, with InfoQ covering the AWS release as a self-hosted control plane for Claude Code and Claude Desktop. The clearest measure of what this displaces is that AWS’s own reference implementation for the same job — a CloudFormation stack of OIDC federation, STS credential exchange, a Fargate OTel collector, Lambda-plus-DynamoDB quota enforcement, and an S3/Athena analytics lake — is now in maintenance mode, with new deployments pointed at the gateway instead. The gateway is a subcommand of the claude binary with no separate license or per-seat fee. What it governs is narrow and worth naming precisely: it authorizes the coding agent’s access and cost surface server-side, while agent-action policy is centrally set but enforced on the developer’s machine — so only some of what it governs is enforced where the developer can’t reach it.

Key Findings

1. Five hand-rolled tiers collapse into one config file

The capability list is unremarkable on its own; the consolidation is the event. Per Anthropic’s documentation, the gateway does five things: it acts as an OIDC relying party against Okta, Entra ID, Google Workspace, Keycloak, Dex, or any compliant provider (SAML and LDAP are not supported); it maps IdP groups to model allowlists and managed-settings policies; it delivers those settings to signed-in clients, replacing the claude.ai console’s server-managed-settings path; it fans OTLP metrics carrying token counts, model, user identity, and latency out to Datadog, Splunk, ClickHouse, or whatever the org runs; and it translates the Anthropic Messages API for whichever upstream is configured — Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, Microsoft Foundry, or the Anthropic API — with failover between them.

The deployment shape is deliberately boring. A single stateless Linux container plus PostgreSQL 14 or later, behind a TLS-terminating ingress; the gateway “scales horizontally because replicas are stateless and Postgres is the shared coordination layer,” and boot is fail-closed on config, store connectivity, OIDC discovery, and upstream construction (deployment guide). AWS’s version wraps that in ECS, EKS, or EC2 behind an Application Load Balancer with RDS for PostgreSQL holding “short-lived sign-in state and rate-limit counters,” using an IAM task role for the upstream call; Google’s wraps it in Cloud Run with internal ingress, Cloud SQL, and Secret Manager. Both cloud posts describe the same binary with a different upstreams: block.

The economics matter for the build-vs-adopt call: “there is no separate license or per-seat fee for the gateway; it’s part of the claude binary. You pay for inference through your existing cloud or Anthropic commitment, plus the compute for the container and your telemetry collector.” A team already paying for Bedrock inference is looking at a container, a small Postgres, and an OIDC app registration.

Against that, look at what AWS’s superseded guidance actually required a platform team to own: IAM OIDC federation or Identity Center, AssumeRoleWithWebIdentity credential exchange, an ECS Fargate OTel collector, CloudWatch dashboards, a Lambda-and-DynamoDB quota checker that ran before credential issuance, an S3-plus-Athena analytics lake, and a binary distribution mechanism. That is five or six services, each with its own failure mode and on-call surface, to reach roughly the capability set the gateway now ships as one process. AWS’s README now says: “For new deployments of Claude Apps on Amazon Bedrock, we recommend Claude Apps Gateway — a self-hosted service that sits between your Claude clients and your model provider.” The solutions team opened an issue on July 2 to work through gaps and migration paths, so the transition is in progress rather than settled.

2. The enforcement boundary is the thing to read before the security review

This is the finding a platform or security team should spend its attention on, because the documentation is precise about it and a casual read will flatten it.

Two classes of control live in this gateway, and they are enforced in different places.

Server-side, out of the developer’s reach. Model access is checked at the gateway: requests for models the policy doesn’t grant “return 400, and the /model picker is filtered to the policy’s availableModels allowlist.” Spend caps are checked at the gateway on every /v1/messages request. The upstream credential never leaves the gateway; developers hold short-lived JWTs, one hour by default, and ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY, apiKeyHelper, and any prior claude.ai login are ignored while signed in. Deprovisioning in the IdP expires the session within the token TTL. These are real controls with a real trust boundary.

Client-side, delivered as policy. Tool permissions, MCP server allowlists, sandbox filesystem and network rules, and hooks are delivered by the gateway and “applied by the CLI at the managed settings tier.” The CLI refreshes hourly and exits at startup after about ten seconds if the gateway is unreachable, rather than starting unrestricted. That’s a well-designed client, but it is still a client — and the gateway’s own threat model states plainly that “the gateway sits inside your network perimeter, but individual developer laptops aren’t treated as trusted.” A team should not describe its tool-permission policy to an auditor in the same sentence as its model allowlist; one is a server-side authorization decision and the other is a configuration push to an untrusted endpoint.

Three specifics sharpen this.

First, the gateway is not a chokepoint unless the network makes it one: “the gateway doesn’t enforce that the only route to a model goes through it. A developer with their own credential can still call the provider directly, so closing that path is a network policy decision.” Egress control is still the org’s job, and blocking api.anthropic.com has a side effect — it breaks the client-side URL domain safety check each developer’s machine performs against Anthropic, which the documentation addresses by setting skipWebFetchPreflight: true in the managed policy.

Second, Claude Desktop sessions silently escape policy without an explicit opt-in. Desktop runs embedded Claude Code sessions and passes the gateway’s policy down as parent settings, which Claude Code ignores on any managed machine unless the winning admin source sets parentSettingsBehavior: "merge". The documentation’s warning is the kind that belongs in a runbook: “Without the opt-in those sessions run with none of the gateway’s restrictions, and nothing warns you.” Any org deploying Desktop alongside the CLI needs that key mirrored into whichever source wins on each machine — OS policy outranks the managed-settings file, and the gateway’s own remote policy outranks both.

Third, the gateway host is now MDM-class infrastructure. Anthropic scopes a compromised gateway host out of the threat model as the customer’s problem, and explains why the stakes are what they are: the host “both holds the upstream credential and distributes managed settings to every connected developer, so control over the gateway’s configuration is comparable to control over your MDM.” Anyone treating this as “just a proxy” in a design review has mis-tiered it.

3. Spend caps answer the right problem at the right layer — and are explicitly not accounting

The demand-side case for this tier was made vividly earlier in July: InfoQ reported a three-person agency hit with a $14,000 one-day AWS bill after attackers extracted static keys and spent them on Bedrock invocations, alongside May’s DN42 incident in which an autonomous agent with full AWS access provisioned oversized infrastructure and ran up $6,531.30 before the operator noticed, later negotiated down to $1,894. The structural point in that reporting is that Budgets evaluates against delayed billing data, “so budget actions fire after the money is spent.” Get the bound the right way round, though: AWS does not promise a 24-hour ceiling. Cost Explorer “refreshes your cost data at least once every 24 hours,” and AWS warns that because this depends on upstream billing applications, “some data might be updated later than 24 hours” (AWS Cost Management docs). That is a floor on refresh frequency with no stated maximum — which makes the architectural argument stronger, not weaker.

The gateway’s answer is admission control rather than alerting. Caps are set through an admin API at /v1/organizations/spend_limits — scoped to user (by OIDC sub), rbac_group, or organization, in whole-cent amounts, over daily, weekly, or monthly periods. On each inference request the gateway resolves caps and period-to-date spend in one Postgres query and returns 429 with error.type: billing_error and x-should-retry: false when the developer is over. Token counting is exempt because it’s free.

Several design details are worth knowing before anyone builds a finance process on top of this:

• Caps are per-seat defaults, not shared pools. “A group or organization cap is a per-seat default that each member inherits, not a shared pool.” Resolution order is per-user override, then most-restrictive group cap, then org default, then unlimited — with admin.group_limit_mode: max flipping the multi-group tie-break.
• It is a circuit breaker, not an invoice. Metering prices tokens at USD list price using the same table the CLI uses for its cost display. Anthropic’s guidance is to “reconcile against your provider’s own usage reporting,” and Google’s post makes the same caveat concrete: committed-use discounts and negotiated rates don’t appear, so treat the numbers as a runaway-usage guardrail.
• The metering closes two obvious evasions. An unrecognized model ID — a Foundry deployment name, an inference-profile ARN — prices at a fallback tier of $5/$25 per million input/output tokens rather than zero, “so an unrecognized ID can’t bypass a cap by going unmetered.” And aborted streams, which never carry the terminal usage frame, are billed against a conservative floor estimated at about four characters per token.
• Enforcement fails open by default. If the Postgres pre-check times out at two seconds, “the request proceeds and the gateway logs a warning,” unless enforcement.fail_closed_on_error: true is set. That default is the right one for availability and the wrong one for a hard budget guarantee; it is a deliberate choice each org should make rather than inherit.

Set against the billing-lag problem, this is the correct architectural move — the decision binds at request admission, where the meter never could. It is also worth being clear-eyed that a cap denominated in list-price estimates against a shared upstream credential is a blast-radius limiter, not a cost-management system.

4. What this control plane does not govern

The layer boundary is where practitioners most often mis-file this — and it needs stating more carefully than the slogan version allows. The gateway governs which developer, using which model, under whose settings, against which budget. On agent actions it is not absent, but it is not an authorizer either: it delivers tool permissions, MCP allowlists, sandbox rules, and hooks centrally, and Anthropic’s own framing is that “different teams get different models, tools, and permissions, and a developer can’t override what their policy locks” (gateway documentation). What it does not do is mediate each tool call server-side. Action policy is centrally decided and locally enforced, by a client on a machine the threat model already declines to trust — so the precise claim is that the gateway does not server-side authorize or observe individual agent actions, not that it has no say in them. That distinction was the sharpest note in the launch-week commentary: writing in DevOps.com, Mitch Ashley of The Futurum Group observed that “Enterprise identity, policy, cost attribution, and spend caps now ship as first-party infrastructure for Claude Code,” then drew the limit: “It does not govern what agents do, and that is the control problem that still decides enterprise autonomy.”

The adjacent layers each answer a different question, and a team standing up agent governance needs all of them mapped rather than conflated:

MCP Enterprise-Managed Authorization lets an IdP grant or deny server access by group membership, role, and conditional-access rules — connectivity eligibility, decided before any tool call. The gateway’s allowedMcpServers policy overlaps that surface but reaches it through client-side managed settings rather than through the IdP’s own authorization decision. Neither one answers whether a particular rm -rf, a particular payment, or a particular force-push should run. That question remains the open one.

5. Build-vs-adopt turns on the protocol-drift tax, not the feature list

The reflexive objection from a platform team is “we already run LiteLLM / Portkey / an internal proxy, so this is redundant.” On feature surface, that objection has merit: LiteLLM’s proxy supports budgets at key, user, team, org, customer, agent, and tag scope with arbitrary reset windows, multi-window stacking, and a fail_closed_budget_enforcement option — a richer budget hierarchy than the gateway’s three periods and three scopes, and multi-provider besides.

What the objection misses is the maintenance contract. Anthropic publishes the wire contract Claude Code expects of any gateway, and its central instruction is to treat the forwarded surface as an open list: “Claude Code gains capabilities over releases, and they arrive as new anthropic-beta values, new request body fields, and occasionally new anthropic-* or x-claude-code-* headers… A gateway pinned to an observed list strips the next capability’s header or field and breaks it on the release that introduces it” (gateway protocol reference). The failure modes are specific and unpleasant: capabilities pair a beta header with a body field, and a gateway that forwards one without the other “produces hard 400 errors” while dropping both merely turns the feature off quietly. A gateway that rewrites request bodies for content inspection breaks the pairing the same way. A gateway that wraps upstream errors in its own envelope breaks Claude Code’s automatic retry-and-degrade path, “even when it preserves the status code.” The system-prompt attribution block is stripped positionally by the Anthropic endpoint, so reordering or merging the system array pushes it into the prompt and the cache key. And the rollout guide adds an operational trap that has nothing to do with LLMs: prompts carry source code and XML-style tags that trip cross-site-scripting body rules, so the gateway path must be exempted from WAF request-body inspection or “a WAF in front of the gateway returns 403 on real sessions while short test requests pass.”

That is the tax the first-party gateway removes, because it ships from the same binary and is tested alongside each CLI release. The rollout guide’s maintenance table names the recurring work a self-maintained gateway keeps: forward headers verbatim and test each new CLI release before developers get it; add new model names to the routing table or developers see 404; rotate the provider credential on its own schedule.

The counterweight is scope. The gateways overview is blunt that “Anthropic doesn’t endorse, maintain, or audit other gateway products, and doesn’t support routing Claude Code to non-Claude models through any gateway.” A shop running Claude Code, Codex, and open-weights models behind one policy point is being asked to choose between a per-vendor gateway that tracks its vendor’s protocol perfectly and a neutral one that tracks several imperfectly — the tension Ashley framed as whether “per-vendor gateways or a neutral control point govern a multi-model estate.” Running both is the pragmatic answer and the honest one is that it means two policy surfaces to keep consistent.

6. The gaps that decide adoption

The unavailability table is short and specific, and several entries will disqualify the gateway outright for some teams:

• No service-token flow for CI. “Gateway sign-in always runs the browser device flow, so a CI job with no developer to approve the sign-in can’t authenticate; configure those against your provider directly.” Unattended pipelines stay outside the control plane entirely — which means spend caps, model allowlists, and policy delivery don’t cover them. For teams whose agent spend is increasingly pipeline-driven rather than laptop-driven, that is a substantial hole. InfoQ’s coverage notes the workload-identity gap drew immediate practitioner comment.
• One OIDC issuer per gateway, no multi-tenancy; run separate instances. OIDC only — front SAML or LDAP with a bridge.
• No admin UI and no Helm chart. “Configuration is the YAML file; redeploy to change it.” Caps are the exception, being API-driven.
• Linux server only; macOS for local development.
• Feature losses on gateway sessions. Server-side web search is disabled because the CLI can’t tell which upstream it’s routed to. The 1-hour prompt-cache TTL is off — gateway sessions use the 5-minute TTL — as are first-party-only optimizations like global cache scope and token-efficient tools. For long-running agent sessions, the shorter cache TTL is a plausible cost regression, though public reporting hasn’t quantified it against the gateway’s own metering.
• Private-network requirement. Claude Code refuses to /login to a self-hosted gateway whose hostname resolves to any public address, and the CLI pins the gateway’s TLS leaf certificate per hostname on first connect, so certificate rotations must be treated as planned events with the fingerprint republished.

AWS’s guidance repository, which had these capabilities in its superseded stack, publishes its own gap list: native IAM Identity Center authentication without an external OIDC provider; historical usage analytics via S3 and Athena; and IAM principal-based cost allocation, noting that “Gateway spend controls are based on cost estimates.”

One capability worth not over-crediting to the gateway: per-user usage telemetry does not require it. Claude Code has emitted OpenTelemetry metrics natively for some time, including a claude_code.cost.usage metric in USD with model, session, and user attributes, configurable through managed settings that users can’t override (monitoring docs). What the gateway adds is that identity is stamped from the signed session JWT rather than from client-set attributes, and the OTLP export endpoint is pinned server-side. That’s a meaningful integrity improvement over self-reported client telemetry, not a new capability.

7. Three architectures for the same control plane

The coding-agent control plane is productizing on both sides of the vendor line, but in structurally different shapes — and the comparison is a three-way one, not the two-way split it is usually drawn as.

OpenAI’s managed path for Codex keeps governance in its own platform: workspace membership, seats, groups, and RBAC in ChatGPT Enterprise settings, with local policy delivered as a requirements.toml “through a supported cloud, device, or system channel,” and usage visibility through an analytics dashboard, an Analytics API, and a Compliance API (Codex enterprise admin setup).

But OpenAI also ships a customer-controlled path, and any comparison that omits it is wrong. Codex can run against Amazon Bedrock, in which case “Codex runs locally in the CLI, desktop app, or IDE extension,” authentication “uses AWS credentials or another Bedrock-supported authentication method,” and — the load-bearing detail — “the OpenAI-hosted Responses API is not in the request path.” Access, governance, billing, quotas, regions, and request handling are managed “through their AWS account and applicable Amazon Bedrock controls” (Use Codex with Amazon Bedrock). That is a genuinely customer-controlled inference path with AWS-native governance. What it is not is an equivalent of the gateway: there is no self-hosted OpenAI gateway binary consolidating OIDC identity, per-group policy delivery, telemetry fan-out, and spend caps into one process, and the Bedrock path gives up the cloud-hosted Codex features. The accurate distinction is about what is consolidated and by whom, not about whether the vendor hosts the data plane.

Anthropic’s model puts the gateway’s inference and governance data plane in the customer’s network: “the gateway’s own data plane sends nothing to Anthropic infrastructure unless the Anthropic API is a configured upstream,” and telemetry, audit logs, managed settings, and IdP identity go only where the operator points them. Note the scoping in Anthropic’s own wording — it is the gateway’s data plane. The host process is separate and does talk home: the deployment guide states that “the host process is the Claude Code CLI, which can send startup analytics and update checks to Anthropic,” alongside the client-side URL domain-safety preflight discussed above. Those are disableable through managed settings, but they are residual egress a network review will find, and “nothing leaves your network” is not the claim the documentation supports. Anthropic’s own documentation says the gateway is aimed at organizations that must route inference through their own cloud provider — for example to meet data-residency requirements — and steers everyone else toward Claude Enterprise, which is where SCIM provisioning and Claude Code on web and mobile live. That’s an unusually clean piece of vendor self-differentiation, and it maps directly onto the decision: if the constraint is data residency or network perimeter, the self-hosted gateway is the fit; if the constraint is provisioning and surface coverage, the subscription org is, and the feature-availability matrix shows what a third-party-provider deployment gives up either way — the analytics dashboard, server-managed settings, and every subscription-only surface.

Practical Implications

If you run Claude Code on Bedrock, Google Cloud, Foundry, or Claude Platform on AWS, price the migration now. A container, a small managed Postgres, one OIDC app registration, and a gateway.yaml with five sections is a smaller project than most in-house equivalents, and there’s no license cost. Requires CLI v2.1.195 or later on both the server and every developer machine — v2.1.198 for the Claude Platform on AWS upstream — so the client-version floor is a real rollout dependency.

Write the enforcement boundary into your security documentation explicitly. Two columns: enforced at the gateway (model allowlist, spend cap, credential custody, session expiry on deprovision) and delivered to the client (permission rules, MCP allowlists, sandbox rules, hooks). Auditors and incident responders will make different assumptions about each. Treat the gateway host at MDM tier in your access model.

Do not skip the network-egress work. The gateway is a chokepoint only if egress policy makes it one. Decide deliberately, and if you block direct egress, set skipWebFetchPreflight: true in the managed policy so you know you’ve traded away the client-side URL domain check rather than discovering it in a ticket.

Deploying Claude Desktop too? Set parentSettingsBehavior: "merge" and mirror it into whichever source wins on each machine. Without it, embedded Desktop sessions run unrestricted and nothing warns you. Verify with the Agent SDK’s resolveSettings() and check the policyOrigin field rather than assuming your file won.

Set caps deliberately, then decide fail-open vs. fail-closed on purpose. Start with a per-seat org default and tighter group caps for contractors and new hires. If your reason for adopting this is the runaway-agent scenario, the default fail-open behavior on a Postgres outage undercuts it — flip enforcement.fail_closed_on_error and accept that a store outage becomes an inference outage. Reconcile against provider billing monthly; the gateway’s ledger is list-price estimation.

Solve CI separately and say so out loud. Pipeline agents can’t authenticate through the gateway, so they need their own provider credential, their own budget mechanism, and their own policy delivery. A control plane that covers laptops and not pipelines should be described that way internally, or the coverage gap becomes an assumption nobody rechecks.

If you already run a multi-model gateway, don’t rip it out — bound it. Keep the neutral gateway for the multi-provider estate and evaluate the first-party one for the Claude Code path specifically, where the forwarding contract keeps changing with each CLI release. If you keep a self-maintained gateway on that path, adopt three rules from the contract: forward anthropic-* headers and bodies verbatim rather than allowlisting, return upstream error bodies unmodified, and exempt the path from WAF request-body inspection.

Open Questions

• Does the protocol stay open? Anthropic publishes the gateway contract at GET /protocol and documents it for third-party implementers, but states that breaking changes are announced in advance while “indefinite backwards compatibility isn’t guaranteed.” Whether third-party gateways can realistically track a contract that ships with a weekly-cadence CLI is unproven either way.
• Does workload identity arrive for CI? The absence of a service-token path is the most-cited gap, and public reporting so far shows workarounds discussed rather than a roadmap commitment.
• Does per-action authorization land here or in a separate tier? The gateway sees every inference request but not the tool calls the agent then makes locally. Whether the control plane grows toward action-level decisions, or that stays with the MCP and runtime-authorization layers, is unresolved in public documentation.
• Do other coding-agent vendors follow the self-hosted shape? OpenAI’s Codex governance is vendor-hosted today. Whether data-residency pressure pulls other vendors toward shipping a customer-hosted control plane, or Anthropic’s choice stays a differentiator tied to its multi-cloud distribution, is the thing to watch over the next few quarters.
• How much does the shorter cache TTL cost in practice? Gateway sessions lose the 1-hour prompt-cache TTL. For long agent sessions that’s a real economic difference, and no public measurement of the delta has surfaced.

Sources

1. Introducing the Claude apps gateway for Amazon Bedrock and Google Cloud — Anthropic, June 29, 2026
2. Claude apps gateway for Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry — Claude Code documentation
3. Claude apps gateway spend limits — Claude Code documentation
4. Claude apps gateway deployment and operations — Claude Code documentation
5. Run Claude Code through a gateway — Claude Code documentation
6. Gateway protocol reference — Claude Code documentation
7. Roll out an LLM gateway for your organization — Claude Code documentation
8. Monitoring usage with OpenTelemetry — Claude Code documentation
9. Feature availability — Claude Code documentation
10. Introducing Claude apps gateway for AWS — AWS Machine Learning Blog, July 8, 2026
11. Announcing Claude apps gateway for Google Cloud — Google Cloud Blog, July 1, 2026
12. AWS Ships Claude Apps Gateway as Self-Hosted Control Plane for Claude Code and Claude Desktop — InfoQ, July 2026
13. Anthropic Adds Enterprise Gateway to Simplify Claude Code Access on AWS and Google Cloud — DevOps.com, July 1, 2026
14. Guidance for Claude Code with Amazon Bedrock — AWS Solutions Library Samples (repository README)
15. Claude Apps Gateway — issue #737 — AWS Solutions Library Samples, opened July 2, 2026
16. AI Agents with Cloud Credentials Are Outrunning Billing Guardrails — InfoQ, July 2026
17. Enterprise-Managed Authorization — Model Context Protocol blog, June 2026
18. LiteLLM proxy — budgets and rate limits — LiteLLM documentation
19. Codex enterprise admin setup — OpenAI / ChatGPT Learn documentation
20. Use Codex with Amazon Bedrock — OpenAI Help Center
21. Enterprise AI controls & the agent control plane are in public preview — GitHub Changelog, October 28, 2025
22. What is AWS Cost Explorer? — AWS Cost Management User Guide