Solo shipped agentgateway enterprise 2026.9.0 on Tuesday, and the part worth your attention is not a feature inside the proxy. It is where the token service now lives. The STS ships as its own binary, on a public bucket, installable with one command and no GitHub account. A setup that used to start with “provision a cluster” now starts with curl.
I verified the distribution end to end before writing this. The details, and the parts I could not verify, are below.
Why the token service is the piece that matters
Almost everything I have written here this year converges on one claim: an AI agent should never hold a durable credential. I made the argument directly in your AI agent should not hold the LLM API key, and the reason is not really about agents at all. It is that a long-lived key sitting in a process that takes instructions from a model is a key with an unbounded blast radius, and every incident writeup this year has said the same thing in different words.
The alternative is well understood. The caller authenticates once, and infrastructure exchanges that identity for a short-lived, narrowly scoped token per backend, per request. The agent never sees the backend credential. The user’s identity survives the hop, so the audit trail is still a chain rather than a shrug.
That exchange has to happen somewhere, and that somewhere is a token service. Which is exactly the component that has been hardest to try. The proxy side of this has been publicly documented for a while: agentgateway’s OAuth token exchange does the RFC 8693 single-leg exchange, Cross App Access does the two-leg ID-JAG flow for calling a downstream API as the authenticated end user, and signed JWT mints a per-request token for upstreams that will not take a durable credential at all. Those pages carry a “code examples on this page have been automatically tested” badge, which is more than most projects offer.
The enterprise token service is the other half, and until this release trying it meant standing up Kubernetes first. That is a real barrier for something you want to evaluate in an afternoon.
What actually shipped
Three things, which I summarised on X when the release landed:
- The token service can run without a signing key.
- Issuer files can be referenced from configuration.
- There is a
redirect_uriallowlist on the issuer.
The signing key change is the one that lowers the floor. A token service that requires you to produce and mount a signing key before it will start is a token service you evaluate next quarter. One that will come up without it is one you try today.
What I verified, and how
I do not publish install commands I have not run. Here is the actual evidence.
The version is published in the open. The bucket carries a plain-text pointer to the current release:
curl -s https://storage.googleapis.com/enterprise-agentgateway-standalone/releases.txt
v2026.9.0
The installer is public and needs no account. It answers with HTTP 200 and no credentials:
curl -fsSL https://storage.googleapis.com/enterprise-agentgateway-standalone/install.sh | sh
Read it before you pipe it to a shell, as you would with any installer. It resolves the version from releases.txt when you do not pin one, and it installs two components, not one:
COMPONENTS="agentgateway-enterprise:agentgateway agentgateway-enterprise-sts:agentgateway-sts"
and reports them on the way out:
agentgateway the proxy
agentgateway-sts the STS server
That second line is the whole story. The token service is a peer of the proxy now, a separate process you can run next to it, not a thing that only exists as a workload inside a cluster.
The artifacts are real and they match their checksums. Every artifact publishes a .sha256 next to it. I pulled the darwin-arm64 STS build and checked it:
BASE=https://storage.googleapis.com/enterprise-agentgateway-standalone
curl -fsSL "$BASE/v2026.9.0/agentgateway-enterprise-sts-darwin-arm64" -o agw-sts
curl -fsSL "$BASE/v2026.9.0/agentgateway-enterprise-sts-darwin-arm64.sha256" -o agw-sts.sha256
shasum -a 256 agw-sts
148,083,362 bytes, and the digest matched the published file exactly:
0097abcd7a2d0431ae1556add21e93ab7eb4c7faed864dd70ca7ce9fff0b6168
Binaries are published for linux/amd64, linux/arm64, darwin/arm64 and windows/amd64.
The container images are anonymously pullable. If you would rather stay on Kubernetes, the registry namespace is public. Both of these return a manifest with no credentials at all:
curl -s -o /dev/null -w '%{http_code}\n' \
https://us-docker.pkg.dev/v2/solo-public/enterprise-agentgateway/agentgateway-enterprise/manifests/2026.9.0
200
The same is true of agentgateway-enterprise-bundle, which is the one to look at if you want the proxy and the token service together rather than as two processes.
What I did not verify
The configuration. I checked the public documentation set for the STS server’s own configuration reference, including the llms.txt index and every documentation URL reachable from the standalone and Kubernetes trees, and I did not find one. The proxy-side exchange methods linked above are documented and tested; the token service’s own configuration surface is not in the public docs I could reach.
So this post tells you the token service ships as a standalone binary, that the binary is real, and that you can get it without an account. It does not show you a working agentgateway-sts configuration, because I could not validate one against a public source, and a configuration example that has not been run is worse than none.
If you are evaluating this, that is the gap to plan around: budget time with the product docs you get with the software rather than expecting a public quickstart.
Why “no cluster” is the actual change
It is easy to read a distribution change as packaging trivia. It is not, for this component specifically.
Agent identity is the least-settled part of the whole agent infrastructure stack. When I went through what the MCP specification actually ratifies versus what it merely proposes, in MCP agent identity: one spec shipped, three still open, the honest summary was that the ecosystem has one stable extension and a roadmap. DPoP and workload identity federation are both still open proposals. Nobody’s answer here is finished.
When a space is unsettled, the thing that decides which pattern people adopt is how cheaply they can try it. A token service that needs a cluster gets read about. One that is a binary on your laptop gets run, and the person who runs it forms an opinion about whether gateway-mediated identity is worth the operational cost. That opinion is the thing that actually moves.
The same logic applies in reverse to the credential problem. Everyone agrees agents should not hold durable keys. Far fewer people have actually watched a token exchange happen on a request they made themselves. The distance between those two states was, until Tuesday, a cluster.
Trying it
curl -fsSL https://storage.googleapis.com/enterprise-agentgateway-standalone/install.sh | sh
agentgateway --version
agentgateway-sts --version
The first command is validated. The two --version calls are the obvious next step and I have flagged them as unverified: I downloaded and checksummed the binary but did not execute it in the environment I wrote this from.
For the proxy side, the standalone quickstart is the place to start, and the backend authentication section is where the exchange methods live.
Where this goes
The interesting follow-up is not a feature request, it is a measurement. Once the token service runs on a laptop, you can put a stopwatch on the exchange and find out what per-request token minting actually costs at the p99, which is the number that decides whether anyone ships this in front of a latency-sensitive agent. That is a post I can write once I have a configuration I can validate.
Until then: the token service is a binary, the binary is public, and the checksum matches.
Disclosure: I work at Solo.io, which makes agentgateway. The OSS project is agentgateway/agentgateway; everything I verified above is publicly reachable without an account, and I have said explicitly which parts I could not verify.