Protocol-Layer Security for MCP, A2A, and Agent Gateways

Use MCP-specific policy where tool names, resources, prompts, schemas, annotations, or method names materially affect authorization. This is especially important when one MCP server exposes both read and write operations.

The teams that skip this step usually end up with agents that work in demos but cannot pass production review.

Introduction

The practical pattern is to put an agent gateway in the request path, require explicit agent and tool registration, enforce least-privilege authorization at the protocol level where supported, broker credentials instead of embedding them in agents, and capture decision-grade telemetry for every tool or agent-to-agent request.

A practical MCP control model includes:

apiVersion: ai.security.dtd/v1 kind: AgentGatewayPolicy metadata: name: issue-triage-agent-policy environment: production spec: enforcementMode: enforce defaultDecision: deny

subjects: agents: – id: issue-triage-agent runtime: production owner: platform-automation users: requireUserContext: true

mcp: allowedServers: – id: github-operations-mcp trustLevel: internal-approved

allowedTools: – name: list_issues risk: read – name: get_issue risk: read – name: get_issue_comments risk: read

deniedToolRiskLabels: – write – destructive – credential-access

tokenControls: requireAudienceValidation: true forbidTokenPassthrough: true

a2a: allowedAgents: – id: change-advisory-agent trustLevel: internal-approved

allowedSkills: – name: summarize_change_risk risk: read – name: recommend_review_path risk: advisory

discovery: requireAuthenticatedExtendedCard: true

controls: stepUpRequiredFor: – risk: write – dataClassification: restricted – action: approval

contentInspection: promptInjectionDetection: enabled sensitiveDataLeakageDetection: enabled

credentialBroker: required: true noStaticSecretsInAgentRuntime: true

observability: logPolicyDecision: true includeFields: – traceId – userId – agentId – protocol – target – operation – decision – reason

Agent gateway policy should not live as ad hoc settings buried inside an agent framework. It should be treated like production infrastructure and security configuration.

Why Protocol-Layer Security Matters Now

A better target state is:

“Can the agent connect to the tool?”

A useful event should include:

The assumptions are straightforward:

“Only this agent can call this tool.”

For agentic systems, you usually need to separate at least four identities:

That question belongs in the gateway, policy layer, and application boundary together.

For enterprise teams, this changes the design question from:

TL;DR

For MCP, that can mean understanding the difference between tools/list, tools/call, resources/read, and a specific tool name. It can also mean using the MCP server’s authorization model, validating token audience correctly, preventing token passthrough, and treating tool annotations or risk labels as policy inputs.

Scope and Assumptions

This is where AI and DevOps meet. Agent capability should be promoted like infrastructure. Gateway policy should be versioned. Tool access should be reviewed through pull requests or change records. Observability should feed the same operational process used for service reliability and security response.

The goal is to provide a practical design model that security, platform, DevOps, and AI engineering teams can use before the environment becomes a web of direct agent-to-tool connections.

Assumption	Why It Matters
Agents will use multiple tools	Single-tool security patterns break down when tool catalogs grow.
Some tools are sensitive	Read-only lookup and destructive workflow execution need different policies.
Agent identity matters	A generic service account is not enough for investigation or least privilege.
User context may matter	Some actions must be authorized based on the user, not only the agent.
Gateway capabilities differ by vendor	Do not assume every gateway can parse every protocol attribute equally.
Application-level authorization still applies	A gateway should reduce risk, not become the only security layer.

The core problem is that agent traffic is not just API traffic with a chatbot in front of it. Agent traffic carries intent, delegation, context, and tool selection. Security controls need to inspect and govern those dimensions where the protocol and platform allow it.

MCP, A2A, and Agent Gateways Are Different Security Surfaces

For an agent gateway, protocol-layer security means the gateway is more than a reverse proxy. It becomes a policy enforcement point that can combine identity, route, target, protocol attributes, content inspection, and telemetry.

Area	MCP	A2A	Agent Gateway
Primary purpose	Connect AI applications and agents to tools, prompts, and resources	Let independent agents communicate and collaborate	Govern, route, authenticate, authorize, and observe agentic traffic
Common interaction	Agent invokes a tool or reads a resource	Agent delegates or coordinates with another agent	Agent traffic passes through a central policy enforcement point
Capability description	Tool, prompt, and resource definitions	Agent Card and skills	Registry, target, route, policy, identity, and telemetry metadata
Security focus	OAuth, token audience, scopes, tool authorization, prompt/tool risks	HTTP-layer authentication, Agent Card security schemes, skill authorization, task delegation	Identity enforcement, protocol-aware policy, egress control, audit, and integration with security services
Main failure mode	Overprivileged tools, token passthrough, prompt injection, session misuse	Overtrusted remote agents, weak skill authorization, opaque delegation	Blind passthrough, incomplete policy context, missing ownership, noisy logs without decision evidence

Google Cloud’s Agent Gateway is positioned as part of the Gemini Enterprise Agent Platform governance layer. Its documentation describes gateway support for HTTP-based traffic, including MCP and A2A, with deeper MCP request parsing for attribute-based authorization policies. The design also ties into agent identity, Agent Registry, authorization policies, Model Armor, logging, tracing, and Service Extensions for delegated authorization.

A2A has a different shape. The remote agent may be an independent system. It may expose a public Agent Card, an authenticated extended Agent Card, and one or more skills. It may support long-running tasks, streaming, state updates, or push notification callbacks.

The Request Flow That Needs to Be Governed

Teams do not need to solve every future agent security problem on day one. They do need a minimum control set before tool adoption spreads across the environment.

What Protocol-Layer Security Actually Means

The vendor-specific implementation will change over time. The architectural direction is the part worth acting on now.

Most early agent deployments start with a simple trust model:

The security boundary becomes clearer when you look at the request path. The important point is not just that a request moves from an agent to a tool. The important point is where identity is asserted, where policy is evaluated, where protocol attributes are extracted, and where evidence is recorded.

The fastest way to make an AI agent useful is to give it tools. The fastest way to make an AI agent dangerous is to give it tools without a security boundary that understands what the agent is doing.

Identity Is Necessary but Not Sufficient

to:

Without this level of telemetry, teams are left with vague logs that show an agent called something. That is not enough for incident response, compliance review, or production troubleshooting.

Identity	Example	Security Question
User identity	Human user initiating the request	Is this user allowed to trigger this business action?
Agent identity	Deployed agent runtime or service account	Is this agent approved to access this tool or peer agent?
Client identity	IDE, assistant, app, workflow, or automation caller	Is this client allowed to reach this agent surface?
Downstream resource identity	API, SaaS app, database, workflow system	What credential should be used to call the backend safely?

Use application-level authorization regardless of the gateway. The gateway should reduce exposure, centralize policy, and improve observability. It should not become the only place where sensitive business rules are enforced.

Authorization Needs Operation Context

That is the tension most enterprise teams are walking into now. Agent frameworks are making tool integration easier. MCP servers are exposing databases, SaaS systems, internal APIs, and operational workflows. A2A is creating a path for agents to collaborate across frameworks and organizational boundaries. Developers are connecting all of this faster than security teams can model the resulting trust paths.

This article focuses on enterprise protocol-layer security patterns for MCP, A2A, and agent gateways. It is not a step-by-step guide for a specific product deployment.

Where Google and AWS Are Signaling the Architecture

Decision telemetry also helps DevOps and platform teams improve the system. Denied requests can reveal missing policy, broken registration, overbroad agent design, or a tool that should not be exposed to agents at all.

Use A2A-specific governance when agents delegate tasks, expose skills, share status, or operate across framework, account, project, tenant, or organizational boundaries. Treat remote agents as governed services, not trusted libraries.

Agent -> Gateway -> Registered MCP Server
Agent -> Gateway -> Registered A2A Agent
Agent -> Gateway -> Registered API Target
Agent -> Gateway -> Approved Model Route

Traditional request logs often answer what happened. Agent gateway telemetry needs to answer why it was allowed to happen.

MCP, A2A, and agent gateways often get discussed together because they sit in the agent connectivity path. They solve different problems, and that difference matters for security design.

Design Area	Google Cloud Agent Gateway Direction	AWS AgentCore Gateway Direction	Practical Takeaway
Agent connectivity	Governed entry and exit point for agent interactions	Single secure entry point for agents, tools, other agents, and models	Put a managed control point in the path instead of direct tool sprawl
MCP handling	Supports MCP traffic and documented MCP attribute extraction for policies	Aggregates MCP targets into a unified virtual MCP server	MCP is becoming a first-class gateway concern
A2A handling	Supports HTTP-based A2A traffic through gateway routing	Supports A2A-style services through HTTP targets and passthrough	A2A needs identity and route-level governance even when deep inspection varies
Policy model	Authorization policies, Service Extensions, IAM-related controls, Model Armor integration	Inbound authorization, credential providers, gateway rules, target routing	Gateway policy needs to combine identity, protocol, route, and content controls
Observability	Cloud Logging, Cloud Trace, and agent observability integration	Gateway-level routing and operational controls with AWS-native integration paths	Logs must preserve agent, target, operation, decision, and trace context

This is the same architectural instinct behind network segmentation, API gateways, service mesh, and privileged access management. The difference is that the policy input now includes agent behavior and protocol context.

The most important operating principle is simple: adding a tool to an agent is a security-impacting change. It deserves the same level of review as exposing a new API route, granting a new IAM permission, or adding a new automation runbook action.

The most important shift is operational. Adding a tool to an agent is not a small developer convenience. It is a change to the enterprise action surface. Teams that build gateway-level controls now will have a much easier time scaling agentic systems without losing track of who can do what, through which protocol, against which system, and under which policy.

Protocol-layer security is the ability to apply security decisions using protocol-specific context, not just network location or endpoint identity.

That sounds reasonable until the tool surface grows. A single MCP server may expose dozens of tools. Some are harmless read operations. Some can write tickets, update records, approve requests, rotate credentials, query sensitive data, or trigger automation. Treating all tool calls as equivalent turns a useful integration into an overprivileged execution path.

Use an agent gateway when agents call multiple tools, operate across teams, access sensitive data, invoke workflow systems, call peer agents, or need production observability. That should be the default enterprise direction.

Control	Why It Belongs in the Gateway Path
Agent registration	Prevents unknown agents from connecting directly to tools
Tool and target inventory	Makes the exposed action surface visible
Ingress authentication	Validates the caller before traffic reaches the agent or gateway target
Egress authorization	Restricts which tools, agents, APIs, or models an agent can call
Credential brokering	Avoids storing broad downstream secrets inside agent code
Protocol-aware policy	Allows decisions based on tool, resource, skill, method, route, or risk label
Content and prompt inspection	Adds a runtime guardrail for injection, sensitive data, or unsafe output
Decision telemetry	Captures the security reason for allow, deny, step-up, or audit-only decisions

MCP security should start with a simple rule: do not treat tool discovery as authorization.

A Practical Control Model for MCP

AWS positions Amazon Bedrock AgentCore Gateway as a managed secure entry point for agentic traffic. Its documentation describes MCP target aggregation, HTTP passthrough targets for services such as other agents and A2A services, inference targets, inbound authorization options, credential providers, and gateway rules that can route based on caller identity or request path.

You need all three layers to align: protocol contract, gateway enforcement, and backend authorization.

Agent -> MCP Server
Agent -> SaaS API
Agent -> Internal API
Agent -> Another Agent
Agent -> Model Endpoint

A lot of teams start with this pattern:

A Practical Control Model for A2A

A better policy model evaluates:

Decision Guidance for Architects and Platform Teams

The important pattern is that both vendors are moving the enterprise control point away from individual agent code and toward a gateway layer that can centralize connectivity, authorization, routing, credentials, and telemetry.

Gateway Policy Should Be Managed Like Production Infrastructure

For A2A, that can mean requiring authenticated agent discovery, validating the security schemes advertised in an Agent Card, applying authorization per agent or skill, and treating long-running tasks or push notifications as part of the security model. A2A intentionally relies on standard web security mechanisms at the HTTP layer, so the agent server and gateway design must preserve that boundary.

Agent security is not only a security team problem. It changes how platform and DevOps teams manage environments.

The highest-risk shortcut is token passthrough. It is tempting because it makes integration easier. It also breaks the boundary between the MCP client, MCP server, and downstream API. Once tokens are passed around without proper audience validation and exchange, logs become harder to trust, controls are easier to bypass, and downstream systems may accept credentials that were not meant for them.

This is the practical difference between a connected agent and a governed agent.

The Minimum Control Set for Enterprise Agent Gateways

An MCP client may list available tools. That does not mean every listed tool should be callable by every agent. Tool catalogs should be filtered, scoped, and logged. Tool calls should be authorized based on the agent identity, user context where applicable, target MCP server, tool name, tool risk, and requested arguments when feasible.

Control Area	Minimum Requirement	Why It Matters
Inventory	Register agents, MCP servers, tools, A2A agents, APIs, and owners	You cannot secure an action surface you cannot name
Identity	Assign distinct identities to agents, users, clients, gateways, and backend targets	Shared identities destroy least privilege and audit quality
Authorization	Enforce per-agent and per-operation access where supported	Server-level access is too broad for tool catalogs
Credential handling	Use credential providers, token exchange, or brokered credentials	Agents should not become secret storage locations
Protocol inspection	Extract MCP and A2A attributes where supported by the platform	Policy needs operation context, not only endpoint context
Content guardrails	Inspect high-risk prompts, tool inputs, and responses	Prompt injection and data leakage are runtime concerns
Telemetry	Log identity, target, protocol, operation, decision, and trace ID	Security investigations need decision-grade evidence
Change control	Version policy, review tool additions, and test deny paths	Agent capability changes are production changes
Break-glass	Define emergency disablement for agents, tools, targets, and routes	Fast containment matters when an agent path misbehaves
Drift detection	Detect direct tool access that bypasses the gateway	Gateway control fails if bypass paths remain open

Endpoint-level authorization is too coarse for many agent workloads. If an MCP server exposes twenty tools, allowing access to the server is not the same as allowing access to every tool. If an A2A agent exposes multiple skills, allowing communication with the agent is not the same as allowing every delegated action.

Observability Needs to Capture Decisions, Not Just Traffic

A production agent should have a release path that includes:

Traditional API security still matters, but it is no longer enough by itself. An API gateway can tell you which endpoint was called. A protocol-aware agent gateway should also help answer which agent called it, which user or workload context was involved, which MCP tool or A2A skill was requested, whether the operation was read-only or destructive, and whether the policy decision was enforced before the request reached the backend system.

Field	Example
Trace ID	Request chain across agent, gateway, tool, and peer agent
User identity	Human or workload context that initiated the request
Agent identity	The acting agent or runtime
Client identity	Application, IDE, workflow, or service invoking the agent
Protocol	MCP, A2A, REST, gRPC, inference
Target	MCP server, tool, resource, A2A agent, skill, API, model
Operation	Tool call, resource read, skill invocation, route, model request
Policy decision	Allow, deny, step-up, audit-only
Reason code	Matched allowlist, missing scope, unregistered target, destructive operation
Credential path	Brokered token, IAM role, OAuth grant, blocked secret path
Content decision	Prompt inspection result, sensitive data result, guardrail outcome

The practical direction is clear. Agents need explicit identities. Tools and peer agents need registration and ownership. Gateway policy needs enough protocol context to distinguish safe requests from risky ones. Credentials need to be brokered rather than scattered across agent runtimes. Logs need to capture decisions, not just traffic.

The common mistake is assuming that A2A makes agents trustworthy because they can describe themselves. Discovery is not trust. An Agent Card is a starting point for policy, not a replacement for identity verification, authorization, and monitoring.

“Should this agent, acting for this user or workload, be allowed to perform this operation against this tool or peer agent, with these inputs, from this runtime, right now?”

A strong identity tells you who is calling. It does not automatically tell you what they are allowed to do.

Lifecycle Stage	Required Gate
Design	Define agent purpose, tool needs, data classification, and ownership
Build	Register tool contracts, expected permissions, and protocol targets
Test	Validate allowed and denied tool calls in lower environments
Release	Promote gateway policy with the agent deployment
Operate	Monitor decisions, exceptions, latency, and failed authorization
Change	Review every new tool, skill, route, or credential provider
Retire	Remove agent identity, tool bindings, policies, and credentials

The same problem appears in A2A patterns. One agent may ask another agent for a summary, a risk review, a workflow decision, or an action that touches downstream systems. The remote agent may be opaque by design. You may not see its internal prompt, memory, tools, or implementation. That makes the external contract and the policy boundary more important, not less.

That gives security and platform teams a place to enforce the baseline:

The security model should reflect that.

The mistake is treating the protocol as the security boundary. MCP can define how tools are exposed and how authorization should work. A2A can define how agents describe and communicate with each other. A gateway can enforce policy in the request path. None of these automatically gives you a complete enterprise security model by itself.

Google Cloud and AWS are both emphasizing gateway-level control for agentic traffic, but they are approaching the control plane through their own platform models.

The point is not to create policy complexity for its own sake. The point is to avoid granting broad access because the enforcement layer cannot see the actual operation.

Conclusion

The exact feature sets are not identical. That is the wrong comparison anyway.

Google Cloud and AWS are both moving in this direction with gateway-level controls for agentic traffic. The implementation details differ, but the architectural signal is consistent: agent connectivity needs a governed control plane, not a pile of direct tool integrations.

MCP, A2A, and agent gateways are becoming part of the enterprise AI control plane. That is a good thing, but only if teams treat them as security architecture and not just integration plumbing.

External References

Share this:

Like this:

Like Loading…