A Safebot is an AI behavior attached to your team. It listens, it talks, it proposes — but it never reaches for your files, your keys, or your money without someone approving the move. The result is collaboration where the bot does most of the work, the audit trail proves what happened, and a wrong answer can't quietly turn into a wrong action.
Most AI products today are agents. An agent is given a task, given tools — file write, email send, payments, code execution — and turned loose to figure it out. When the agent is right, this feels magical. When it's wrong, the wrongness reaches your systems in the same loop. There's no gap between "the model decided to do this" and "this is now done."
For a personal task on your own laptop, that's a calculated risk. For an organization — anywhere that other people are affected by the bot's actions, anywhere there's an auditor or a regulator or a customer relationship — it's the wrong shape. A prompt injection in the input becomes an action in the output. A confidently-wrong answer becomes a confidently-wrong send. Whatever the agent did, you'll find out about it the way everyone else does: through its consequences.
Safebots is the other architecture. The bot can think anything, propose anything, draft anything. But the moment something would actually happen — a message sent, a file changed, a key used — that proposal hits a gate. A signer reviews it. A policy approves it. Then, and only then, the thing happens. The bot's job is to do the work of figuring out what should happen. Your job, or your team's job, or another policy's job, is to confirm it should.
Most AI assistants are intern-with-the-company-credit-card. Safebots is intern-who-drafts-purchase-orders. Same eager helper, very different blast radius.
Researchers at Tel Aviv University demonstrated that AI coding assistants reliably hallucinate the same fake package names — up to 85% of the time for repositories, 100% for skill installs. An attacker registers the fake name, hides a prompt injection inside it, and waits. When a real user asks their assistant to fetch the popular tool, the assistant invents the same fake name, pulls in the attacker's version, and — because these assistants have a built-in terminal — runs whatever the attacker planted. They tested it against Cursor, Windsurf, Copilot, Cline, Gemini CLI, and OpenClaw. All of them ran attacker code.
The article's conclusion: "It all turns on one condition: an agent that fetches an outside resource and runs it with no one checking. Close that, and the attack stops."
Safebots closes it at five layers. The sandbox has no terminal — the injected "install a bot" instruction has no function to call. Every install is a proposal — a human sees the package name before anything happens. The contract judgment rejects proposals outside the handler's declared action shapes. Safebox's M-of-N package gate requires multiple human signatures before a new dependency enters the environment. And prompt injection without tools is prompt injection without consequence — even a successful hijack can only call the sandbox API, which routes every write through governance. The attack chain that worked against every agent they tested has no path through any of these five.
Noma Labs demonstrated that GitHub's new Agentic Workflows — which pair GitHub Actions with an AI agent — can be tricked into leaking private repositories. The attack: open an innocent-looking issue in a public repo. Hide prompt-injection instructions in the body. The agent reads the issue, follows the hidden instructions, fetches data from a private repo in the same organization, and posts the contents as a public comment. No credentials, no access, no coding skills required. GitHub had guardrails; adding the word "Additionally" bypassed them.
Noma's own framing: "Traditional security models assume trust boundaries are enforced by code. In agentic systems, trust boundaries are partly enforced by the model's behavior, and models are inherently instruction-following."
Safebots enforces trust boundaries at the substrate, not the model. Per-stream access control means a tool triggered on stream A cannot read stream B unless B is explicitly in the tool's declared scope — the "fetch the private repo" instruction has no API path to execute. The proposal gate means even a tool that somehow read private data can't post it without human review. The contract judgment restricts each handler to posting on its triggering stream — cross-scope writes get rejected before reaching the policy queue. And the fundamental point: the model is inherently instruction-following, which is exactly why you don't let its instructions determine what the system does. You let the model propose. The substrate decides.
A researcher chained three OpenClaw vulnerabilities (all CVSS 8.4–8.8) to go from a WhatsApp message to full host code execution. The key flaw: OpenClaw's sandbox uses a denylist to block bind-mounting sensitive directories (~/.ssh, ~/.aws, ~/.gnupg). But the denylist never checked parent directories. Mount /home into the container and you can read every user's SSH keys and AWS credentials. Mount /var and you get the Docker socket — full host escape from inside the "sandbox." A WhatsApp message triggered the chain. The sandbox was supposed to be the defense. The sandbox broke.
Safebots tools don't run in a Docker container with bind mounts. They run in a V8 JavaScript isolate with an enumerated API — no filesystem, no bind mounts, no Docker socket, no host paths. There is no denylist to bypass because there is no filesystem to deny. The tool's read scope is an allowlist: it declares what it can access, and everything else doesn't exist. Credentials aren't on the host disk in plaintext — they're in Safebox's two-box separation, where even a full sandbox escape yields only AES-GCM wrapped blobs that require a second machine to decrypt. The attack surface that OpenClaw exposed — host filesystem via bind mounts — is a surface Safebots doesn't have.
Each of the three properties below is non-negotiable. A "Safebot" that violates any of them isn't a Safebot — it's an agent with marketing. Together they produce a system where ninety-five percent of work flows at full speed and the other five percent stops at a gate where a human, or a policy, takes responsibility.
| Property | What it means |
|---|---|
| The bot never writes to your stream, sends your email, calls your API, or spends your tokens directly. It produces proposed actions — structured records that say "I would like to do this." Only the governance layer can turn a proposal into a thing that actually happened. | |
| The bot's code runs inside an isolated worker with no network, no filesystem, no host APIs. It can read information you've granted it, draft proposals, and call the LLM through a metered gate. Whatever the AI tries to do "off the rails" hits a wall the sandbox enforces — not a policy the model is asked to follow. | |
| Each kind of action — sending a message, updating a record, spawning a workflow — has its own policy. The policy says who has to sign for it to commit, and how many signatures it needs. Routine work auto-approves. Sensitive work waits for a person. Communities pick where the line goes, and can move it later. |
An agent is one model holding the credit card. A Safebot is the same model writing requisitions that go through purchasing. Same speed for ninety-five percent of work. Catastrophe avoided for the other five.
A Safebot isn't an app. It isn't a process running somewhere. It's a small set of records inside your team's coordination platform that, together, describe a behavior. Different teams compose different records to get different bots. Each piece has a job, and each piece has a list of things it explicitly cannot do.
| Piece | What it is | What it can do | What it can't do |
|---|---|---|---|
| Bot | A record that says "this is a behavior our team has." | Declare which message types it cares about, which tool runs for each, and what it's allowed to propose. | Run any code itself. Be modified except through the same governance the team uses for any record. |
| Handler | One entry in the bot's list. Maps "this kind of thing happened" to "run this tool." | Filter by stream type, message content, conditions. Pass context the tool will need. | Trigger anything not declared. Bypass the contract. |
| Tool | Pre-audited code that runs in a sandbox. The bot's "muscle." | Read streams it's allowed to see, call the LLM, draft proposals via the propose API. | Touch the network, write files, see credentials, or commit anything without going through governance. |
| Contract | A declaration on each handler: "this tool may propose actions of these specific shapes." | Bound what the proposal layer will even attempt at runtime. | Be expanded by the running tool. A bot can never propose outside its declared contract. |
| Judgment | A short program that reads each proposed action and votes approve, reject, or abstain. | Auto-approve work that matches the team's rules. Reject obviously out-of-bounds proposals. Abstain on anything ambiguous. | See data outside its read scope. Bypass policy thresholds. Run with side effects. |
| Policy | The governance setting for each kind of action: how many signatures it needs. | Gate which proposals commit. Different settings per action type. Updatable by the team. | Be bypassed by any tool, judgment, or bot. Signatures are cryptographic. |
A prompt-injected Safebot can't see the network, can't forge a signature, can't reach a key, can't propose actions outside its declared contract, and can't bypass the policy that approves them. Five doors, each closing a different way the bot could be turned against you.
When a Safebot decides something should happen, that decision walks through five stages before it becomes a real thing. Each stage has a different job. Any of them can stop the proposal cold.
| Stage | Step | Headline | What happens |
|---|---|---|---|
| 01 | Trigger | Something happens. | A message arrives, a stream updates, a goal advances. The bot's handler matches. The dispatcher loads the tool. |
| 02 | Think | The tool runs. | Inside the sandbox. Reads context, calls the LLM, weighs options. Drafts a proposal. |
| 03 | Declare | The proposal arrives. | Its action type, its target, its payload — all visible at the governance layer. All logged. |
| 04 | Judge | Judgments vote. | Routine proposals matching the team's rules get auto-approval. Sensitive ones wait for a person. |
| 05 | Commit | The action runs. | When the policy's threshold is reached. Receipt goes into the audit log alongside who voted. |
Installing the Safebots plugin gives your team a starter set of bots and tools — pre-audited, pre-approved, with sensible default policies. Teams use them as-is or fork them for custom behavior. Below is what ships today, with brief notes on what each one earns its place doing.
Every team's goal bot is parameterized by a goal template — a small record that says "the bot's job here is X, the fields to gather are Y, the artifact to produce is Z." Templates that ship by default include:
Every starter goal template is a record your team can fork. Customize the prompts, change the fields, override the artifact shape — all with the same governance that protects any other team record.
Day-to-day, most Safebots show up where you already are — a chat thread. The bot reads what's been said, may suggest things you might want to say next, and can propose actions that show up inline as cards anyone in the conversation can see and approve.
legacy_format is a breaking change for the external consumers.
Three things to notice. First, the Code bot didn't change anything — it proposed a workflow. The proposal sits as a card until Jess (or someone with the right authority) signs. Second, the suggestion chips under Jess's message are the Suggest bot at work — read-only completions that disappear if she ignores them. Third, the bot's analysis ("20 callers, 3 cross-language consumers") came from Grokers' codebase index, not from the bot reading source code on the fly. The bot's job is fast and cheap. The expensive comprehension was done once, in the background, and is queryable forever.
Two sibling plugins extend Safebots into the deepest collaboration case shipped today: AI that works alongside software engineers on real codebases. Grokers builds a structured map of the code. Code provides the workflows that actually change it. Safebots is the conversational surface where humans and the bot discuss what should happen and how.
Before any bot is useful on a codebase, the bot needs to actually know the codebase. Not "has read access to the files." Actually know — at the level of what each function does, what calls what, which tests cover what, and where the same operation lives in three different languages. This is what Grokers builds, automatically, in the background, for every repository the team registers.
It indexes. It extracts a four-attribute contract for every symbol — preconditions, postconditions, side effects, invariants. It traces calls. It bridges across languages — when a Python function has a Go shim and a TypeScript binding, Grokers connects them, so a question about the Python function automatically knows about its peers. And it surfaces uncertainty: anywhere the indexer wasn't sure (dynamic dispatch, reflection, runtime configuration), it leaves an explicit "concept to investigate" marker for a human or a follow-on workflow to clarify.
The Code plugin provides a family of pre-audited workflows that a Safebot can propose: modify a function, rename a symbol, document something undocumented, audit for patterns. Each workflow is a tree of steps — fork a workspace, propose the rewrite (LLM-driven), verify the new contract matches what was agreed, run covering tests, push a branch. Steps can succeed, fail, or fall back. Each step is one tool. Every tool runs in the same sandbox the rest of the team's tools do.
When a Safebot proposes one of these workflows, the proposal carries the inputs the workflow needs and the rationale for proposing it. It sits at the governance gate until signed. After signing, the workflow runs end to end with a full audit trail back to the original chat message that started the conversation.
Claude Code and Cursor are great for one developer changing one file. Safebots-plus-Code is for changes that need agreement — refactors crossing team boundaries, deprecations affecting downstream consumers, the kind of work where the audit trail matters as much as the diff.
The longer technical write-up on this part of the system, including the cost economics and the cross-language refactor flow end-to-end, is at safebots.ai/code.html.
The interesting case isn't one bot in one team. It's two teams that need to coordinate — and each team's bot represents their own side of the conversation. A negotiation is the multi-party machinery for working out an agreement, recording who signed what, and triggering whatever happens next.
Negotiations look a lot like the chat we just saw, but they live across team boundaries and they have structure. There's a lock: a proposed agreement that parties can sign, contest, amend, or supersede. There's a question thread: a side-channel for asking and answering specific points without bloating the main conversation. And there's a trigger: when the lock collects enough signatures to commit, an attached workflow can fire automatically — for example, "code modification proceeds as agreed."
Each side keeps its own private context — what its bot was told, what its team's policies are, what prior agreements with this counterparty already exist. But the negotiation transcript is shared. Both sides can read every message, every proposal, every signature. The transcript itself is the artifact of record. Six months later, if someone asks "why did we agree to do this," the answer is a query, not a reconstruction from chat scrollback and email.
parse_args. We'd like to deprecate the legacy keyword in 3 months. 20 callers internal, all updated.
legacy_formatlegacy_format
Both sides signed. Quorum met. The lock commits. Because the lock had an attached workflow — Code's modify workflow for parse_args — that workflow now fires automatically. The signing ceremony was the human approval. Asking for a second signature at execution time would have been empty ceremony. The transcript above is the document of record; the code change that follows is its consequence.
Email threads, Slack messages, and "I think we agreed on a call" are how cross-org agreements normally die. A negotiation transcript is the same conversation, with structure: signatures are real, the agreement is queryable, and what happens after the agreement is wired to it.
Everything above describes Safebots' behavior. The reason that behavior is trustworthy — the reason a regulated organization could actually deploy this — is what's underneath. Safebox is the hardware-attested execution environment Safebots run inside. Without it, every promise on this page collapses to "we'll take your word for it."
A Safebox instance runs inside an enclave — AMD SEV, Intel TDX, an HSM, or a similar trusted execution environment. The hardware itself produces a cryptographic receipt at boot saying which exact code is running. That receipt is verifiable by anyone with the manufacturer's root key. If a node operator swapped the code for something else, the receipt wouldn't verify; the work would be rejected.
Practically: when a Safebot uses a private key to sign something, the key never appears in the model's context, never crosses the network, and never gets written to a logfile. The signing happens inside the enclave; the only thing that comes out is the signed result.
Safebox is multi-tenant by design. Many teams' bots can run on the same hardware without seeing each other's data. Each team has its own keys, its own policies, its own audit log. A bug or malicious tool in one team's plugin cannot reach another team's storage or signers. The walls between tenants are structural — not policy notes the operator promises to follow.
An ordinary cloud says "we promise not to look at your data." A Safebox says "we can't look at your data — here's a hardware receipt proving it." Different category.
— The simple version
The full mechanics of the two-box credential separation, the attestation chain, the open-source infrastructure, and the red-team program are documented at safebots.ai/safebox.html.
Outside of chat, a Safebot's work is often pointed at a goal — a specific outcome the team wants. A new hire's profile gets filled in. A sales lead gets qualified. A capability gets generated. The goal lives as its own record, with fields that get filled as the conversation progresses. The bot drives toward completing them, asking just enough questions to make progress without becoming a form-filler in disguise.
The bot drives the next conversation toward filling the two pending fields, with judgment about timing (don't ask about budget on a first call). When all fields are filled, the goal completes and the bot routes the lead to whoever the team's policy says — a sales rep, a CRM record, a follow-up task. Nothing on this panel was filled by the bot writing to fields directly; each value is a proposal the responsible team member confirmed.
Different things matter depending on what you're trying to do.
If you've tried to roll out an AI agent inside an organization that answers to anyone — auditor, regulator, board, legal counsel, anxious customers — you've hit the same wall. The pilot works. The compliance review doesn't. "How do you know what the model did?" "What stops it from sending data outside the company?" "When something goes wrong, who's accountable?" — these questions don't have good answers in the agent architecture, and the answers they do have are policy notes nobody's compelled to follow.
Safebots-plus-Safebox is the answer. Hardware-attested execution. Every action a signed receipt. Every cross-boundary call a recorded capability. Every approval a cryptographic signature, replayable end to end. SOC 2 auditors don't want your promise the AI behaved — they want a log they can verify. This is what that log looks like.
The Safebots plugin is open source under the Qbix umbrella. Install it on a Qbix-based platform (or set one up — also open source), and you get the starter set described on this page. Compose your own bots from the same pieces. Author new tools that go through the audit pipeline. Define new goal templates for your team's specific work.
The architecture is documented in depth: every record type, every API surface, every contract the judgments enforce. There are no proprietary holdouts. If you want to understand exactly how a tool is loaded, sandboxed, and gated — read the source.
A community in Qbix terms is any group of people coordinating around shared work — a startup, a non-profit, a creator's audience, a research collective, a guild, a city government department. Each community runs as its own publisher on the platform. Each can have its own Safebots, its own policies, its own keys.
Where Safebots really earns its keep at this scale is in the cross-community case: when two communities need to agree on something. Two startups partnering on a feature. A creator and a sponsor working out a deal. A research group and a publisher arranging a release. The negotiation system gives each side its own bot — its own perspective, its own policies, its own context — and gives both sides the shared transcript that captures the agreement as it forms.
Safebots is the part of the stack closest to the people using it — the bots, the chats, the goals, the negotiations. Underneath, Safebox is the hardware-attested container that makes the safety claims structural rather than promised. Sibling plugins (Code, Grokers) extend the system into specific domains; the same pattern handles dozens of other domains the same way.
The fastest way to see whether this fits your situation is a short conversation — fifteen or thirty minutes, no slides, no pitch deck. We'll listen to what you're trying to do and tell you whether Safebots is the right shape for it or not.
Bots that ask first. AI that doesn't take the keys. Agreements that mean something.