Sindook Steward

Threat-aware access and key-rotation planning for encrypted files

Comment

Why I built it

I created Sindook, my public open-source file-encryption project, before starting this workbench. I chose the name because sindook is the Bengali word for a strongbox. For me, it describes the purpose better than a generic AI product name.

Sindook can change who has access to an encrypted file in two ways. A fast rotation updates the recipient header without decrypting the payload. A deep rotation creates a new file key and re-encrypts the payload. The difficult part is not running either command. It is deciding which one is honest for the situation, understanding what it can prove, and stating what it cannot undo.

I built Sindook Steward for that decision layer.

What it does

Sindook Steward is a local workbench for four access events: adding a recipient, routine key hygiene, removing a recipient, and responding when an old ciphertext copy may have escaped.

The workflow is deliberately reviewable:

  1. Describe the access change and the threat.
  2. Let GPT-5.6 classify a small set of risk signals.
  3. Check that classification against deterministic policy.
  4. Review the exact recipients, cost, guarantees, and remaining risk.
  5. Type the literal approval ROTATE.
  6. Execute a pinned Sindook v0.3.0 binary against a disposable sample vault.
  7. Inspect an evidence ledger showing what changed.

The demo begins with Bob leaving, where a fast rotation removes his current recipient slot. It then adds one important sentence: Bob may still have an older encrypted copy. GPT-5.6 recognizes the stronger threat, and the policy engine upgrades the plan to deep rotation. The interface still says the uncomfortable but important truth: no new operation can erase a historical copy that somebody already kept.

What was new for Build Week

Sindook came first and remains a separate public repository. I treated its pinned CLI and file format as the upstream base.

Sindook Steward is the new Build Week project. I created the Go service, deterministic policy engine, React workbench, sample vault, approval flow, proof ledger, tests, Docker judge path, threat model, and submission evidence for this project. The repository includes a dated baseline and commit history so judges can distinguish the underlying encryption tool from the new Steward work.

How Codex helped me

I used Codex throughout the main build, especially for coding and debugging. It helped me turn the first concept into a working Go and React application, implement the planner and execution boundaries, write adversarial tests, debug integration problems, package the project with Docker, and verify the finished experience in the browser.

The most useful collaboration was not producing more code. It was challenging security claims. Codex helped me find places where the interface could accidentally promise too much, such as describing fast rotation as constant-time or implying that removing a recipient slot revokes an old copy. I kept the final product decisions: deterministic policy is authoritative, the model never executes a command, real secrets stay outside the model boundary, and every plan shows its residual risk before approval.

I used ChatGPT Work for the surrounding submission work, including research, organizing documentation, reviewing visuals, and editing the demo video. I checked the final statements against the actual code, tests, and recorded demo.

The role of GPT-5.6

GPT-5.6 Sol powered my main Codex build session and also has a narrow, meaningful role inside the product.

At runtime, it interprets a short natural-language request and returns typed signals for the scenario, risk, and whether the stated goal is achievable. It receives recipient aliases, sample metadata, and fixed policy facts. It never receives vault keys, passphrases, plaintext, or ciphertext contents.

GPT-5.6 cannot choose the final recipient list, select an executable command, or write the security guarantee shown to the user. A strict schema and deterministic validator control those decisions. If the model is unavailable, times out, returns invalid data, or disagrees with policy, the application falls back to deterministic behavior.

This role is intentionally small. Language understanding is useful at the point where an operator describes an ambiguous threat. It is not a substitute for cryptographic policy.

Challenges and lessons

The hardest part was keeping every claim precise.

  • Fast rotation avoids payload decryption and re-encryption, but Sindook still copies the complete file. The workbench reports O(file size) I/O and temporary storage.
  • Removing Bob's current slot proves only that the supported current-header path is gone. It does not prove he forgot plaintext or deleted an old key.
  • Deep rotation protects the replacement file with a fresh key and nonce. It cannot reach backward and erase copies already held elsewhere.
  • A language model can help interpret intent, but it should not be the authority for encryption or access control.

These limits made the product stronger because they forced the interface to explain the real boundary instead of presenting a more impressive but false promise.

How to try it

The judge path uses Docker Compose and a synthetic sample vault:

make up

Then open http://127.0.0.1:8787. No OpenAI login, API key, or real encrypted file is required for the deterministic judge path. The repository also documents the supported platforms, threat model, GPT-5.6 boundary, and exact test commands.

What's next

Before this could handle real files, it would need an external security review, production key management, identity-key replacement, signed or exportable proof records, and broader platform testing. For Build Week, I kept the scope intentionally narrow: a working local prototype that demonstrates how AI can help interpret a security decision without being allowed to control it.

Built With

Share this project:

Updates