Expanding Managed Agents in Gemini API: Background Tasks, Remote MCP and More

On July 7, 2026, Google DeepMind announced new capabilities for Managed Agents in the Gemini Interactions API: background execution, remote MCP server integration, custom function calling, and credential refresh across interactions.

These are production features. They turn a synchronous conversation API into an asynchronous worker runtime. Agents can now execute long-running tasks in the background, connect to private databases and internal APIs through remote MCP servers, call custom functions alongside sandbox tools, and refresh short-lived credentials without restarting the environment.

Each capability answers a real developer need. Each also expands the attack surface. Security teams evaluating Managed Agents for production workloads need to understand where the new risks are, what mitigations Google provides, and what remains the responsibility of the deploying organization.

What Changed

Managed Agents in the Gemini Interactions API previously operated as synchronous, request-response interactions. A client sent a request, the agent executed inside an isolated cloud sandbox, and the connection remained open until completion.

The July 2026 update adds four capabilities:

Background Execution

Developers can now pass background: true to run interactions asynchronously on the server. The API returns an interaction ID immediately, and clients poll or stream progress while the agent continues working remotely.

Security implication: Background execution means an agent can operate without a live client connection. There is no human in the loop during execution. If a background task encounters adversarial data — through an MCP server, a database query, or a previously injected memory — the agent will act on it without an opportunity for real-time intervention.

Remote MCP Server Integration

Managed Agents can now connect directly to remote Model Context Protocol (MCP) servers, accessing private databases, internal APIs, and enterprise services. Remote tools can be mixed with built-in sandbox capabilities like Google Search and code execution.

Security implication: This is the most significant expansion of the attack surface. MCP servers are the channel through which an agent receives external data. As demonstrated by the Agentjacking class of attacks disclosed in June 2026, data arriving through MCP is not inherently trustworthy. A Sentry MCP server returning attacker-submitted telemetry, a database MCP server serving poisoned records, or an internal API MCP server exposed without authentication — all become vectors into the agent’s decision loop.

Custom Function Calling

Developers can add custom tools alongside built-in sandbox tools. Built-in tools run automatically on the server, while custom functions transition the interaction to requires_action so the client executes local business logic.

Security implication: Custom function calling creates a split trust boundary. Built-in tools execute inside Google’s sandbox. Custom functions execute on the client side. If the agent reasons about data received from an MCP server and decides to invoke a custom function, the client-side execution inherits whatever permissions the calling process has.

Network Credential Refresh

Access tokens and short-lived API keys can be refreshed by passing an existing environment_id with a new network configuration. The sandbox keeps its filesystem state, installed packages, and cloned repositories intact.

Security implication: Credential refresh extends the lifetime of agent sessions. A session that should have expired with its credentials can continue operating. If credentials were compromised during the session, the refresh mechanism provides a window for exfiltration. The sandbox state — filesystem, packages, repositories — persists across credential refreshes, meaning a compromise that writes to the sandbox survives token rotation.

The MCP Trust Problem, Now In Production

The June 2026 Agentjacking disclosures showed that MCP has no trust tiering. Data from a public telemetry endpoint and data from an authenticated database arrive through the same protocol with the same trust level. The protocol does not distinguish between user-generated content and system-generated context.

Google’s Managed Agents update makes this architectural gap operational. Remote MCP servers are now first-class integrations in a production agent platform. Any MCP server that accepts unauthenticated input — public APIs, shared telemetry endpoints, internal services without origin verification — becomes a potential injection vector into the agent’s reasoning loop.

Google’s security documentation for Managed Agents references best practices and links to the Google Cloud guide for securing remote MCP servers. That guide identifies five deployment risks:

• Unauthorized tool exposure: A misconfigured MCP manifest can expose internal administration functions.
• Session hijacking: An attacker can steal a session ID to impersonate a legitimate user or inject payloads into an active session.
• Tool shadowing: Rogue MCP tools can mimic legitimate services and trick agents into interacting with them.
• Sensitive data exposure: Improperly configured environments can leak API keys, credentials, and PII.
• Authentication bypass: Weak authentication mechanisms can be exploited to gain unauthorized access.

The recommended mitigation is a centralized MCP proxy architecture on Google Cloud, using Cloud Run, Apigee, or GKE as an enforcement layer for authentication, authorization, request inspection, and routing.

This is a defense that depends on the deploying organization, not the platform. Security teams must decide whether to adopt the proxy pattern, how to configure it, and how to monitor it.

Background Execution and the Loss of Interactive Control

Background execution removes the synchronous human-in-the-loop model that many agent security controls depend on. When an agent runs in the background, there is no client connection to interrupt, no approval dialog to display, and no real-time log to review before the next action executes.

Google’s own guidance on securing AI agents, published by the Office of the CISO, identifies three fundamental principles: well-defined human controllers, limited agent powers, and observable agent actions.

Background execution directly tensions the first principle. A background agent has no live human controller during its execution window. The controller’s involvement is reduced to pre-authorization (starting the task) and post-hoc review (checking results). The agent acts autonomously in the gap between those two points.

Observability becomes critical. Google’s architecture includes audit logging through Cloud Logging and Security Command Center, but those are infrastructure-level logs. The agent’s internal reasoning — what data it read, what it inferred, what triggered each action — is not necessarily captured in the same log stream.

What Security Teams Should Evaluate

MCP Server Inventory

For every remote MCP server connected to a Managed Agent, document:

• Who can submit data to the server?
• Is the server’s endpoint authenticated?
• Does the server distinguish between user-generated and system-generated content?
• What tools does the server expose, and what permissions do those tools require?

Any server that accepts unauthenticated input is a trust boundary. Agents should not treat data from such servers as equivalent to authenticated data.

Background Task Authorization

Background tasks should be scoped to the minimum necessary permissions. If a task only needs read access to a specific database, it should not have write access to the filesystem or the ability to install packages. The credential refresh mechanism should issue short-lived tokens scoped to the task, not the user’s full session.

Observability and Audit

Monitor background tasks for:

• Unexpected tool invocations
• Credential refresh events outside normal cadence
• MCP servers returning unusually large or structured payloads
• Sandbox state changes that persist across interactions

Proxy Architecture for MCP

For organizations deploying multiple MCP servers, the centralized proxy pattern recommended by Google Cloud is not optional. Without it, each server enforces its own authentication, creating inconsistencies and blind spots. A proxy provides a single enforcement point for authentication, authorization, request inspection, and audit logging.

The Platform vs. Deployment Responsibility Gap

Google provides the sandbox isolation, the Interactions API, and the infrastructure for MCP proxy deployment. What it does not provide is a trust model for MCP channels, automatic content inspection for MCP payloads, or runtime guardrails for background execution.

These are not gaps in the product — they are architectural decisions. The protocol layer (MCP) was designed without trust tiering. The execution model (background) was designed for asynchronous operation. The security model assumes the deploying organization will supply the missing controls.

That assumption is reasonable for enterprise deployments with dedicated security teams. For smaller teams adopting Managed Agents without the proxy architecture, without runtime monitoring, and without MCP server access controls, the risk is higher.

References

1. Google DeepMind, “Expanding Managed Agents in Gemini API: background tasks, remote MCP and more” (blog.google, July 7, 2026). https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/
2. Google Cloud, “How to secure your remote MCP server on Google Cloud” (cloud.google.com, July 2026). https://cloud.google.com/blog/products/identity-security/how-to-secure-your-remote-mcp-server-on-google-cloud/
3. Anton Chuvakin, “How Google secures AI Agents” (Google Cloud Blog, June 2025). https://cloud.google.com/blog/products/identity-security/cloud-ciso-perspectives-how-google-secures-ai-agents
4. Tenet Security, “Agentjacking: Hijacking AI Coding Agents via MCP + Sentry” (PointGuard AI, June 12, 2026). https://www.pointguardai.com/ai-security-incidents/agentjacking-shows-coding-agents-can-take-the-bait