Federated with the directory systems already inside the perimeter.
Limit Platform consumes identity from the customer's existing IdP, not from a separate user directory. Humans, services, and AI agents are all identified, audited, and authorized through the same identity layer.
// identity · already inside the perimeter
No second directory. No third login.
Regulated enterprises already operate identity systems: an enterprise IdP, federated SSO, service-account directories, privileged-access tooling. The last thing the security team wants is another user directory to provision, audit, and reconcile.
Limit Core plugs into what is already there. Humans authenticate through the customer's existing identity provider. Services and AI agents receive identities issued and rotated by the customer's existing infrastructure. Limit Vault holds secrets and short-lived credentials inside the perimeter. Every access decision rides on identity context the customer already trusts.
Identity that fits the perimeter you already have.
- 01
Federated human identity through OIDC and SAML
Humans authenticate through the customer's existing identity provider. No password storage, no separate account lifecycle, no privileged-access bypass.
- 02
Service and AI-agent identity rooted in customer infrastructure
Services and AI agents are identified by certificates or tokens issued by customer-controlled infrastructure. Rotation, revocation, and audit follow the customer's existing processes.
- 03
Matter, role, and context propagated through every request
Identity claims include matter or case context, role assignments, and ethical-wall constraints. Downstream authorization decisions consume the full context without making it up.
- 04
Every authentication and authorization in the audit trail
Login events, token issuance, claim resolution, and downstream authorization decisions all land in the evidence store with the full identity context.
Identity rides the customer's existing infrastructure.
No identity data leaves the customer perimeter. The platform consumes claims from the existing IdP; it does not mirror the directory. Service identity is issued by customer infrastructure; the platform consumes the resulting credentials.
For customers operating in air-gapped or restricted-connectivity environments, identity continues to function fully. The platform never depends on an external identity service.
- Protocols
- OIDC and SAML for federated human authentication. mTLS, SPIFFE/SPIRE-compatible patterns, or customer-defined for service identity.
- Where identity claims live
- In the customer IdP and in the request context. The platform does not maintain a long-term user store.
- Service accounts
- Issued and rotated by customer infrastructure. The platform validates; it does not provision.
- Air-gapped operation
- Full identity functionality without external dependency, where the customer IdP itself operates inside the perimeter.
This capability is one layer of the operating system. Every application uses it. Every customer perimeter that runs Limit Platform gets it. See the full architecture →
See it in your environment.
Walk us through the systems already in place. We'll show you how this layer fits.