A2A Solves How Agents Talk. It Does Not Solve Who Is Allowed.

Imagine a finance agent asks a procurement agent to retrieve a contract.

The procurement agent asks a document agent to find the signed copy. The document agent calls a storage service and returns a file. The finance agent extracts a renewal clause and drafts a recommendation.

Every agent behaved helpfully. Every protocol message was valid. Every service was available.

One question still decides whether the workflow was legitimate:

Whose authority did the document agent use?

Did the finance user have permission to see the contract? Did the procurement agent silently substitute its broader service credential? Was the request limited to one supplier, or could it search the entire legal archive? Which organisation did the task belong to? If the final answer is challenged, can anyone reconstruct the chain?

Agent-to-agent protocols solve an important problem: how agents find each other and exchange work.

They do not, by themselves, solve who is allowed.

What A2A Actually Solves

The Agent2Agent protocol gives independent agent systems a common interaction model. An agent can publish an Agent Card describing its identity, skills, endpoint, supported interaction modes, and authentication requirements. Other agents can discover those capabilities, create tasks, exchange messages and artifacts, and follow work that may continue asynchronously.

That is materially different from every company inventing a private integration for every pair of agents. The A2A specification treats agents as enterprise applications and builds on familiar web security mechanisms. The original launch prompted a substantial Hacker News debate about the difference between an agent and a tool, but there was broad agreement that stateful, long-running collaboration needs a better abstraction than hundreds of narrow calls. Read the HN discussion.

MCP solves a related problem at another boundary. It standardises how an agent or host discovers and uses tools, resources, and prompts exposed by a server. A2A is generally framed around agent collaboration; MCP is generally framed around an agent reaching capabilities and context.

Both make the ecosystem more interoperable.

Interoperability is not authority.

A Valid Message Can Still Be an Unauthorised Action

A protocol can validate that a message has the expected shape. Transport security can protect it in transit. Authentication can establish which client connected.

None of those facts necessarily establish that the action is allowed.

An agent may be authenticated as procurement-agent. The request may have originated from a user in finance. The procurement agent may possess access to contracts that the finance user cannot see. If it executes the request under its own broad identity, the workflow has increased the user's authority simply by relaying the message.

This is a version of the classic confused-deputy problem. A deputy has legitimate power. A caller convinces it to use that power on the caller's behalf without preserving the caller's actual limits.

Agents make this easier to encounter because delegation is the product. We want one agent to ask another for help. We want specialised agents to own tools and context the first agent does not possess. The risk appears when specialisation becomes an accidental privilege bridge.

The unsafe chain looks like this:

1. A user asks Agent A to perform a task.
2. Agent A sends a valid request to Agent B.
3. Agent B authenticates Agent A.
4. Agent B acts with all of Agent B's authority.
5. The user receives a result they were never entitled to obtain directly.

Nothing in that sequence requires a forged token or malformed protocol message.

The failure is a lost chain of custody.

Actor and Subject Are Different

Safe delegation needs to distinguish at least two identities:

• The actor: the agent or service performing the immediate call.
• The subject: the user or workload whose authority the actor is exercising.

The actor matters for accountability. The subject matters for authorisation.

Collapsing them creates two opposite failures. If every action is attributed only to the user, the system cannot tell which agent actually performed it. If every action is authorised only under the agent's identity, the agent can become a privilege escalator for any user able to reach it.

Established authorisation standards already contain useful primitives for this distinction. OAuth token exchange, defined in RFC 8693, can represent both a subject and an actor in delegated scenarios. The important principle is larger than one standard: authority must travel explicitly, with an audience and scope, rather than being inferred from the fact that two agents can communicate.

An agent protocol can carry that credential. It should not be mistaken for the policy that decides what the credential permits.

Authentication Is the Beginning of the Question

Enterprise discussions often compress identity and authorisation into the word “auth.”

That hides several separate decisions:

1. Who established the connection?
2. Which human or workload initiated the task?
3. Which organisation are they acting within?
4. Which role and policy apply?
5. Which capability is being requested?
6. Which resource or governed product can that capability reach?
7. Does the action require approval?
8. What evidence must be retained?

A2A Agent Cards can advertise security schemes. MCP has also advanced towards centrally managed enterprise authorisation. Its Enterprise-Managed Authorisation extension allows an organisation's identity provider to control which MCP servers users receive through their corporate identity. That is a meaningful improvement over repeated per-application consent flows. Read the MCP announcement.

Central provisioning still does not remove the need for resource and action policy at execution time.

“This user may connect to the finance server” is not the same policy as “this user may query payroll,” “this agent may create a journal,” or “this run may export customer data.”

Connection authority opens the door. Action authority decides which room can be entered and what can happen there.

How MLX Holds the Chain of Custody

MLX separates transport authority, tenant authority, user authority, and runtime capability.

User-scoped authority comes only from the signed x-mlx-subject-token. The x-user-context header is display metadata, not permission. A tenant API key represents tenant-level authority. MLX_APP_SHARED_SECRET protects transport between trusted components; it does not become the user's identity.

Those distinctions stop convenient metadata from quietly becoming authorisation.

Clients request capabilities for a run. The control plane grants the allowed intersection of that request and tenant policy. Normal policy can include readonly-data and writeback; browser and terminal access remain explicit opt-ins.

The intersection matters.

If a client asks for readonly-data, it should not receive terminal access because the agent happens to support it. If a tenant forbids writeback, a client cannot create it by requesting a broader profile. Neither the agent nor the model gets to widen the boundary through persuasion.

For a governed Twin query, the boundary becomes narrower again. The helper creates a read-only run with the warehouse and Twin catalog. The agent selects a published manifest and queries the exact relation it names. A structured product citation must match the observed run evidence before the helper returns the result.

Authority has several linked objects:

• the signed subject;
• the organisation;
• the granted capability;
• the published product and version;
• the relation actually queried;
• the run and evidence record.

The protocol that carried the original request is not one of the objects allowed to redefine those decisions.

Do Not Delegate Raw Credentials

The most brittle agent integrations give a model a powerful credential and rely on instructions to keep its use narrow.

This reverses the proper relationship.

The credential defines what the system can do. The prompt merely describes what someone hopes it will do.

An agent that can read a secret can potentially expose it. An agent that holds a token with access to several organisations can potentially cross the requested boundary. An agent that invokes another service under a global identity can turn that service into a deputy for less privileged callers.

Safer systems broker credentials at the tool or service boundary, keep raw material outside agent-visible state, and apply policy to the requested action. MLX uses Infisical-backed secret brokers for plugin and connector credentials. Resolved plugin secrets are supplied immediately before the outbound operation and serialise as redacted values rather than entering ordinary agent state.

That does not solve every delegation problem. It ensures the model does not need possession of the secret in order to use an approved capability.

An agent should receive authority to perform a bounded operation, not custody of the credential from which unlimited operations can be improvised.

A Reviewed Product Is Part of Authorisation

Traditional authorisation often stops at resources: this identity may read this database or call this API.

Enterprise agents also need authority over meaning.

A finance user may be permitted to see revenue data while still being required to use the board-approved revenue product for a board report. Giving the agent arbitrary access to warehouse tables leaves it authorised to read but free to reinterpret.

The Twin adds a product boundary:

• the definition has been reviewed;
• the product has a stable version;
• the published relation is explicit;
• available fields and filters are constrained;
• validation evidence is attached;
• the run can cite what it actually used.

This is not a replacement for identity or capability policy. It is the business-semantic part of the authorisation decision.

The agent is allowed to answer this class of question using this approved interpretation of the company's evidence.

What MLX Does Not Expose Today

MLX does not currently implement A2A.

It also does not expose a generally available remote Twin endpoint that arbitrary Claude Code, Codex, Gemini, ChatGPT, or other third-party agents can connect to directly.

MLX can consume configured MCP servers as runtime plugins today. That makes MLX an MCP client at that boundary. It is not the same thing as operating a public inbound MCP gateway for the Twin.

First-party Twin access currently runs through the admin workspace, the typed sdk.twin namespace, MLX task agents with bound skills, fleet tooling, evaluation runners, and guarded recovery paths.

A remote MCP surface, public manifest, and public CLI are product direction. If they are exposed, they must preserve the same identity, organisation, capability, product, and evidence contract across the wire. Supporting a fashionable protocol before that chain is coherent would make interoperability easier by making authority ambiguous.

The correct sequence is contract first, transport second.

What to Ask Any Agent Platform

When an agent can call another agent or tool, ask:

1. Does the downstream service see both the acting agent and the initiating subject?
2. Can the caller's authority become broader at any hop?
3. Is capability granted as an intersection, or does the agent receive everything it supports?
4. Are credentials brokered outside model-visible state?
5. Is resource access separated from approval to use a particular business definition?
6. Can the final result identify which identities, policies, products, and operations were involved?
7. Does a failed identity or policy check stop execution, or merely produce a warning?

If the answer is “the model knows not to do that,” the system does not have a boundary. It has an instruction.

Talk Is the Easy Part

Agents need common protocols. A2A and MCP are valuable because bespoke pairwise integrations will not scale to the number of agents, tools, and services now being built.

But communication is the easy half of collaboration.

The hard half is preserving authority while the request moves: who asked, which agent acted, what was permitted, which company meaning applied, and what evidence came back.

A valid message proves that agents can talk.

A governed chain of custody proves that they were allowed to do what they did.

---

Previous: Your Agent Remembers You. Who Remembers the Company?. Why personal continuity and institutional memory need different owners.

Read first: One Twin, Many Interfaces. The current map of Twin interfaces and the contract a future external surface must preserve.

Next: Context Is a Security Boundary, Not a Token Budget. Why deciding what an agent may see is part of deciding what it may do.