Isolation and governance, enforced by construction.

Sigmaera holds confidential content under a layered, mechanically-enforced security model. No single control carries the isolation guarantee on its own — each layer is designed to hold if the one above it is bypassed, and each is verified by an automated test or a build gate rather than by procedure. The controls an enterprise reviewer cares about most:

Six principles govern the platform's security architecture. They are the reason the controls in this document look the way they do, and they are applied consistently rather than per-service.

Where we have invested

Security work in the current cycle concentrated on five areas. Each is described in full later in this document.

The platform handles these categories of content, each with a defined home and handling shape.

Sensitivity taxonomy & handling shapes

An 18-category canonical taxonomy is declared once in a shared package and distributed to every consuming service as TypeScript and Python siblings with parity tests — so the same tag means the same thing everywhere, and a category cannot drift between services. Representative categories: HR_Compensation, MA_Confidential, MA_HighlySecret, Board_Material, Customer_PII, Customer_PHI, Security_Incident, Security_Vuln.

The default — index everything, gate at read — preserves analytical value while making authorization correctness load-bearing. The platform compensates for that with a single shared filter implementation, fail-closed semantics, two-user isolation tests on every read endpoint, and mandatory per-read auditing.

Three orthogonal axes

The platform separates three questions that are often conflated. Keeping them independent is deliberate: a control that answers one does not answer the others, and treating classification as though it answered ownership is a well-known source of subtle exposure in content platforms.

The platform is organized into planes that form the primary trust-boundary structure. The data plane runs identically in our cloud and inside your perimeter — the code does not branch on deployment mode. Two edge-plane services exist only in our cloud and are never shipped on-premises.

The lifecycle of a piece of content, hop by hop. Click a stage to see the security control at that hop.

A single identity service is the only token issuer, implementing OpenID Connect and OAuth 2.1. It supports authorization code with PKCE for user login, client credentials for service-to-service calls, refresh tokens with rotation on every use, and RFC 8693 token exchange for delegation. The implicit and resource-owner-password grants are not supported. No other service may issue or sign anything resembling a platform token.

The full authentication surface is implemented: multi-factor authentication with recovery codes, password reset and email verification using single-use hashed tokens, session termination and revocation, personal access tokens, and key publication with rotation.

Membership-verified organization selection

One person frequently belongs to several organizations — a consultant across clients, an executive across portfolio companies, a contractor across engagements. The platform supports this with one credential and one multi-factor enrollment, without weakening the boundary between those organizations.

At authorization time the identity service computes the caller's eligible set from live membership data and issues a token for one organization chosen from it.

-- a token may only ever be issued for an organization in this set
eligible(user) = ( { home_organization(user) } ∪ { org | membership(org, user) = 'active' } )
                 ∩ { org | org.status = 'active' }

-- membership is re-verified at EVERY issuance and EVERY renewal,
-- and fails closed: never to a different organization.

Service-to-service & delegated access

Every service is a registered client obtaining tokens with asymmetric client authentication — never a shared secret. Service tokens carry a service subject and the least-privilege scopes that service needs.

For features that must act with an end user's permissions — an analyst agent answering a question on your behalf — the platform uses standards-based token exchange. The delegated token's scope is the intersection of what was requested with what the user actually holds, so delegation can never broaden privilege, and a dedicated claim records the delegation chain for audit. Delegated tokens inherit the same 15-minute lifetime.

The most consequential control in a multi-customer intelligence platform. The defense is layered and mechanical, and identical whether the platform runs in our cloud or inside your perimeter.

The policy stack

ALTER TABLE <table> ENABLE ROW LEVEL SECURITY;
ALTER TABLE <table> FORCE  ROW LEVEL SECURITY;   -- required: without FORCE the owner is exempt

-- The organization boundary.
CREATE POLICY <table>_tenant_isolation ON <table>
  USING      (tenant_id = current_setting('app.tenant_id', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- The workspace boundary — RESTRICTIVE, so it is AND-ed beneath the policy
-- above and is structurally incapable of widening visibility.
CREATE POLICY <table>_scope ON <table> AS RESTRICTIVE
  USING      (scope_id = ANY(string_to_array(current_setting('app.scope_ids', true), ',')))
  WITH CHECK (scope_id = ANY(string_to_array(current_setting('app.scope_ids', true), ',')));

Both policies read their context from a transaction-local setting established at the start of every transaction, so context cannot leak between concurrent requests sharing a connection pool. If that context is unset, the predicate evaluates false and the query returns zero rows — not an error, and emphatically not everything. Both fail closed by construction.

Privilege separation at the database

Schema migrations and grants run under an administrative role. The application runtime connects under a separate role that has no policy-bypass privilege at all. Every service asserts its own runtime role at startup and refuses to start in production if it is connected with a role that could bypass policy.

A separate reserved administrative role exists for explicitly-audited operations that must legitimately span organizations — retention cleanup, re-classification, index maintenance, and the event outbox drain. Each re-establishes per-organization context before touching customer data, so even these paths operate one organization at a time.

Graph isolation

The knowledge graph is the highest-consequence surface in the platform: an unconstrained traversal could otherwise disclose an entire organization's decision, project and personnel structure. It is protected by a single enforced path:

• The graph driver may be imported in exactly one bootstrap module; all access goes through an organization-scoped session wrapper.
• The wrapper parses every query at runtime and rejects any that does not bind the organization on every node and relationship — including variable-length paths, which must carry an explicit predicate across the whole path.
• An automated code guard fails the build on any attempt to open a raw graph session outside the wrapper.
• Callers cannot submit graph queries. The query endpoint accepts only a closed set of named, parameterized patterns — no client-supplied query fragments, and no runtime string construction.
• Graph read endpoints apply the same workspace and sensitivity filtering as every other read path in the platform.

Machine-identity organization selection

Service credentials are organization-agnostic by design, so a background job selects the organization it is operating on per request. Selecting an organization requires a dedicated capability that is deliberately separate from any data-access permission — holding broad read permission does not confer the ability to choose which organization to read from. The two are independent, and both are required.

Beyond the organization boundary, the platform provides a finer in-organization boundary so personal, team, and department material can live inside a single organization yet remain invisible to other members. The organization invariant is unchanged: workspaces exist strictly inside one organization and can only narrow, never widen, what that organization's members can see.

Workspace membership is data, not a token claim. A caller's authorized workspace set is resolved server-side on every request from the membership registry — it is never asserted by the client, never carried in a token, and never resolvable by a service credential. Reading personal or team material requires a delegated user token.

Ownership travels with derived intelligence

A platform that analyzes content produces new records from it — signals, findings, graph entities, rollups. If those inherit only the classification of their source and not its ownership, private material can become organization-visible in derived form even while the original stays private. The platform treats this as a first-class design requirement rather than a downstream concern.

Activation

Managed-service providers, parent companies, investors and shared-services teams need visibility across the organizations they are responsible for. The platform supports this without weakening single-organization isolation, and the design deserves close review because it is the one place the platform deliberately spans an organization boundary.

Consent is the precondition

A relationship between a parent and a managed organization is a first-class, consented, auditable grant. It becomes active only after an owner or administrator of the managed organization consents, and only if that organization has enabled linking at all. Every state change — request, consent, decline, revoke — is audited and emits an event. Consent is granted by the organization whose data is at stake, never by the parent, and never by us.

What the parent actually holds

Cross-organization derived artifacts are records in the parent's own organization, protected by the parent's own policy like any other record, holding references as opaque identifiers plus minimal display metadata — a name, a type, a last-seen timestamp — whose refresh honors current access. Source content is never copied.

The consequence for isolation is the important part: a parent record is an ordinary single-organization record that references an identifier. Every read of the referenced content resolves through per-organization access at the time of reading. There is no server-side blending, and the graph remains strictly single-organization — a parent's graph holds link nodes referencing identifiers, never a copy of a managed organization's structure.

Credentials are bound to the relationship

Where a background process computes portfolio rollups, it uses a credential bound to one specific consented relationship, verified against that relationship being currently active — not a general cross-organization capability. The check is deny-by-default: no active relationship, no access. The process writes only into the parent; it never writes into a managed organization.

Revocation

Every capability class — linked graph, rollups, portfolio views, live spanning reads — is consented separately by the managed organization and enabled separately by the parent. All default to off. Consent to one class is never consent to another.

A dedicated authorization service owns the permission catalog, roles, and role assignments, and exposes an evaluation endpoint that every service consults. The permission catalog is append-only — permissions are never silently redefined — and built-in roles are protected at the database layer so they cannot be edited into something more permissive.

Sensitivity clearance is expressed as authorization scope: a caller's granted scopes determine which sensitivity categories they may read, and the shared filter takes that scope set as its input. This is why authorization correctness is load-bearing for content confidentiality, and why the filter is centralized rather than reimplemented per service.

Authorization answers may this identity touch this resource? Governance answers a different question that conventional access control does not address: may this AI workload run at all — at this cost, on this data, right now? A dedicated governance service is the platform's policy decision point; the model gateway is the policy enforcement point. Neither is optional, and both fail closed.

What governance decides

Policy surfaces & their defaults

The sensitivity filter is a single shared implementation used by every service. Reimplementing it locally is blocked by an automated guard that flags any code touching sensitivity data without using the shared filter — so the filter cannot drift or be quietly weakened in one service.

If clearance cannot be positively established, the record is excluded. The filter fails closed.

The classification service determines what is sensitive, and its result closes the gate that every downstream read depends on. Three independent stages run over each segment, behind a language gate.

A strict one-model-library-per-module rule isolates each model, keeping boundaries explicit and making a model replaceable without touching pipeline logic.

Reliability & deletion behavior

• Exactly-once semantics — work is reserved before processing, so a redelivered message is skipped rather than duplicated, and work held by another worker is returned to the queue rather than discarded.
• Durable publication — every event is written in the same transaction as the state change it describes and drained separately, so a state change and its notification cannot diverge.
• Deletion is ordering-independent — a deletion records a marker that suppresses any later-arriving work for that item, so a delayed in-flight message cannot re-materialize content you deleted.
• Replay-safe — reprocessing the full event history produces the same result as processing it live.

The audit service consumes durably from the platform event bus into an append-only store. Updates are prohibited outright, and deletion exists only within the retention process. Corrections are made by appending a new event, never by altering history — so the audit trail is evidentially sound rather than merely informative. Cross-organization audit access requires an administrative clearance and is itself audited.

What is audited

• Every authentication event and every authorization denial.
• Every administrative or cross-organization action, with a mandatory reason.
• Token issuance for an organization other than the user's home organization, with membership evidence.
• Every change to a cross-organization relationship.
• Every sensitivity-filtered read, retained for a 730-day minimum. The audit record is written in the same transaction as the response, so a read cannot succeed without being recorded.

Observability & operational resilience

Every service emits distributed traces carrying the organization identifier, structured logs carrying it on every request-scoped line, and health and readiness endpoints. Traces and logs never carry content or personal data — attributes are restricted to identifiers and counts, because the audience for telemetry is broader than the audience cleared for the content.

Software supply chain

Container images are built and signed in the pipeline, with a vulnerability scanning gate. Dependency updates are automated and grouped, with major-version changes held for explicit review. Build tooling is version-pinned rather than resolved at build time, so a build cannot silently take an unverified upstream change.

The platform maintains a formal threat model; every service inherits its mitigations and adds tests proving they hold. The classes most relevant to a security review:

The data plane is identical in both models. In our cloud, customers are isolated by the mechanisms in this document. On-premises, you run the same code for a single organization. The reference target is Kubernetes via a Helm chart with your own or bundled PostgreSQL, event bus, object storage, Vault and telemetry collector. Air-gapped deployment is supported: offline installation bundles, no outbound calls at startup, offline license validation, and telemetry that can be disabled with no loss of function.

Connected sources — a contained, opt-in exception

Connectors are the one place the platform deliberately speaks a third-party API. The exception is contained, not granted:

• Optional and off by default — the platform is fully functional with no connector configured, and air-gapped deployments cannot run external connectors at all.
• Confined to the edge — no core or data-plane service imports a provider SDK; the coupling cannot spread inward.
• Per-connection and consented — a provider you connect is a sub-processor of your own choosing, adding no default third-party dependency for anyone else.
• Credentials in Vault only, never in the database, logs, traces or events — verified by automated tests.
• Content re-enters through existing paths, inheriting classification, the sensitivity gate, isolation policy, per-read audit, and private-by-default ownership for email.
• Individual self-connection is configurable per organization; organization-wide connectors remain a privileged operation.

Data residency

Data services are configurable per region and per organization; data does not cross regions without explicit configuration; audit events record their region of origin; and for sovereign or air-gapped deployments telemetry can be configured never to leave your boundary.

Model processing & training

Standards alignment

A consolidated view, on two independent dimensions. Status answers whether the control is built and enforcing — nearly everything here is. Where it is enabled answers the separate question of scope: whether it applies everywhere by construction, or is activated for your organization, per capability, or by how the platform is deployed. We publish both because a security document that collapses them is less useful — and less credible — than one that is precise about each.

A control that is not verified automatically is a control that erodes. The platform's governing discipline is that every security rule has a matching enforcement mechanism that runs on every change — so a regression fails a build rather than waiting to be discovered.