Verify identity once
Login verifies a local bcrypt password or an LDAP and AD bind, then issues a short-lived access token and a single-use refresh token, never a long-lived secret in reversible form.
PMAP capability
Multi-Tenancy and Access Control
Keep every engagement isolated and every grant intentional. PMAP is multi-tenant across 48 backend domains, enforces the tenant boundary on every repository, and controls who sees what with role-based access.
Isolation that holds across the platform
When one platform serves many companies and projects, a single leaky query can cross a boundary it never should. Access has to be enforced everywhere, not just at the front door.
PMAP builds the tenant boundary into the data model itself. Every downstream repository enforces it, so a project-scoped grant never silently opens the owning company, and data stays inside the engagement it belongs to.
From scattered access checks to one governed grant
Access enforced ad hoc in four different places leaks, drifts, and over-shares. PMAP resolves it from one matrix, scoped in time and tenant, and denies by default.
Access checks scattered ad hoc
- Query A no tenant filter data leak
- Service B inline role check drift
- Module C allow by default over-share
- Database plaintext secret reversible
One governed grant
Reviewer on Subsidiary A
- company scope
- expires Q3
- default-deny
Authorization resolves from one 10 by 6 matrix, the tenant boundary applies in every domain, and an empty allow-list denies by default rather than returning everything.
What governance covers
Tenant isolation by default
PMAP is a multi-tenant platform across 48 backend domains, and every downstream repository enforces the tenant boundary, so isolation is the default rather than an add-on.
- Boundary enforced on every repository
- 48 backend domains, one model
- Isolation by default
Project-scoped access grants
Access is granted at the project scope, so a grant never silently opens the owning company and data stays inside the engagement it belongs to.
- Grants scoped to the project
- No silent escalation to the owner
- Data stays in its engagement
Role-based access control
Role-based access control decides who can see and act on findings, so analysts, owners and viewers each get exactly the access their role needs.
- Roles for analysts, owners and viewers
- Least-privilege by design
- Consistent across modules
One consistent data model
Scanning, asset inventory, analytics, automation and access control share one consistent data model, so governance applies the same way everywhere.
- Shared model across modules
- Uniform enforcement
- No per-tool exceptions
How access control works end to end
Every request answers three questions in order: who is the principal, what may they do, and which tenant data may they touch, with every credential encrypted or hashed at rest.
Step up with MFA
When MFA is required, a TOTP challenge gates sign-in. The secret is stored AES-256-GCM encrypted, recovery codes are bcrypt-hashed, and disabling MFA needs fresh proof, not just a bearer token.
Resolve permission from one matrix
Authorization is one matrix of 10 entity types by 6 actions, resolved per request and cached with explicit invalidation, so there is a single place to audit who can do what.
Scope every grant in time and tenant
A role is granted at global, company, or project scope with an optional expiry. A project grant never opens the owning company, and a lapsed grant drops from scope within seconds.
Enforce the tenant boundary everywhere
Every repository applies a scope filter over the allowed companies. An empty allow-list denies by default rather than returning everything, and cross-tenant access by ID is rejected outright.
Gate writes behind a verified license
An Ed25519-signed license is verified offline against a compiled public key. When it expires or is revoked, writes return 403 while reads stay available, so entitlement cannot be forged or quietly bypassed.
What your team gets
Engagements that stay isolated
The tenant boundary is enforced in every domain, so data from one company never leaks into another report or query, even on a platform-wide roll-up.
Access you can audit at a glance
Because every permission resolves from one matrix with scoped, time-bound grants, you can review exactly who can see and act on findings, and stale access expires on its own.
Credentials that survive a breach
Passwords, recovery codes, and API keys are hashed and TOTP secrets encrypted at rest, so a single database read cannot hand an attacker a working credential.
Frequently asked questions
Can any stored credential be read back?
No plaintext is retained. Passwords and recovery codes are bcrypt-hashed, the TOTP secret is AES-256-GCM encrypted and never serialized, and an API key is kept only as a SHA-256 digest plus prefix. The key plaintext is shown exactly once, at creation.
What stops a stolen refresh token from being replayed?
Single-use rotation. Every refresh atomically swaps the token on the session, so the old one is invalid the instant the real client refreshes once, and access tokens expire in 15 minutes.
How is one tenant kept from seeing another tenant data?
The company row is the tenant boundary, applied as a scope predicate on every list, export, and facet. An empty allow-list denies by default, and a project-scoped grant does not open the owning company.
Can someone forge a license?
No. The license is signed by an Ed25519 key held outside PMAP, and the verifying public key is compiled into the binary, so it cannot be overridden by an environment variable or file and an attacker cannot substitute one they control.
See the governance model
Walk through tenant isolation, project-scoped grants and role-based access in a working session.