The last session of day one at Nordic Summit 2026 was Tatu Seppälä and Claire Edgson on “MCP vs. A2A: Bridging the security and governance gap for agentic AI in Power Platform”. Tatu is a security architect at Context& in Finland who, as he put it, creeps into Power Platform. Claire leads the Microsoft platform practice at Capgemini globally and says she is brutally honest to Microsoft even when they are in the room. This is my recap. The findings are theirs, the summary and any mistakes are mine.
Two protocols, two jobs
MCP, Model Context Protocol, came from Anthropic and is now adopted by Microsoft and, after some backtracking, Google. It is the USB-C for AI: a standard way for an agent to reach a data source and, more dangerously, act on it. A2A came from Google and is about passing a job along: I have done the invoicing, now your agent does the credit note. A year ago everyone thought MCP was all there was. A2A matters far more now.
Your DLP policy already allows MCP servers you never approved
Go back to your Power Platform data policy and look at the connector list. Many connectors you allowed months ago are now called Jira MCP, SAP MCP and so on. It is not a rename: the connector now ships with an MCP server, sometimes eight or nine, and if you allowed Jira without going down to action level, you have allowed the Jira MCP servers too. Claire called it the biggest connector security flaw of the year.
A second gap follows from how MCP servers are managed. For an ordinary connector you can control individual actions. For most MCP servers you only get on or off; the Dataverse connector exposes its MCP actions, the Microsoft ones are getting there, the third-party ones are not.
Anyone can wire up anything, with just a URL
Then the part that carries the whole session. You are not limited to the pre-packaged MCP servers. Anyone can set up an MCP server anywhere, and a maker can add a custom one to an agent with nothing but a URL.
Claire regularly finds makers who downloaded MCP servers from Reddit, and clients with thousands of internal MCP servers nobody remembers creating. Every one is a black box: you put something in, you get something out, and you have no idea what happens in between. There is an industry effort, started by SAP and joined by Google, Oracle and Salesforce, to certify MCP servers with retesting every 28 days. Microsoft is on the fence. Claire guarantees it will happen.
Do not leave custom connectors on Ignore
This is the one thing in the session you can act on tomorrow. Every custom MCP connection a maker creates also creates a custom connector in the Power Platform environment. The same is true of every A2A connection. That is the only place the wild west can be tackled, and it is where the default is wrong.
When you build a data policy, the screen after the connector groups is custom connectors, and most tenants have left it on Ignore. Tatu’s line: Ignore sounds like block, but it means everything is allowed by default. It is not secure by default; it is all doors open by default for MCP and A2A. The advanced connector policies that are replacing data policies do not have a custom connector control at all yet, so for now you need both. Blocking custom connectors does not make the ones people ask for good, but it means nobody wires up a random server without coming to an admin first.
And because the maker can name the connection anything, the way to see what it really points at is the solution: open the custom connector, read the OpenAPI definition, and the real host is right there.
What comes back is the part people forget
Everyone worries about where their data goes. Their examples were about what comes back. MCP-in-the-middle servers that still deliver you to the service you expected while copying everything in and out; Claire said they had caught five or six in two weeks. Poisoned payloads that spin an agent into token-burning loops or quietly change values: she said Mercedes has been targeted several times this year by MCP servers trying to change the price of a car. A propeller manufacturer whose steel-price MCP had been tampered with so that the answer was always one supplier, which nobody noticed until the steel took forever and was rubbish. A newspaper whose paper-price feed carried an extra payload once a week that sat in Dataverse and was picked up by Graph.
The internal version of the same problem is laziness: service principals and credentials hard-coded into internal MCP servers that were set up quickly and never hardened. Tatu added that the MCP SDK itself had a serious vulnerability this year that spawned a list of critical issues, some patched and some still in progress. Their hardening list, quoted from the researchers at Ox Security who found the flaw, was:
- Block public IP access to sensitive services
- Treat external MCP configuration input as untrusted
- Only use official MCP directories
- Run your internal MCP-enabled services inside a sandbox
- Monitor tool invocations
Plus their own: due diligence on any external MCP, monitoring that the output is still valid, and never reusing the service accounts your MCP servers run under. Any external MCP belongs in the golden set from Claire’s morning session and gets tested regularly.
Two more gaps before A2A. Sensitivity labels do not travel to external MCP servers at all; they are not in the schema. Inside Microsoft they are honoured between SharePoint and Dataverse MCPs, ServiceNow tries if your labels match, nobody else even tries. And an MCP server can run under the author’s permissions rather than the user’s. Claire’s example was a governance MCP built by an admin with delete-environment tools enabled, shared with users, and a client with over 10,000 environments where the agent got through 7,000 of them, backups included, before anyone stopped it.
A2A: the same connector, the same gap
A2A got less time but the same conclusion. An A2A connection also creates a custom connector; the endpoint is again just a URL, and again a black box. Claire cannot get over how many companies send payroll to an external agent over A2A, or how many dodgy payroll agents carry names very close to real companies. Why use A2A at all? Because the agent you want lives elsewhere, and because it is cheaper: a Google or Salesforce agent already paid for per user costs less than burning your own tokens. Cost will drive A2A for the next two years.
Microsoft’s position is hands off, and the slide they showed was the note from Microsoft Learn’s article Connect an agent available over the Agent2Agent (A2A) protocol:
You’re responsible to carefully review and test connected agents in the context of your specific use cases, and make all appropriate decisions and customizations. When you connect to agents outside of Copilot Studio, you’re responsible for the use of such agents. Considerations include ensuring: data flows, data handling, and data sharing between agents are appropriate for your use case and meet relevant requirements and laws; agents meet appropriate quality, reliability, security, and trustworthiness standards; appropriate permissions, boundaries, and approvals are provisioned, if prudent for your use case; proper observability, identity and traceability, and human oversight functions are in place.
Two practical warnings closed it. The connected agents environment setting does nothing for external A2A; it only governs Microsoft-to-Microsoft. And when a maker disables a dangerous A2A or MCP, it can take up to 48 hours to stop being used, even after the custom connector is deleted, so the only real emergency control is stopping the agent for at least an hour. Every agent needs a documented way to stop.
The premise was MCP versus A2A. The answer was both, in tandem, MCP to surface data and A2A when someone else’s agent does the job cheaper, with an A2A version 2 due before the end of the year and Microsoft now on the committee. And one instruction to take home: disable custom connectors by default and allow only the ones you need.