Compose governance across agent boundaries

Learning objective

Design governance and policy enforcement across identity, registry, gateway, tool, and content boundaries. This lesson focuses on composing the boundaries, not on configuring each product in detail.

Core idea

Treat governance as a chain of independent policy decisions, not as one security check at the edge:

effective permission = trusted identity
                    AND approved destination
                    AND permitted route
                    AND permitted operation
                    AND acceptable content

Each term answers a different question. A request proceeds only when every applicable term permits it. Registration makes a tool discoverable and governable, but does not authorize an agent to call it. Authentication proves the principal, but not whether its requested action is allowed.

This is defense in depth with distinct controls. Enforce each rule at the boundary that has enough trusted context to decide correctly.

How the boundaries work together

A policy decision point evaluates a rule. A policy enforcement point intercepts the operation and applies the result. Design both explicitly; a policy document or scanner verdict without an enforcement point does not control behavior.

Agent Identity provides a distinct, cryptographically attested principal. IAM allow and deny policies grant or block permissions, while a PAB limits eligible resources for supported permissions. Identity therefore gives policies a reliable subject; it does not grant access by itself.

Agent Registry is the inventory for agents, MCP servers, endpoints, skills, and metadata. Restrict who can change entries, and require ownership and lifecycle metadata. Registry IAM roles control management and discovery. Runtime communication uses separate Agent Gateway policies, as the Agent Registry access-control documentation explains.

Agent Gateway is the traffic enforcement boundary for client-to-agent and agent-to-anywhere communication. It can use identity, registry, destination, protocol, and tool attributes in authorization decisions. IAM Access policies can contain allow and deny rules; deny rules are evaluated first. Remove alternate network paths that bypass the gateway, or those policies cover only some traffic.

The tool remains the final authority for its own operation. It knows facts the gateway might not know, such as whether an account belongs to the delegated user, an amount exceeds a limit, or a record permits change. Derive security-sensitive scope from verified identity context. Do not trust a model-generated tenant ID or readOnly annotation. The MCP tools specification requires clients to treat tool annotations as untrusted unless they come from a trusted server.

Content policy evaluates payload meaning, not permission. Apply it on the relevant ingress and egress paths, including tool arguments and results when they can carry instructions or sensitive data. The Model Armor integration with Agent Gateway can inspect traffic and enforce templates inline. A clean content verdict does not authorize a tool call, and an authorized call can still contain prohibited content.

Correlate evidence across boundaries. Record the actor, delegated subject, registry resource, policy version, destination, operation, decision, and trace ID. Keep secrets and sensitive content out of ordinary logs. Agent Gateway exposes request and access-decision logs, as described in Monitor traffic through Agent Gateway.

Key distinctions and trade-offs

Central policy versus local enforcement: Central policy reduces drift and makes fleet-wide changes easier. Local tool enforcement sees richer business state and remains effective if traffic reaches the tool through another path. Use a shared policy model with enforcement at both the gateway and the tool.

Broad registry rules versus resource rules: Registry-wide access simplifies onboarding but increases blast radius as new entries appear. Resource- and tool-scoped rules require more maintenance but preserve least privilege.

Fail closed versus fail open: Deny when a required control cannot decide on identity, destination, operation, or high-risk disclosure. A documented low-risk degraded mode must never widen privilege.

Architecture / decision scenario

A customer-support agent reads cases and can request a refund through an ERP MCP server. The organization also permits a vendor-hosted knowledge endpoint.

The agent receives its own Agent Identity; delegated user context remains separate. Agent Registry contains the approved ERP server and vendor endpoint, their owners, lifecycle status, and connection metadata. Agent Gateway denies egress by default, then permits this agent to call the knowledge endpoint and the ERP get_order and request_refund tools. It rejects an unregistered look-alike endpoint even if a prompt supplies its URL.

The ERP server independently verifies the agent and user, checks tenant and order ownership from trusted context, validates the refund amount, and enforces the order-state rule. Content inspection blocks injected instructions in vendor results before they return to the agent and prevents secrets from leaving in tool arguments. A trace connects the registry entry, gateway decision, content verdict, and ERP result.

If the registry approves the ERP server but no gateway rule permits request_refund, the call is denied. If the gateway permits the route but the order is ineligible, the tool denies it. This is the intended composition, not duplicate work.

Common exam traps

• Treating a registry entry or binding as runtime authorization.
• Treating authentication, a valid token, or a content scan as permission to perform an operation.
• Enforcing policy only at the gateway even though the tool owns resource and business-state rules.
• Adding a gateway while leaving a direct endpoint that agents can use to bypass it.
• Trusting model-generated identifiers or unverified tool annotations as policy inputs.
• Logging decisions at each service without a shared trace ID and policy version.
• Failing open when a required identity, authorization, or content decision is unavailable.

What to remember

• Give each boundary one explicit governance question and enforcement point.
• Compose applicable decisions as an intersection; no control substitutes for another.
• Use identity as policy input, the registry as governed inventory, and the gateway as the traffic choke point.
• Keep operation and business authorization at the tool and data boundary.
• Inspect content where it crosses trust boundaries, then correlate every decision without logging sensitive payloads.

Knowledge check

References

• Google Cloud, Agent Identity overview
• Google Cloud, Agent Registry overview
• Google Cloud, Agent Gateway overview
• Google Cloud, IAM Access policies for Agent Gateway
• Google Cloud, Principal Access Boundary policies
• Google Cloud, Integrate Model Armor with Agent Gateway
• Model Context Protocol, Tools specification