Gemini Managed Agents Get Files and Credentials APIs

Google shipped an updated harness for its Gemini API managed agents on September 17, 2026 — antigravity-preview-09-2026 — bringing the tools and behavior of its standalone Antigravity coding agent directly into the Interactions API and AI Studio, running by default on Gemini 3.8 Flash. Alongside the harness update, Google introduced two new APIs: a Files API for moving data in and out of an agent's sandbox, and a Credentials API that lets an agent authenticate to services like GitHub or Slack without the underlying model ever seeing the actual secret. Here's what a managed agent actually does, what's new in the Files and Credentials layers, and the one concrete migration note that could break existing code.

TL;DR

What a Gemini managed agent actually does

A single API call to ai.interactions.create() spins up an agent inside an isolated Linux sandbox hosted by the Gemini API — the agent reasons, executes code, manages files, and browses the web, following a plan-act-observe-repeat loop until the task is done or it hits a context or token limit. Out of the box it ships with bash code execution, filesystem tools (read, write, edit, search, list), google_search and url_context for web access, support for custom function tools, and remote MCP server connections. Long sessions get automatic context compaction around 135K tokens rather than simply truncating or failing.

The harness is configurable at two levels: inline on a single call via agent_config (model choice, max_total_tokens spend cap, tool selection), or saved once via agents.create() and referenced by ID for reuse — Google's own example is a cheap, search-only "paper scout" agent capped at 500K tokens and restricted to google_search and url_context tools, a pattern worth comparing against explainx.ai's own coverage of scoping agent permissions tightly to the task rather than granting broad default access.

Files API: sandbox I/O without parsing text output

Before this update, getting a file an agent produced meant either parsing it out of the model's text response or building your own upload/download plumbing around the sandbox. The Files API makes the sandbox environment directly addressable: your first interaction returns an environment_id, and from there you can files.list() to see what the agent wrote, files.upload() to add new data mid-conversation, and files.download() to pull a specific file out — a CSV in, a self-contained HTML dashboard out, without touching anything else the agent generated along the way. The environment persists across turns, so a second interaction referencing the same environment_id and a previous_interaction_id can build directly on files a prior turn created — upload Q4 sales data, ask the agent to extend a dashboard it already built from Q3 data, and it works from the existing sandbox state rather than starting over.

Credentials API: the model never sees the secret

This is the more consequential of the two additions from a security standpoint, and it addresses a real, common failure mode in agent tooling: passing clear-text API tokens into a request where a prompt-injected or simply careless agent could leak them. The Credentials API supports three types — bearer_token for MCP servers and APIs using an Authorization header, environment_variable for anything the agent calls via curl or an SDK inside the sandbox (scoped to an explicit trusted_domains allowlist), and oauth2 for providers issuing refresh tokens, which Google's API refreshes automatically before expiry.

The mechanism is the interesting part: a credential attached to a remote MCP server tool gets its Authorization header added by the Gemini API itself, outside the model's context entirely. A credential bound to a sandbox environment variable gives the container only a placeholder string — something like __GEMINI_CRED_slack-bot-token__ — and an egress proxy swaps in the real value only when the outbound request actually reaches a domain on the trusted_domains list. If a prompt injection or a bug tricks the agent into sending that placeholder to an untrusted host, the proxy sees an unreplaced placeholder and returns a 403 instead of forwarding anything — the secret is structurally unreachable from inside the sandbox, not just policy-restricted. That's a materially stronger guarantee than the common pattern of trusting an agent's own judgment not to leak a token it was handed directly, and it's the same class of problem explainx.ai covered from a different vendor's angle in Meta Muse's Sentinel-brokered network access architecture.

Performance changes worth knowing before you migrate

Google reports the new harness delivers meaningfully better caching on long conversations — roughly 9% higher cache hit rate on multi-turn coding and research tasks, and roughly 22% higher on long question-answering runs — which it says translated into a 17% cost reduction on reasoning tasks and 30% lower cost on multi-turn coding, per internal evals. Separately, it reports 40% fewer output tokens on file edits and up to roughly 8% higher task completion on multi-turn software engineering and research tasks. These are Google's own internal eval numbers, not an independently reproduced benchmark, and worth treating with the same caution explainx.ai applies to any single vendor's self-reported performance claims.

The one concrete breaking detail: tool names in step events changed — file tools now report as view_file, write_to_file, and replace_file_content rather than their prior names — so any code that filters or logs based on specific tool names in step events needs a small update before switching harnesses. Pricing itself is unchanged, and Google states existing requests continue to work unmodified.

Honest limitations

• Performance gains are Google's own internal eval numbers, not independently reproduced or benchmarked by a third party.
• antigravity-preview-05-2026 is deprecating October 5, 2026, with automatic redirection after that date — teams relying on the old harness's exact tool-naming behavior in step events have a hard deadline to update filtering code.
• The Credentials API's guarantees depend on correct trusted_domains scoping — a credential given an overly broad allowlist loses much of the practical protection the placeholder/egress-proxy design otherwise provides.
• This is a preview harness (antigravity-preview-09-2026), not a stable, versioned release — the naming convention itself signals Google expects further iteration.

Comparing the credential pattern to what other providers ship

The placeholder-plus-egress-proxy design is worth situating against how other agent platforms have approached the same problem. A common, weaker pattern is passing an API key or token directly into an agent's system prompt or environment, trusting the agent's own judgment (and the underlying model's alignment) not to leak it into a response, a log line, or an unintended outbound request — a pattern that fails specifically when a prompt injection or a bug tricks the agent into doing exactly that. Google's design removes that trust requirement structurally: the credential is never in a place the model can read it from, so there's no judgment call for the agent to get wrong in the first place.

This is the same category of design decision explainx.ai covered in Meta Muse's Sentinel-brokered architecture, where a kernel-level process — not the model — approves every network request, and it's the same broader principle behind restricting Claude Desktop's file and app access: enforcement that happens outside the model's own reasoning is more robust than enforcement that depends on the model behaving correctly under adversarial pressure. As agent platforms mature, this pattern — credentials the model can request the effect of but never directly observe — is likely to become the baseline expectation rather than a differentiator, the way TLS became table stakes for web traffic rather than a selling point.

What this means for builders

The Files and Credentials APIs are the more durable news here relative to the harness performance numbers, because they solve infrastructure problems every team building agentic products eventually hits: getting structured data in and out of a sandboxed agent cleanly, and giving an agent real tool access without handing the model itself anything it could leak. If you're building agent tooling on any provider, the placeholder-plus-egress-proxy credential pattern here is worth studying as a design reference regardless of which platform you ship on — and worth asking about directly if your current agent stack still passes secrets into a prompt or an environment the model can read from.

Related on explainx.ai

• Google Cloud agent sandboxes: five things about isolation
• Google Antigravity: boost, deep reasoning, command
• Meta Muse's Sentinel security architecture
• How to restrict Claude Desktop's access: a sandbox guide
• Gemini 3.8 Flash launch and coding benchmarks
• How to read AI benchmark claims critically
• Build your first MCP server: a step-by-step guide
• Official source: Google AI Studio — Gemini API Managed Agents Update

This post is sourced to Google's own September 17, 2026 announcement and technical documentation. Performance figures (cache hit rates, cost reductions, task completion rates) are Google's self-reported internal eval results; no independent third-party benchmark was available at time of writing.