An IT Director at a mid-size manufacturer recently found herself trying to explain, in a security review, why the company had eleven custom connectors feeding Copilot Studio agents and Power Automate flows, and why only three of them could be governed with any real precision. The other eight sat in a tenant-level policy bucket, classified by a URL pattern someone had written eighteen months earlier, long before anyone imagined an agent would be reading from that endpoint autonomously. Nobody had done anything wrong. The tooling simply hadn’t caught up to how fast custom connectors were multiplying once agentic AI entered the picture.
That gap between what Microsoft’s first-party and certified connectors can be governed with, and what a homegrown custom connector can be governed with, has existed for years. It matters more now because Copilot Studio agents lean heavily on custom connectors to reach line-of-business systems, and every one of those connectors is a new surface for a data loss prevention (DLP) policy to either control precisely or wave through by default. Microsoft’s overhaul of Power Platform connector certification, now routed through Partner Center, is worth a close look, not because it makes publishing easier (though it does), but because of what certification actually changes about how a connector can be governed afterward.
The governance gap custom connectors created
Power Platform’s DLP model treats connectors in three tiers: Business, Non-Business, and Blocked, with a rule that data can’t move between a Business-tier connector and a Non-Business one in the same flow or app. Certified and Microsoft first-party connectors slot cleanly into that model at the environment or tenant level. Custom connectors do too, technically, but the mechanics are cruder. At the environment level, an admin classifies each custom connector individually by name. At the tenant level, classification runs on URL pattern matching against the connector’s host address, using ordered allow and deny rules that end in a wildcard catch-all. It works, but it asks a governance team to maintain URL pattern lists by hand, and it treats a connector’s trustworthiness as a function of its address rather than anything Microsoft has actually reviewed.
Advanced Connector Policies (ACP), the newer and stricter allowlist model Microsoft has been rolling out for tenant-wide connector governance, makes the distinction sharper. ACP applies to certified connectors. Custom connectors and HTTP-based connectors, including the generic HTTP connector and HTTP Webhook triggers that many home-grown integrations depend on, are explicitly not supported in ACP as of this writing and still require classic DLP policies or connector endpoint filtering. In practice, that means a company standardizing on ACP for its governed estate is, by definition, leaving its custom connectors in a separate, less rigorous governance lane, no matter how business-critical those connectors have become.
What actually changed in Power Platform connector certification
Microsoft’s new certification pathway moves connector and Copilot plugin submissions into Partner Center, tied to enrollment in the Microsoft 365 and Copilot program. The prior process required manual review that partners reported taking two to five weeks, with limited visibility into where a submission stood or what specifically had failed if it was rejected. The Partner Center path automates the review, gives submitters real-time status and error detail, and covers four scenarios: new custom connectors built in Power Automate, version upgrades to already-certified connectors, custom connectors paired with an associated Copilot plugin, and version upgrades to that paired combination.
Once certified, a connector stops being a homegrown artifact and becomes a standard connector in Microsoft’s catalog. It shows up in the same list as first-party connectors in Power Automate, Power Apps, and Logic Apps, and if it has an associated plugin, that plugin becomes available for admins to enable through the Microsoft Admin Center for Copilot for Microsoft 365. For an enterprise that built an internal connector purely to reach an ERP or CRM system from a Copilot Studio agent, and never intended to publish it externally, this is the detail that matters most: certification is not only a go-to-market lever for ISVs, it is a path out of the custom connector governance lane described above.
What certification does, and does not, fix
It would be a mistake to read this as Microsoft closing the governance gap entirely, and a CIO evaluating whether to push a critical connector through certification should go in with accurate expectations. Certification moves a connector into the standard three-tier DLP classification that Business and Non-Business connectors already use, replacing the name-based or URL-pattern approach reserved for custom connectors. That is a genuine improvement in precision, and it makes a connector eligible for ACP’s stricter allowlist model instead of being permanently excluded from it.
What certification does not do is retroactively fix the connectors an organization decides not to certify, and it does not extend ACP support to HTTP or HTTP Webhook connectors, which remain governed under classic DLP regardless of certification status elsewhere in the estate. A company with a mixed environment, some certified connectors under ACP and a long tail of custom and HTTP connectors under classic DLP, is still running two governance models side by side. Certification narrows that split. It does not eliminate it.
There is also a real cost to weigh. Certification requires standing up a Partner Center account, completing verification materials, and enrolling in the Microsoft 365 and Copilot program, none of which is a five-minute administrative task. For a connector built and used entirely inside one business unit with no reuse potential, that overhead is unlikely to pay for itself. For a connector that a dozen teams route sensitive financial, HR, or customer data through, or one that sits underneath a production Copilot Studio agent making autonomous decisions, the calculus is different.
Deciding which connectors are worth the investment
The practical question for an IT Director or CIO is not whether to certify every custom connector in the tenant. It is which ones justify the enrollment overhead and the ongoing maintenance of keeping a certified version current as the underlying API changes. Three characteristics are worth screening for. First, does the connector back a Copilot Studio agent or automated flow that acts on data without a human reviewing every step, since that is precisely the scenario where blunt, address-based DLP classification is riskiest. Second, is the connector reused across more than one business unit or environment, since URL-pattern tenant policies were never designed to express nuance across multiple consuming teams with different data sensitivity needs. Third, does the connector touch data categories, financial reporting, payroll, customer records, that already sit under stricter internal data handling policy, where a coarser custom-connector classification is a harder position to defend in an audit.
Connectors that fail all three tests, a one-off integration built by a single team for an internal utility with no agent dependency, probably do not need to go through Partner Center at all. The classic DLP tools, applied deliberately rather than left on default settings, are adequate for that tier. Where the calculus shifts is in exactly the kind of estate the manufacturer’s IT Director was trying to defend: a small number of connectors that carry disproportionate risk because of what they connect to and what increasingly autonomous agents do with that access.
Where this fits in a broader governance plan
None of this replaces the fundamentals. A tenant that has not yet adopted DLP custom connector parity, the capability that lets custom connectors be classified individually rather than only by URL pattern, should do that first, since it is available today at no additional cost and requires no Partner Center enrollment. Certification is the next step up for the specific connectors where individual classification still is not precise enough, and where eligibility for ACP’s allowlist model is worth the administrative investment.
Routeget Technologies has walked several clients through exactly this kind of connector inventory exercise, mapping which integrations sit behind agentic workflows and which ones are candidates for certification versus tighter classic DLP rules. The pattern that keeps showing up is not that organizations have too many custom connectors. It is that almost none of them have ever been ranked by actual risk, which is what makes the certification decision harder than it should be. Microsoft has removed the excuse that certification takes too long. The remaining work, deciding which connectors actually warrant it, is squarely a governance decision, not a technical one, and it belongs on the same review calendar as any other access control question in an increasingly agent-driven Power Platform estate.
#PowerPlatformGovernance #CustomConnectors #DataLossPrevention #CopilotStudio #EnterpriseAI #ConnectorCertification
No comment yet, add your voice below!