Appriana Platform · Access Control
Multi-tenant by design.
Enforced on each record.
Fortress is the identity and access plane underpinning each Bloom path and action. It carries the questions your enterprise security teams want to know about isolation, identity, and access, addressed as a first-class element of the offering.
Where Fortress sits
Identity and access,
treated as first-order engineering.
Bloom is powered by Appriana, a multi-tenant SaaS platform. Outpost collects unstructured customer signal. Orbit schedules background work. AIHub provides the intelligence pipeline. Bostanci watches the platform itself.
Fortress is the access plane. It decides who can see what, who can do what, and at which scope. Every other component asks Fortress before returning data. It carries its own identity, its own engineering, and its own page here, because isolation and access are the questions enterprise buyers press on hardest, and they deserve a deeply anchored answer.
01 · Tenancy
Isolation lives at query time.
Settled before a row is read.
Every read in Fortress is bound to a tenant before it reaches the database. The boundary is part of the query itself, resolved beneath the application, where no application-side operation can forget to apply it. One tenant's data and another's are never in reach of the same query.
The same rule governs internal services and automated jobs. They run inside a tenant context like anyone else, and any elevation across tenants is granted narrowly, through controlled paths, and shaped only for the single tenant and operation that needs it.
Bound at the query
Every read passes through a tenant-aware query layer with a resolved tenant context attached, and the scope of the result is fixed before the database runs it. A new record is tagged to its tenant as it is written, or the write does not complete.
Scoped by path
Tenancy is a path carried on every record (e.g., /orgs/acme). Reads stay within the caller's path and reach nothing outside it.
Systems held to the same rule
Internal services and automated jobs run inside a tenant context too. Cross-tenant elevation is granted only as needed, through controlled paths, scoped to the operation at hand.
Isolation is guaranteed by the way data flows, not by the habits of the people building on it. Crossing a tenant boundary has one explicit, system-flagged path, and no other.
02 · Identity
One identity.
Many ways to reach it.
Fortress models a user as a Principal: one durable identity that can carry several identifiers and several credentials across its life. A person who changes email, adds a device, or logs in a new way stays the same identity underneath.
Multiple identifiers
Work email, personal email, legacy username, phone. Identifiers can be added, verified, or retired while the identity beneath them holds steady. Identity is the durable thing, not the address.
Multiple credentials
Password, SAML, OAuth, API key, each attached to the same principal, each revocable on its own. An enterprise SAML credential on a laptop and a Google sign-in on a phone resolve to one identity.
Humans and services
Service accounts are first-class principals, distinct from human users, with their own rotating keys and scopes. Machine access sits in the same model as human access, and audits the same way.
Realms
A boundary for each population.
With policy to match.
A Realm is the boundary an identity belongs to. Your internal staff, your customer-facing users, and your contractor population each live in their own Realm, confined to it, with authentication policy set on the population rather than per user. Where a large enterprise needs subsidiaries to share one identity boundary, several orgs can map under a single Realm.
| Policy | Internal staff | Customer users |
|---|---|---|
| Self-registration | Disabled | Invite-only or open |
| Email verification | Required | Required |
| MFA | Enforced | Enforced or optional |
| SSO | SAML or OIDC required | SAML, OIDC, or password |
Your team's authentication policy is yours to set. Bloom staff sit in their own Realm, with stricter requirements and a boundary that does not overlap yours.
03 · Access
Permissions on a path.
Scoped to the resource.
Resources in Fortress live on hierarchical paths, and permissions are granted to those paths. A grant can cover a single record, a single operation, a whole namespace, or an entire org, with the same shape of expression. The model holds the considerations a hard multi-tenant system arrives at on its own: hierarchy, scope, wildcards, and explicit exclusion, kept clear enough to manage by hand.
Permissions, roles, groups
Permissions are atomic, read, write, delete, execute, admin, attached to a path. Roles bundle permissions, with risk levels and optional auto-expiry. Groups collect principals. Grants bind groups to roles or permissions.
DENY beats ALLOW
When grants overlap, an explicit DENY wins. A contractor group can hold read across /orgs/acme/** with a DENY on /orgs/acme/ns/finance/**, and the exclusion holds however many ALLOW grants point at the same path.
Sessions
Every session visible.
Every session in reach.
Administrators see every active session for a principal: IP address, device fingerprint, when it began. A session can be revoked one at a time or all at once, and revocation invalidates the underlying web tokens at once.
- Revoke one: lost device, suspicious IP, a single session to close.
- Revoke all: offboarding, credential rotation, a broader response. Every web token for the principal goes invalid at once.
- Safe Mode: destructive admin actions, like archiving an organization or changing a core security role, ask for explicit confirmation. On by default. Key entities and states are retained for later audit rather than removed.
04 · For Bloom customers
What this looks like
on your side.
Authentication
SSO with your IdP
SAML or OIDC. Your team signs in the way it already does, under the policies your IT already enforces.
Policy
MFA at the Realm level
MFA is set on the population, so it covers everyone in it, including the next person to join.
Roles
Granular access for your teams
Read-only execs, admin VoC operators, scoped contractor access. Configured by path, clear to read back.
Incident response
Sessions revocable by your admins
Your team revokes a lost-device session or rotates a credential directly, without a Bloom support ticket.
Isolation
Tenancy held at query time
Your data and another customer's stay out of reach of the same query, by the structure of the system and not via after-the-fact controls.
Vendor access
Bloom staff in a separate Realm
Any required system access to your tenant runs through Fortress as well, in its own Realm with its own policies, held to the same enforcement in both directions, with each request attributed to a principal and org and traceable through the actions it takes.
Vetting Bloom for enterprise rollout?
Bring your security team.
A 30-minute briefing covers tenancy, access controls, and security posture with your IT, security, or compliance leads in the room. Direct conversation with the people who build and run the platform.