Cloak File · protected-file workflow

Protect the file.
Bound the agent's authority.

Embed sensitive-file protection into an AI workflow without giving the agent a permanent key. A human defines the policy, Cloak File protects the data, Cloak KMS controls the permitted key operation, and a signed receipt records the result.

See the workflow ↓

Use this when an agent touches customer documents

Especially when a production launch or enterprise security review needs answers.

Tenant separation

Bind file and key operations to the correct customer boundary.

Revocable agent access

Expire or revoke a credential without rotating a raw key out of agent prompts or code.

Portable evidence

Return a signed receipt so another system can verify the recorded operation.

How Cloak Files works

Encryption without changing your workflow. It fits around the tools you already use.

1

Select any file

Right-click any file in Windows Explorer, Finder, or your mobile file picker. Or drag into the Cloak desktop app. Any file type — PDF, Excel, Word, image, archive.

2

Set a policy

Choose who can open the file (by email), what they can do (read-only, download, print), and for how long. Policies are enforced by Cloak's key server — not by the file itself.

3

Encrypt and share

The encrypted file is safe to send via email, Dropbox, USB, or any channel. Keys never travel with the file. Recipients need the Cloak app to open it.

4

Receive a signed receipt

Every encrypt, decrypt, share, and revoke operation returns a signed JSON receipt. Collect them for your audit trail. Verify any receipt at verify.cloakapps.com — no login needed.

5

Revoke any time

Change your mind? Revoke access to a file from the console or via API. The recipient's Cloak app will deny the next open — even if they already have the encrypted file on their machine.

6

Review your audit dashboard

The console shows every file operation: who encrypted what, when each recipient opened it, and any access denials. Filter by client matter, date range, or file type.

What makes Cloak Files different

Password-free encryption

No shared password to remember or lose. Keys are managed by Cloak's key server and tied to identity. Lose your device — not your files.

Cryptographic audit receipts

Every operation returns a receipt signed with Cloak's ECDSA private key. Verifiable offline. Present in a regulatory review or dispute without calling Cloak.

Remote revoke

Revoke a file's decryption key from the console at any time. The next open attempt fails — on any device, anywhere. No need to retrieve the file.

Time-limited access

Set an expiry date on any file policy. Access auto-revokes at midnight on the last day — no manual action required. Useful for draft deliverables and time-sensitive disclosures.

Compliance-ready dashboard

The console shows a full operation log per file, per user, and per client matter. Export as CSV or JSON for PDPA, GDPR, or internal audit.

REST API + MCP tools

Automate file protection in your existing workflows. Or wire it to an AI agent via MCP — protect files autonomously with human-authorized policies. No SDK lock-in.

Agent-ready · human-granted scope

Give agents a protected-file operation, not a permanent key

The protected-file integration is designed for MCP-compatible agents and application workflows. The human administrator grants the scope first; the agent receives an operation result and receipt, not the underlying private key.

Policies are human-authorized upfront. The agent operates within the policy boundary and cannot escalate its own permissions. Every agent action appears in the same audit log as human actions.

  • protect_file — encrypt with policy
  • decrypt_file — retrieve plaintext
  • create_receipt — generate signed audit receipt
  • verify_receipt — confirm receipt authenticity
  • revoke_access — remote revoke by key reference
Read the agent integration guide →
agent_workflow.py
# Agent calls protect_file via MCP
result = mcp.call_tool(
  "protect_file",
  {
    "file_path":  "./client_financials.xlsx",
    "policy": {
      "recipients": ["alice@firm.com"],
      "permissions": "read-only",
      "expires_at":  "2025-12-31"
    }
  }
)

# Every call returns a signed receipt
receipt = result["receipt"]
# → { operation, actor, file_hash,
#     key_ref, timestamp, signature }

Available on the web and mobile today

Encrypt and open protected files in the browser, on Android, and on iOS. Desktop apps (Windows / macOS) are coming soon.

All apps are free to download. A paid account is required to encrypt files.

Built on Cloak KMS

Every protected file is rooted in a KMS key

Cloak Files does not store file keys next to the file, in the app, or in the agent. Each protect and each open is a scoped key operation performed by Cloak KMS inside the configured key boundary — a SoftHSM software token in the sandbox, or a hardware HSM in BYO and hosted custody paths.

1 · Protect

File key wrapped by a KMS masterkey

The per-file encryption key is wrapped for each recipient using their account masterkey — ECDH key derivation for ECC identities, RSA-OAEP for RSA. The masterkey itself stays inside the KMS boundary.

2 · Open

Every open is a live key operation

Opening a protected file requires a fresh unwrap by KMS under the recipient's identity and the file's policy. No standing key travels with the file — which is what makes remote revoke real, not best-effort.

3 · Govern

One credential model for humans and agents

Agents get the same KMS-scoped, TTL-limited, revocable credentials that back the file tools. Revoking the credential or the key stops the agent — no key rotation out of prompts or code.

Why the integration matters

  • One authority chain. File policy and key operation are enforced together: the agent receives the operation result, never the file key or the masterkey.
  • Revocation enforced at the key layer. Because decryption always calls KMS, revoking access denies the next open even for copies already on a recipient's machine.
  • Custody upgrade without a workflow change. The same protect / open / revoke calls run against a SoftHSM sandbox token or a hardware HSM — only the key boundary changes.
  • Evidence on both layers. File operations return signed receipts in supported workflows, and KMS records the credential scope behind each key operation.
HSM keys

When the masterkey must live in hardware

In hardware custody paths, the masterkey that wraps your file keys is generated inside a PKCS#11 HSM — smartcard HSM, YubiHSM 2, AWS CloudHSM, or a customer-controlled device — and is non-exportable by design. Wrap, unwrap, and signing run inside the device; Cloak Files only ever sees the operation result.

Start in the SoftHSM software sandbox, then move regulated file keys to managed hardware (capacity-limited) or your own HSM after a compatibility assessment. The file workflow, API, and MCP tools stay the same.

Explore Cloak KMS custody paths →

One path from sandbox to production custody

Evaluate with software keys. Use the Managed Key Custody for production. Connect customer-controlled hardware when ownership of the root trust is a requirement.

See plans and custody paths →

Start protecting files in the sandbox

Free account. 50 file operations included. No credit card. Full API and MCP access from day one.

Create free account →

Preview: the 15-minute protected-file quickstart — agent encrypts, you open it in the browser, receipt verified.

Governed by the OMMAU Charter — humans authorize, agents execute, receipts record supported actions.