Platform · Access & Identity
The right AI access for
every role. Nothing more.
Grant AI tools, connectors, and agents by employee, team, or department — mapped from the identity provider you already run. Agents get their own identities with owners. When someone leaves, one revocation removes everything they could touch.
Why identity comes first
AI adoption failed the identity test before it failed any other.
Most companies already run disciplined identity programs: SSO in front of every SaaS app, roles mapped from directory groups, offboarding checklists that actually revoke things. Then AI arrived through the side door. Personal accounts, department subscriptions, and API keys shared in chat threads created a parallel access system nobody designed — 2026 industry studies consistently find nearly half of generative-AI use flowing through personal accounts, invisible to every control IT built.
Agents raised the stakes again. A person with an unapproved tool is a data-governance problem; an autonomous agent holding OAuth grants to your CRM is an operational one. Agents need what employees have had for decades: an identity, an owner, a scope, and an expiry.
LeapForce extends the identity discipline you already have to every AI tool, model, connector, and agent — using your IdP as the source of truth, so AI access reads like your org chart instead of a spreadsheet of exceptions.
Access matrix
Access reads like an org chart,
not a spreadsheet of exceptions.
Illustrative example — roles, scopes, and agent identities are defined by your policies. Note the agent row: non-human identities are first-class, with a named owner.
Capabilities in depth
Identity for people. Identity for agents. One system.
SSO & directory sync
SAML/OIDC in front of every AI surface. Group changes in Okta, Entra, or Google propagate to AI access automatically — a promotion, a team move, or a contractor end-date is reflected without a ticket.
Role-based provisioning
Grant by role, team, department, or function. A new hire in Support gets the Support bundle on day one: the right models, the ticket connector, the shared triage coworker — nothing else.
Non-human identities
Every agent and workflow runs under its own identity with a named human owner, an explicit scope, and an expiry. Unowned automation is the root of most AI governance gaps — here it cannot exist.
Scoped, short-lived credentials
Access is exercised through tokens that expire and carry their scope with them. There is no broad “integration user” whose password everyone knows, and no API key that outlives its purpose.
Data-class boundaries
Roles bound not just tools but data classes: a role can reach the finance connector yet be restricted to local models for it, or reach the CRM read-only. Boundaries follow the data, not the app.
Approvals & exceptions with expiry
When someone genuinely needs more, the exception is requested in-product, approved by the resource owner, logged, and time-boxed. Exceptions that never expire are just policy drift with paperwork.
One-step offboarding
Deactivation in the IdP revokes gateway access, connector sessions, agent grants, and tokens together. The audit trail records what was revoked, when, and what the identity touched before it ended.
Access reviews on demand
“Who can reach what, and why?” is a report, not a project. Quarterly reviews and auditor requests export directly from live state — including every agent and its owner.
The regulatory angle
Employment AI is a named high-risk category. Access control is your first line of evidence.
Under the EU AI Act, AI used for recruitment, evaluation, task allocation, and worker monitoring falls into the high-risk category, with obligations applying from December 2027 under the 2026 simplification package — and duties for deployers include human oversight and monitoring of use. Whether or not those specific uses are on your roadmap, regulators and auditors increasingly open with the same questions: who can reach which AI systems, on which data, and who approved it?
Role-based access mapped from your directory answers those questions structurally. It also addresses the finding that appears in nearly every AI breach post-mortem — access controls that didn't exist. Industry analyses of 2025–2026 incidents attribute the overwhelming majority of AI-related breaches to missing AI access controls, not model failures.
Rollout guide
Start with three roles, not thirty.
Phase 1 · Federate
Connect the IdP and mirror your existing groups. No new access model yet — the win is that AI access now has the same front door as everything else.
Phase 2 · Three roles
Define a default role (safe models, no sensitive connectors), one power role, and one restricted role for regulated data. Most companies cover 90% of people with three.
Phase 3 · Name the agents
Inventory existing automation and re-issue each agent under its own identity with an owner and scope. This is where shadow OAuth grants and stray API keys get retired.
Phase 4 · Review rhythm
Turn on expiring exceptions and quarterly access reviews. From here, access quality is maintained by rhythm, not by heroics.
Questions we hear
Access & Identity — frequently asked.
Any SAML or OIDC provider — Okta, Microsoft Entra, and Google Workspace are the common ones. Roles map from the groups you already maintain, so there is no second user database to keep in sync by hand.
No. Start by mirroring the groups you have and attach AI scopes to them. Most companies refine from there — the three-role starting point (default, power, restricted) covers the large majority of employees on day one.
IdP deactivation cascades: gateway tokens are invalidated, connector sessions end, and agent grants owned by that person are flagged for reassignment or shutdown. The audit trail keeps the full history of what that identity touched.
Agents don’t die with their owners — they get reassigned. Because the agent has its own identity and scope, transferring ownership is a metadata change, and the handover is recorded. Work built by one person remains a company asset.
Yes. A role can hold the finance connector but only via local models; another can read the CRM but not export from it. Scopes combine tool, action, data class, model tier, and budget.
Every exception has a requester, an approver, a reason, and an expiry. When it lapses, access reverts automatically. The review report shows exceptions by age, so nothing quietly becomes permanent.
They enter through the same IdP flow with time-boxed accounts, or through a guest role with a narrow default scope. Their access expires on the contract date rather than depending on someone remembering.
No — it extends it. Your IdP remains the source of truth for who people are; Leapforce translates that identity into AI-specific entitlements: models, tools, connectors, agents, budgets, and data classes.
A shared coworker runs under its own identity, scoped to what the task needs — not to what its most privileged user could reach. Users interact with it under their identity, so the audit trail shows both who asked and what the agent did.
Yes — access state and history export as reports mapped to common frameworks (SOC 2, ISO/IEC 42001, NIST AI RMF, EU AI Act evidence requests). See Observability & Audit.