Access Context Manager lets you define different access levels for fine-grained control within an organization. Access levels are used for permitting access to resources based on contextual information about the request. Access levels are used by ingress policies to control calls from services outside a perimeter to resources inside the perimeter.
Access levels can't be used by egress policies, but you can use contextual information about requests in your egress policies to control what calls can be made from inside the perimeter to resources outside the perimeter.
Use the following api attributes in your access levels and
egress policies to control MCP use:
mcp.is_mcp: Indicates whether the API call is being made by an MCP service.mcp.tool.is_read_only: Indicates whether the MCP tool call is read-only.request.auth.oauth.client_id: The client ID of the agent principal making the MCP tool call.
Before you begin
- Set up a VPC Service Controls perimeter.
- Ensure that you have the correct permissions to use Access Context Manager.
Create a custom access level
Create a custom access level that uses the api
attributes to control MCP use within your perimeter. For example, the following
access level is only applicable to the principal with the OAuth client ID
12345678-example.apps.googleusercontent.com:
request.auth.oauth.client_id==12345678-example.apps.googleusercontent.com
For details about building Common Expression Language (CEL) expressions for custom access levels, refer to the custom access level specification.
Access levels only allow requests from outside a perimeter for the resources of a protected service inside a perimeter. To allow access from a protected resource inside a perimeter to resources outside the perimeter, create an egress policy. For more information, see Limitations of using access levels with VPC Service Controls
Configure context-aware ingress rules
Context-aware ingress rules allow access to resources in the perimeter based on client attributes such as network origin (IP address or VPC network), identity type (service account or user), identity, MCP tool call or call type, and device data defined either within the policy or within an access level.
Configure your ingress policy to use the custom access level that you created.
For example, the following ingress policy allows ingress to read-only MCP
tools in the project number 123456 within a corporate network with the IP
range 198.51.100.0/24:
- ingressFrom:
identityType: ANY_IDENTITY
sources:
- accessLevel: accessPolicies/222/accessLevels/corpNetwork_to_readOnlyMcpTool
ingressTo:
operations:
- serviceName: bigquery.googleapis.com
methodSelectors:
- method: "*"
resources:
- projects/123456
Where accessPolicies/222/accessLevels/corpNetwork_to_readOnlyMcpTool is the
name of an access level with the following conditions:
inIpRange(origin.ip, '198.51.100.0/24') && 'api.mcp.tool.is_read_only'== true
For more information about how to configure ingress rules, see Ingress rules reference.
Create an egress policy
Egress refers to any access that involves an API client or resources within the service perimeter and resources outside a service perimeter. You might want to use an egress policy to only allow access to Google Cloud APIs outside the perimeter to a specific principal.
For example, the following egress policy allows the principal
//agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-agent to access Cloud Storage outside the
perimeter. For more information about identities in egress rules, see
Supported identities for ingress and egress rules.
egressPolicies:
- egressTo:
operations:
- serviceName: storage.googleapis.com
methodSelectors:
- method: '*'
resources:
- projects/123
egressFrom:
identities:
- principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-agent
For more information about how to configure egress rules, see Egress rules reference.
Examples
The following are useful examples of access levels and ingress policies that control MCP use within a perimeter.
Deny ingress to MCP requests
The following access level evaluates to true for any API request that isn't sent with MCP:
api.mcp.is_mcp == false
The following ingress policy allows access to the perimeter for non-MCP API calls:
- ingressFrom:
identityType: ANY_IDENTITY
sources:
- accessLevel: ACCESS_POLICY
ingressTo:
operations:
- serviceName: SERVICE_NAME
methodSelectors:
- method: "*"
resources:
- projects/PROJECT_NUMBER
Replace the following:
ACCESS_POLICY: The name of the access level that you created. To list access levels, follow the instructions in List access levels.SERVICE_NAME: The name of the protected service—for example,bigquery.googleapis.com.PROJECT_NUMBER: The Google Cloud project number. To find the project number, see Find the project name, number, and ID.