Teams are giving AI agents access to tools faster than they are defining the security boundaries between the agent, the protocol, the tool, and the user. That is the part that matters.
Most early agent projects start with a simple integration question: “How do I let this agent query a database, call an API, open a ticket, or delegate work to another agent?” That question quickly turns into a control-plane problem. Which identity is being used? Which tool was discovered? Who authorized the action? Can the request be inspected? Can the response leak sensitive data? Can a compromised tool description steer the agent into unsafe behavior?
MCP and A2A are helping standardize how agents connect to tools and other agents. MCP provides a common way for LLM applications to connect to external data sources and tools, using a host/client/server model and JSON-RPC messaging. A2A standardizes communication between independent, potentially opaque agent systems so they can discover capabilities, negotiate modalities, manage tasks, and exchange information without exposing internal memory or tools.
But protocols are not the same thing as enterprise security architecture.
The strategic shift now showing up in Google Cloud and AWS guidance is that agent connectivity needs gateway-level control. Google’s Agent Gateway is positioned as a policy enforcement point for A2A agents, MCP servers, and endpoints, with support for HTTP-based traffic including MCP and A2A. AWS describes Amazon Bedrock AgentCore Gateway as a managed AI gateway that provides a secure entry point for agentic traffic across tools, other agents, and LLMs.
The practical takeaway: agent security should not live only inside the agent framework. It needs to live at the protocol boundary.
Why Protocol-Layer Security Matters
Traditional application security assumes a fairly stable request path. A user calls an application. The application calls a service. The service checks authorization. Logs and controls are attached to known endpoints.
Agentic systems make that path more dynamic. An agent may discover tools at runtime. It may call tools based on model reasoning. It may pass user context to another agent. It may retrieve structured data, generate a plan, call a backend API, and summarize the result in one chain of activity. MCP tools are explicitly designed to be discoverable and invokable by models, and the MCP tools specification notes that tools can interact with external systems such as databases, APIs, or computation services.
That creates several security questions that cannot be answered by “we authenticated the user” alone:
| Security Question | Why It Gets Harder With Agents |
|---|---|
| Which identity is acting? | The request may involve a user, an agent, a gateway, and a backend service identity. |
| Which tool was selected? | The model may choose from a dynamic tool catalog. |
| Was the tool allowed for this user and this agent? | Tool access may depend on user role, agent identity, environment, data class, and action risk. |
| Did the request include unsafe content? | Prompt injection, malicious tool metadata, or sensitive data may move through protocol payloads. |
| Can we audit the full chain? | The important event is not just an API call; it is user intent, agent decision, tool call, and response handling. |
MCP’s own security guidance calls out risks such as confused deputy behavior, token passthrough risk, SSRF, session hijacking, local MCP server compromise, OAuth authorization URL validation issues, and scope minimization mistakes. Google’s MCP security guidance similarly highlights risks such as unauthorized tool exposure, session hijacking, tool shadowing, sensitive data exposure, token theft, and fragmented authentication across distributed MCP servers.
That is why the gateway pattern matters. It creates a place where protocol traffic can be authenticated, authorized, inspected, routed, logged, and constrained before it reaches tools, agents, or models.
Scope and Assumptions
This article is focused on enterprise agent connectivity, not consumer chatbot plugins or local-only developer experiments.
The assumptions are:
- Agents need access to real systems such as APIs, databases, SaaS tools, ticketing systems, CI/CD systems, infrastructure platforms, or other agents.
- Some traffic will use MCP for agent-to-tool access.
- Some traffic will use A2A for agent-to-agent collaboration.
- The organization needs centralized policy, observability, identity enforcement, and operational ownership.
- Agent frameworks alone are not sufficient as the only security boundary.
This does not mean every prototype needs a full gateway implementation on day one. It does mean that production designs should avoid direct, unmanaged agent-to-tool sprawl.
MCP, A2A, and Agent Gateways Are Different Layers
The first mistake teams make is treating MCP, A2A, and gateways as competing ideas. They are not the same layer.
| Layer | Primary Job | Security Boundary It Introduces | What It Does Not Solve Alone |
|---|---|---|---|
| MCP | Connect agents or LLM applications to tools, resources, and prompts | Agent-to-tool access | Enterprise-wide policy, centralized catalog control, cross-tool observability |
| A2A | Let agents communicate, discover capabilities, and collaborate | Agent-to-agent access | Trust governance, registry control, backend authorization, enterprise routing |
| Agent gateway | Govern and route agentic traffic | Protocol inspection, policy enforcement, identity, routing, telemetry | Correct tool design, safe agent logic, data classification, backend least privilege |
MCP gives agents a standardized way to call tools. A2A gives agents a standardized way to collaborate with other agents. The gateway gives the enterprise a place to control the traffic.
That distinction is important because the protocol is not the control plane by itself. MCP authorization can protect access to MCP servers, and the MCP authorization guide recommends authorization when servers access user-specific data, require auditability, expose consented APIs, support enterprise access controls, or need rate limiting and usage tracking. A2A similarly delegates authentication to standard web mechanisms such as OAuth2 and OpenID Connect, with identity established at the HTTP layer rather than inside the JSON-RPC payload.
Those are necessary controls, but not the full operating model.
Request Flow: Where the Security Boundary Should Sit
The request-flow diagram below shows the architectural pattern to aim for. The key point is that the gateway is not just a reverse proxy. It is the enforcement point where identity, policy, content inspection, tool catalog control, and telemetry come together.
What to notice in the flow: the agent should not have unrestricted direct paths to every tool. The gateway should see the request before the tool or remote agent does. That gives security and platform teams a stable control point even when agent behavior, tool catalogs, and backend services change.
MCP is powerful because it gives agents a standard way to discover and call tools. That is also what makes it sensitive.
A poorly governed MCP deployment can turn into a tool sprawl problem. Each team exposes a server. Each server advertises tools. Agents discover capabilities. Developers wire endpoints directly into IDEs, chat interfaces, automation agents, or custom runtimes. Before long, nobody has a single view of which agent can call which tool on behalf of which user.
The controls should be explicit:
| MCP Control | Practical Requirement |
|---|---|
| Tool catalog governance | Every MCP server and exposed tool should have an owner, environment, data class, and approval state. |
| Per-tool authorization | Access should be based on user role, agent identity, tool risk, and environment. |
| Method-aware policy | tools/list is not the same risk as tools/call; read-only tools are not the same as destructive tools. |
| Human approval | Destructive or externally visible actions should require confirmation or workflow approval. |
| Token handling | Avoid static secrets in agent configs; use scoped, short-lived, delegated credentials where possible. |
| Auditability | Log the user, agent, tool, arguments classification, decision, and result status. |
| Response filtering | Inspect tool responses for sensitive data leakage before returning content to the agent or user. |
AWS’s AgentCore Gateway documentation is a good example of where this pattern is heading. AWS describes MCP targets as an aggregation model where multiple backend capabilities can be combined into a unified virtual MCP server, and it defines gateway targets across MCP, HTTP, and inference categories. AWS also describes inbound authorization options such as OAuth JWT and IAM SigV4, and outbound authorization through execution roles, credential providers, SigV4, or other target-specific approaches.
That does not remove the need to secure the backend API. It gives you a managed control point before traffic reaches it.
The A2A Boundary: Secure Agent-to-Agent Delegation
A2A changes the problem from “Can this agent call a tool?” to “Can this agent ask another agent to do work?” That is a different trust boundary.
In A2A, agents are often opaque. They should not need to expose their internal memory, tools, or implementation details to collaborate. The A2A specification frames this as a protocol for independent agent systems to discover capabilities, negotiate modalities, manage tasks, and exchange information securely without needing access to internal state, memory, or tools.
The security focus shifts to:
| A2A Control | Practical Requirement |
|---|---|
| Agent discovery | Do not treat every discovered agent as trusted. |
| Agent card protection | Sensitive agent cards should be protected with authentication and authorization. |
| Skill authorization | Access should be controlled per skill, not just per agent endpoint. |
| Delegation policy | Define which agents can delegate to which agents and under what user context. |
| Data minimization | Do not pass full user prompts, credentials, or unnecessary context to remote agents. |
| Traceability | Preserve a correlation ID across user request, root agent, delegated agent, and backend calls. |
| Trust tiering | Internal agents, partner agents, SaaS agents, and public agents should not share the same policy. |
A2A’s enterprise guidance states that production communication should use HTTPS, that authentication relies on HTTP headers and standards such as OAuth2 and OpenID Connect, and that A2A payloads do not carry user or client identity directly. Its agent discovery guidance also notes that Agent Cards can include identity, endpoint, capabilities, authentication, and skills, and that sensitive Agent Cards should be protected with mechanisms such as mTLS, network restrictions, or HTTP authentication.
That means the Agent Card should be treated like infrastructure metadata, not harmless documentation.
Gateway-Level Control: Google and AWS Are Converging on the Same Pattern
Google and AWS are not implementing identical products, but the direction is similar: centralize control around agent/tool/agent traffic instead of pushing every control into every individual agent.
Google’s Agent Gateway documentation describes it as a managed regional networking component and runtime policy enforcement point for A2A agents, MCP servers, and endpoints. It supports all HTTP-based traffic, including MCP and A2A, and can parse MCP traffic to extract attributes for authorization policies such as restricting access to specific tools. Google also ties gateway-level control to Model Armor, which can inspect prompts and responses passing through the gateway and block traffic that violates configured policies.
AWS describes AgentCore Gateway as a managed AI gateway that connects agents to tools, other agents, and LLMs through a single secure entry point. It can convert APIs, Lambda functions, and existing services into MCP-compatible tools, front other agents and HTTP services including A2A traffic, and route inference requests through a unified endpoint. AWS also documents gateway targets across MCP, HTTP, and inference categories, with inbound authorization configuration required for each gateway.
| Capability Area | Google Agent Gateway Direction | AWS AgentCore Gateway Direction |
|---|---|---|
| Primary control point | Regional gateway for agent traffic and policy enforcement | Managed gateway for agentic traffic across tools, agents, and models |
| Protocol coverage | HTTP-based traffic including MCP and A2A | MCP-compatible tools, HTTP/A2A passthrough, and inference routing |
| MCP-specific controls | MCP attribute extraction for authorization policies | MCP aggregation into a unified virtual MCP server |
| Identity and access | IAM/IAP-oriented policy enforcement for agent egress; authorization policies and Service Extensions for gateway scenarios | Inbound authorization options including OAuth JWT and IAM SigV4; outbound target authorization through roles or credential providers |
| Content safety | Model Armor can inspect prompts and responses through gateway flows | Interceptors and policy integrations can support request/response customization and guardrail enforcement |
| Operational concern | Registry and regional alignment matter for governed agent discovery | Target management, listing mode, credential handling, and observability become gateway design concerns |
The architectural message is consistent: do not let each agent invent its own security model for every tool and peer agent.
A Policy Model for Protocol-Layer Security
A gateway is only useful if the policy model is clear. Otherwise it becomes another routing hop with a better dashboard.
A practical enterprise policy model should define controls across six dimensions:
| Policy Dimension | Example Questions |
|---|---|
| Caller identity | Which user, workload, service account, or agent identity initiated the call? |
| Agent identity | Which agent runtime is acting, and is it approved for this environment? |
| Protocol intent | Is this tools/list, tools/call, an A2A task request, an HTTP passthrough call, or inference traffic? |
| Target classification | Is the target internal, partner-managed, SaaS-hosted, public, production, or development? |
| Action risk | Is the operation read-only, write-capable, destructive, externally visible, or privileged? |
| Data class | Does the prompt, argument set, tool result, or agent response contain regulated, confidential, credential-like, or customer data? |
This should not live only in a wiki. It should become enforceable policy. Here is a simplified YAML-style policy example. This is not vendor-specific syntax. It is a design artifact that shows the kind of decisions a gateway policy layer should be able to express.
policySet: agent-protocol-security
version: 1.0
defaults:
denyUnknownAgents: true
denyUnknownTools: true
requireCorrelationId: true
logDecision: true
identities:
trustedAgentGroups:
- finance-ops-agents
- platform-automation-agents
trustedUserGroups:
- finance-approvers
- platform-admins
mcpRules:
- name: allow-readonly-finance-tools
when:
protocol: mcp
method: tools/call
toolRisk: read_only
toolOwner: finance-platform
userGroup: finance-approvers
agentGroup: finance-ops-agents
then:
decision: allow
inspectResponse: true
redactSensitiveData: true
- name: require-approval-for-destructive-tools
when:
protocol: mcp
method: tools/call
toolRisk: destructive
then:
decision: require_human_approval
approvalWorkflow: change-management
logLevel: high
a2aRules:
- name: allow-approved-agent-delegation
when:
protocol: a2a
sourceAgentGroup: platform-automation-agents
targetTrustTier: internal
skillRisk:
- read_only
- diagnostic
then:
decision: allow
passUserContext: scoped
includeTraceHeaders: true
- name: block-public-agent-sensitive-context
when:
protocol: a2a
targetTrustTier: public
dataClass:
- confidential
- regulated
- credential
then:
decision: block
reason: sensitive_context_to_untrusted_agent
inspection:
promptInjection:
action: block
credentialLeakage:
action: redact_or_block
pii:
action: redact
unknownToolMetadata:
action: quarantine
The point is not the YAML format. The point is the decision model. A mature agent platform should be able to answer: who called, which agent acted, which protocol method was used, which tool or skill was requested, what data class was involved, what policy was evaluated, and what happened next.
DevOps Implications: Treat Agent Connectivity Like Platform Engineering
Agent protocol security will fail if it is treated as a one-time security review. The operating model needs to look more like platform engineering:
| Practice | Why It Matters |
|---|---|
| Tool registration pipeline | MCP tools should not appear in production catalogs without ownership, risk classification, schema review, and environment tagging. |
| Agent registry governance | A2A agents need approved metadata, trust tiering, skill classification, and lifecycle ownership. |
| Policy-as-code | Gateway authorization rules should be versioned, reviewed, tested, and deployed through controlled workflows. |
| Environment separation | Development agents should not use production tool catalogs or production delegated credentials. |
| Change control | New destructive tools, new external agents, and new delegated workflows should trigger review. |
| Observability standards | Tool calls, A2A tasks, content safety decisions, and backend calls should share trace context. |
| Incident response | Security teams need a way to disable a tool, quarantine an agent, revoke credentials, or block a target quickly. |
AWS’s AgentCore Gateway MCP guidance shows why this matters operationally. AgentCore Gateway can aggregate capabilities from multiple MCP servers into a single MCP endpoint, and clients can see a unified tool catalog, prompt library, and resource namespace instead of managing many separate connections. That centralization is useful, but it also means gateway configuration, target synchronization, listing mode, tool naming, resource handling, and access control become production responsibilities. AWS specifically notes that resource URIs from downstream MCP servers are not validated or sanitized by the gateway and should be treated carefully when targets are untrusted.
This is exactly where DevOps practices matter. The gateway becomes part of the delivery platform.
Start with these decisions:
| Decision | Recommended Starting Point |
|---|---|
| Tool exposure | Require every MCP tool to have an owner, environment, data class, and risk rating. |
| Agent identity | Assign stable workload identity to agents; do not rely only on shared API keys. |
| User delegation | Preserve user context where the action depends on user permissions. |
| Gateway placement | Put a gateway between production agents and production tools or remote agents. |
| Policy model | Start with deny-by-default for unknown agents, unknown tools, destructive actions, and sensitive data paths. |
| Observability | Log user, agent, protocol method, target, decision, and correlation ID. |
| Approval | Require human approval for destructive, externally visible, or privileged operations. |
| Emergency controls | Build a fast path to disable a tool, block an agent, or revoke target credentials. |
If the organization is early in its agent journey, start with catalog governance and logging. If agents are already calling production systems, prioritize gateway enforcement and identity cleanup.
Practical Implementation Pattern
A production-ready pattern usually has four layers.
1. Protocol Catalog
Maintain a central catalog for MCP servers, tools, A2A agents, skills, and backend targets. Include ownership, environment, risk, data class, and approval state.
2. Identity and Delegation
Separate user identity, agent identity, gateway identity, and backend service identity. Decide when the agent acts on behalf of a user versus when it acts as a service. The MCP ecosystem is also moving toward more enterprise-managed authorization. The MCP project announced the Enterprise-Managed Authorization extension as stable on June 18, 2026, describing it as a way for organizations to centrally provision MCP server access through their identity provider and reduce per-server OAuth prompts. That reinforces the broader direction: identity should be centrally governed, not handled as one-off tool wiring.
3. Gateway Policy
Enforce protocol-aware rules at the gateway. For MCP, that means controlling tool discovery and invocation. For A2A, that means controlling agent discovery, task delegation, and skill access. For HTTP and inference traffic, that means applying the same identity, inspection, routing, and logging standards.
4. Backend Enforcement
Keep authorization and validation in the backend systems. A gateway can stop bad traffic early, but it should not be the only place that knows whether a user can approve a payment, delete a resource, create a firewall rule, or access customer data.
Operational Gotchas
The hardest problems are not always in the protocol. They are in the seams between systems.
Watch for these:
| Gotcha | Why It Matters |
|---|---|
| Tool descriptions become prompt surface area | Tool metadata can influence model behavior. Treat it as input, not static documentation. |
| Tool catalogs drift | If tools change faster than policy, agents may gain unexpected capabilities. |
| User and agent identity blur | Audit trails become weak when logs show only the gateway or service account. |
| Read-only labels are unreliable without validation | A tool marked read-only can still expose sensitive data or trigger expensive operations. |
| Remote agents expand the trust boundary | A delegated A2A task may pass data into another vendor, region, or policy domain. |
| Local development shortcuts leak into production | Static tokens, direct endpoints, and broad scopes often survive longer than intended. |
| Gateway logs are not enough | You still need backend logs, model traces, approval records, and policy decision logs correlated together. |
A good gateway design gives you a control point. A good operating model keeps that control point accurate.
Conclusion
MCP and A2A are important because they standardize how agents connect to tools and to each other. But standardization does not remove the need for security architecture. It makes the architecture more urgent.
The enterprise pattern is becoming clear: agents should not connect directly to every tool, API, model, and peer agent with custom security logic scattered across each implementation. Production agent systems need a protocol-aware gateway layer that can enforce identity, policy, routing, inspection, observability, and emergency controls.
Google and AWS are both moving in that direction with gateway-level control for agentic traffic. The details differ, but the architectural signal is the same.
The next security boundary for agentic AI is not just the model. It is the request path between the agent and everything the agent can do.
External Sources
The article above was validated against the following primary vendor, protocol, and product sources:
- Model Context Protocol Specification
- MCP Tools Specification
- MCP Security Best Practices
- MCP Authorization Guidance
- MCP Enterprise-Managed Authorization Announcement
- A2A Protocol Specification
- A2A Enterprise-Ready Guidance
- A2A Agent Discovery Guidance
- Google Cloud: Import and Govern Agents with Agent Registry and Agent Gateway
- Google Cloud: Configure Model Armor for Agent Gateway
- Google Cloud Blog: How to Secure Your Remote MCP Server on Google Cloud
- AWS Documentation: Amazon Bedrock AgentCore Gateway
- AWS Documentation: AgentCore Gateway Core Concepts
- AWS Blog: Extending MCP Support for Amazon Bedrock AgentCore Gateway
