Every security leader I talk to has the same moment with Claude. First it's a pilot. Then it's a team. Then someone in finance asks why the seat count keeps climbing, and nobody in security can say exactly who has them, what role they hold, or who approved it. That's not a shadow AI problem. Claude Enterprise is sanctioned, paid for, and rolled out on purpose. It's an identity problem. Claude now has admins, custom roles, groups synced from your identity provider, invites that sit open for weeks, and API keys that keep working long after the person who created them has moved on. In other words, Claude is an identity system now. So we built Opti to govern it like one.
What we built
Anthropic now lets security platforms connect directly to Claude Enterprise, and Opti is one of them. Opti connects to Claude Enterprise and brings every human and non-human identity in it into the same identity graph, access reviews, and remediation workflows you already run for the rest of your stack. No new console. No separate process for AI. Claude becomes one more application Opti governs, with the same rules.
Human access: who has Claude, and how much
Most organizations can tell you how many Claude licenses they bought. Very few can tell you who holds admin rights, which roles are custom, or which groups were created by hand instead of synced from the identity provider (IdP). Opti pulls every Claude Enterprise user, their organization role, and every pending invite. It maps role-based access control (RBAC) roles and their permissions, and the groups those roles are granted through. For each group, Opti knows whether it was provisioned through SCIM from your IdP or created directly in Claude. That last detail matters more than it sounds. A group created directly in Claude doesn't follow your joiner-mover-leaver (JML) process. When someone changes teams or leaves, their IdP account updates. Their manually granted Claude access doesn't. With Claude in the identity graph, Opti flags the patterns that turn into audit findings:
Users removed from your IdP who still hold an active Claude account
Admin and owner roles that have quietly multiplied since rollout
Access granted through manual groups that bypass your provisioning process
Invites sent weeks ago, sometimes to personal email addresses, that are still open
Then it does something about them. Findings go into the same risk-scored access reviews and remediation workflows Opti runs for every other application, so reviewers see what's risky first instead of rubber-stamping a list of names.
Non-human access: the keys nobody owns
Humans are half the story. The other half is the scripts, integrations, and agents that call Claude with a key instead of a login. Opti treats every Claude API key as a non-human identity (NHI) and governs it like one. For every key, you see who created it, when, and whether that person still works for you. That's the context you need to answer the only question that matters for a credential: should this still exist? The risky ones are rarely dramatic. A key created for a proof of concept eight months ago. A key whose creator left the company in the spring. A key that was supposed to be temporary. None of them shows up in a user access review, because none of them is a user. Opti puts them in the review anyway, with an owner attached, so every non-human identity in Claude gets the same scrutiny as a human one.
Activity as evidence, not screenshots
Access reviews fail audits for a simple reason: they show what access someone had on the day of the review, not how they got it or whether they used it. Opti ingests the Claude activity feed, which covers more than 400 event types: logins, authentication events, role and group changes, API key creation and deletion, and administrative actions. Anthropic retains that history for six years, and Opti keeps it in sync on a continuous schedule. That changes what a reviewer sees. Instead of a name and a role, they see when the user last logged in, who granted the admin role and when, and whether a key has been touched since it was created. Unused access becomes easy to remove. Recent privilege changes stand out. And when an auditor asks who had admin access to Claude last quarter and who approved it, the answer is a record in Opti, not a screenshot from an admin panel.
Why Claude can't be governed on its own
You could review Claude access inside Claude. You'd find users and roles. What you wouldn't find is the context that makes any of it risky. Risk lives in the connections. A Claude admin who is a contractor in your HR system. A user who was offboarded from your IdP last month but still holds an active Claude account. An API key created by an engineer who no longer has access to the code that uses it. Each of these looks harmless inside Claude. Together with the rest of your environment, they're exactly what an attacker or an auditor looks for. That's why Opti puts Claude in the same identity graph as your IdP, your HR system, your cloud accounts, and the hundreds of other applications you already govern. One identity, every account it holds, one place to review and fix it.
Say yes to Claude, with governance in place
I don't believe security teams should be the ones slowing AI down. Your people want Claude because it makes them better at their jobs. Blocking it just pushes them toward tools you can't see at all. The job is to make sure that when Claude is in your environment, it's governed like everything else: every identity known, every privilege justified, every key owned, and every change on the record. With Opti, it is. If you're running Claude Enterprise and want to see who and what has access to it, book a demo.
