SigmaEra for Risk & Compliance

Prove how AI is being used here. Right now.

SigmaEra is the enterprise AI orchestration platform — the control plane that makes every AI interaction in your organization logged, attributable, and defensible.

Request a demoSee how it works
From questionnaire to evidence

Everything you will be asked to prove, and what proves it.

The arc a risk or compliance leader walks with SigmaEra: the questions you will be asked by regulators, customers, and your own auditors — and whether the answer is a document or a query.

  1. 1The policy gap

    Your AI policy is a document nobody can enforce

    There is a policy. It says employees should not put confidential material into external AI tools. You have no way to know whether it is being followed, and no way to prove it either way.

    What you have to answer

    • Is the policy enforceable, or only publishable?
    • What is actually happening today, as opposed to what is permitted?
    • How would we detect a breach of it?

    The layer that answers it

    Policy as configuration

    Handling rules are configuration rather than prose: each sensitivity category is set to index-and-gate, withhold from the index, or redact, with the most restrictive defaults reserved for board material and highly-confidential matters.

    Every isolation decision fails closed

    Live, test-pinned

    Unset tenant context returns zero rows. Unset scope context returns zero rows. An unclassified document is not yet visible. Unestablished clearance excludes the row. A missing budget denies the run. A config read failure degrades scopes to org-only.

    White paper — Security design principles

    What changes for you

    The policy stops being a document you circulate and becomes a control that runs, with a record of what it did.

  2. 2The incident question

    Who did what, and can you show it

    Something surfaces — a leaked figure, a disputed decision, a complaint. You need to reconstruct who had access to what and when, and you need it to stand up to challenge.

    What you have to answer

    • Is there a record of every access to sensitive content?
    • Can the record be edited by anyone, including us?
    • How long is it retained, and by what rule?

    The layer that answers it

    Append-only audit

    Updates to the audit table are forbidden and deletion is restricted to a retention worker; corrections are made by appending a new event, never by altering history. The audit record for a filtered read is written in the same transaction as the response, so a read cannot occur without it.

    Reads of sensitive content are audited in the same transaction

    Live, test-pinned

    Append-only audit table with UPDATE forbidden and DELETE permitted only to the retention worker. Every authentication event, authorization deny, cross-tenant admin action, and sensitivity-filtered read is recorded, with a 730-day minimum retention on intelligence reads. The audit event for a filtered read is emitted in the same transaction as the response.

    White paper — Audit & observability

    Logs and traces carry identifiers, never content

    Live, test-pinned

    One service is permitted to persist detected-PII position data; every other consumes only the derived tag set. PII text is excluded from logs, traces, and event payloads platform-wide, verified by a per-service adversarial log-output test. Trace attributes are restricted to IDs and counts.

    White paper — Audit & observability

    What changes for you

    Your evidence is contemporaneous and tamper-evident, rather than reconstructed afterwards from logs that were never designed to be evidence.

  3. 3The DSAR

    A subject-access or erasure request arrives

    Someone exercises their rights. You have thirty days, the data is spread across transcripts, documents, and everything derived from them, and "we deleted the original" is not an answer.

    What you have to answer

    • Can we find every appearance of one individual?
    • When we delete a source, does the derived intelligence go too?
    • What happens to a deletion if a message arrives late?

    The layer that answers it

    Lifecycle and erasure cascade

    Subject-access cascades by participant label and reaches derived intelligence through provenance back-links. Deletion propagates from source through classifications, entities, signals, findings, and reports, and tombstones suppress late-arriving derivation events so erasure is ordering-independent.

    Deleting a source retracts everything derived from it

    Live, test-pinned

    Deletion cascades from source to classifications, entity references, signals, findings, and reports, pinned by a cross-service invariant test. Tombstones recorded on the delete event suppress later-arriving derivation events, making erasure ordering-independent. Each service declares a tenant-purge SLA, with a reconciliation job that flags stragglers.

    White paper — Data lifecycle & your rights

    What changes for you

    Rights requests become a defined procedure with a verifiable end state rather than a manual hunt you can never fully certify.

  4. 4The questionnaire

    A customer sends you their vendor assessment

    Two hundred questions arrive, half of them about your sub-processors and your AI posture. Every answer you give becomes a contractual representation.

    What you have to answer

    • Which third parties see content, in which configuration?
    • What can we assert about certification, honestly?
    • Where are the limits of what we should put in writing?

    The layer that answers it

    A published, honest posture

    A platform security white paper that states plainly where content goes in each deployment mode, and that no certification is claimed against SOC 2, ISO 27001, or HIPAA — describing control coverage as evidence rather than as a certificate.

    Keeping content away from third-party models

    Partial

    Sensitivity classification routes by default to a cloud model, so in the default SaaS configuration content reaches a third-party LLM sub-processor. Overriding the model to a local one keeps content in-boundary; whether any cloud provider is reachable at all is a per-deployment key configuration. The classifier sends only content plus structural metadata and receives a schema-validated tag set.

    White paper — Deployment, residency & sub-processors

    Cross-tenant access holds no privileged credential

    Live, test-pinned

    The parent view never holds a credential that reads children. There is no service-side spanning read path: every spanning read resolves through the requesting user’s own per-child membership and scope grants at read time, gated by a consent state machine with defined revocation semantics.

    White paper — Multi-organization access

    What changes for you

    You answer from a published document rather than improvising, and you never sign a representation the architecture cannot support.

  5. 5Ongoing

    Staying defensible as it grows

    Adoption spreads, new teams onboard, new content types arrive. Your exposure changes continuously and your last assessment is already out of date.

    What you have to answer

    • Does control coverage keep pace with adoption?
    • What changed since my last review?
    • Will I be told when something material moves?

    The layer that answers it

    Continuous compliance evidence

    Evidence assembles as the platform runs rather than being gathered for an assessment, and control maturity is published as a register — including a change log of what moved since the previous revision.

    What changes for you

    Your assessment stops being a snapshot that decays, and audit preparation stops being a project with its own timeline.

Control register

8live and test-pinned

1built, switched off

1partial

Read the full security white paper

Every layer above is documented there in full, including the threat model and the control-status register.

Where your data goes

Two deployment models. One data plane.

The honest version, including the parts that need a configuration decision from you rather than a promise from us.

SaaS

Pool isolation. Fastest to stand up.

  • Tenant isolation enforced by database Row-Level Security
  • Object storage encrypted at rest; service holds metadata only
  • Regional configuration per tenant; audit events record region of origin
  • Sensitivity classification routes to a third-party cloud model by default — override to a local model for a fully in-boundary posture
  • Optional external connectors are the one place vendor APIs are spoken, and are off by default

On-premises / air-gapped

Silo isolation — pool with N=1. The same data plane, not a fork.

  • Identical code path; the data plane does not branch on deployment mode
  • No outbound calls at startup; offline licence validation
  • Your own Vault, Postgres, object store, and identity provider
  • Telemetry is opt-out with no degradation in function
  • Local model in the gateway keeps content fully in-boundary
  • Edge services — external connectors and billing — are never shipped on-premises

Amber marks a constraint or a decision you own, not a defect. A strict content-stays-local posture is achievable and is the on-premises target — it is configuration, and it should be confirmed per deployment rather than assumed.

Further controls

Everything else the review will ask about.

Controls beyond those covered in the walkthrough above, in the same format: what it guarantees, how it is enforced, and its current status.

3 live · 1 built but gated · 0 partial

Tenant isolation is enforced by the database, not by application code

Live, test-pinned

A query written incorrectly cannot return another organization’s rows. The isolation does not depend on every developer remembering to add a filter.

How it is enforced

Every domain table carries tenant_id NOT NULL under Postgres Row-Level Security with FORCE ROW LEVEL SECURITY, keyed on a transaction-local GUC. A privilege split means the runtime role cannot bypass RLS, a boot-time assertion refuses to start in production if a service connects as a superuser or BYPASSRLS role, and CI fails any migration that creates a domain table without RLS.

White paper — Tenant isolation

The tenant claim is verified against live membership at every mint

Live, test-pinned

A token cannot assert a tenant the user does not currently belong to — checked at every code exchange and every refresh, not just at first login.

How it is enforced

The issuer computes an eligible set from live membership data and mints the tenant claim only for a tenant in that set, re-verifying at every exchange and refresh and failing closed to invalid_grant — never to a different tenant. One tenant per token is an absolute invariant; there are no multi-tenant tokens.

White paper — Identity & tenancy

The same data plane runs air-gapped

Live, test-pinned

Deploying inside your own boundary is not a fork, a port, or a roadmap item — it is the same code path, with no outbound calls at startup.

How it is enforced

A must-follow rule forbids cloud-vendor-locked primitives in the data plane: S3-compatible storage, OIDC, SMTP, Vault, OpenTelemetry, PostgreSQL, NATS JetStream. CI rejects forbidden cloud SDK imports and an air-gap startup test asserts services reach readiness with no external DNS resolution. Offline licence validation; telemetry is opt-out with no degradation.

White paper — Deployment, residency & sub-processors

In-tenant workspace isolation

Built, gated off

Private and team content stays separated from colleagues inside the same organization — the mechanism is built and proven, and is deliberately not switched on yet.

How it is enforced

Scope labels enforced by an AS RESTRICTIVE RLS policy AND-ed beneath the tenant policy, so it can only ever narrow visibility and fails closed on unset context. Committed across eleven services. Derived artifacts inherit their evidence’s scope, most-restrictive-wins, and never default to organization-wide.

White paper — Workspace isolation

Read the full security white paper

Including the threat model, the trust-boundary architecture, and a control-status register that names what is on the roadmap rather than shipped.

The full SigmaEra platform, for Risk & Compliance

Beneath the controls, the platform itself.

The five capabilities every SigmaEra deployment runs, read through the lens of this role.

Five stages · Protect → Emerge
  1. 01

    Protect

    PII and privileged material are classified and contained before any model sees them.

  2. 02

    Orchestrate

    One governance layer spans every AI interaction — Trust Ladder permissions, retention policy, and jurisdictional controls applied consistently.

  3. 03

    Automate

    Compliance evidence assembles continuously, so audit preparation stops being a project with a deadline.

  4. 04

    Compound

    Policy precedent accumulates — the platform learns your risk posture and applies it the same way every time.

  5. 05

    Emerge

    Exposure surfaces before it becomes an incident, rather than during the disclosure review afterward.

The Compound Effect

Intelligence that builds on itself.

100%
of AI interactions governed — every call through one policy enforcement point, with a full audit trail.
Source: Platform security white paper — Governance & AI policy
48h
to full AI governance — from shadow AI discovery to unified control plane.
8
must-follow platform standards, each with a named enforcement gate in CI — control coverage mapped to SOC 2, GDPR and HIPAA expectations.
Source: Platform security white paper — Standards alignment
In Practice

What this actually looks like.

Sensitive data classified before it left the perimeter

  1. 1

    Meeting Summarizer

    Input & Translation

    Ingests meeting recording — every model call routed through the governed gateway, to an in-boundary model where the deployment requires it

  2. 2

    Security Sentinel

    Enterprise Intelligence

    Flags 3 mentions of unreleased product roadmap and one instance of customer PII in meeting transcript

  3. 3

    Compliance Auditor

    Intelligence & Analysis

    Cross-checks flagged content against GDPR and internal data handling policies — risk level: High

  4. 4

    Ethics Guardian

    Meta-Intelligence

    Validates that automated response stays within approved governance boundaries before any action is taken

  5. 5

    Compliance Historian

    Meta-Intelligence

    Logs complete incident record with evidence chain — immutable audit trail ready for regulatory review

Every AI interaction governed through one policy enforcement point — with a full audit trail of every sensitivity-filtered read.

Stop leaking data. Start compounding intelligence.

See How Legal Teams Use SigmaEra

  • Runs air-gapped inside your own boundary
  • Full audit trail on every interaction
  • 100 agents, one control plane
Request Demo
Related problems

Shadow AI & data exposure

Company data is going into tools we don’t control.