[ Security ]

Denied by default.

Every access decision is evaluated by policy, denied by default, and recorded with its reasons. An explicit denial always overrides a grant, and when a dependency fails, Tabellix fails closed.

Talk to us Platform hardening

01 Policy as code

Every decision has a reason.

Access rules are code in the signed configuration release, reviewed as a diff and approved by people other than the author. Each decision carries the reasons that produced it.

Deny by default

Nothing is allowed unless a rule allows it. A policy error denies instead of guessing.

Denials win

Rules are named permits and forbids. A forbid always overrides a permit, and a time-limited grant on an object never lifts a forbid.

Decisions with reasons

Every decision carries the reasons behind it, so a refusal can be explained and an allowance can be audited.

Rich attributes

Rules decide on the person and their roles, the action, the type, the creator, the version and its state, the cases an object belongs to with their access fields, active grants, and an open break-glass session.

Tested before it ships

Policies can be checked and their decisions tried offline, before a release is submitted for approval.

No self-approval

An author cannot approve their own work, and the refusal is recorded.

02 Hidden existence

Hidden records stay hidden.

A person who may not see a record cannot tell that it exists. Lists, search, counts and error messages treat hidden and missing the same way.

Hidden and missing look identical

The same answer, the same error, the same shape, whether the record is hidden or was never there.

Authorization inside the query

Read rules are translated into the database query itself, so search, lists, folder items and link lists return complete pages of exactly what the person may read.

Nothing leaks through counts

Because filtering happens in the query, results, counts and paging reveal nothing a person may not see.

Refused if it cannot be filtered

A configuration release whose read rules cannot be applied inside the query is refused, rather than filtered after the fact.

Logs keep the secret too

The security event stream and the denial records never name the hidden object or the policy text.

Folders never grant

Navigation folders never grant access, listings hide what the reader cannot read, and a folder can itself be restricted.

03 Identity

Your identity provider, our rules.

People sign in through any OIDC provider and are provisioned over SCIM 2.0. Roles are defined in Tabellix and assigned from your directory groups.

Separate issuers

Company staff, invited outside accounts and optional vendor support each come from their own issuer. The server refuses to start if the support issuer is the company's.

Audiences kept apart

Tokens for the company surface, the outside-recipient surface and MCP must name different audiences, and a token for one is refused by the others.

Provisioned and disabled

SCIM pre-provisions people, binds the first sign-in, maps directory groups to roles, and disables accounts without deleting their history.

Fresh sign-in for what matters

Signatures, redaction approval, erasure and break-glass require an interactive sign-in inside the deployment's window.

Service principals

Systems that capture records authenticate as listed integration clients, never as a person. A token with an empty subject is refused.

Accounts for outsiders

Invited external accounts are trusted on the recipient surface only, and a second factor can be required from their provider.

04 Content protection

Encrypted per object, checked on every read.

Every stored file is its own encrypted content object with its own key, and its digest is checked every time it is read. Personal data about each person sits under that person's own key.

A key per content object

Each file is encrypted with its own data key, held under a key manager the database cannot use.

A key per person

Personal data about each person that records concern is encrypted under its own key, so it can be erased by destroying that key.

Integrity on every read

The digest is checked on every read and re-verified on a schedule. Damaged content is never served again.

Encrypted in transit

TLS 1.2 and 1.3 with modern suites, or an encrypting service mesh you declare. Every client verifies its server, and a process with an unencrypted link does not start.

FIPS 140-3 cryptography

Cryptography runs in FIPS 140-3 approved-only mode, with ECDSA P-256 for signatures and licenses.

Safe downloads

Files are served as attachments with headers that stop browsers from running active content, and every download is logged before its first byte.

Privacy and retention

05 Malware scanning

Scanned before anything else.

Every stored file is scanned for malware before it is converted, indexed or served. Infected content stays encrypted, every read of it is refused, and it is never converted, indexed or served.

uploadacceptedencrypted at rest

scannerscansyour clamd or ICAP

verdictclean onlyfrom an explicit answer

contentconverted, indexedand served

Clean means clean

A file counts as clean only when the scanner explicitly says so. A scanner that is down releases nothing.

A limit is not a verdict

A file that hits a scanner limit is an incomplete scan, never reported clean. Uploads larger than the scanner can scan are refused before they start.

Publishing waits for a clean scan

A lifecycle transition can require a clean scan, and a scheduled publication checks again when it fires.

Hostile files refused

A file that is not what it claims to be, or a hostile document, is refused when it is committed. Encrypted files are refused by default.

Agents notice too

An agent that reads unscanned content loses session trust, which narrows what it may write.

Your scanner

Any clamd service, or any ICAP service following RFC 3507, supplied by the deployer.

06 Isolated helpers

Untrusted files meet isolated services.

The built-in converter, the renderer and the text extractor run as separate, isolated helper services with no network egress, so a hostile file has nowhere to go.

No credentials, no egress

The built-in converter carries no credentials and cannot reach the network. The renderer and the extractor run isolated the same way.

An isolated rasterizer for redaction

Redacted copies are produced as image-only PDFs by an isolated rasterizer, reached over mutual TLS, so no text survives under a redaction.

Refuse what it cannot render

The converter refuses documents with constructs it cannot render faithfully, such as tracked changes, and the refusal happens before storage.

Fuzzed parsers

Upload metadata, webhook and MCP payloads, policy bundles, scanner replies, share addresses and content checks are fuzzed.

07 Break-glass

Emergency access, always reviewed.

When someone needs access they do not normally have, break-glass gives it for a limited time, on the record, and under review.

Enabled by the deployer

Break-glass exists only where the deployment profile allows it.

Justified, fresh sign-in

Opening a session requires a justification and an interactive sign-in.

Time-limited and alerted

The session ends on its own clock, and opening it raises an alert.

Reviewed, every time

A built-in review record and workflow follow every session, and each access in it is logged with the session.

08 External access

Outsiders get scope, not seats.

Inspectors, auditors and counterparties get scoped, expiring, watermarked access without a user seat, and you get a report of everything they fetched.

Shares that follow the sharer

A share never serves more than the sharer may still read, checked on every page. Shares expire, can be revoked, and can require an agreement before any content.

Inspector sessions

Read-only access for a regulator or auditor: fixed in scope, at most 72 hours, the opener's own access asked again on every serve.

Watermarked by default

Recipients see watermarked page images by default, with downloads only where allowed.

A surface of their own

Outside recipients use a separate surface with sessions of their own, apart from the staff API.

Vendor support, by approval

Off by default. A vendor's support session is bounded, time-limited, approved by the company with a fresh sign-in and never by the requester, and every read lands on the company's own access log first.

Sharing is a person's act

Creating, widening or ending a share or an inspector session is never an agent's act under the regulated preset.

Disclosures and sharing

09 Isolation

One company, its own everything.

Each company is provisioned with its own database, encryption keys, storage and audit trail.

Its own database

A dedicated database per company, in its own namespace, with dedicated application and worker processes.

Its own keys

A key namespace per company in the key manager, with keys the database cannot use.

Its own ledger

A company's history is chained and sealed on its own, and verifies without anyone else's.

10 Platform hardening

Hardened down to the image.

Tabellix runs on your Kubernetes under the strictest standard pod profile, behind default-deny network policy, from images that contain one static binary and nothing else.

Minimal images

Each image is one static binary, running as a numeric user on a read-only root file system.

Pod Security restricted

Every workload meets the Kubernetes restricted profile, checked live by an installation check.

Default-deny network

Network policy denies by default and allows each workload only what it needs, including the helpers.

Admission in deny mode

Admission policies refuse root, missing seccomp, writable roots, added capabilities, host ports and host processes, and check image signatures.

Security events out

Authentication failures, policy denials and rate refusals leave as OpenTelemetry logs over TLS, with no tokens, content or hidden names, and an outage of your collector does not slow requests.

Precise outages

An unavailable dependency answers with a reason and a retry time, and readiness reflects what each role needs. Policy errors fail closed.

11 Supply chain

Verified offline. Never calls home.

Tabellix ships as binaries with signed software bills of materials. Licenses are verified offline, release verification needs no network, and the software never contacts the vendor.

Signed SBOMs

CycloneDX and SPDX bills of materials, signed and bound to the image digest, with an image vulnerability scan and a known-vulnerability check in the build gate.

Offline release trust

Release verification is built for air-gapped sites: checksums and signatures are checked with no network, against a key fingerprint the customer types in.

An offline license

The license is signed and checked before any of it is read, never blocks reading or exporting existing records, and needs no connection to the vendor.

Air-gappable by design

No cloud-provider dependency in the core and no phone-home, so it is built to run in air-gapped networks.

Binaries only

Tabellix never ships its source, its CI or its development environment, and a tool checks every shipment against an allowlist.

Permissive dependencies

Every shipped and mirrored component passes a license policy check, and the notices are generated.

Deployment and releases

12 FAQ

Questions from security reviews.

Can a person tell that a record they cannot see exists?

No. Hidden and missing records look identical in lists, search, counts, errors, the security event stream and the denial records.

What happens when the malware scanner is down?

Nothing new is released. A file is converted, indexed or served only after the scanner explicitly answers clean, and infected content is kept encrypted with every read refused.

Does the vendor have access to our data?

Vendor support access is off by default. When a deployment enables it, each session is requested by the vendor, approved by the company with a fresh sign-in, bounded in time, and every read is written to the company's own access log before it happens.

How is emergency access controlled?

Break-glass is available only where the deployment allows it. It requires a justification and a fresh sign-in, ends on its own clock, raises an alert, and is always reviewed afterward.

Does Tabellix need an internet connection?

No. Licenses are verified offline, release verification needs no network, the core has no cloud-provider dependency, and the software never calls home.

[ Contact ]

Send us your security questionnaire.

Tell us what your security team needs to see. We'll answer with how Tabellix decides, hides, encrypts and records.

Talk to us Tabellix Cloud early access