One core process, the Pramaan broker, signs people in, checks their devices, decides access and records the evidence. OIDC and SAML applications receive their decision when a token is issued; private apps behind the connector are decided on every request.
Illustrative.
Pramaan speaks OIDC, SAML 2.0, LDAP, SCIM, each for its own job: applications sign people in over OIDC or SAML 2.0, which works as identity provider and as service provider. SCIM 2.0 provisions users in and out, and legacy applications can bind to its LDAP provider once it is switched on.
Pramaan is its own MFA provider: passkeys, number-matched push approvals and codes from an authenticator app. The second factor is checked inside the same broker that issues the sign-in.
Private applications are published through four entry points: a connector that dials out from beside the app, a sign-in check in front of web apps that have none, the secure web gateway and direct connections for desktop tools such as SSH or database clients. Each is switched on separately and stays off until you do.
An inline forward proxy and a DNS filter sit on outbound web traffic, each switched on by its own setting.
Each AI agent gets its own sign-in identity, with a named human owner, a ceiling on what it may do and a kill switch. Its token requests always need a proof from its own key, whatever the deployment-wide setting.
Illustrative: example rows, not a live console.
What devices report, weighted by you.
How requests are decided, and how access ends.
A model drafts; broker code checks; you commit.
Private apps with no inbound port.
Sign-in protocols.
Second factors.
Gateway, DLP, sessions.
Agent identity.
For your engineers
Apart from the public router, a listener opens only when an administrator gives it an address. Every setting is described in the configuration reference.
| Listener | How it starts |
|---|---|
| Public router | always; it has a default address |
| Admin router | only when an administrator sets its address |
| LDAP provider | only when an administrator sets its address |
| Connector tunnel | only when an administrator sets its address |
| Raw-TCP ingress | only when an administrator sets its address |
| Web gateway proxy | only when an administrator sets its address |
| DNS filter | only when an administrator sets its address |
| UDP tunnel (desktop client only) | only when an administrator sets its address and switches it on |
| TLS on-demand check | only when an administrator sets its address |
Yes. One core process, the broker, does the identity, policy, device-trust and evidence work, and it starts each optional entry point inside itself rather than as a separate service.
The LDAP provider, the connector, the entry point for direct connections, the web gateway proxy, the DNS filter, DLP and the network-level tunnel all ship off: each is opt-in. AI-agent identity ships off too.
No. Pramaan has no RADIUS server, so equipment that authenticates people over RADIUS needs a RADIUS server of its own. Inbound SCIM provisioning also has no request that deletes a user or group.
In the configuration reference at docs.pramaanid.cloud, which documents 156 settings. The reference is generated from the broker's configuration source rather than written by hand.
Not for every kind of application. OIDC and SAML applications receive their decision when a token is issued; private apps behind the connector are decided on every request. Access tokens are resolved on every call, but revoking a session does not end the access tokens already issued from it; deactivating or deleting the person does.
Against your own apps, not slides.
It uses a demonstration account; none of your data is involved.
Published floors, named-user bands and what every tier includes.
