Gemini's Credentials API keeps secrets out of the agent sandbox

Most agent setups hand the agent the API key and hope. Google's new Credentials API stops doing that, and the design is worth stealing whether or not you run on Gemini. Alongside a refreshed antigravity-preview-09-2026 harness, Google shipped a Credentials API for managed agents that stores secrets server-side and injects them at the network edge. The agent never sees the token it is using.

What actually happened

The updated harness brings the Antigravity coding agent's tools and behavior into the Gemini API, running on Gemini 3.8 Flash by default with the model swappable per interaction via agent_config.model. Per Google's docs, each run gets an Ubuntu sandbox with Python 3.12 and Node.js 22, persistent files across turns, and a configurable network allowlist. It's in public preview on free and paid tiers; environment compute is unbilled during preview.

The Credentials API is the part that changes how you should build. Three credential types — bearer token, OAuth2, and environment variable — all share one property: secret values are write-only. Once stored, no endpoint returns them. From the docs: a compromised agent "cannot read back the tokens it is using."

The mechanism is an egress proxy. Credentials attach to network allowlist rules by domain (exact or wildcard), to MCP server definitions as injected auth headers, or to environment variables. For the env-var type, the agent gets a placeholder; the proxy substitutes the real value only on outbound requests to trusted domains. Anything carrying that placeholder elsewhere is rejected rather than forwarded. OAuth2 credentials get refreshed server-side as access tokens expire, so the refresh token never enters the sandbox either.

Why agent secrets management matters for your business

The default pattern in every agent tutorial is GITHUB_TOKEN in the environment. That is fine right up until the agent is browsing the web, running code it generated, and talking to an MCP server you did not write — which is the whole point of the thing. At that moment a prompt injection, a malicious dependency, or a bad tool response only needs the agent to echo $GITHUB_TOKEN into its output.

The architecture here has three properties you should demand of any agent runtime you put on a client's systems:

Write-only storage. If your runtime has an endpoint that returns a stored secret, that endpoint is a credential dump waiting for an injection. Ours are write-only for the same reason.

Injection at egress, not in the process. The secret lives in the network layer, not in the agent's memory or filesystem. This is the difference between exfiltrating a token and merely being able to use it while the run lasts — one survives the session, one does not.

Domain-scoped placeholders. Binding a credential to specific hostnames is what stops the classic exfil move: agent gets convinced to POST its config to an attacker's endpoint. The placeholder goes out, the proxy refuses, nothing leaks.

You can approximate all three without Google. Run your agent behind a proxy you control, keep secrets in the proxy (or a vault it reads), and give the agent placeholder values with a strict outbound allowlist. It is an afternoon of work and it converts "agent leaked our Stripe key" from a company-ending event into a failed request in a log.

The honest caveat: this is preview, the docs list real gaps — no structured outputs, no computer_use, text and image inputs only — and none of it protects you from an agent that is authorized to do something destructive. Scope the credential's permissions too, not just its storage.

Sources: Google AI for Developers — Credentials in managed agents, Google AI for Developers — Antigravity agent.