Agent credential containment

Security teams can pilot a central OAuth broker for agents that need email, calendar, GitHub, or internal API access. The broker runs the browser login flow and receives the real OAuth token. It gives the agent a signed JWT that copies nonsecret claims and stores the real token as an encrypted claim. The agent sends API calls through a proxy, and the proxy verifies the broker signature, decrypts the embedded token, swaps it into the Authorization header, and forwards the request.

A useful first test is small: put the flow in front of one high-risk agent and instrument the container filesystem, tool outputs, logs, and repository writes. The pass condition is that the upstream OAuth token never appears in the agent runtime while the agent can still inspect scope-like claims and complete normal API calls. The same pilot should record latency and failure modes because the source proposal gives architecture, not deployment measurements.

Teams that already give agent workloads client certificates can bind broker-issued JWTs to the agent environment. The agent presents a client certificate when it asks the broker for a token. The broker embeds a representation of that certificate in the JWT. The proxy then requires mTLS and checks that the live client certificate matches the embedded certificate before decrypting the real OAuth token.

The practical security test is to copy a broker-issued JWT out of one agent environment and try to use it through the proxy from another environment. The expected result is proxy rejection unless the caller also has the private key for the original environment. Hardware-backed or hypervisor-backed private keys make that check more meaningful. This can be adopted even when the upstream identity provider has no support for RFC 8705 token binding.

Agent teams integrating with GitHub and other SaaS APIs should test broker adapters before committing to a shared production path. The broker may need provider-specific handling where login does not run through the enterprise identity provider. Opaque access tokens also need coverage: the broker can wrap the opaque token inside a new JWT as an encrypted claim, and the proxy can present the opaque token only after the mTLS check passes.

A practical adoption check is a provider matrix covering login flow, token type, claim visibility, refresh behavior, proxy header rewrite, and mTLS enforcement. GitHub is a good first case because the source calls out provider-specific login friction. Passing the matrix for two or three common SaaS services would show whether the broker can stay small or needs a larger adapter layer.