Secure Folders — feature brief for pricing

Status: shipped and live on the demo (2026-08-07). Base switches are core; the
encryption tier is the licensed module securefolder.
Audience: whoever sets client pricing. This document states what was built, what it
costs to run, what it does NOT do, and where the commercial edges are. It deliberately
does not propose a price.

1. What the customer gets, in their words

Four levels of folder protection, chosen when the folder is created:

Preset	What the customer sees	Licensing
Standard	Today's behaviour. Access follows the parent folder.	Core
Restricted	Hidden from everyone who is not explicitly a member — not in folder lists, not in search, not by direct link (they get "not found", so they cannot even learn it exists).	Core
Secret	Restricted, plus opening it demands a fresh identity check (authenticator code or passkey) even from someone already signed in. One check opens secure folders for 15 minutes.	Core
Vault (encrypted)	Secret, plus every file is encrypted with a key belonging to that folder alone. A stolen disk, a leaked database dump or a stolen backup is unreadable. Every single decryption is identity-checked and written to the tamper-evident audit log; unusual decrypt volume alarms the security admins.	Licensed — `securefolder`
Private Vault	The key never leaves the member's browser — not even the people who run Obscura can open it. In exchange, nothing server-side works inside: no preview, no search, no AI, no signing. Lose every member's credentials and the contents are gone permanently.	Licensed — `securefolder`

The sales line that separates them: the first two protect against the wrong colleague;
the Vault protects against the stolen disk; the Private Vault protects against us.

2. What is actually enforced (so claims can be made safely)

Verified end-to-end against the live demo (21 automated assertions, plus object-level
inspection of the stored bytes):

Hidden means hidden. Non-members get no rows in folder lists, document lists,
full-text search, semantic search, or the AI assistant's retrieval — and a direct URL
answers 404, not 403.
The identity check has no exceptions. Administrators and the folder's own owner are
gated too. (The system's other admin bypasses deliberately do not apply here: the
question is "is this person physically present", which no role answers.)
Encrypted means encrypted on disk. Vault files are stored as age (X25519 +
ChaCha20-Poly1305) ciphertext in their own storage namespace. We confirmed by reading
the raw object out of storage: the plaintext does not appear anywhere in it.
Keys are layered. Each vault folder has its own key, itself encrypted by a
deployment key held in a file outside the database. A database dump alone unlocks
nothing.
Every decrypt is evidence. Each unseal writes securefolder.decrypt (who, which
document, why — preview/download/export…) into the hash-chained audit log. Volume
above a threshold notifies security admins — this is the control that catches an
insider copying a folder out.
The doors are all shut, not just the front one. Public share links are refused on
secure folders (and links created before a document was moved in go dark). API keys /
MCP integrations are refused, because an API key can never pass an identity check.
Rendered page images are never cached to disk for vault documents. Moving a document in
encrypts it and purges its old cached renders; moving it out decrypts it and deletes
the sealed copy.

3. What it explicitly does NOT do (say this before the client discovers it)

These are deliberate design decisions, already written into the product's own UI copy —
so the honesty is a feature, but it must be priced and pitched accordingly.

It does not protect against the operator of the server. The server holds the keys
in order to preview, search and seal documents. It defends stolen storage, database
dumps and backups. A client who wants protection from us / from their own IT needs
the Private Vault tier (§6).
Secure folders are not full-text searchable. Their content is never extracted or
indexed, so a document inside one is findable by title and metadata only — not by a
phrase in its body, and not through AI answers. This reverses an earlier decision, and
the reason is worth repeating to a client because it sells: indexing wrote each
document's text into the database in the clear, so the file was encrypted and its text
sat in plaintext beside it — a database dump read the vault with no key at all. The
index is now simply absent. (Sales note: this is a stronger story than the one it
replaces. The trade is real, though — say it plainly rather than let a buyer discover it
in a demo.)
Encrypted folders opt out of records retention/disposal schedules. They are outside
the archival lifecycle by design — the person creating one must tick an acknowledgment
saying so. Legal holds still apply. For an ANRI/JRA-driven buyer this is a real
trade-off to discuss, not a footnote.
Encryption is chosen at creation and cannot be switched on or off later. Existing
folders cannot be "upgraded" in place; content is moved into a new vault instead.
A folder cannot be moved across an encryption boundary (its documents can, one at a
time). This bounds an unbounded re-encryption job.
Lose the deployment key, lose every vault. Permanently. It is escrow-tooled, but it
is a real operational obligation on the customer.

4. What it costs to deliver (operational reality)

Per-deployment key file. Every environment needs one key file generated and escrowed
before its next deploy. Bootstrap generates it automatically; the deploy fails loudly if
it is missing (chosen over failing quietly). Existing customer environments (production
and the multi-tenant cloud) need this one-time step.
No new infrastructure. No HSM, no KMS, no extra container, no network dependency.
Encryption is in-process using a library already shipped. This keeps air-gapped and
on-premise deployments viable, which matters for the government/BUMN segment.
No measurable performance tier. Sealing/unsealing is streaming; the practical cost is
one extra pass over the bytes on upload/download. There is no per-document licence
metering, no per-decrypt cost, nothing to meter or resell by volume.
Storage: vault files do not deduplicate against identical plaintext copies elsewhere
(that is the point — dedup would leak existence). Slightly more storage where the same
file exists inside and outside a vault.
Support burden: the predictable tickets are (a) "I lost my authenticator and cannot
open the folder", (b) "why can't I share this document by link", (c) "why is this folder
missing from the retention report". All three are working-as-designed.

5. Licensing mechanics (how it is switched on and off)

Module name in the licence file: securefolder. It sits alongside
correspondence, watermarking, ai, esign, office, klasifikasi — the seventh
module.
Enforcement is at folder creation: unlicensed, the Vault preset is not offered in the
UI and the API refuses module.not_licensed. The three base presets stay available to
every customer.
It is a per-deployment entitlement, not per-seat and not per-folder. A licensed
customer may create unlimited vault folders. If a seat-band or volume-band model is
wanted, note that licence seat counts are currently display-only and not enforced
anywhere in the product — that has to be built before it can be sold.
Existing customer licences do not include it. Production and every cloud tenant need
a reissued licence to sell this. The demo licence has been reissued already.
Downgrade behaviour is worth deciding commercially: today, if the module lapses, existing
vault folders keep working (the server can still decrypt them) but no new ones can be
created. If lapse should hard-lock existing vaults, that is a product decision, not a
bug.

6. The higher tier and the governance controls — now BUILT

Both of the items this document previously listed as roadmap have shipped. They change
what can be sold and to whom.

Private Vault (`e2ee`) — the second encryption tier

Keys are generated and held in the member's browser; the server stores ciphertext it
cannot decrypt. This is the tier that answers "protect it from the vendor and from our
own IT." Unlocking is a passkey (Face ID / Windows Hello, via WebAuthn PRF) with a
passphrase fallback for browsers or security keys that cannot do PRF.

The price of that protection is severe and must be priced with it — inside such a folder
there is no preview, no search, no AI answers, no e-signing or e-Meterai, and no
recovery whatsoever if every member loses their credentials. Break-glass does not exist
for it and cannot: nothing server-side can open it. The product states all of this at
creation, behind a typed acknowledgment.

Commercially it sits inside the same securefolder module (the owner's decision) as a
fifth folder preset, so it is a reason to buy the module rather than a separate SKU —
unless pricing decides otherwise.

Break-glass, admin visibility, orphan hygiene (at_rest only)

Two-person emergency release: one administrator requests with a typed reason, a
different administrator approves, the grant expires in 60 minutes, only the requester
can use it, and the folder's owner plus every security admin are notified at both steps.
Every state change is on the tamper-evident audit log. This is the procurement answer to
"what happens when the vault owner leaves?"
Secure-folder inventory for security admins: every secure folder with its tier,
owner, member count, last unlock, 7-day decrypt count and any live emergency release —
counts only, never document titles.
Storage hygiene: encrypted objects are reference-counted per namespace and a daily sweep
reclaims strays.

Permissions worth naming in a proposal

Two privileged permissions gate this feature, and they can be held by different people:
folder.secure (create and manage secure folders — including vaults) and
folder.break_glass (request or approve an emergency release). Neither is granted by
default.

7. Positioning notes

The base tier (Restricted/Secret) being core, not paid, is a deliberate
give-away: it makes every deployment better and it makes the encrypted tier the only
thing there is to buy. Worth keeping in mind if bundling is being considered.
The strongest demonstrable claims, in order of how well they demo: (1) the folder is
invisible to a non-member, live, side by side; (2) the raw file pulled straight out of
storage is unreadable ciphertext; (3) the audit log showing who decrypted what and when;
(4) the volume alarm.
The compliance framing that fits Indonesian buyers: this is a technical control
supporting UU PDP obligations over sensitive personal data (encryption at rest, access
logging, least privilege, presence verification). It is not a certification and must
not be sold as one — the same discipline docs/COMPLIANCE.md applies to ISO claims.

Product state as of 2026-08-07: P1 (switches), P2 (at_rest vaults), P3 (Private Vault) and
P4 (break-glass, inventory, hygiene) are all shipped and verified on the demo.
Implementation detail: docs/superpowers/specs/2026-08-07-secure-folders-design.md (the
contract) and the P1–P4 plans beside it; scripts/securefolder-e2e.sh +
scripts/securefolder-vault-ui.cjs are the executable proof.