The agent interoperability problem is being solved in public, quickly, and reasonably well. Two protocols now cover most of the ground: agents can describe themselves, find each other, and exchange work.
Read either specification closely, though, and you find the same shape of hole in both. They tell you how to reach an agent. Neither will tell you whether to.
What the protocols actually say about trust
A2A — the Agent2Agent protocol Google donated to the Linux Foundation in June 2025, with AWS, Microsoft, Salesforce and others alongside it — gives agents a public descriptor called an Agent Card, served at /.well-known/agent-card.json. The card declares who an agent is, what it can do, and which authentication schemes a caller must satisfy: API key, HTTP auth, OAuth 2, OpenID Connect, mutual TLS. Standard, well-chosen, unglamorous plumbing.
Now search the specification for reputation, or standing, or any notion of an agent’s track record. There isn’t one — and the protocol is candid about where its boundary falls. Its payloads, the docs note, “don’t carry user or client identity information directly,” and “authorization logic is specific to the agent’s implementation, the data it handles, and applicable enterprise policies.” That is not an oversight. It is an explicit handoff.
The Model Context Protocol says it more bluntly. Its authorization chapter is substantial, and it opens by announcing that “Authorization is OPTIONAL for MCP implementations.” The security section goes further: “While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD…” — followed by everything implementors are on the hook for. And on tool safety: descriptions of tool behaviour “should be considered untrusted, unless obtained from a trusted server.”
That final clause is the entire subject of this essay. The spec correctly identifies that trust is prior to the protocol, and then correctly declines to solve it. “Unless obtained from a trusted server” is not a gap in MCP. It is MCP pointing at a job and saying: not mine.
Someone still has to do that job. Almost nobody is.
Four questions
A trust system for agents has to answer four things, and they are harder in this order:
Who is this? Not which key signed the request — who is behind it, and on whose authority. A descriptor an agent publishes about itself answers what it claims to be, which is a different and much weaker thing; the agent identifier takes that argument apart properly.
What may it do — here, for this person, right now? Capability is relational, not intrinsic. The agent that may read a calendar should not thereby be allowed to spend from an account, and the answer changes per relationship.
What happens when it misbehaves? A system with no consequence has no trust in it, only optimism. Reputation without the ability to remove standing is decoration.
Who is accountable? Every agent traces to a legal person who can be reached, argued with, and held responsible. An agent is not a party to anything. Its operator is.
Authentication answers a strict subset of question one. It is necessary and nowhere near sufficient — mutual TLS proves you are talking to the same counterparty as last time, and says nothing whatsoever about whether that counterparty should be booking things in your name.
What we implement today
Agents here are not anonymous callers holding a key. Each is a record with an identity, and that identity is bound rather than declared: an agent is tied to the business it acts for and to the capability it operates.
Those two bindings are not enforced equally, and the difference is more useful to you than the headline. The business binding is a wall: an agent asking to act for a business it isn’t attached to is rejected, and doesn’t execute. The capability binding is not a wall. When the capability a caller names disagrees with the one on the agent’s record, the system logs the disagreement and carries on using the stored value. There is a stricter resolver in our codebase that refuses that case outright, and nothing in production calls it. There is a skill-level blocking path, and it ships behind a flag set to off. We would rather write those two sentences than round the whole thing up to “refused.”
Above that binding sits the enforcement described in governance for agents: the deny-wins pipeline, rules held where a jailbroken agent cannot reach them, and escalation to a named person the moment something falls outside the ordinary. That note makes the architectural case; this one owes you the coverage. Guardrails — the named rules that stop a specific action on a specific tool — are attached to six tools out of the fifty-three in our catalog, and all six are in a single domain. The audit trail those checks write is, today, an in-memory record with a TODO where the database write belongs, which means it lasts exactly as long as the process does. “Governance you can’t replay is governance you’re taking on faith” is our own sentence from that note, and we are not going to quietly exempt ourselves from it.
Beside all that, the position from the agent supply chain is poisoned: our tool catalog is first-party and curated, because an open skill marketplace is a distribution channel for whatever anyone uploads. And the credentials authorizing sensitive actions are deliberately unattractive to steal — signed, request-bound, valid for seconds rather than sessions, worthless against any request but the one they were minted for.
Here is the honest limit, worth stating plainly because it is where the whole industry currently is. The subject of those credentials is a human acting for a business. No field in them names an agent. When an agent acts here, the credential carrying the action says a person did it. The accountability is real and lands on someone reachable — but the agent itself is not yet a first-class identity on the wire.
Closing that gap is the passport: identity, reputation and verification in one credential, the Trust API on our developers page. Coming What we ship today is binding, enforcement and accountability. What we don’t yet ship is the agent’s own name on the credential — the subject of the agent identifier.
This composes, it doesn’t compete
None of this argues against A2A or MCP, and we are not proposing a rival protocol. We speak these dialects, and it is worth being exact about which direction we speak them in: we publish MCP client metadata, and we run an MCP client that dials out to third-party providers’ servers so our own agents can use the tools those providers expose. The traffic goes outward. There is no inbound MCP surface here — no door through which an outside developer’s agent calls myOrbit. As bring your own agent puts it, the live developer surface today is IP protection; the seat and the rails around it are still ahead. Interop is being solved well by people with more standing in it than us.
The argument is about layering. A2A’s own discovery chapter lists three mechanisms, and the second is curated registries — an intermediary holding a collection of cards that clients query. That word “curated” is doing enormous unexamined work. A registry is where trust has to live, because it is the only party in the arrangement positioned to enforce anything.
Look at what open registries verify today. MCP’s official one is still in preview, and what it checks is namespace ownership: that you control the GitHub account or domain in the name you published under. That is worth having. It proves who published a thing, and says precisely nothing about whether the thing is safe to run.
The protocol authors left a socket. Almost nothing has been plugged into it.
The layer above the protocols is not more protocol. It is admission: identity that is bound rather than claimed, permission that is scoped and revocable, consequence that actually lands, and an accountable human at the end of every chain.
The web is learning to answer agents. Answering is the easy half. The hard half is deciding which ones get in.