Authorization architecture

Authentication proves who presented a credential. Authorization decides whether specific evidence may influence a response.

Organizational AI Memory makes that decision as an intersection:

active actor ∩ organization ∩ OpenFGA relationship ∩ source permission ∩ classification ∩ current state

No administrator role, connector, MCP client, or search adapter can bypass a missing gate.

Request flow

Every protected content read passes the same five stages:

1. Authenticate: accept a browser session or a bearer token from the configured identity boundary.
2. Bind the actor: resolve an active application user, organization, and department from the durable OIDC issuer/subject binding.
3. Resolve relationship scope: ask OpenFGA which organizations, Knowledge Spaces, and stable Assets are candidates under the active authorization model.
4. Intersect canonical evidence: apply source ACLs, source identity and membership, classification, lifecycle, current version, and projection state before ranking or disclosure.
5. Audit and disclose: commit the permission decision, then return only authorized evidence.

Unknown, inactive, stale, or ambiguous state fails closed at the stage where it is discovered.

Identity binding

After initial binding, the OIDC issuer/subject pair is the only automatic identity lookup key. Email, display name, and identity-provider roles do not grant organization or Knowledge access.

During the first sign-in before a durable binding exists, an email claim marked verified by the identity provider may bootstrap that binding. The application first searches directory-managed users. Exactly one active directory match wins even when an invitation also exists. Only when there is no directory match may exactly one open invitation be used. Multiple matches within either category create no binding.

Browser and bearer paths resolve the same server-derived actor. The caller cannot select an organization or department by changing token attributes.

Relationship authorization

OpenFGA relationships govern organization administration, Knowledge Spaces, stable Knowledge Assets, and registry Assets. A request pins the authorization model ID used for its decision. A projection prepared under another model is stale and cannot be disclosed during a model rollout.

An administrator can create a Knowledge Space and author supported grants, but cannot write arbitrary knowledge_asset tuples. Connected sources own the ACL ceiling for their content; a second writer would allow source and product permissions to diverge.

Source evidence and classification

OpenFGA narrows the candidate set, but it is not the final content decision. Canonical retrieval also checks:

• the ACL bound at ingestion for application-authored content;
• the latest sealed, complete ACL generation for source-authored content;
• current source-principal mappings and group membership;
• organization, lifecycle, version, revision, model, and projection state;
• classification policy.

Here, ORGMEMORY means content whose ACL is authored in Organizational AI Memory. SOURCE means content whose ACL is imported from a connected source.

Control-plane roles and knowledge roles remain separate. An Admin controls system configuration but is not automatically an Executive. The EXECUTIVE application role affects only the classification gate and never replaces an OpenFGA relationship or source permission.

In this table, an ordinary knowledge role means an active employee without the EXECUTIVE application role. Public is the broadest authenticated classification inside the product; it does not mean anonymous internet access.

Separate security planes

SCIM provisioning

Directory provisioning uses a separate stateless SCIM filter chain with scoped user and group credentials and its own rate limits. Credentials prefixed with omscim_ are rejected on the product API. They can provision directory state but cannot read Knowledge or act as a user or agent.

MCP for agents

MCP is a separate OAuth2 resource server. It validates its own token audience, requires assets:read or assets:write at the route boundary, and applies per-caller and global rate limits. The gateway exchanges the caller token for the API audience and invokes the same API authorization path. It has no direct database or object-storage access.

Opaque denial and citations

After request-boundary authentication, missing, changed, and unauthorized protected object IDs produce the same generic not-found response. Object-store addresses and internal denial reasons are not disclosed.

Opening a citation is a new request. The API performs a fresh canonical access check, verifies the source revision and blob integrity, and only then streams the original bytes after its audit record commits. Missing or corrupt bytes produce the same opaque response as a denied citation.

A caller missing a required control-plane role is rejected at the route boundary. That is distinct from hiding whether a particular protected object exists.

Audit evidence

Permission audit is append-only and commits independently of the surrounding business transaction. It records actor, resource, operation, decision, reason, policy, request identifier, query fingerprint, and exact ACL snapshot IDs. Raw query text and unrestricted metadata are not stored.

An audit attempt proves that a decision was recorded, not that the surrounding business transaction committed. A protected read returns only after its audit record commits. If audit persistence fails, the read fails closed.