Skip to lesson

Google CloudProfessional Agentic Architect2026-095.1 Configuring agent security and governance

Control agent traffic with Agent Gateway

Completed by the knowledge check

Learning objective

Use Agent Gateway as a controlled traffic, authentication, policy, and observability boundary for agent interactions.

Core idea

Treat Agent Gateway as an inline checkpoint. A request gains gateway protection only when its network path crosses that checkpoint:

caller -> Agent Gateway -> destination
             |  |  |
             |  |  +-- record traffic and decisions
             |  +----- evaluate applicable policy
             +-------- authenticate supported identities

The gateway centralizes controls that would otherwise be implemented differently in every agent and tool. It is not the identity issuer, registry, or final business-authorization service. Agent Identity supplies a verifiable principal, Agent Registry supplies destination metadata, and the destination still decides whether the authenticated caller may perform a particular business operation.

Agent Gateway is the network entry and exit point for governed agent interactions. Its value depends on coverage: a direct path around it is an ungoverned path.

How the boundary works

Agent Gateway has two governed access paths:

  • Client-to-Agent (ingress) places the gateway in front of an agent or tool on Agent Runtime. It controls traffic arriving from clients.
  • Agent-to-Anywhere (egress) places the gateway between a managed agent and agents, Model Context Protocol (MCP) servers, tools, or APIs. It controls what the agent can call.

Agent Runtime supports both modes. Gemini Enterprise supports egress only. These modes are not interchangeable, and their policy capabilities differ. For example, gateway IAM access policies and Identity-Aware Proxy (IAP) enforcement apply to egress, not ingress. See the deployment-mode and policy matrix.

For egress, the boundary performs four related jobs:

  1. Control traffic. Route agent calls through one governed point. Agent Gateway supports HTTP-based traffic, including MCP and Agent2Agent (A2A). It can pass through general HTTP traffic and can extract MCP method and tool attributes for more granular decisions.
  2. Authenticate. IAP authenticates agent identities to the gateway. Agent Identity uses an X.509 certificate and certificate-bound token; mutual TLS (mTLS) protects access to the gateway, and Demonstrating Proof of Possession (DPoP) protects use of the bound token beyond it. For an external service, Auth Manager can supply an API key or OAuth credential, but the destination still validates that credential. See end-to-end agent identity authentication and Auth Manager authentication models.
  3. Enforce policy. IAM access policies use the source agent principal, destination, and request attributes in Common Expression Language (CEL) conditions. Rules can allow or deny access. A matching deny takes precedence over an allow. Registered destinations support stable resource attributes; unregistered endpoints can be governed by host and request attributes, but are harder to manage as approved resources. The IAM access-policy overview describes these inputs and effects.
  4. Create evidence. Gateway logs capture HTTP request data and can include the matched Agent Registry resource, MCP method and tool, and information about the authorization extension that processed the request. The gateway dashboard summarizes requests and authorization failures. See Monitor traffic through Agent Gateway.

Key distinctions and trade-offs

Authentication versus authorization: Authentication establishes which principal made the call. Gateway policy decides whether that principal may cross the route. The tool or API still enforces operation-level and data-level authorization. A valid credential does not imply permission.

Registered versus unregistered destinations: Registering a destination gives policy a governed resource identity and enables resource- or tool-level conditions. Host-based rules for an unregistered endpoint can support a transition, but DNS names and URL patterns are weaker governance handles than an owned registry resource.

Central enforcement versus dependency risk: One checkpoint reduces policy drift and produces consistent evidence. It also becomes part of the request’s latency and availability path. Deploy it in the required region, monitor its failures, and keep destination-side authorization so a bypass cannot become a privilege bypass.

Dry-run versus enforcement: Dry-run is useful for measuring the effect of a policy before rollout. It logs traffic that would be denied but does not block it. Move to enforcement only after testing expected calls and intentional denials. Google recommends this staged approach in the Agent Gateway setup guidance.

Architecture / decision scenario

A finance agent reads exchange rates from an external MCP server and submits payments to an internal API. The platform team deploys an egress gateway in the agent’s region, registers both destinations, and ensures the runtime routes outbound calls through it.

The access policy allows the finance agent’s SPIFFE principal to call the MCP server’s get_rate tool and to send payment requests only to the internal API. It denies calls to unregistered hosts. Auth Manager supplies the MCP server’s OAuth credential. The internal API separately checks the agent identity, delegated user authority, account ownership, and payment limit.

The team first uses dry-run and examines gateway logs. Expected rate requests match the registered server and tool. A test call to a look-alike host appears as a would-be denial. After fixing one required monitoring endpoint, the team switches to enforcement and blocks direct egress routes.

This design uses the gateway for traffic admission and evidence without asking it to decide whether a particular account may send a particular payment. The payment API owns that business decision.

Common exam traps

  • Assuming that deploying a gateway automatically redirects every network path through it.
  • Treating ingress and egress as equivalent or applying egress IAM policy behavior to ingress.
  • Treating successful authentication, registration, or OAuth token injection as authorization for the requested operation.
  • Expecting arbitrary HTTP payloads to provide the same tool-level policy attributes that the gateway extracts from MCP traffic.
  • Assuming dry-run blocks prohibited requests.
  • Replacing destination authorization with a gateway rule.
  • Collecting logs without correlating the agent principal, destination, operation, policy decision, and trace identifier.

What to remember

  • Agent Gateway controls a request only when the request crosses the gateway.
  • Choose ingress or egress from the direction of the traffic and the controls each mode supports.
  • Use authenticated agent identity and stable destination attributes in least-privilege egress policies.
  • Keep credential handling and destination authorization distinct from gateway route authorization.
  • Test policies in dry-run, enforce them deliberately, and monitor both allowed and denied traffic.

Knowledge check

References