Introducing Guardrails

AI agents write code faster than any of us can review it. That speed is why zokie exists, and it's also the problem. An agent with access to your project can read your .env, push straight to main, run rm -rf on the wrong folder, or install a package whose name is one letter off from the one you meant. The usual fix is a line in the prompt asking the agent to behave. That's a request, not a rule. So today I'm introducing Guardrails: rules for your agents that live outside the agent, where it can't read or change them.

Your agents can use your keys without ever seeing them

Key Shield is the part I'm proudest of. Your real API keys stay in your computer's keychain. Your agents, their terminal and your dev server only ever get placeholders, something like zk_ph_stripe.

When your code calls Stripe, the request passes through a small proxy inside zokie. If the host, path and method match what you allowed, zokie swaps in the real key on the way out. Anywhere else, the placeholder goes out as it is. So if an agent prints your env, logs a key or posts it to some random webhook, all it leaks is a dummy string.

Zokie also checks everything headed to the model. If a key turns up in a file or a pasted message, it's replaced with a placeholder before it leaves your machine, and zokie offers to store it in the keychain. Hardcoded keys get caught before a commit, too. Your keys never reach zokie's servers in readable form.

Rules that don't depend on the agent behaving

Key Shield is one Guardrail. The others cover the ways an agent can do damage without touching a secret. You can protect paths, so migrations, payment code or CI files don't change without your approval. Risky commands like git push --force or DROP TABLE pause and ask first, and the approval comes to your phone through Anywhere. Agents can be kept off main entirely, working only through PRs that QA has to pass. You can also limit which domains agents reach, flag new or look-alike packages before they install, cap Zokie AI spend per person or per day, and keep agents away from production data. For teams that want more, you can require a security audit before a merge or a Zokie Deploy. It's built on Cloudflare's open-source security-audit skill, and the agent that verifies a finding is never the one that found it.

When zokie stops something, you'll hear about it

A Guardrail that blocks things silently is hard to trust. So whenever one catches something, zokie shows a sheet that says what went wrong, what it did about it, and what you can do next, like allowing it once or keeping it blocked. These alerts come from zokie, not from the agent. An agent can't fake one, and it can't press the buttons for you. Every real alert shows the security phrase you picked at setup, and anything risky, such as allowing a new host, asks for Touch ID or Windows Hello.

Set it once for your whole team

On a team, Guardrails belong to the admin. You set them per org and per repo, and they apply to each new member automatically based on what they're there to do. An intern and a senior engineer can start with different rules on day one. Synced keys stay end-to-end encrypted, so zokie's servers only ever store ciphertext. Working solo? You're your own admin, with the same controls.