Revoke a Rep's Clay MCP Access (No Per-User OAuth Button)

A rep hands in their notice on a Friday. Their laptop gets collected, their SSO gets cut, and then you open Clay to shut off the MCP connection their AI assistant has been using all quarter.

There's no button for that.

Clay's own docs say so. A Clay admin has two documented ways to cut off one rep's MCP access, and neither one is a revoke:

-> Remove the user from the workspace entirely (Settings → Team). -> Set their credit limit to 0, which hard-blocks any further actions without removing them.

From Clay's MCP troubleshooting page, verbatim: "admins can't revoke an OAuth connection from the MCP page itself." The security page is blunter: "Individual MCP connections cannot be revoked from the admin UI." Scalekit flagged this first in a technical guide on August 18, 2026, after mapping Clay's MCP surface (16 admin-provisioned tools). Clay's docs confirm it as expected behaviour.

I connect Clay to Claude for clients regularly (I wrote up the install and its impersonation error here), so this gap is not abstract for me. Offboarding is the moment access control actually gets tested, and account-level levers fail that test in a specific way worth understanding before you're in it.

How the grant gets created in the first place

Clay's MCP server has been live in Claude since January 2026, ChatGPT since April, and Codex since June. The connection happens from the rep's side, not the admin's. For Claude Code, the working config from my install post, dropped into one project's .mcp.json:

{
  "mcpServers": {
    "clay": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.clay.com/v3/mcp"]
    }
  }
}

First run opens a browser to https://app.clay.com/oauth/authorize, the rep approves it, and from then on their AI client holds a token that acts as them inside Clay. The admin decides which Functions are exposed and which client platforms are allowed. The rep's individual grant lives with the rep.

That split is the whole mechanism behind the gap. Provisioning is admin-scoped. The grant is user-scoped. Clay's admin surface exposes controls for the first and not the second.

Why both levers overshoot

Removing the user cuts the AI's access by cutting the person's access. For a departure, that's where you end up anyway. It's the wrong tool for every other case: a role change, a permission experiment, a contractor between projects, or a rep you just want to move off MCP while they keep working in the Clay UI. You wanted to unplug one connection. You unplugged the human.

Zeroing the credit limit works because Clay operations spend credits. Clay's docs describe it as a hard block on further actions without removing the user, and the OAuth connection itself stays in place. It also freezes the human. If the rep still works for you, you've cut off their AI and their day job in one move.

Two things that look like they should work, and don't:

-> Lowering their role. Per Clay's docs, a Viewer can still trigger runs through MCP. Role is not an MCP kill switch. -> Turning off the client under Allowed MCP clients. This one is real, and it's stronger than it looks: Clay re-checks the policy every time it issues a token, so turning a client off blocks refreshes as well as new connections. But it's per platform, not per person. Switch off Unknown and every mcp-remote bridge in the workspace dies, not just the one rep's.

Neither documented lever can tell the difference between the AI's access and the person's access. That is the gap, stated plainly.

The revoke endpoint exists. Admins just can't reach it.

Here's the part the LinkedIn version of this post didn't have. Clay's connection docs list a standard revocation endpoint, https://api.clay.com/oauth/revoke, following RFC 7009. To disconnect a user, you POST their token to it with your client credentials.

Read that again. The thing you need in order to revoke one user is that user's token. The admin doesn't have it. The AI client does. So per-user revocation in Clay is possible today, but only from the side that holds the token, which in the default setup is a rep's laptop.

An on/off switch wearing a fancier name

This is the kind of finding that never shows up in a demo. It shows up three months in, when someone changes roles, or you want to test a permission change without nuking a seat, or a rep resigns and you want their AI cut off before their laptop is.

"Jaron, our IdP handles offboarding." Maybe. Your IdP handles the identities it federates. A Clay OAuth grant held by an AI client is a token relationship between Clay and that client. Clay's MCP docs don't say whether deactivating the person's identity-provider account invalidates that token downstream. An offboarding control you can't verify is a hope, not a control.

MCP raises the stakes on this compared to classic SaaS offboarding. The grant doesn't sit in a browser tab that logs itself out. It sits in an AI client that can act with the rep's authority whenever it runs. Access control that only works at the account level isn't access control. It's an on/off switch wearing a fancier name.

The pattern that avoids the whole class of problem

This is the layer I build into every deployment: put something in the middle. Each person's AI connects to a gateway, the gateway holds the Clay connection, and each connection is scoped to the Functions that person's work actually needs. Now the gateway is the side that holds the token, which means the gateway can call https://api.clay.com/oauth/revoke for exactly one person. Revocation becomes a one-line change, and no user gets deleted to make it happen. The same pattern is what keeps one client's servers out of another client's sessions (the scope-leak version of this problem).

Clay isn't unusual here, to be fair. Most SaaS vendors shipped MCP servers in 2026 far faster than they shipped admin controls for them. Clay is just the one with docs honest enough to make the gap checkable.

Run this test before someone resigns

1. Pick one rep who has connected Clay to Claude or ChatGPT.
2. Open Settings → MCP users and try to revoke just their connection without touching their seat, their role, or their credits.
3. Time it. If the only paths you find are removing the user and zeroing their credit limit, you've reproduced the finding.
4. Write down what you would actually do if that rep resigned today. That document is your MCP offboarding runbook. If step 4 produced a blank page, that's the real result of the test.

Then do the same test for every other tool your team has wired into an AI client. The Clay finding is one row in a table most companies haven't started filling in.

If a rep left today, could you turn off just their AI's access, or would you have to delete them to do it?