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

TL;DR

MCP, A2A, and agent gateways are becoming the connectivity layer for enterprise agents, but the security model cannot stop at “the agent has a token.” Teams need protocol-layer controls that understand who is calling, which agent is acting, which tool or peer agent is being invoked, what operation is requested, and whether the request should be allowed at that moment.

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.

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.

Introduction

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.

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.

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.

That is what protocol-layer security is really about. It is not a replacement for IAM, OAuth, TLS, secrets management, or application authorization. It is the connective tissue between those controls and the actual behavior of agentic systems.

Why Protocol-Layer Security Matters Now

Most early agent deployments start with a simple trust model:

“Only this agent can call this tool.”

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.

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.

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.

For enterprise teams, this changes the design question from:

“Can the agent connect to the tool?”

to:

“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?”

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

Scope and Assumptions

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.

The assumptions are straightforward:

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 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.

MCP, A2A, and Agent Gateways Are Different Security Surfaces

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.

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

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.

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

The Request Flow That Needs to Be Governed

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.

What matters in this flow is separation of duties. The agent should not carry every downstream credential. The gateway should not blindly forward every request. The tool should not assume that a request is safe because it came from an agent. The policy engine should not make decisions without enough context to distinguish a read operation from a destructive action.

What Protocol-Layer Security Actually Means

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

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.

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.

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.

Identity Is Necessary but Not Sufficient

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

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

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?

The weak pattern is collapsing all of these into one shared service account. That may work for a lab, but it damages auditability and makes least privilege almost impossible in production.

Authorization Needs Operation Context

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.

A better policy model evaluates:

Policy Dimension	Example
Subject	Which user, agent, client, or workload is calling?
Target	Which MCP server, tool, resource, A2A agent, skill, API, or model is being invoked?
Operation	Is the request read, write, delete, approve, execute, or delegate?
Context	Runtime, environment, tenant, data classification, session state, business workflow
Risk	Is the tool destructive, externally visible, privileged, or sensitive?
Control	Allow, deny, step-up authorization, human approval, content inspection, audit-only

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.

Where Google and AWS Are Signaling the Architecture

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.

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.

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.

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

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.

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

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

The Security Boundary Should Sit Between Agents and Tools

A lot of teams start with this pattern:

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

That pattern scales badly. Every direct connection becomes a separate identity decision, secret-handling decision, logging path, exception process, and operational dependency. Eventually, no one can answer which agents can perform which actions without reading code, checking environment variables, and reconstructing traffic from scattered logs.

A better target state is:

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

This does not mean the gateway owns all logic. Backend systems still enforce their own authorization. The gateway provides the shared control plane for agent connectivity.

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

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

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.

A Practical Control Model for MCP

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

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.

A practical MCP control model includes:

MCP Control	Implementation Intent
Token audience validation	Tokens accepted by the MCP server must be intended for that resource
No token passthrough	The MCP server or gateway should not blindly forward upstream tokens to downstream systems
Per-tool allowlists	Agents should only call approved tools needed for their role
Read versus write separation	Read-only tools and destructive tools should have different policies
Scope minimization	Request only the scopes needed for the operation or workflow stage
Step-up authorization	Sensitive actions should require additional user consent or workflow approval
Prompt and response inspection	Tool inputs and outputs should be inspected when prompt injection or sensitive leakage is a realistic risk
Session binding	Sessions should be tied to the right user, client, and agent context
Tool metadata governance	Tool descriptions, schemas, and annotations should be reviewed like an API contract

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.

A Practical Control Model for A2A

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 security model should reflect that.

A2A Control	Implementation Intent
Authenticated discovery where needed	Do not expose sensitive capabilities through unauthenticated Agent Cards
Agent Card validation	Treat advertised security schemes, skills, endpoints, and capabilities as a contract to validate
Per-agent allowlists	Only approved agents should be reachable from production agents
Per-skill authorization	Calling an agent is not the same as being allowed to invoke every skill
HTTP-layer authentication	Preserve the A2A model that identity is established through standard web mechanisms
Task lifecycle controls	Long-running or stateful tasks need cancellation, timeout, callback, and ownership rules
Push notification validation	Callback URLs, tokens, and notification authentication need explicit controls
Opaque agent boundary	Do not assume remote agent internals are visible or trustworthy
Delegation logging	Record which agent delegated what task to which peer agent and why

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.

Gateway Policy Should Be Managed Like Production Infrastructure

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.

The following vendor-neutral YAML is not intended to match a specific Google or AWS schema. It shows the type of control intent that should exist in a real gateway policy model. The names, targets, and identity values should be mapped to the actual gateway, IAM, registry, and policy engine used in your environment.

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

Successful enforcement should produce a clear result: the issue triage agent can read issue data and ask an approved advisory agent for review guidance, but it cannot update issues, merge code, rotate credentials, or call an unregistered peer agent. The gateway decision record should explain every allow or deny decision in a way that supports troubleshooting and audit review.

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

The Minimum Control Set for Enterprise Agent Gateways

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.

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

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.

Observability Needs to Capture Decisions, Not Just Traffic

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

A useful event should include:

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

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.

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.

DevOps Ownership Changes When Agents Get Tools

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

A production agent should have a release path that includes:

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

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 teams that skip this step usually end up with agents that work in demos but cannot pass production review.

Decision Guidance for Architects and Platform Teams

Use a direct connection pattern only for isolated prototypes, local development, or low-risk internal experiments where the tool surface is narrow and the blast radius is understood. Even then, design the prototype so it can move behind a gateway later.

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.

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.

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.

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.

Conclusion

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.

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 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.

External References

• Model Context Protocol: Authorization
  Canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
• Model Context Protocol: Security Best Practices
  Canonical URL: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• A2A Protocol: Agent2Agent Protocol Specification
  Canonical URL: https://a2a-protocol.org/latest/specification/
• A2A Protocol: Enterprise Features
  Canonical URL: https://a2a-protocol.org/latest/topics/enterprise-ready/
• Google Cloud: Agent Gateway Overview
  Canonical URL: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview
• Google Cloud: Delegate Authorization with Service Extensions
  Canonical URL: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/delegate-authorization
• Google Cloud Blog: The Case for Envoy Networking in the Agentic AI Era
  Canonical URL: https://cloud.google.com/blog/products/networking/the-case-for-envoy-networking-in-the-agentic-ai-era
• AWS: Amazon Bedrock AgentCore Gateway — A Secure AI Gateway for Agents, Tools, and Models
  Canonical URL: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
• AWS: Core Concepts for Amazon Bedrock AgentCore Gateway
  Canonical URL: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-core-concepts.html
• AWS: Supported Targets for Amazon Bedrock AgentCore Gateways
  Canonical URL: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-supported-targets.html
• AWS: Add Rules to a Gateway
  Canonical URL: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rules.html