Four platforms, four identity systems. Who writes the shared record?

The scene this week

In the span of 48 hours in late April 2026, four of the largest enterprise AI providers announced the same thing from different angles.

Each launched a governance plane for agents running inside its own cloud. Each introduced some form of per-agent cryptographic identity. Each promised the ability to trace what an agent did, when, and with what scope. Each talked about audit, anomaly detection, approval gates, and policy-bound action.

The phrasing varied. The structure did not.

One vendor called theirs "Agent Identity," paired with an "Agent Gateway" and an "Agent Anomaly Detection" module. Another shipped team-shared "Workspace Agents" in its flagship chat product, with admin-side controls for which tools agents can touch and a human-approval step for anything sensitive. Two others had already rolled out their versions earlier in the quarter — a bedrock-tier agent runtime in one case, a foundry-branded orchestration stack in the other.

For anyone building on one of these stacks, the value is real. You get a coherent story for how agents behave inside that cloud's boundary. You get logs a compliance team can point at. You get an identity primitive that didn't exist eighteen months ago.

For anyone building across these stacks — or whose agent will ever need to interact with an agent that lives in a different one — a new problem has just been inherited. Four identity systems that don't speak to each other. Four log formats that aren't cross-verifiable. Four audit trails, each asserted as authoritative for agents inside its own walls.

The structural shape of this

The shape is familiar. It is the same shape email had before SMTP, that payments had before interbank settlement standards, that the web had before shared certificate authorities. Every platform becomes internally coherent and externally opaque. Internal coherence is a real achievement. External opacity is what the next layer has to solve.

At this stage, every major vendor's pitch is some variant of: "We can tell you what your agents did, inside our system." That is true and useful.

What none of them can say — structurally, not because of product gaps — is: "We can tell you what your agent and the other agent agreed to, when the other agent was in a system we don't run."

No vendor can credibly say that, because doing so would require speaking for something outside its own operational boundary. It would mean making claims about another company's infrastructure. Their lawyers would not allow it, and they would be right not to.

Internal identity is not external agreement

It is worth being careful about what an "Agent Identity" actually establishes.

A cryptographic identity issued by a platform establishes a few things: that this agent was provisioned inside this platform; that its actions, as observed by this platform's logging layer, were recorded; and that its scope was configured at a particular time by a particular admin.

These are real facts. They matter for compliance, for internal forensics, for the question did someone on my team configure this agent badly?

They do not establish any of the following: that the agent's counterparty, running on a different platform, agreed to the same terms; that two agents from two different platforms shared a common boundary before executing; or that a human dispute between two organizations has a neutral record to refer to.

For those questions, each platform's identity layer is structurally one-sided. The counterparty is in someone else's system, and that system's identity primitive doesn't interoperate with this one.

The weekly announcements are making internal identity sharper. They are not — and cannot — make agreement across identities verifiable.

The gap widens as internal governance tightens

A counterintuitive thing is happening. As each major provider invests harder in internal governance, the external gap becomes more visible, not less.

A year ago, the question who is responsible for what this agent did? was muddy everywhere. Internal logs were thin. Agent identity was implicit. Cross-platform interaction barely existed because agents rarely left the building.

Now internal logs are getting thick. Agent identity is explicit. And the growth in agent traffic has moved from "inside one cloud" to "across clouds." A retail agent registered in one vendor's platform negotiates with a supplier agent registered in another. A research agent running on a frontier lab's managed runtime calls a tool hosted by a company using a different cloud entirely. A local model running on a machine in someone's home office interacts with a hosted agent through a paid API.

In each of these cases, each side has an increasingly detailed internal record. Each side can produce a compliance-grade account of what happened in its own system. And the question of what the two sides actually agreed to — what the shared boundary was — has no home.

The internal-governance investments make this gap more noticeable, because the quality of the internal records makes it obvious when those records disagree.

A small concrete example

Consider two agents. Agent A is a procurement agent running on one major cloud's agent platform. It has been issued an Agent Identity by that platform, has a scope that lets it execute purchases up to a certain value, and its every action is logged to that platform's audit trail. Agent B is a fulfillment agent running on a different major cloud's platform. Same story, different vendor.

They agree on a bulk order. Settlement happens over a micropayment rail. Delivery happens. Something about the delivery doesn't match what A's operator expected.

A's operator pulls up A's log. It shows a clear agreement at $18.50 per unit, cryptographically signed by A's platform, Agent Identity attached. Everything checks out on A's side. B's operator pulls up B's log. It shows a clear agreement at $22 per unit, signed by B's platform, Agent Identity attached. Everything checks out on B's side.

Both logs are internally consistent. Both are high-quality. Both are authoritative inside their respective platforms. Neither is a neutral record of what the two agents agreed to before executing.

The fact that both platforms have better internal governance than they did a year ago does not make this dispute easier to resolve. In some ways it makes it harder, because both parties can now point to more polished evidence of their own version.

What "external" means, precisely

At this point the word "external" carries more weight than it used to. It has a specific structural meaning: not operated by either counterparty; not operated by either counterparty's platform; not accepting privileged access from any single vendor; recording the existence and scope of a decision, not its content; and resolving records from both sides to the same reference.

"External" does not mean "stored somewhere else." Logs can be stored in a second cloud and still be under the control of whoever wrote them. "External" means operationally independent of both sides of a decision.

For the procurement-fulfillment example, an external record looks like this: at the moment Agent A and Agent B declared a shared boundary — whatever the scope was, whether quantity, maximum price, delivery window, or counterparty identity — that declaration was fixed outside both platforms. Neither side could unilaterally change it afterward. Both sides reference the same record ID. Both produce their local evidence alongside that ID in a dispute.

The external record does not say who was right. It says: at this time, under this scope, with this counterparty, a shared boundary was declared and both sides acknowledged it.

That is the missing artifact. Internal governance doesn't produce it. It can't. Its job is to be internal.

What this is not

It is worth heading off a misreading.

External anchoring is not a competing identity system. It does not replace Agent Identity on any platform. It does not try to unify them. It does not attempt to be the canonical identity for any agent on any runtime.

It also does not judge. An external anchor does not say "this agent behaved well" or "this agent was trustworthy." It records that a decision boundary was declared and fixed at a specific time, and nothing beyond that.

It does not see decision content. It does not see prompts, tool outputs, inference traces, model weights, or any of the things a platform's internal governance legitimately needs to see to do its job. It records that one agent declared a boundary at a given time under a given scope, and that another agent acknowledged it.

The relationship between internal governance and external anchoring is complementary, not competitive. Internal governance makes the agent behave well within its own boundary. External anchoring makes cross-boundary agreements checkable. Each needs the other to produce a full picture.

Why now, specifically

There is a narrow window where this gap is worth attention.

The platforms that announced their identity layers this week are not going to pause and wait for a cross-platform standard to emerge. They will keep hardening their internal offerings. That is rational for them and good for their customers.

The agent traffic crossing between these platforms is growing faster than standards bodies can respond. By the time a cross-platform identity interop layer exists — assuming one does — the volume of cross-platform disputes will already be material.

The question for anyone running agents across more than one of these platforms is not which vendor's identity system should I pick? — it is what external reference point exists for agreements an agent makes outside its home platform?

If the answer is "the counterparty's platform logs plus our own logs," that is the self-testimony problem wearing a nicer outfit. Both sides will have beautiful logs. Neither will have a neutral one.

How an external anchor fits

The shape of the fit doesn't require changing which platform an agent runs on. An external anchor sits alongside whatever identity system the platform provides.

Before executing an agreement with a counterparty, the agent declares the scope of the agreement to an external environment: what the decision is, what accountability boundary applies, optionally that this is a bilateral declaration with another named agent. The environment records the timestamp, the scope, and an integrity reference, and returns an ID.

If the counterparty is also using the same external environment, a bilateral acknowledgment can be recorded. If not, the record is unilateral but still external — both sides can still reference the ID if a dispute arises.

After execution, the agent confirms. The record is then fixed and append-only. Neither side can change it. Neither side's platform can change it. The platform's Agent Identity still accounts for the agent's internal behavior; the external anchor accounts for the agreement's existence and scope at a specific moment.

The short version

The big vendors are converging on strong internal identity for agents inside their clouds. That is good and will keep improving. The gap it creates — cross-platform agreement without a neutral record — is the shape of the next problem, and it is already here for anyone running agents across more than one platform.

The question worth asking, for anyone building agents that will talk to agents outside their home platform: when two of these agents disagree about what was agreed, where does the shared record live?

If the answer is "in my platform's logs and theirs, both controlled by the party that wrote them," that is the self-testimony problem at an institutional scale. Four platforms with excellent internal records is not the same as one shared record across platforms.