Security Engineering

Systems that keep their promises when a request is hostile, a permission changes, or a shared dependency fails.

These guides follow one path: what can go wrong, where to enforce the boundary, and how to test it. Each one covers implementation choices and the limits of those choices.

Start here

01 / Secure a multi-tenant system

Keep one customer’s data, credentials, and workload from becoming another customer’s problem. Covers verified tenant context, PostgreSQL row security, pooled connections, caches, workers, signed URLs, and offboarding.

Read the guide · Jump to the release checklist

Next in the series

02 / Bots and automation — upcoming. Identity, abuse controls, scoped credentials, and limits on what automated actions can do.

03 / RAG systems — upcoming. Document permissions, hostile retrieved content, answer caches, and the tools attached to a model.

Until those guides are ready, read the existing essays on agent tool permissions and RAG permission revocation.

How to use these guides

Start with the threat model, not a library choice. Treat examples as a starting point for your own tests, not a certification that a system is secure. Where a control depends on a role, deployment setting, or service guarantee, test the version you actually run.

Engineering snippets · Engineering notes · All essays

>