Every OAuth grant has two ends. Your admin console shows you one.

If you want to know what has access to your GitHub org or your Slack workspace, there's a page for that. Most major platforms give administrators some way to enumerate OAuth grants: which applications have been authorized, and which users granted the access. It's not always pretty, but it exists, and it's where most OAuth governance starts and ends.

‍

Here's the problem. That page shows you exactly half of the grant.

‍

An OAuth grant is a relationship between two tenants. Your GitHub org is one end. The application on the other side, running in its own tenant, is the other. The GitHub admin console can tell you "Claude has access to these repositories, granted by this user." What it cannot tell you is which Claude. Whose Anthropic account is sitting on the other end of that connection?

‍

What we're finding in the wild

This isn't hypothetical. Nudge Security customers average 88 OAuth grants per employee, 31 of them carrying data-level permissions, and we're seeing an emerging pattern within that population: OAuth grants to tools like Anthropic where the tenant on the other side of the grant isn't the corporate Anthropic instance at all. It's someone's personal account.

‍

Walk through what that means. Your company has approved Claude. You have a corporate Anthropic tenant with SSO, admin controls, and a data agreement. An employee connects Claude to GitHub, and from the GitHub side, everything looks fine: approved app, known user, reasonable scopes. Your inventory says Anthropic has access to GitHub, and Anthropic hooking into GitHub is exactly what you signed up for.

‍

Except the grant doesn't terminate in your corporate tenant. It terminates in a personal account the employee signed up for with their own email. Your source code is now flowing into an environment with none of your controls: no SSO, no retention policy, no admin visibility, and no offboarding path when that employee leaves. And nothing on the GitHub side will ever tell you the difference. The grant to the corporate tenant and the grant to the personal account look identical from where you're standing. This is the Workforce Edge in action: one employee's decentralized decision, invisible to any centralized console, quietly creating risk.

‍

Why one-sided inventory fails

The instinct is to treat the platform admin console as the source of truth for OAuth exposure. Enumerate the grants, review the apps, done. But a one-sided inventory can only answer "is this application allowed?" It can't answer "is this specific connection landing where we think it is?"

‍

Those are different questions, and the second one is where the risk lives. "Anthropic is approved" is a policy statement about a vendor. A grant is a live pipe between two specific tenants, and the vendor's name on the consent screen tells you nothing about which tenant is on the far end.

‍

The fix is reconciliation

The only way to close this gap is to inventory both ends and match them up. For every grant you see on the platform side, there should be a corresponding grant visible in the corporate console of the app on the other side. Claude connected to GitHub? Then the connection should appear in your corporate Anthropic tenant's inventory. If it doesn't, you've found something: a grant that exists in your GitHub org but terminates somewhere you don't control. Almost always, that somewhere is a personal account.

‍

Treat unmatched grants as findings, not noise. They're the signature of exactly the scenario above: sanctioned tool, unsanctioned tenant, corporate data flowing to an account you can't see, can't govern, and can't revoke access to when the person walks out the door.

‍

This reconciliation is tedious to do by hand, which is why almost nobody does it. The consoles weren't built to talk to each other, the grant identifiers don't line up neatly, and the whole exercise has to be repeated every time someone clicks "authorize."

‍

How Nudge Security does it

This is exactly the problem we built Nudge Security to solve. Nudge doesn't just enumerate the grants a platform reports. It associates both ends of every OAuth grant with the identity inside each app that issued it. When Claude connects to GitHub, Nudge ties the GitHub side of the grant to the user and org that authorized it, and ties the Anthropic side to the specific account and tenant receiving the access.

‍

That means the question that stumps the admin console, which tenant is on the other end, gets answered automatically. A grant from your GitHub org into your corporate Anthropic tenant shows up as exactly that. A grant from your GitHub org into someone's personal Anthropic account shows up as exactly that too, and it looks very different in the inventory. No manual cross-referencing, no exporting two consoles into a spreadsheet and squinting at grant IDs.

‍

And because Nudge already knows which accounts are personal and which are corporate across your whole SaaS footprint, the personal-tenant grant isn't just visible. It's flagged, attributed to a specific employee, and ready for the same employee-led remediation flow as any other finding: nudge the person, move the grant to the corporate tenant, or revoke it.

‍

Your admin console isn't lying to you. It's just answering a smaller question than the one you're asking. The grant list tells you what's connected. It takes both ends to tell you where your data is actually going, and seeing both ends is the whole point.

‍

Want to see which of your OAuth grants are landing somewhere you don't control? Start a free trial and find out.