Identity Is Your AI Control Plane: SSO, RBAC, and Access Reviews

Every AI tool I evaluate eventually asks the same two questions: who is this user, and what are they allowed to see? The AI doesn’t answer those questions. Your identity system does. The assistant simply inherits whatever answer it gets.

That’s why, when teams ask me where to start on AI security, I usually point them at identity and access management before anything AI-specific. Microsoft documents that Microsoft 365 Copilot only surfaces content the signed-in user already has permission to access. Most enterprise assistants work the same way. So the quality of your AI controls is, to a surprising degree, the quality of your identity controls. If access is broad and rarely reviewed, the assistant will be broad too, and fast.

Three kinds of identity AI depends on

When people think about identity they think about employees signing in. AI adds two more categories that most mid-size teams haven’t inventoried:

• Human users. An assistant acting for a user sees what that user can see. Every stale group membership and every “temporary” permission becomes something the assistant can find and repeat.
• Non-human identities. Agents, automations, and connectors act through service accounts or app registrations. These often have more access than any person, no owner, and credentials that never expire. The rules for those are in APIs before agents.
• The AI apps themselves. Every SaaS AI tool that connects to your tenant does so through a consent grant. If users can approve those grants on their own, your organization’s data access is being decided one “Accept” button at a time.

Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:

S3. How mature is your identity and access management?

0. MFA is not enforced everywhere
1. MFA everywhere, but access is broad and rarely reviewed
2. SSO for most apps; role-based access in key systems
3. SSO, role-based access, and periodic access reviews
4. Conditional access, least privilege, regular access reviews, and managed service/API identities

If you’re at level 0, stop reading and go enforce MFA. That’s not an AI problem, and nothing else in this post matters until it’s done. Level 1 is the most common place I find mid-size teams: the front door is locked, but once someone’s inside, they can wander into most rooms.

Why each rung matters for AI specifically

SSO is your on-off switch. If an approved AI tool signs in through your identity provider, you can grant it to a group, revoke it for a leaver the same day, and see who used it. If it uses local accounts, you can do none of those things.

Role-based access limits what the assistant can reach on each user’s behalf. When access is granted to roles instead of individuals, the assistant’s reach follows the job, not the history of every request anyone ever approved.

Access reviews remove the stale permissions that AI turns into live exposure. Most oversharing isn’t a policy decision. It’s access that was right once and never got removed.

Conditional access and managed identities let you say “this AI app, only from a managed device” and “this agent, only these scopes, with credentials that rotate.” That’s level 4, and it’s where identity stops being a directory and becomes a control plane.

The asset: a 10-point identity checklist for any AI rollout

Run through this before a new AI tool goes to more than a pilot group. Anything you can’t tick becomes a rollout blocker or a written exception with an owner.

1. MFA enforced for all users, with phishing-resistant methods for administrators.
2. The AI tool signs in through SSO. No local accounts, no shared logins.
3. Licenses assigned by group, so access can be granted and removed in one place.
4. User consent to third-party apps is restricted, with an admin approval workflow for requests.
5. Existing consent grants for AI apps have been reviewed, and anything unused or over-permissioned has been removed.
6. The pilot group’s access has been reviewed, especially membership in groups that grant access to finance, HR, legal, and executive content.
7. The leaver process removes AI tool access the same day, which SSO handles if item 2 is true.
8. Every service identity the tool uses is inventoried, with a named owner, documented scopes, and a secret rotation schedule.
9. Privileged roles are reviewed quarterly, and nobody holds standing admin rights they don’t use.
10. Conditional access limits the AI tool to managed or compliant devices, where your identity platform supports it.

And one decision rule to write into your standard: no AI tool gets access to organizational data unless it authenticates through SSO. That single rule eliminates most of the shadow AI integration risk in one line, and it’s easy for everyone to understand.

Access reviews that actually remove access

Most access reviews fail the same way: a manager gets a list of 80 people, clicks “approve all,” and nothing changes. To get reviews that work:

• Review groups, not individuals. Start with the 20 groups that grant access to your most sensitive sites and systems. That’s a manageable list.
• Send the review to the data owner, not the manager. The head of finance knows who should see finance content. A line manager usually doesn’t.
• Default to removal. If a reviewer doesn’t respond, access is removed, and they can ask for it back. That flips the incentive.
• Do it quarterly for sensitive groups and annually for everything else.

The first cycle is always the painful one, because it catches years of accumulated access. It’s also the one that makes the biggest difference to what an assistant can surface. If you’re preparing a Copilot rollout, it pairs directly with the SharePoint oversharing cleanup.

Mistakes I see at this stage

SSO with a local fallback. Many SaaS tools keep a local login working after SSO is turned on. Former employees keep access through the side door. Disable local login wherever the tool allows it.

Letting users consent to AI apps. This is the most common gap I find. A user tries an AI note-taker, approves its permissions, and it now has access to calendars and mail across the tenant. Restrict consent, then give people a fast way to request tools, or they’ll route around you. That trade-off is the heart of a good shadow AI policy.

Service accounts with no owner. If you can’t name the person responsible for a service account, you can’t tell whether its access is still needed. Assign owners during the inventory, and disable anything nobody claims after a reasonable notice period.

Treating role-based access as a project to finish. You won’t design perfect roles. Start with roles for the systems your first AI use case touches, and extend as you go.

Where identity fits in the bigger picture

Identity is one of four security questions in the readiness assessment, alongside shadow AI, data classification, and vendor review. It’s the one the other three depend on: labels mean little if everyone can open everything, and vendor reviews miss the point if any user can grant a vendor access. For the full picture, see AI security readiness, and for the questions to ask AI vendors about how they use the access you give them, two questions to add to every vendor security review.

Where does your team actually stand?

Identity and access management is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.

Get your free AI Readiness Score →

Want to see what the full assessment covers first? Flip through a complete 38-page sample report.

Related guides

• APIs Before Agents: Giving AI Access to Your Systems Safely
• Fix SharePoint Oversharing Before You Turn On Copilot
• The Shadow AI Policy Your IT Team Actually Needs (With Template)
• AI Security Readiness: Closing the Gaps AI Exposes
• Two Questions to Add to Every Vendor Security Review This Year