Something quiet but significant happened in enterprise software over the last year. The major platform vendors - Microsoft, AWS, Google, Salesforce, SAP, ServiceNow - all agreed on a common way for AI agents to talk to each other. The competing proposals folded into one. For practical purposes, the standard is settled.
On the surface, this is good news. It means an agent your finance team builds can hand work to an agent your procurement team built, which can in turn reach an agent run by one of your suppliers. No custom integration for each pair. They discover each other, exchange tasks, and get on with it.
If you run security or technology for your organization, that last paragraph should make you slightly uneasy. Not because the technology is bad - because it answers a question you weren’t worried about while leaving a bigger one wide open.
Interoperability solves “can they talk.” It doesn’t solve “should they.”
The new standard is very good at letting agents connect. It says almost nothing about governance. When agents from different teams, different vendors, and different clouds can all reach each other freely, someone has to be able to answer three questions at any moment:
- Who is allowed to call whom?
- What data is each agent allowed to touch when it does?
- Who recorded that it happened?
These aren’t questions the protocol answers. They’re questions you answer - or don’t. And the moment your agents can reach beyond your own four walls, “or don’t” becomes an audit finding waiting to happen.
A concrete version of the problem
Here’s the scenario that makes this real, stripped of the technical detail.
An agent shows up and introduces itself to your systems as the agent belonging to one of your trusted suppliers. It comes with credentials - paperwork, effectively - that say “I am who I claim to be.” Your agents are configured to trust that supplier. So this new agent gets to participate: it can be handed tasks, it can ask for data, it can act.
The question that decides whether you have a security program or a liability is simple: does your system actually verify that the paperwork was issued by the supplier - or does it just take the agent’s word for it?
Because a forged introduction is easy. An attacker can present an agent that claims to be your supplier and supplies its own credentials to back the claim. A naive system checks that the paperwork is internally consistent, sees that it is, and waves the agent through. The impersonator is now inside your workflow, trusted, acting on real data.
A system built for governance does the opposite. It treats every external agent as unproven until its identity is verified against the party it claims to represent - not against credentials the agent handed over about itself. The real supplier’s agent gets in. The impersonator is stopped at the door, and the rejection is written to a log you can show an auditor.
That distinction - verifying identity against the claimed source, not against the claimant’s own say-so - is the entire difference between an open agent network and an open door. It is unglamorous, it is invisible when it works, and it is the thing most teams haven’t built yet.
”Can’t we just use our cloud provider’s agent platform?”
You can. Several of them now offer agent management with governance attached, and for an organization that lives entirely inside one cloud and one AI model, that may be enough.
Most organizations don’t live like that. Your agents will run across more than one cloud. They’ll be built on more than one AI model - because the best model for one task is rarely the best for the next, and because betting your entire agent strategy on a single AI vendor is the kind of dependency you spend the rest of your career regretting. And increasingly, your agents will need to interact with agents outside your organization entirely.
A governance layer that only works inside one vendor’s walls can’t see any of that. It governs the agents that vendor hosts, on that vendor’s model, and goes blind the moment an agent steps outside. That isn’t governance - it’s a fence around one field while the herd wanders across three.
The governance layer that actually protects you has to be neutral: independent of which cloud the agent runs in, independent of which AI model it’s built on, and able to apply the same identity checks, access rules, and audit trail to every agent regardless of where it came from. Neutrality isn’t a feature here. It’s the precondition for the whole thing being worth anything.
This is not your fire today. It will be soon.
Be honest with yourself about timing. If your organization has three agents and they all run in one place, you do not have this problem yet. Anyone telling you your house is on fire is selling something.
But the direction is not in doubt. The standard is settled, every major vendor is shipping support for it, and the number of agents inside a typical enterprise is going one way. The teams that think about identity, access, and audit before the sprawl will spend an afternoon on it. The teams that wait will spend a quarter untangling it, probably after something goes wrong.
Governance is dramatically cheaper to install before you have forty agents than after. That’s the whole argument. Not fear - sequence.
What to ask
You don’t need to understand the protocol to ask the right questions of whoever owns your agent strategy:
- When an external agent introduces itself to our systems, how do we verify it is what it claims to be - and are we verifying against the source, or trusting its own credentials?
- If we needed to show an auditor every agent that has touched a given dataset, could we?
- Does our agent governance work across our clouds and our AI models - or only inside one vendor?
- Can we answer all of the above today, or only in a slide deck?
If the answers are solid, you’re ahead of most. If they’re not, the good news is that this is a far smaller job now than it will be in a year.
The agents are going to start talking to each other regardless. The only choice you have is whether someone’s checking IDs at the door.
Need a neutral governance layer for agents across clouds, models, and suppliers? Tell us about your setup using the form below - we’ll walk through identity, access, and audit on your own architecture.