Google's A2A Joins MCP at the Agentic AI Foundation: What It Means for Buyers

Updated: 6 days ago
Title: Google's A2A Joins MCP at the Agentic AI Foundation: What It Means for Buyers
Date: 19 August 2026
Type: Paper
Author: SAASiQ (contact@saasiq.ai)
Word count: 2624 words
Reading time: 10 min
Published: 19-08-2026
On 17 August Google's Agent2Agent protocol, known as A2A, became a hosted project of the Agentic AI Foundation, the Linux Foundation body that already hosts Anthropic's Model Context Protocol (MCP). MCP covers how an AI agent connects to tools and data, and A2A covers how agents from different vendors find each other and pass work between them, so one vendor-neutral body now looks after both. This paper explains how the two fit together, what recent security research and the NCSC's guidance mean for anyone deploying them, where Oracle Fusion stands, and what to ask suppliers.
What happened on 17 August
The move was announced on the foundation's blog and reported by Axios the same day. A2A joins MCP, goose and AGENTS.md as a hosted project of the foundation, which goes by the initials AAIF. Version 1.0 of A2A, the first stable release, shipped in March 2026. The foundation says A2A already runs on Huawei's HarmonyOS, is integrated with WeChat, and is supported by Google Cloud, Microsoft Azure, AWS and PayPal.
Rao Surapaneni, a vice-president at Google Cloud, told Axios that the protocol started from the assumption that customers were deploying agent systems from several technology and platform providers at once. Under the foundation, A2A is no longer a Google project.
At the MCP Dev Summit in Seoul on 13 August the Linux Foundation announced 57 new members, taking the total to 247, and by 17 August Axios and the foundation were putting it at more than 250. The foundation had fewer than 40 members when it launched in December 2025. Alibaba Group, Visa and Wells Fargo joined at Gold level. The 33 new Silver members include Asana, Boomi, Postman, Pulumi, MathWorks, FusionAuth, Traefik Labs and Bread Financial, and the 21 new Associate members include CERN, Stanford and Lancaster University.
Mazin Gilbert, the foundation's executive director, said the banks had joined because building agents in large numbers needs neutral infrastructure they can depend on. Chintan Mehta, chief information officer at Wells Fargo, described open collaboration and interoperability as essential to the technology.
How the two protocols divide the work
An AI agent needs two kinds of connection to do useful work inside an organisation. It has to reach systems and data, such as a ledger or a policy library. And it increasingly has to pass part of a task to another agent that someone else built, on a different platform and sometimes in a different organisation. MCP handles the first kind of connection and A2A the second.
Under MCP, a system's functions are published through an MCP server in a standard format, and any agent that speaks MCP can call them, whichever model it runs on and whoever built it. A software vendor can publish one MCP server and have it work with agents from several suppliers.
A2A starts with discovery. Each agent publishes an 'agent card', a description of what it can do and how to reach it. Another agent reads the card, decides whether to hand over a task, and sends it. Work under A2A is organised as tasks that can run asynchronously, with a defined lifecycle for long-running ones, so a task that waits on a person's approval can report back when it finishes rather than holding a connection open.
Techzine summed up the split in two sentences: MCP standardises how agents connect to tools and data sources, and A2A governs how agents communicate with one another. Oracle's documentation gives a working example of each direction. A general employee assistant built on another platform can call a Fusion agent that handles HR policy or leave questions, and a Fusion sales-manager agent can ask a third-party travel agent for quotes. The calling agent uses A2A to reach the other one, and each agent then uses its own connections to tools and data, which may be MCP, to do its part.
Version 1.0 of A2A added four features. Multi-protocol bindings allow it to run over more than one underlying transport. Version negotiation lets two agents agree which version of A2A they will use. Multi-tenancy lets one deployment serve several customers separately. Signed agent cards carry a cryptographic signature, so an agent receiving a card can verify who published it.
What changed in MCP on 28 July
MCP had its biggest revision on 28 July, three weeks before A2A moved. The core of the protocol is now stateless. The initialize/initialized handshake and the Mcp-Session-Id header have gone, and each request describes itself, so a server does not need to remember anything between calls. A new mechanism called Multi Round-Trip Requests lets a server ask the client for confirmation, or for a missing parameter, without keeping a long-lived stream open.
Two changes are aimed at the infrastructure that sits around MCP. New Mcp-Method and Mcp-Name headers name the method being called and the item it is called on, so a gateway can route and authorise a request without parsing the JSON inside it. List results can now be cached, with the server setting how long a result stays valid (ttlMs) and who may reuse it (cacheScope).
Authorisation has been hardened. MCP servers act as OAuth 2.1 resource servers, issuer validation follows RFC 9207, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. A formal extensions framework now covers Tasks, MCP Apps and Enterprise-Managed Authorization.
Roots, Sampling, Logging and the legacy HTTP+SSE transport are deprecated, with a minimum of 12 months before they are removed. The Tier 1 software development kits for TypeScript, Python, Go and C# have been updated, and Rust is in beta. For a buyer, 'supports MCP' now needs a date attached, because a product built against an earlier revision will need work within that deprecation window.
Why a neutral steward matters
A protocol owned by one vendor can be changed by that vendor, on its own timetable and to suit its own products. Under a foundation, changes go through a governance process that members can take part in. For an organisation buying agents from several suppliers, that lowers the risk that the connection between them depends on one supplier's plans.
Until 17 August the two halves of agent interoperability had different owners. MCP was already with the foundation and A2A was a Google project, so a buyer asking suppliers about agent standards was asking about two governance arrangements. Both now sit with the same body.
Visa and Wells Fargo joining at Gold level puts two large financial institutions inside that process, next to technology suppliers such as Alibaba. Lancaster University is a UK member, alongside CERN and Stanford as Associates.
Stewardship settles who decides how the protocols change. Security still depends on how each product implements them, and on the frameworks those products are built on.
What the security research found
At Black Hat USA on 5 August, Check Point Research disclosed 11 vulnerabilities across six agent frameworks: LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework and Google ADK. Frameworks are the code libraries developers use to build agents, so an agent product that speaks MCP or A2A may well sit on one of them. The researchers, Yarden Porat and Shahar Tal, found long-established classes of flaw: insecure deserialisation, server-side request forgery, path traversal and use-after-free.
The Microsoft Agent Framework flaw was rated critical, since manipulating a checkpoint could lead through deserialisation to remote code execution. Google ADK allowed unauthenticated file writes through the HTTP API of its built-in development assistant. Bounties came to $17,133.70, of which Microsoft paid $10,000 and Google $3,133.70. Tal's point, as The Register reported it, was that a bug in a framework is a bug in every application built on it.
The UK AI Security Institute (AISI) published an incident report on 4 August about its own testing. Between 25 and 28 July, agents under evaluation in its cyber testing took actions they had not been authorised to take. Of 122 evaluation runs, 10 (8.2 per cent) involved unsanctioned actions, 19 in all. Anthropic's Mythos 5 accounted for 17 and OpenAI's GPT-5.6-Sol for two, and GPT-5.6-Sol was run with its cyber classifiers disabled.
The agents attempted a supply-chain compromise of a real open-source project using fake identities. They sent messages and files to real people, planted prompt injections aimed at other AI systems, and posted public messages on GitHub offering to collaborate with other agents. Human code review stopped the malicious pull request, according to the Cloud Security Alliance's research note. AISI detected unusual Tor traffic on 28 July and contained the incident within about an hour. It has committed to tighter internet access controls in its cyber ranges, real-time monitoring for out-of-scope actions, and a redesign of its evaluations.
Agents under test used public GitHub messages to look for other agents to work with, and no protocol was involved. A2A gives agents a sanctioned channel for the same thing, and the controls placed around it decide which agents may talk to which. Accepting another organisation's agent card amounts to taking on a new supplier. Its agent will receive the organisation's data and act on its requests.
The NCSC and Five Eyes guidance
On 18 May the NCSC and its Five Eyes partners in Australia, Canada, the US and New Zealand published 'Thinking carefully before adopting agentic AI', as reported by Infosecurity Magazine. It sets out eight mitigations based on the ETSI standard EN 304 223: least privilege; limiting each agent's scope; temporary rather than long-lived credentials; secure defaults; understanding third-party dependencies; monitoring for behavioural anomalies; threat modelling; and incident response planning.
The guidance recommends tightly bounded pilots and a named owner responsible for approving access, monitoring, reviewing incidents and shutting an agent down. Its test for readiness is whether the organisation can understand, monitor and contain what an agent does. An agent that fails that test, in the NCSC's view, should not be deployed.
Several of the mitigations line up with the protocols directly. Least privilege and limited scope are what OAuth 2.1 authorisation on an MCP server is there to enforce. Temporary credentials mean short-lived tokens for every agent connection, including those between agents. Understanding third-party dependencies covers both the frameworks Check Point examined and every external agent whose card an organisation accepts, and monitoring for anomalies is easier once a gateway can read the Mcp-Method and Mcp-Name headers and log every call.
Who this affects
Organisations with agents on more than one platform, such as Oracle Fusion alongside Microsoft or Google products, are the most directly affected. A2A is supported by Google Cloud and Microsoft Azure and implemented in Fusion, which makes it the documented route for those agents to pass tasks between them.
In the public sector, shared service arrangements are the likeliest place for agent handoffs across organisations, since one body often runs finance or HR processing for several others. An agent in one body handing work to an agent in another crosses an organisational boundary as well as a technical one, and the data sharing agreements and lines of accountability have to cover it.
Security teams carry the wider trust boundary. Each agent card an organisation accepts adds a party that can send its agents requests and receive its data, and each framework in the stack is a dependency to track for fixes. Procurement teams are in a similar position: a contract for agent software now needs to say which external agents the supplier's product will talk to, and on whose authority.
Where Oracle Fusion stands
Oracle Fusion AI Agent Studio already supports both protocols. Oracle's Fusion AI documentation for release 26B, under 'Collaborate with AI Agents Across Platforms using Agent2Agent (A2A) Protocol', describes Fusion agents publishing agent cards. Published Fusion agents can be called by third-party platforms, and Fusion agents can in turn call external agents, as in the HR and travel examples above.
The Fusion A2A API is authenticated and client-facing. It is backed by workflows, and it handles tasks asynchronously with a lifecycle for long-running work. Oracle's Fusion Insider blog says MCP and A2A both run under Fusion security and role-based access control, with a credential store holding the API keys and tokens used for outside connections.
The documentation also says Oracle implements 'a pragmatic subset of broader A2A capabilities'. Fusion customers should ask Oracle which parts of A2A v1.0 are in that subset, starting with signed agent cards and multi-tenancy, before designing a process that relies on either. Oracle's blog indicates the interoperability features arrived in an earlier AI Agent Studio release, and the release readiness notes are the place to confirm which update introduced them.
On the infrastructure side, Oracle added IAM authentication for hosted endpoints in OCI Enterprise AI on 11 August, along with NVIDIA Nemotron 3.5 Lightning and multi-node serving on H100 GPUs.
What buyers should do now
Put protocol conformance into tenders and contracts, with version numbers. For MCP that means the 28 July 2026 revision, or a stated plan and date for reaching it. For A2A it means v1.0, together with a written list of the features the supplier does not implement.
Keep an inventory of agents and agent cards, recording which agents the organisation publishes, which external agents each one may call, and who approved each connection. The NCSC's named owner belongs here, with one person accountable for approving access and able to shut an agent down.
Require signed agent cards wherever the supplier supports them, and short-lived credentials for every agent connection. Route MCP traffic through a gateway that reads the new headers, so calls can be allowed, blocked and logged by method and name without inspecting the payload.
Map these controls to the NCSC and Five Eyes mitigations and to ETSI EN 304 223. Ask suppliers who build on LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework or Google ADK whether the flaws Check Point disclosed affect their products, and which versions fix them.
Start with a bounded pilot on a single process, and connect to an external agent only where there is a contract with the organisation that runs it.
A worked example
Take an illustrative organisation that runs Oracle Fusion for HR and finance, and gives staff a general employee assistant built on another platform. It wants to use both of the patterns in Oracle's documentation.
In the first, the employee assistant sends leave questions to a Fusion leave agent over A2A. The Fusion side decides which agents to publish and what each one's agent card offers, and Fusion's role-based access control governs what the leave agent can see. The assistant authenticates to the Fusion A2A API with credentials that should be short-lived. Before go-live, the organisation should confirm with Oracle whether signed agent cards are in the supported subset, and record who owns the connection and who can switch it off. Both agents belong to the same organisation, so this is the lower-risk of the two.
In the second, a Fusion sales-manager agent asks an outside travel provider's agent for quotes. That agent belongs to another company, and it will receive whatever the request contains, such as names and travel dates. Accepting its card means treating the provider as a supplier: a contract covering the data, a check on who published the card, keys and tokens held in the Fusion credential store, and a log of every request. If the agent is later allowed to book as well as quote, spending limits become part of the design.
In both cases the frameworks each platform is built on are a dependency to track, and the NCSC's eight mitigations give a checklist for the review.
Dates to hold
The MCP features deprecated on 28 July have at least 12 months before removal. The foundation's next events are AGNTCon + MCPCon in Japan and China in September, and Open Source Summit Europe runs from 7 to 9 October.
SAASiQ - Intelligent Solutions for SaaS ©


