Our rules for safely running OpenClaw with KiloClaw in production

Get started today.

Every organization now says they’re deploying agents in production, but most of those agents are on tight guardrails. Does it really count as an agent if all it’s doing is reading PDFs without the ability to take action on the results? When OpenClaw was released, we saw something more exciting – a real autonomous agent. And we wanted to use it ourselves.

But “use agents for work” is not a policy. It’s a wish. And without a real framework, you end up with a mess of personal bots with live credentials, shadow accounts in external services, and nobody quite sure what has access to what.

As we’ve built KiloClaw to be the safest way to Claw by hardening the underlying instance, we’ve also been thinking hard about how to actually use those agents in a way that makes them useful – and not dangerous.

What follows is the actual guidance we run by internally. I’m sharing it because I think a lot of companies are stuck in the same spot we were – they want to use AI agents, they’re nervous about the risks, and they don’t have a starting point.

Start with the one rule that changes everything

So what does it actually mean to deploy AI agents safely?

Bots can have access to internal data OR the ability to communicate externally. Not both.

We call this the Golden Rule, and it does most of the heavy lifting. An agent that can read your internal systems and reach the open internet is a different beast – one with a much wider blast radius when something goes wrong.

Separating those two concerns keeps things manageable.

The second principle that falls out of this: work bots stay in the work org. Just like you wouldn’t use your personal Gmail for company email, you don’t use a personal KiloClaw instance for work purposes. They’re separate accounts, with separate naming conventions to make that clear – every work bot has “KiloClaw” or “internal” in its name.

These two rules cut through most of the ambiguity.

The full setup, in practice

Identity and email

Every bot in our org gets its own email address – formatted as `[yourname].bot@kilocode.ai`. Bots have read-only access to their inbox, and any email they receive also auto-forwards to the human owner. (Verification links used to be annoying. This fixed it.) Bots cannot send email. We have this limited when the email addresses are provisioned.

Where bots can talk

Bots can communicate on KiloClaw Chat or Kilo Slack. Not Telegram. Not Discord. Not personal channels of any kind. This is the communication side of the Golden Rule in action – we know exactly where bot conversations live.

For enterprise customers, we can enforce this at the organization level.

Credentials: the part that matters most

Don’t share API keys with your bot directly. This is the rule people are most tempted to break because it’s easier in the moment – and it’s the one that causes the most problems down the line.

Instead, bots get their own seats in the services they need: Axiom, Vercel logs, wherever they actually require access. Those credentials are provisioned as dedicated accounts and stored in 1Password. The bot gets a 1Password account of its own, with a shared vault. You never paste a secret into a chat window.

GitHub

Bots can create issues and submit PRs. That’s useful. What they cannot do is approve or merge. We’ve audited approval rules across our repos to enforce that – a bot’s approval simply doesn’t count. Humans review and merge.

When someone leaves

Bot accounts are handled exactly like employee accounts during offboarding. When someone departs, their KiloClaw, its credentials, its instances, its tokens – all of it is terminated and removed from the org as part of standard IT offboarding. No orphaned agents.

You don’t need to have it all figured out before you start

We didn’t. We built these guidelines by actually using the tools, running into the edge cases, and tightening things up as we went.

Start with the Golden Rule. Build the separation of concerns into your setup from day one. Get credentials into 1Password before you need to audit them. The details will follow.

The teams that build good habits now are going to be in a much better position six months from now. I want Kilo to be one of them. I’d like you to be too.