Teams · Identity

Keep your identity provider. Add the authorization it was never built for.

Okta, Entra ID, and Auth0 are excellent at proving who someone is. They were not built to decide whether that person can approve this invoice in this tenant, or whether an agent acting for them can call this tool. Permit is that layer, and it lives alongside your identity stack, not instead of it.

Book a demo Start free

“Once a startup grows, it starts to have bigger and more demanding customers. Enterprise customers expect better integration with dynamic roles, external identity providers, and the ability to bring their own authorization mechanisms into our product.”

OmriSoftware Architect, Salt Security

Where identity stops and authorization starts

Groups are too coarse
A group says someone is in Finance. It cannot say which accounts, records, or tenants that person should reach.
Tokens become permission dumps
Packing permissions into token claims makes tokens large, stale the moment a role changes, and hard to revoke.
Every app reinvents the mapping
Each application translates groups into its own permissions, differently, and none of it is visible to the identity team.
Agents do not fit the identity model
An AI agent acting for a person is not that person, and not a service account. Neither identity type captures delegation and consent.

How Permit extends your identity stack

Bring the identities you already manage. Permit turns them into fine-grained, real-time decisions.

Works with the identity provider you have
Provision users and groups over SCIM from Okta or Entra ID, or sync from any identity provider through the API. The MCP Gateway accepts Okta, Entra ID, Auth0, JWT, and SPIFFE identities directly. Permit authorizes; it does not replace sign-in.
Groups in, fine-grained decisions out
Map groups and claims to roles and attributes, then add the resource-level rules that groups cannot express.
Evaluated at request time, not baked into tokens
A role change or revocation applies on the next check, not when a token eventually expires.
Delegated identity for AI agents
The MCP Gateway builds an agentic identity from the delegating person, their consent, and the agent’s declared intent. Agents never hold standing credentials.
One authorization plane the identity team can see
A single policy layer for every application and API, visible to the identity team instead of buried in each codebase.

Delegation that follows live permissions

The user’s role changed minutes ago. The agent acting for her feels it on its next call. Illustrative data.

Example decisiondeny

subject: agent:calendar-assistant for user:noa@example.com
action: tools/call create_event
resource: calendar:team-leadership
reason: noa’s role changed to viewer at 09:12; delegated access follows her live permissions
decided by: Permit MCP Gateway

Diagram: an identity provider signs people in through SSO and provisions users and groups through SCIM into Permit, which maps them to roles and authorizes apps and AI agents. — Sign-in stays with your identity provider over SSO. SCIM provisions users and groups into Permit, which decides what apps and agents can do.

Agentic identity

Delegating humanSigned in through your identity provider. The agent can never exceed their live permissions.
ConsentWhat the person allowed this agent to do, scoped down to individual tools and arguments.
Intent fingerprintThe gateway asks the agent what it is trying to do. If that intent drifts, consent is asked again.

Agentic identity

Human, consent, and intent, bound together and checked against policy on every tool call.

The agent receives a representative token.

Real upstream credentials stay vaulted in the gateway.

Agents hold no standing credentials. Revoke the person, change their role, or withdraw consent, and the agent loses access on its next call.

SSO and SCIM, the way identity teams run them

Sign-in stays with your identity provider. Provisioning flows from your directory. Permit picks up from there.

SCIM provisioning

Joiners, movers, and leavers, straight from the directory

Access should change when the directory changes, not when someone next runs a sync script. Permit runs a SCIM 2.0 server, so Okta or Entra ID provision users and groups into authorization the same way they provision any other application.

Users and groups sync over SCIM 2.0. Groups become roles, and group membership becomes a role assignment.
Your identity provider pushes creates, updates, and deactivations, so a leaver loses access through the same connection that granted it.
Tenant-aware endpoints let each of your enterprise customers point their own identity provider at their own tenant, with role assignments kept separate per tenant.
Step-by-step guides for Okta and Entra ID, and a separate endpoint for the EU region.

SCIM base URLs

# One environment for all users
https://scim.permit.io/scim/v2/{project}/{environment}

# One connection per customer tenant, assignments isolated per tenant
https://scim.permit.io/scim/v2/{project}/{environment}/v2/{tenant}

Single sign-on

Your SSO stays the front door

Permit is not in the sign-in path. People authenticate with the SSO you already run, over SAML or OIDC, through Okta, Entra ID, Auth0, or your own provider. Permit takes the verified identity and decides what it can do.

Works with any authentication provider: sync the user after sign-in, pass JWT claims as attributes, or check directly.
Choose where roles are managed: in your identity provider, in Permit, or split between them.
For AI agents, the MCP Gateway can authenticate the delegating person through enterprise SSO over SAML or OIDC before any agent acts for them.
Your own team signs in to Permit with enterprise SSO, available as an add-on, with workspace, project, and environment roles.

Read the docs, run the code

Documentation

Example projects on GitHub

Questions identity teams ask

Does Permit replace Okta, Entra ID, or Auth0?

No. Permit handles authorization and works alongside your identity provider, using the identities and groups it already manages.

Why not put permissions in token claims?

Claims are fixed when a token is issued, so they go stale as soon as access changes, and they grow with every permission. Evaluating policy at request time keeps decisions current and tokens small.

How do users and roles get from our identity provider into Permit?

Through SCIM, so Okta or Entra ID provision users and groups directly, or through the API and SDKs, typically by syncing a user right after sign-in. Groups and claims map to roles and attributes.

How are AI agents identified?

Through the MCP Gateway, which binds the agent to the person delegating to it, the consent they granted, and a fingerprint of the agent’s intent. If that intent drifts, consent is requested again.

Which identity sources can Permit use?

Any identity provider, through SCIM or the API. For AI agents, the MCP Gateway works directly with Okta, Entra ID, Auth0, JWT-based identities, and SPIFFE workload identities.

Do you support SSO?

Permit works with whatever SSO your applications use, because authentication stays with your identity provider. For your own team’s access to the Permit workspace, enterprise SSO is available as an add-on.

Bring your hardest permission problem.

Tell us what you are authorizing and where it runs. We come to the call with a model of how Permit would enforce it.

Book a demo Read the docs

SOC 2 Type II attestedSecurity, Availability, Confidentiality
Cloud, hybrid, or on-premDecisions run in your network
Every decision loggedExplained, and forwardable to your SIEM
Built on open standardsOPA, Cedar, and OPAL

Review our security program in the Trust Center

Keep your identity provider. Add the authorization it was never built for.

# One environment for all users https://scim.permit.io/scim/v2/{project}/{environment} # One connection per customer tenant, assignments isolated per tenant https://scim.permit.io/scim/v2/{project}/{environment}/v2/{tenant}

Questions identity teams ask

Does Permit replace Okta, Entra ID, or Auth0?

No. Permit handles authorization and works alongside your identity provider, using the identities and groups it already manages.

Why not put permissions in token claims?

Claims are fixed when a token is issued, so they go stale as soon as access changes, and they grow with every permission. Evaluating policy at request time keeps decisions current and tokens small.

How do users and roles get from our identity provider into Permit?

Through SCIM, so Okta or Entra ID provision users and groups directly, or through the API and SDKs, typically by syncing a user right after sign-in. Groups and claims map to roles and attributes.

How are AI agents identified?

Through the MCP Gateway, which binds the agent to the person delegating to it, the consent they granted, and a fingerprint of the agent’s intent. If that intent drifts, consent is requested again.

Which identity sources can Permit use?

Any identity provider, through SCIM or the API. For AI agents, the MCP Gateway works directly with Okta, Entra ID, Auth0, JWT-based identities, and SPIFFE workload identities.

Do you support SSO?

Keep your identity provider. Add the authorization it was never built for.

Where identity stops and authorization starts

Groups are too coarse

Tokens become permission dumps

Every app reinvents the mapping

Agents do not fit the identity model

How Permit extends your identity stack

Works with the identity provider you have

Groups in, fine-grained decisions out

Evaluated at request time, not baked into tokens

Delegated identity for AI agents

One authorization plane the identity team can see

Delegation that follows live permissions

SSO and SCIM, the way identity teams run them

Joiners, movers, and leavers, straight from the directory

Your SSO stays the front door

Read the docs, run the code

Documentation

Example projects on GitHub

Questions identity teams ask

Bring your hardest permission problem.

Keep your identity provider. Add the authorization it was never built for.

Where identity stops and authorization starts

Groups are too coarse

Tokens become permission dumps

Every app reinvents the mapping

Agents do not fit the identity model

How Permit extends your identity stack

Works with the identity provider you have

Groups in, fine-grained decisions out

Evaluated at request time, not baked into tokens

Delegated identity for AI agents

One authorization plane the identity team can see

Delegation that follows live permissions

SSO and SCIM, the way identity teams run them

Joiners, movers, and leavers, straight from the directory

Your SSO stays the front door

Read the docs, run the code

Documentation

Example projects on GitHub

Questions identity teams ask

Bring your hardest permission problem.