Sep 18, 2026 • 8 min read

Building secure functions that run on encrypted data

Most data leaks don't happen in the database. They happen in the places around it: logs, analytics tools, support dashboards and the dozen services that quietly receive a copy of every request. Sealed functions flip the model — your code works on encrypted data, and plaintext only exists for the few milliseconds it is actually needed.

Understanding the fundamentals

A sealed function runs inside an isolated sandbox with no network access except the endpoints you explicitly allow. Inputs arrive encrypted, are decrypted inside the sandbox, and every output is re-encrypted before it leaves. Even if your servers are compromised, the sensitive values were never there in readable form.

Building them well means thinking about three things up front: which fields are sensitive, who is allowed to see them, and where results are allowed to go. Write those rules down as policy and the platform enforces them for you.

Step-by-step implementation

Start small. Pick a single flow — say, verifying a user's identity — and move just that logic into a sealed function. Mark the fields, write the policy, deploy from the CLI and watch the audit log fill up with events instead of raw data.

Once the first flow is live, the rest follows the same pattern. Most teams migrate their critical paths in a few sprints, and the best part is that nobody has to remember to be careful anymore: the default is safe.