Best practices for securing agent interactions with Model Context Protocol

Model Context Protocol (MCP) standardizes how generative AI agents connect to Bigtable. Due to the inherent risks of autonomous agents, mitigating vulnerabilities like prompt injection requires a shared responsibility model, combining platform controls with secure application design.
To design and deploy AI applications that use Google Cloud Model Context Protocol (MCP) tools, follow the best practices in this guide.

Before you begin

When you use MCP tools, your application's security posture depends on the agent's interaction model. To learn how your use of agents impacts the security risks associated with integrating agents with an MCP server, see AI security and safety.

Security responsibilities

As a customer, you are responsible for the secure configuration and operation of your agent platform.

Follow the principle of least privilege

Run your agent with a minimally-scoped service account. This is the first and most critical layer of defense.

  • Dedicated identity: Create a separate, dedicated service account for each unique agent or application using MCP tools. Do not reuse existing SAs, especially those with broad permissions.
  • Minimal scopes: Grant the service account only the necessary Identity and Access Management (IAM) roles—for example, alloydb.viewer, not alloydb.admin. If the agent only needs read access to a specific dataset, use custom IAM roles to restrict access to the absolute minimum needed for its function.
  • Separation of duties: If an agent needs both read access to data and write access to a log or temporary storage, use two separate service accounts—one account for high-risk data access (minimally scoped) and one for low-risk operational tasks.

Use database-native granular controls

For the strongest defense, combine IAM roles with the granular access controls offered by the database itself. This ensures that even if an attacker compromises the agent's IAM token, the scope of damage is limited by the database engine's internal permissions—for example, preventing a DROP TABLE command.


Product
Granular Control Mechanism
Focus

Cloud SQL and AlloyDB
Database-level roles like CREATE ROLE in PostgreSQL and MySQL.
Manage permissions in a specific database instance and schemas.

BigQuery
Column-Level Access Control (using policy tags)
Restrict agent access to sensitive columns—for example, PII— even in an authorized table.

Spanner
Fine-Grained Access Control (Database roles with GRANT/REVOKE)
Enforce precise read/write/update permissions on tables and columns.

Firestore
IAM roles and IAM conditions
Configure per-database access permissions using IAM roles and IAM conditions.

Bigtable
IAM roles
Bigtable offers granular control through IAM roles at the project, instance, and table levels.

Oracle Database@Google Cloud
IAM roles
Oracle Database@Google Cloud offers granular control through IAM roles at the project and resource levels.

Secure agent design

Agent-Only models require robust application-level defenses against prompt injection attacks, which attempt to override the system prompt. For more information, see AI safety and security.

Treat data and user inputs as untrusted

Treat input from end users, or data fetched by the agent from external sources—like a web search result or a third-party document—as untrusted.

Implement action-selection patterns

Avoid open-ended plan and execute architectures, in which the system decouples high-level task specification from mechanical execution. Instead, use design patterns that limit the model's freedom.

  • Action-selector pattern: the model's only job is to translate a user request into one of a small, pre-defined set of safe functions. The action logic is hard-coded and can't be modified by the LLM. This helps to make the agent immune to injection attacks targeting control flow.
  • Dual-LLM pattern: use a primary LLM (the action LLM) that performs the core task, and a secondary, highly-secure LLM (the guardrail LLM) that pre-screens the user prompt for malicious intent and post-screens the action LLM's output for unauthorized actions or data leakage.

Prevent unauthorized tool chaining

Agents must only call tools that are necessary for the task. Make sure that your orchestration code prevents the following:

  • Dynamic tools: the agent must not be able to dynamically register new tools or change the permissions of existing tools.
  • Allowlist enforcement: declare an allowlist of functions or database tables that the agent can access in its initial system prompt and backend code. For a Gemini CLI example, see Restricting Tool Access.

Limit data access in multi-tenant databases

A general tool like execute_sql lets the caller execute database queries that can read any data that IAM and database permissions allow access to. When you create an agent that accesses data in a multi-tenant application without a trusted human in the loop, you might need to limit data access further.

To make sure that the agent can only read subsets of the data that it has access to, we recommend that you create custom tools using a framework like