Microsoft 365 Copilot

Microsoft 365 Copilot can use your organization's Airlock MCP endpoint like any other AI client: every tool call goes through your policies, approvals and audit trail, and each person signs in as themselves. There are three ways in, from quickest to most involved:

Fastest: add Airlock to an agent with the Reference ID

Copilot cannot take an MCP server's client ID, secret and endpoints directly. It asks instead for a Reference ID, the ID of an OAuth client registration stored on Microsoft's side. Airlock keeps one such registration, open to every Microsoft 365 organization, so you can use Airlock's ID and skip the registration step entirely.

Wherever your agent asks for an MCP server, enter these three values:

Copy the Reference ID whole, including the trailing =. The server URL is the bare endpoint on purpose: Airlock works out which organization you belong to from the account you sign in with, so the same three values serve every Airlock organization.

Where to enter them:

• Agent builder inside Copilot. Open Copilot, select Agents, then Create agent. On the Configure tab, add an action and choose the MCP server option; the form asks for the three values above. Save, then chat with the agent.
• Microsoft 365 Agents Toolkit. When the toolkit prompts for OAuth details for an MCP plugin, choose the existing registration and paste the Reference ID; it writes it into the plugin manifest as "auth": { "type": "OAuthPluginVault", "reference_id": "..." } with the server URL above.
• Copilot Studio. Its MCP wizard has no Reference ID field and signs in through a callback of its own rather than Microsoft's Copilot callback, so Airlock's registration does not apply there. Two things are needed instead: choose OAuth 2.0 with Dynamic discovery, which registers a client with Airlock on the spot, and have an Airlock admin approve the callback URL the wizard shows under Settings → Security → Allowed AI clients, or the sign-in is refused as an untrusted redirect. Copilot Studio is a separate product with its own settings, and this route has not been walked through end to end.

Then sign in once:

1. Open the agent you just saved and send it a prompt that needs Airlock, for example "What services can you reach through Airlock?".
2. Copilot shows a consent card. Select Sign in.
3. A pop-up opens on Airlock's sign-in page. Sign in with your Airlock account and approve the connection. The pop-up shows Microsoft's confirmation and closes on its own.

Copilot repeats your prompt with Airlock connected and stores the sign-in for your account, so later prompts do not ask again. If the pop-up is blocked or never closes, see Troubleshooting.

The ready-made package

If nobody in your organization builds agents, the package gives everyone an Airlock agent without building one. It takes three people and about fifteen minutes: an Airlock admin downloads the package, a Microsoft 365 admin uploads and approves it, and each user signs in once from Copilot. The steps below walk through each part in order.

Before you start

• Copilot licenses. The people who will use the agent need a Microsoft 365 Copilot license. Without one, Copilot lists the agent but every prompt to it fails with a generic "Sorry, I wasn't able to respond".
• Custom apps must be allowed in your tenant. In the Teams admin center, under Teams apps → Manage apps → Actions → Org-wide app settings, the Custom apps section must allow uploading custom apps. Many tenants leave this off. Copilot agents are Microsoft 365 apps, so this setting governs them even though nothing about Airlock involves Teams itself.
• An Airlock admin account. The package download sits on the organization settings page, which only admins see.
• Pop-ups allowed for Microsoft's sites. Copilot signs you in to Airlock in a pop-up window. A browser that blocks pop-ups for m365.cloud.microsoft or teams.microsoft.com blocks the sign-in.

Step 1: Download the package (Airlock admin)

1. Open Settings → Organization in the Control Room.
2. Find the Microsoft 365 Copilot card and select Download package.

You get a small zip named after your organization. It contains the app manifest, the declarative agent and the MCP plugin definition that points Copilot at your organization's endpoint. The agent it installs is named after your organization too, "Airlock: Acme" for an organization called Acme, so people who belong to more than one Airlock organization can tell the agents apart. It carries a reference to Airlock's own sign-in registration with Microsoft, so nobody has to enter OAuth settings anywhere. It holds no secrets and no personal data, so it is safe to pass on by mail or chat.

The package carries your organization's name and a stable app id of its own, but the connection follows the account that signs in: each person reaches the Airlock organization their own account belongs to. So share the package with the people who should use it, and treat a package from another organization as the wrong file rather than as a locked one.

Step 2: Upload the package to the organization (Microsoft 365 admin)

The goal of this step is the organization's app catalogue, not your own account. Teams offers both, next to each other, and only one of them reaches everybody. A personal upload succeeds quietly, installs the agent for you alone, and never appears in the Teams admin center, which is the single most common way this goes wrong.

Two routes lead to the catalogue. The developer portal route is the one to prefer: it states plainly what it is doing and leaves a request an admin can see.

From the developer portal.

1. Open dev.teams.microsoft.com and sign in with a Microsoft 365 account from your tenant.
2. Select Apps, then Import app, and pick the zip.
3. Open the imported app, and in the left menu under Publish select Publish to org.
4. Select Get started. The status becomes Submitted (awaiting admin's approval).

From Teams. Select Apps in the left rail, then Manage your apps, then Upload an app, and choose Upload an app to your organization's app catalogue. Do not choose Upload a custom app: that is the personal install described above.

The Microsoft 365 admin center has a similar-looking upload under Integrated apps → Upload custom apps. Avoid it: in some tenants it rejects the package with "Upload failed. Please check the manifest file and try again" even though the package is valid. If somebody has already hit that message, one of the two routes above is the answer.

Whichever route you use, the app ends up in the same place: the Teams admin center, waiting for an admin to approve it. That is step 3.

Step 3: Approve the app and choose who gets it (Microsoft 365 admin)

This is where every catalogue upload arrives, whichever route step 2 used.

1. In the Teams admin center, open Teams apps → Manage apps. A submitted app shows on the Pending approval tile and appears in the list with the status Blocked.
2. Search for Airlock, open it, and select Publish. Confirm in the dialog.
3. The status becomes Unblocked and Available to shows your organization's default, usually everyone. To narrow it, open Users and groups and assign the app to the people or groups who should have it.

Available is not the same as installed, and the same page says so: Installed for still reads No one. Publishing puts Airlock in your organization's store, where the people it is available to can add it themselves in step 4. It does not put it in anybody's agent list.

If you would rather it simply be there for everyone, select Installed for on that page and assign the app to your users or groups. Copilot then shows it without anyone adding anything, and step 4 starts at the first prompt.

Either way, changes take a few minutes to reach Copilot.

Step 4: Sign in from Copilot (each user)

1. Open Microsoft 365 Copilot and select Agents in the left rail. Unless your admin pre-installed it, Airlock is not in your list yet: select Get agents, look under Built for your org, find Airlock: your organization's name and add it. It stays in your list afterwards.
2. Send any prompt that needs Airlock, for example "What services can you reach through Airlock?".
3. Copilot shows a consent card the first time. Select Sign in.
4. A pop-up opens on Airlock's sign-in page. Sign in with your Airlock account, using the same method you use for the Control Room.
5. Approve the connection. The pop-up shows Microsoft's confirmation and closes on its own.

Copilot repeats your prompt with Airlock connected. The sign-in is stored by Microsoft for your account, so you do not sign in again on later prompts or on other devices.

To disconnect, open Chat settings → Agents in Copilot and sign out of Airlock. Signing out clears the stored sign-in. An Airlock admin can stop new sign-ins for the whole organization (see below), but that does not end connections that already exist: those last until the person signs out or their stored sign-in expires.

Using Airlock from Copilot

Copilot discovers your integrations on demand. Ask it what services are available, and it lists the ones your account may use; ask for something specific, and it searches the tools behind those services and runs the right one.

Tool calls that your policies mark Require approval do not run straight away. Copilot tells you the request is waiting and gives you the approval link. Open it and approve in the Control Room: approving runs the call, once, at that moment. Copilot does not notice on its own, so ask it to check on the request and it fetches the result. Do not ask it to run the action again; that queues a second request.

Calls that your policies deny are refused with the reason, and everything Copilot does on your behalf appears in the audit trail under your name.

Controlling who can connect

Microsoft 365 Copilot appears under Settings → Security → Allowed AI clients with the same on/off switch and group scope as every other client. Turning it off stops new Copilot sign-ins for the whole organization; a group scope limits them to members of the selected groups. Both are checked at sign-in only: people already connected keep their access until their stored sign-in expires or they sign out of the agent in Copilot. See Controlling which AI clients may connect. This is independent of the assignment in the Teams admin center: Microsoft's side decides who sees the agent, Airlock's side decides who may sign in.

Troubleshooting

Register your own OAuth client instead

Some tenants only allow OAuth registrations their own admins created, and refuse a third party's. If that is your policy, the Reference ID above will not be accepted, and you create a registration of your own on Microsoft's side. One thing changes with it: your registration and your agent both use your organization's own URL, https://mcp.air-lock.ai/org/<your-slug>, so that the registration's Base URL matches what the agent calls. The sign-in itself is the same.

Where registrations live

You create the registration in Microsoft's developer portal at dev.teams.microsoft.com, under Tools → OAuth client registration. The address says "teams" because that portal grew out of the Teams developer tools, but it serves every Microsoft 365 app and every Copilot agent. Microsoft generates the registration ID when you save the form; that ID is your Reference ID.

Create the registration

Microsoft's form requires a client secret, even with PKCE enabled, so first create a client of your own against Airlock's registration endpoint. Use exactly this redirect URI, or the registration is refused at sign-in:

curl -X POST https://mcp.air-lock.ai/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"Microsoft 365 Copilot","redirect_uris":["https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect"],"token_endpoint_auth_method":"client_secret_post"}'

The response carries a client_id and, exactly once, a client_secret. Airlock keeps only a hash of the secret, so copy it now; if you lose it, register again. Registrations that stay in use never expire; one that goes unused for 90 days is removed, and client_secret_expires_at in the response names that deadline.

Then sign in to the developer portal with a Microsoft 365 account from your tenant, open Tools → OAuth client registration, and choose New OAuth client registration (or Register client if the list is empty). Fill in the fields as follows. Replace <your-slug> with your organization's slug from Settings → Organization.

Save the registration. The portal shows an OAuth client registration ID, a long opaque string (Base64-encoded, so it can end in =). Copy it whole, exactly as shown: that is your Reference ID.

Two settings on this form fail silently if you get them wrong:

• Restrict usage by app must be "Any Teams app". Binding the registration to a specific app ID saves fine, and then every tool call from Copilot returns a 404, because Copilot does not resolve that app ID when it calls an MCP server.
• Leave offline_access out of the scope. Microsoft's own examples add it for Entra-protected APIs. Airlock is not an Entra provider and issues refresh tokens on its own, so the extra scope only produces a consent error.

If your browser offers to fill the Client ID or Client secret field from a saved login, decline it and paste the values yourself. A saved password in the secret field saves without complaint and fails at every sign-in with invalid_client.

Add Airlock to your agent

Wherever your agent asks for the MCP server, enter:

The consent screen names the app "Microsoft 365 Copilot" and shows teams.microsoft.com as the return address, which is Microsoft's fixed callback for every Copilot plugin.

The client you registered is bound to Microsoft's callback URL and to your organization's registration, so publishing its id is harmless; the secret is what Microsoft's token store presents back to Airlock at every sign-in, and Airlock checks it. The ready-made package uses a different client, one built into Airlock, whose secret Airlock holds; nothing about it appears in the package.

Copilot Studio's MCP wizard is a different product with its own settings and is not covered here.