Microsoft 365 Copilot is the easy part. The harder, faster-moving challenge is what comes next: agents. The moment your organization can build custom agents in Copilot Studio, wire up connectors in Power Platform, or stand up a third-party agent platform, the data-exposure surface stops being a single product and becomes a sprawling, self-service ecosystem.

Agents are where I see the most governance debt accumulate — and the most preventable risk.

Why agents are different

A chat assistant answers questions. An agent takes actions: it calls tools, queries connectors, reaches external systems, and can chain steps with a degree of autonomy. Two properties make that risky:

  • Connector sprawl. Each connector is a data pathway. A few well-meaning makers can quietly assemble a route from your sensitive SharePoint data to an external service.
  • Excessive agency. The more an agent is allowed to do, the larger the blast radius when it’s misconfigured — or successfully prompt-injected.

So agent governance isn’t a new discipline. It’s the same questions you’d ask of any privileged automation: who can build, who can connect, what can run, what can act, and how is evidence retained?

A governance model that travels

I treat Power Platform / Copilot Studio and third-party platforms like Onyx as two implementations of the same problem. The model:

1. Ownership. Every agent has a named business owner and technical owner. No orphan agents. Its environment, connectors, and data scope are documented.

2. Environment boundaries. Separate dev, test, and production. In Power Platform that means managed environments and environment groups; don’t let experimentation share scope with production connectors.

3. Connector governance. Classify connectors with Power Platform data loss prevention policies, and default new connectors to non-business until they’re reviewed. The single most effective control here is making the safe state the default.

4. Identity and least privilege. Entra ID roles, narrow permissions, sharing limits, and tenant isolation where cross-tenant connectors are a concern. An agent should hold the least access that lets it do its job — and no more.

5. Runtime protection. Use built-in Copilot Studio security controls — protections against several prompt-injection classes — and, where supported, external threat detection for tool invocations. Assume these are probabilistic and layer them.

6. Responsible-AI guardrails. User disclosure that they’re talking to an agent, a human-escalation route, and review gates before anything touches customers. A written AI acceptable-use policy underpins all of this — here’s a free template to start from.

7. Evidence and review. Logging, usage analytics, and a recurring review of agent health, access, and connector changes. Governance that isn’t reviewed decays.

Third-party platforms: apply the same lens

When a team brings in a non-Microsoft agent platform such as Onyx, I don’t try to manage the product live in a workshop — I run it through a governance checklist:

  • Connector access type — public, private, or permission-syncing? Prefer permission-syncing; be very wary of “public” against private sources.
  • Permission mapping — does access honour the source system’s permissions, or does it flatten them?
  • External LLM routing — do documents and queries leave to a third-party model, or stay local/self-hosted? That’s a data-egress decision, full stop.
  • SSO and RBAC — who can use it, and is access mapped to identity?

The platform changes; the questions don’t.

The connector is the control point

If I had to give one piece of advice: treat every connector and external action as a data-egress decision, reviewed by a human. Most agent incidents I’ve seen trace back to a connector that should never have been approved against a sensitive source. Make the default safe, require review to loosen it, and keep the evidence.

Tooling has caught up since I first wrote this: Microsoft Agent 365 and outside-the-tenant supervisors like Onyx Security now compete to be your “AI control plane” — I compare them surface by surface in Two “AI Control Planes”, Six Surfaces. The model above is what you use to judge them.

The urgency is rising, not falling: frontier models are now classified at capability levels that assume autonomous vulnerability discovery and machine-speed operation — which is the tempo your agent governance has to survive.

Agent governance is the fifth phase of the secure Copilot launch — and the one that most determines whether your AI program stays safe as it scales. If you’re standing up agents and want a governance model that won’t buckle under self-service demand, let’s talk.