Give your AI connectors an offboarding test

Give staff useful AI access, then prove you can remove it. For your first connector pilot, make both outcomes acceptance criteria—not just a successful login.

On June 18, 2026, the Model Context Protocol project announced that Enterprise-Managed Authorization (EMA) was stable. Compatible implementations let organizations centrally determine which MCP servers employees may access, replacing repeated per-server consent. That addresses onboarding work and fragmented access administration. Our recommendation: accept the connector only after testing what happens when an employee’s responsibilities change. MCP announcement

Make the promise an acceptance requirement

EMA makes the organization’s identity provider the authority for MCP server access. The client obtains an identity assertion grant and exchanges it for an access token from the server’s authorization server. Policies can reflect groups, roles and conditional access rules. EMA documentation

The strongest counterpoint is that EMA’s documentation already promises immediate centralized revocation across MCP clients, without separate revocation at each server. Take that promise seriously. The overview does not, however, demonstrate it through a timed test of existing sessions and issued tokens in your integration. Make it an acceptance requirement. EMA documentation

Microsoft’s general Entra guidance explains why credential paths deserve separate attention: it distinguishes access tokens, refresh tokens and application-owned sessions, and states that Entra cannot directly revoke an application-issued session token. This does not establish that EMA fails its promise. It supports inspecting implementation behavior rather than assuming it. Entra revocation guidance

Establish the boundaries

The June announcement identified Okta as the first supported identity provider. EMA’s documentation says client support varies and extensions are opt-in. Confirm compatibility across your identity provider, AI client, MCP server and downstream application; an MCP label alone is not evidence of EMA support. MCP announcement · EMA documentation

Keep connection permission separate from business authority. EMA’s guidance requires authorization servers to map claims to permissions. Microsoft’s MCP Server for Enterprise overview, updated June 26, 2026, describes a public-preview, read-only directory interface that enforces user privileges and granted scopes. That overview does not establish EMA support for the server. EMA documentation · Microsoft MCP overview

For our proposed pilot, choose 1 read-only workflow, such as an internal directory report. Define who may read which records, through which connector, and who approves permission changes. Keep spending, order changes and customer commitments outside scope. This is a proposed design, not a reported deployment.

Test the access lifecycle

Use this proposed acceptance workflow to examine role-based policies and the credential paths described above. It is not a vendor-provided procedure or a completed FAIS result. EMA documentation · Entra revocation guidance

1. Prepare. Use controlled test identities and records. Document credential lifetimes, checkpoints and a remediation owner. Have the workflow owner and access administrator approve expected permissions and an access-removal deadline. Record that business threshold separately from EMA’s immediate-revocation promise.
2. Onboard. Assign the permitted role. Verify that approved reads succeed and out-of-scope reads fail. Record manual connections, consent prompts and administrator interventions.
3. Change roles. Remove access to 1 resource while preserving another. Timestamp the change. Verify that revoked access stops and retained access still works.
4. Offboard. Remove the test identity’s access through the agreed procedure. Attempt new protected reads through a fresh login, an already-open client session and a controlled harness using credentials issued before removal. Test renewal where supported. Never put token values in reports.
5. Repeat and decide. Check immediately after removal, at agreed checkpoints and around credential expiry or renewal. Record the last successful protected read and first observed denial for each path; these observations bracket the change rather than establish its exact time. Fail acceptance if access succeeds after the deadline. The remediation owner investigates and arranges a rerun. The workflow owner and access administrator approve or withhold expansion after reviewing the evidence.

Require evidence of a new request to the protected resource: neither a cached answer nor an empty chat window proves revocation behavior. Assess retained conversations and previously retrieved information separately.

Decide from the evidence

We would build the assessment around your employee-role-to-resource map and a bounded test harness. The trade-off is time spent checking compatibility and access removal before expanding, rather than treating a successful login as sufficient evidence.

Compare administrator time, employee setup steps and exception handling with the existing process. These are proposed measurements, not promised savings. Inspect authorization decisions alongside resource-request records. For the Microsoft integration, its overview instructs administrators to enable Graph activity logs and identifies request timestamps, users and response codes as available evidence. Microsoft MCP overview

Your acceptance artifact should be a signed test record: who could read what, when access changed, and whether every tested path stopped by the agreed deadline.