What we do not claim.

Every claim of ours that comes with a caveat appears here, in our own words, with the limit in plain language beside it.

We say: Pramaan issues AI agents their own identity: a client-credentials principal owned by a named human, with a scope ceiling, a default 300-second token lifetime and an enable/disable kill switch. Token issuance requires a DPoP proof unconditionally on this path, independent of the deployment-wide DPoP setting, and by default requires that the proof key belong to one of the owner's enrolled devices. Agent tokens are access tokens only: no id_token and no refresh token. Disabling the agent, or deactivating or deleting its human owner, stops issuance on the next call.

The limit: Agent identity is off by default. Until an administrator switches it on, the broker refuses the agent grant, although agents can still be registered.

We say: Pramaan's identity plane installs and runs with no network egress. Container images move by `docker save`/`docker load` rather than from a registry; TLS is issued by the operator's own internal CA with no ACME and no Let's Encrypt; and the OIDC signing key is generated on the target host. Verified on a network with no route off the machine: the broker, its store and the edge start and serve OIDC discovery over TLS. That test does not sign anyone in or issue a token.

The limit: The test proves the identity plane only: the broker, its store and the edge start and serve OIDC discovery with no route off the machine. It does not sign anyone in or issue a token. Enrolling the Android app offline and running the copilot model offline are not proven, and no update procedure exists today for an installed air-gapped deployment.

We say: The Pramaan mobile application is Android only; there is no iOS application. The published Android app's broker address is a compile-time constant pointing at Pramaan's own hosted broker, so an organisation running Pramaan on its own infrastructure needs a rebuilt and re-signed Android package. The desktop client, by contrast, can be pointed at a customer's broker at runtime by configuration.

The limit: There is no iOS app. The published Android app connects to our hosted broker, an address fixed when the app is built, so a deployment on your own infrastructure needs a rebuilt and re-signed Android package. The desktop client is built continuously for Linux only; its macOS and Windows installers are produced by hand.

We say: One self-hosted Pramaan broker is an OIDC provider with mandatory PKCE for public clients, a native SAML 2.0 identity provider, and a read-only LDAP provider that legacy applications can bind to; it publishes private applications through an inside-out connector and forward-auth, and offers raw TCP tunnelling, a secure web gateway proxy, DNS filtering and L3 tunnelling; and it is the second factor, supporting WebAuthn passkeys and FIDO2 security keys, TOTP, number-matched push approval and offline codes.

The limit: Most of these surfaces ship switched off: the LDAP provider, connector, TCP tunnel, web gateway proxy, DNS filter, data loss prevention and L3 tunnel must each be enabled. Passkey registration accepts ES256 keys only, so a key that supports only Ed25519 or RS256 will not enrol. Offline codes are deliberately weaker than the primary sign-in path.

We say: Pramaan can bind an OAuth access token to a specific device key using DPoP (RFC 9449). When binding is enforced, the token record stores the RFC 7638 SHA-256 JWK thumbprint of the device's P-256 key, and a request carrying the token from any other device is refused with HTTP 401 - including a request carrying a valid, correctly signed DPoP proof made by a different device's key. The proof's jti is single-use, so a captured proof cannot be replayed.

The limit: Binding is enforced only when an administrator switches it on, and it is off by default so that clients that do not send proofs keep working. With the stock setting no binding is recorded, and a stolen access token can be used from another device.

We say: The key a Pramaan access token is bound to is a dedicated software P-256 key held in the client's secure store. It is deliberately not the device's hardware-backed approval key. Binding therefore ties a token to that device's stored key material, not to a TPM or StrongBox.

The limit: The key a token is bound to is a software key in the client's secure store, not a key held in a TPM or StrongBox. Someone who takes both the token and the device's secure store has both halves of the binding.

We say: Deactivating or deleting a person revokes their sessions, refresh-token families and every access token issued to them. Narrower actions do not: revoking one session, 'sign out everywhere', or disabling an AI agent leaves access tokens already issued valid until they expire, which is 300 seconds by default and administrator-tunable.

The limit: Only deactivating or deleting a person ends their access tokens at once. Revoking one session, signing out everywhere or disabling an AI agent leaves access tokens already issued valid until they expire, which is 300 seconds by default.

We say: Pramaan's security assurance to date is an internal white-box audit dated 13 June 2026, covering the broker, the mobile application and a non-destructive probe of the live endpoints. Pramaan's own documentation states that a commissioned external penetration test is still recommended before public general availability and is not a substitute for the internal audit. No third-party audit or penetration test report exists.

The limit: This is an internal audit, not an outside one. No third-party audit or penetration test report exists, and our own documentation recommends an external penetration test before general availability.

We say: Pramaan does not implement a RADIUS server. Its SCIM support runs in both directions: outbound, it pushes users into a downstream application; inbound, it can host a SCIM 2.0 service provider at /scim/v2 so Entra ID or Okta can provision users into it. Inbound SCIM is off by default and on in our reference deployment; it has no DELETE route and no GET /scim/v2/Groups/{id}.

The limit: There is no RADIUS server, so an identity provider that fronts RADIUS leaves a gap. Inbound SCIM is off by default, has no DELETE route and cannot read a single group, and it has not yet been run against a live Entra ID or Okta tenant.

We say: Pramaan resolves every access token on every call rather than trusting a decision made at sign-in. Access tokens are opaque and resolved by an indexed database lookup on each call, with expiry enforced in the query and no read-through cache on any authentication path; forward-auth and private apps re-read group membership and re-run the access rules per request. Revoking a named access token (POST /revoke) therefore takes effect on the next request. Revoking a session does not end access tokens or refresh tokens already issued from it: those last until they expire or are revoked themselves.

The limit: The per-request rule check applies to forward-auth and private applications; OIDC and SAML applications receive their decision when a token is issued. Revoking a session does not end access tokens or refresh tokens already issued from it.

We say: Pramaan's signed tree head additionally carries a post-quantum SLH-DSA-SHA2-128f (FIPS 205) anchor over the root hash. The browser does not verify that anchor; client-side verification covers the ES256 signature only.

The limit: No browser checks the post-quantum signature; verification in the browser covers the ES256 signature only.

We say: Pramaan runs on the customer's own infrastructure. There is no licence-check server, no telemetry beacon and no phone-home in the broker: nothing reports usage, health or identity to Frontier Labs, and the broker needs no outbound connectivity to start or to authenticate anyone. The outbound calls that exist are optional and off by default or unconfigured, and each has a named switch: (1) the CVE/CISA KEV feed sync to storage.googleapis.com and cisa.gov (the vulnerability-feed switch, default off); (2) Firebase push to fcm.googleapis.com (absent unless a service account is configured; the broker falls back to WebSocket and polling); (3) Google Play Integrity attestation (the Play Integrity switch, default off); (4) the Android key-attestation revocation list at android.googleapis.com, refreshed daily (the key-attestation switch, default off); (5) the Telegram Bot API (only if configured); (6) the secure web gateway's upstream DNS resolver (the gateway's upstream-resolver setting, operator-overridable). Outbound SCIM/Graph/Google Workspace provisioning and outbound OIDC/SAML/LDAP calls go to endpoints the operator names -- in the normal case the customer's own tenant at their own IdP -- and are unconfigured until the operator adds a source or target.

The limit: The list covers the broker, not the mobile app: the published Android app starts its push configuration at startup and reaches Google whatever the broker is configured to do. Our own demonstration deployment turns on three of the six optional connections.

We say: Pramaan's browser SSO session cookie is not device-bound. It is Secure, HttpOnly, SameSite=Lax and __Host- prefixed, which are theft-resistance measures, not binding. Only the access token is device-bound.

The limit: Device binding covers the access token only. The browser sign-in cookie carries theft-resistance attributes (Secure, HttpOnly, SameSite=Lax and the __Host- prefix), but it is not bound to the device.

We say: A browser verifies the transparency log without trusting Pramaan's server: dependency-free WebCrypto code recomputes RFC 6962 inclusion proofs and verifies the ES256 signature over the signed tree head against the public JWKS, in both the account portal and the admin console. Append-only consistency proofs are checked only in the admin console. No browser view verifies the post-quantum signature.

The limit: Append-only consistency proofs are checked only in the admin console, no browser view checks the post-quantum signature, and neither console hashes the event it displays: each starts from a leaf hash the server supplies.

We say: Every Pramaan audit event is appended as a leaf to an RFC 6962 Merkle transparency log. There is no feature flag; the log is written unconditionally. GET /transparency/sth returns a signed tree head to anyone, with no credentials, and inclusion and consistency proofs are served on the same unauthenticated basis because they expose only hashes.

The limit: The log proves that recorded audit events were not altered or removed. It does not prove that every security decision became an event; that is a separate property, checked by reading the code path rather than the tree head.