Oracle AI Agent2Agent (A2A) Protocol
The Oracle AI Agent2Agent (A2A) protocol lets Fusion agents built in AI Agent Studio interoperate with agents on other platforms — publishing an Agent Card that describes what an agent can do, discovering peer agents through a registry, and invoking them agent-to-agent. It is the newest of Oracle's agent-connectivity capabilities: generally available in release 26C, and still early in its maturity curve. This page explains what A2A is, how Agent Cards and registry discovery work, how A2A invocation differs from the app-to-agent paths covered by the agent REST API and external access pages, and the security, testing and governance work interoperating agents create.
Last reviewed: 19 July 2026 · A2A is a newly released, evolving capability — confirm current behaviour against Oracle's 26C readiness documentation before you design around it.
Scope note — three ways an agent connects, and where A2A fits. Oracle exposes three distinct connectivity models, and they are easy to conflate:
- A2A (this page) — agent-to-agent. One agent discovers and invokes another autonomous agent, on Oracle or another platform, using Agent Cards and a registry.
- Agent REST API — app-to-agent. An external application calls in to invoke a Fusion agent through a REST endpoint (polling or SSE). That page owns the endpoint mechanics.
- External access — the identity and access model for any external invocation: tokens, role-based access, async handling and audit. That page owns the trust model.
A2A is not a replacement for either — it is the agent-to-agent layer that sits alongside them and, in practice, depends on the same identity and audit foundations described on the external access page.
What Is the Oracle AI Agent2Agent (A2A) Protocol?
Agent2Agent (A2A) is a protocol for cross-platform agent interoperability. It gives an agent a standard way to describe itself, to be found by other agents, and to be called by them — so that an agent built in Oracle AI Agent Studio can participate in a wider ecosystem of agents rather than being reachable only through hand-built point-to-point integrations. Per Oracle's 26C readiness documentation, Oracle's A2A support comprises three parts: Agent Cards that advertise an agent's capabilities, registry discovery so agents can find one another, and A2A invocation so one agent can call another.
The practical shift is that an agent stops being an endpoint you wire up manually and becomes a participant that can be discovered at runtime — a Fusion agent exposes an Agent Card, and an agent on another compliant platform locates it through a registry and invokes it, or the reverse. It is the same conceptual direction as Oracle's MCP tools (generally available in 26A) but aimed at agent-to-agent collaboration rather than tool consumption.
Availability: Generally available — release 26C A2A is the most recent of Oracle's verified agent-connectivity capabilities. Because it is new and evolving, treat the specifics — registry behaviour, card contents, invocation semantics — as subject to change, and confirm details against the Oracle references below. Note what A2A does not do: it does not change Oracle's underlying permission model. Interoperating agents still operate within the roles, policies and approvals that already govern them — A2A is a connectivity capability, not a new authority.
Why Agent Interoperability Matters
Most enterprises will not run a single vendor's agents in isolation. A Fusion Financials agent may need to hand a task to a procurement agent on another platform; a third-party agent may need to call a Fusion agent for master-data context. Without a shared protocol, every such connection is a bespoke integration — separately built, secured, maintained, and broken by every change on either side. A2A matters because it turns that combinatorial integration problem into a discoverable one. The benefits — and the reasons they need governing — are best read together:
Composition over point-to-point
Agents can be assembled into cross-platform workflows without hand-coding each link, reducing the integration surface an organisation maintains.
Runtime discovery
A registry lets an agent find a capable peer when it needs one, rather than every counterpart being pre-declared at design time.
Specialisation
A best-fit agent for a task can be invoked wherever it lives, so you are not forced to rebuild a capability just to keep it in one platform.
A wider trust boundary
The same reach that makes A2A useful means an action can now originate from an agent you did not build — which is exactly why interoperability demands deliberate security and governance.
Interoperability is a means, not an end — the value only materialises if the interoperating agents remain observable, testable and governed, the subject of the second half of this page.
Agent Cards & Registry Discovery
The two mechanisms that make discovery possible are Agent Cards and the registry. An Agent Card is the agent's machine-readable self-description — an advertisement of what it can do, so another agent can decide whether it is the right one to call. Registry discovery is the lookup layer: agents are registered so peers can find them, rather than every relationship being wired in advance. Oracle's 26C readiness documentation names these three elements — Agent Cards, registry discovery and A2A invocation — as the shape of its A2A support; this page does not invent field names, schema details or registry internals Oracle has not published.
Practically, an Agent Card is the primary control point for interoperability. Whatever it advertises is what peers will believe an agent can do, so its accuracy is both a functional and a governance concern:
- •A card that over-describes an agent invites peers to call it for tasks it cannot safely perform.
- •A card that under-describes an agent hides genuinely useful capability and pushes callers toward bespoke integrations instead.
- •A stale card — unchanged after the agent's tools, instructions or permissions changed — is a discovery-layer defect that ordinary functional testing will miss.
Registry discovery raises a parallel question: which agents belong in the registry, who may register them, and who may discover them. Those are governance decisions, covered later on this page, not defaults to accept unexamined.
A2A Invocation
A2A invocation is the act of one agent calling another agent-to-agent. Once a peer is discovered through the registry and its Agent Card evaluated, invocation is how the calling agent delegates a task and receives a result. This is where interoperability stops being metadata and starts having real-world effect — the called agent may read data, reason over it, and, depending on its own configuration, take actions.
The essential point is who initiates the call. In the REST API and external-access models, the initiator is an external application or a human-facing channel. In A2A, it is another autonomous agent making its own decision to call — small in wiring terms, large in governance terms, because an automated caller can invoke far more often, on its own judgement, with no person in the loop for each call.
That is why Oracle's existing controls remain load-bearing here. A called Fusion agent still runs within its assigned roles and policies; where an action needs sign-off, the agent's own Require Human Approval-style gates (as used by external REST tools, enhanced in 26A) and workflow checkpoints continue to apply regardless of whether the caller was a human, an app or a peer agent. A2A does not bypass those controls — and you should verify by testing that it does not.
How this differs from the REST API and external access. The agent REST API is the endpoint an application uses to invoke an agent; external access defines the identity, tokens, role-based access and audit that govern any external invocation. A2A invocation is agent-initiated and rides on the same trust and audit foundations — so read those two pages alongside this one, and treat their controls as prerequisites for safe A2A, not alternatives to it.
A2A Interoperability — Concept Flow
A conceptual view of how an agent-to-agent interaction proceeds, from publishing a capability to a governed result. This is an orientation model, not an Oracle-published sequence — confirm the mechanics against the 26C references.
Agent-to-agent interaction sequence
- Publish & register: the agent exposes an Agent Card describing its capabilities accurately and no more, and is registered so peers can discover it rather than hard-code a reference.
- Discover, evaluate & invoke: a peer locates the agent, reads its card and trust context, then invokes it carrying identity and tokens consistent with the external-access model; the called agent runs within its own roles and policies.
- Gate, result & audit: human-approval checkpoints and workflow controls apply regardless of an agent caller, the outcome returns to the caller, and every hop is recorded for audit and monitoring.
Suggested visual: a two-lane agent-to-agent diagram (calling agent / called agent) with the registry between them and an approval gate on the action path, for the web team to produce.
Security Implications of Interoperating Agents
Interoperability widens the trust boundary. When agents can discover and invoke one another, an action inside your Fusion environment can be triggered by an agent you did not build, running logic you cannot fully see. The two dominant risk themes are trust — do you actually know the agent on the other end? — and compounded access — chained invocations can combine each agent's permissions into an effective reach no single role review anticipated.
A2A does not remove Oracle's role-based controls, human-approval gates or audit; it makes exercising them correctly more important, because the caller is automated. The risks specific to interoperating agents:
| Risk | How it arises with A2A | Potential impact | Mitigation / test focus |
|---|---|---|---|
| Unverified peer | An agent is discovered and invoked without confirming its identity or provenance | Data or actions handed to an untrusted party | Enforce identity/token checks per the external-access model; test rejection of unknown peers |
| Compounded access | Chained A2A calls combine several agents' privileges | Effective reach exceeds any single role review; latent SoD conflict | Map end-to-end effective access; review against segregation-of-duties controls |
| Misleading Agent Card | Card over- or under-states capability, or is stale | Wrong agent invoked; unsafe delegation | Validate card accuracy against actual behaviour; re-check after any agent change |
| Approval-gate bypass | Agent-initiated call skips a human checkpoint that a UI path would enforce | Sensitive action executes unreviewed | Assert human-approval gates fire on the A2A path, not only the human path |
| Data leakage across boundary | Context or business data passed to a peer on another platform | Confidential data leaves the trust boundary | Restrict what an Agent Card and invocation may expose; test payload contents |
| Prompt / instruction injection | A malicious peer returns content that steers the calling agent | Calling agent takes unintended actions | Treat peer responses as untrusted input; test agent behaviour on adversarial returns |
| Unbounded invocation loops | Agents call one another recursively or excessively | Runaway cost, load, or cascading failure | Test loop limits, timeouts and rate controls on the A2A path |
| Registry exposure | Too many agents discoverable, or by the wrong callers | Expanded attack surface; shadow interoperability | Govern who may register and discover; review registry contents periodically |
| Audit gap | Agent-to-agent hops not fully traced end to end | Cannot reconstruct who caused an action | Confirm each A2A hop is captured in the audit trail before relying on it |
| Evolving-standard drift | A2A behaviour changes across quarterly updates while it matures | Assumptions silently break after an update | Re-test interoperability on every release; track the 26C+ readiness notes |
Compounded access is where interoperability most directly touches financial controls. Because chained agents can aggregate privileges, A2A deserves review against your segregation-of-duties framework — see SyntraFlow's Oracle Fusion Segregation of Duties analysis as a complementary lens for spotting where an agent-to-agent chain creates a conflict a single-role review would miss.
Testing Agent Interoperability
Interoperability testing asks a different question from ordinary agent testing — not only "does this agent do its job?" but "does it behave correctly when it is discovered and called by another agent, and does it call others safely?" Because A2A is new and a peer agent is outside your control, this is best treated as a distinct discipline. A practical interoperability test checklist:
Agent Card accuracy — the advertised capability matches actual behaviour, and nothing more.
Discovery scope — only the intended agents are discoverable, by only the intended callers.
Identity & token enforcement — invocation from an unverified peer is refused.
Approval gates on the A2A path — human-approval checkpoints fire for agent-initiated actions, not just human ones.
Compounded-access mapping — the effective reach of a chained invocation is enumerated and reviewed.
Adversarial peer response — the calling agent is not steered by malicious returned content.
Boundary & loop controls — timeouts, rate limits and recursion limits hold under stress.
End-to-end audit & regression — every hop is traceable, and interoperability is re-verified on every quarterly update while A2A matures.
Interoperability testing overlaps with, but does not replace, the broader agent validation disciplines. It sits within the connectivity work of AI Agent Studio and the composed-workspace context of Oracle Fusion agentic applications, where teams of agents already coordinate under existing role-based permissions.
Governing A2A Interoperability
Governance for A2A is about deciding, on purpose, which agents may interoperate, with whom, and under what controls — before the registry fills up organically. The connectivity is new; the governing principles are not. Oracle positions Fusion agents as operating within existing role-based permissions, policies, approvals and compliance frameworks, and A2A should be governed as an extension of that operating model, not an exception to it. Core questions to answer before enabling A2A broadly:
- •Registration authority — who may publish an Agent Card and register an agent for discovery?
- •Discovery scope — which agents are discoverable, and by which internal or external callers?
- •Trust policy — what identity and provenance an agent must prove before it may be invoked or invoke others.
- •Approval requirements — which agent-initiated actions must still route through a human checkpoint.
- •Change control — how an Agent Card is kept current as the agent behind it changes, and who reviews it.
- •Audit ownership — who is accountable for reconstructing an agent-to-agent interaction after the fact.
Because A2A is agent-initiated, these are not one-time setup choices — they need periodic review as the registry grows and as Oracle's implementation evolves across releases. Governing agent-to-agent interoperability is a continuation of the same accountability you already apply to who can act in Fusion, extended to the case where the actor is a peer agent.
Release & Availability — A2A in 26C
Oracle's Agent2Agent (A2A) protocol — Agent Cards, registry discovery and A2A invocation — is generally available in release 26C, per Oracle's 26C readiness documentation. It is the most recent of Oracle's verified agent-connectivity capabilities, arriving after MCP tools, external REST tools, REST API access to agents and Slack/Teams channels (all delivered in 26A).
Read "generally available" as "released and supported," not as "mature and unchanging." A2A is new and its capabilities are evolving; the practical guidance is to build against it deliberately, keep a close eye on subsequent quarterly readiness notes, and re-test interoperability on each update rather than assuming stability. Where this page and the Oracle documentation differ, the Oracle documentation is authoritative.
| Capability | What it connects | Availability |
|---|---|---|
| Agent2Agent (A2A) protocol | Agent-to-agent — Agent Cards, registry discovery, invocation | GA 26C (newest) |
| REST API access to agents | App-to-agent — external apps invoke a Fusion agent (polling/SSE) | GA 26A |
| MCP tools | Agent-to-tool — connect to external MCP-compliant servers | GA 26A |
| External REST tools | Agent calls out to third-party APIs; Require Human Approval option | Enhanced 26A |
Availability reflects Oracle's readiness documentation as reviewed on 19 July 2026. Confirm current status against the Official Oracle references below.
How SyntraFlow Helps with A2A Interoperability
SyntraFlow helps organisations assess and test the risks that agent interoperability introduces. The capabilities below describe how SyntraFlow can be configured to support A2A validation — scope for your environment is confirmed at assessment, not assumed here.
Interoperability risk assessment
SyntraFlow helps organisations assess where A2A widens the trust boundary — unverified peers, compounded access and audit gaps — against the risk themes on this page.
Approval-gate validation
SyntraFlow can be configured to test that human-approval checkpoints fire on the agent-initiated path, not only the human-facing one.
Compounded-access review
SyntraFlow can help map the effective reach of chained invocations so it can be reviewed against segregation-of-duties expectations.
Release-aware regression
SyntraFlow can connect release intelligence with test planning so interoperability behaviour is re-checked as A2A evolves across quarterly updates.
Adversarial-response testing
The SyntraFlow roadmap can support exercising a calling agent against malicious or malformed peer returns to check it is not steered off-task.
Evidence for audit
SyntraFlow can be configured to retain execution evidence for interoperability test runs to support governance sign-off.
A note on capability. A2A is a newly released Oracle capability and this section describes what SyntraFlow can be configured to help assess, not a guarantee of coverage. SyntraFlow does not automatically test every Oracle AI agent or guarantee interoperability safety; the specific tests applicable to your agents, registry and roles are confirmed during an assessment. SyntraFlow's own AI-driven testing engine — self-healing scripts and test generation — is a separate product capability used to test Oracle, and is distinct from Oracle's A2A protocol described here.
Related Oracle AI Pages
A2A sits within Oracle's wider agent connectivity and governance model. Go deeper on adjacent topics:
AI Agent Studio ⭐
The platform where agents and their connectivity are built.
Agent REST API →
App-to-agent invocation and endpoint mechanics.
Agent External Access →
Identity, tokens, role-based access and audit.
Agentic Applications →
Coordinated teams of agents in composed workspaces.
Oracle AI Hub →
The overview of Oracle's AI capabilities.
Segregation of Duties →
A lens for compounded-access risk across agent chains.
Official Oracle References
The verified Oracle sources relevant to A2A and the connectivity models discussed on this page. These are external Oracle links; confirm current details against them, as A2A is new and evolving. Last reviewed: 19 July 2026.
- •Agent2Agent (A2A) — 26C readiness: docs.oracle.com/…/26C-common-wn-f49247.htm
- •REST API access to agents — 26A readiness: docs.oracle.com/…/26A-common-wn-f42605.htm
- •MCP tools — 26A readiness: docs.oracle.com/…/26A-common-wn-f42183.htm
- •AI Agent Studio — key capabilities: docs.oracle.com/…/fusion-ai/aiaas/key-capabilities.html
- •Oracle Fusion AI — product overview: oracle.com/applications/fusion-ai/
Frequently Asked Questions
What is the Oracle AI Agent2Agent (A2A) protocol?
▼
A2A is Oracle's protocol for cross-platform agent interoperability. It lets a Fusion agent publish an Agent Card describing its capabilities, be found by other agents through registry discovery, and be invoked agent-to-agent. Per Oracle's 26C readiness documentation it comprises those three elements, and is generally available in release 26C.
When did Oracle release A2A, and how mature is it?
▼
A2A is generally available in release 26C — the newest of Oracle's verified agent-connectivity capabilities, arriving after MCP tools, external REST tools and REST API access (all 26A). "Generally available" means released and supported, not finished; it is new and evolving, so confirm specifics against Oracle's readiness notes and re-test as it matures.
How is A2A different from the Oracle AI agent REST API and external access?
▼
The agent REST API is app-to-agent: an external application calls in to invoke a Fusion agent. A2A is agent-to-agent: another autonomous agent discovers and invokes it. External access defines the identity, tokens, role-based access and audit that govern any external invocation — a prerequisite A2A rides on, not an alternative to it. The key difference is who initiates: an app versus a peer agent, which changes the governance.
What is an Agent Card?
▼
An Agent Card is an agent's machine-readable self-description — it advertises what the agent can do so other agents can decide whether to invoke it. It is the primary control point for interoperability: an inaccurate or stale card can cause the wrong agent to be called or unsafe delegation, so its accuracy should be validated against actual behaviour and re-checked after any change.
Does A2A bypass Oracle's roles and approval controls?
▼
It should not. A called Fusion agent still operates within its assigned roles, policies and approval gates regardless of whether the caller is a human, an application or a peer agent — A2A is a connectivity capability, not a new authority. Because the caller is automated, verify by testing that human-approval checkpoints and other controls actually fire on the agent-initiated path.
What are the main security risks of interoperating agents?
▼
The two dominant themes are trust — do you actually know the agent on the other end? — and compounded access, where chained invocations combine several agents' privileges into a reach no single role review anticipated. Others include misleading Agent Cards, approval-gate bypass, data leakage across the trust boundary, prompt injection from a peer, unbounded loops and audit gaps.
How should you test A2A interoperability?
▼
Test Agent Card accuracy, discovery scope, identity and token enforcement, approval gates firing on the agent-initiated path, compounded-access mapping, adversarial peer responses, loop and rate controls, and end-to-end audit. Because A2A is new and evolving, re-verify interoperability on every quarterly update rather than assuming stability.
How can SyntraFlow help with A2A?
▼
SyntraFlow helps organisations assess the risks interoperability introduces and can be configured to test approval gates on the agent-initiated path, map compounded access for segregation-of-duties review, and re-check interoperability behaviour as A2A evolves. Because A2A is new, coverage is confirmed during an assessment rather than assumed — SyntraFlow does not guarantee interoperability safety or automatically test every agent.
Assess Oracle AI Agent Risks
A2A opens your Fusion agents to a wider ecosystem — and a wider trust boundary. See how SyntraFlow can be configured to help you assess interoperability risk, validate approval gates and prepare for how A2A evolves each quarter.