Security

Nothing outbound moves without an answer.

busibody holds no certifications yet, and this page claims none. Control comes from how the runtime is built. Outbound messages and money movements above a threshold stop in an approval queue until a human answers, every act lands on an append-only ledger, and each business runs inside a real legal entity with a named human owner. Each section below says what runs today and what is still an open problem.

01The approval queue

The approval queue is the runtime.

The approval queue is a durable list of questions the body has asked its human. When the body wants to act in a way that is consequential (send a mail to a stranger, spend above a threshold, publish in the owner’s name), it does not act. It writes the exact action into the queue and waits, and it resumes when the owner answers. The queue is not a review step bolted onto the side: an unanswered question blocks that action indefinitely, and there is no timeout that lets it through.

Approval starts at approve-each, where the owner reads the exact text of every outbound message before it leaves. As a category accumulates evidence, its approval graduates along a fixed path: approve-each, then approve-batch, then approved policies, then review-exceptions. Each graduation is itself an event on the ledger, so an auditor can see when a category was loosened and on what evidence. This runs today: every outbound mail the first body sends waits in this queue until a human approves the exact text.

Fig. 1 · The approval queue
outbound.send.queued10:42:07parked, waiting on the owner
· · ·three hours pass, nothing moves
outbound.send.approved13:54:31actor: owner
outbound.send.sent13:54:33executed by the body
Nothing in this figure moved without the human's answer.

02Spend gradients

Spend limits are enforced at the card.

Every body’s card is issued with hard caps, and the caps are enforced by the card issuer rather than by the agent’s judgment. A card capped at a small monthly amount can buy a domain and cannot empty an account, whatever the mind decides. A spend that would exceed a cap becomes a question in the approval queue like any other consequential act.

The state of this, honestly: hard caps on issued cards run today, and the approval queue governs above-cap spends today. The declarative rules layer, where an owner writes category policies such as “approve any transaction under a set amount to a verified counterparty and queue everything else,” is designed and is not built. As far as we know no vendor ships it. The payment rails underneath (virtual cards, agent wallets) are mature, and the governance gradient on top of them is the part busibody exists to supply.

Fig. 2 · The spend gradient
card cap

Enforced at the issuer, always on. The mind cannot raise it. Running today.

approve-each

The owner answers every spend above the cap, one at a time. Running today.

approve-batch

Spends in a proven category are approved in reviewed batches.

policies

Declared rules approve routine spends automatically. Designed, not built.

review-exceptions

Oversight moves to sampling and exceptions, for a category with a long clean record.

A category moves down this table only on evidence recorded in the ledger.

03The ledger

Every act is one typed row.

Everything the body does is recorded as a typed event in an append-only stream: a lead captured, a teaser generated, a send queued, a send approved, a payment received. An event carries its actor, its timestamp, and its payload, and no event is ever edited or deleted. Every table the business reports from, including its pipeline and its revenue, is a view that can be rebuilt from the stream.

For an auditor this means the business is legible without reading its code. The question of who did a thing, when, and on whose approval is answered by reading rows, and replaying the stream reproduces the state of the business at any past moment. This runs today in the first body, where the event stream is the source of truth that every other table is built from.

Fig. 3 · The ledger, five consecutive rows
site.lead.captured09:14:02actor: site
outbound.teaser.generated09:31:40actor: body
outbound.send.queued10:42:07actor: body
outbound.send.approved13:54:31actor: owner
outbound.send.sent13:54:33actor: body
Rows are appended, never edited. Every table the business reports from is rebuilt from rows like these.

04Entity insulation

Each body is a real company with a named human owner.

A spawned business is not a bot with a wallet. It runs inside a real legal entity, and the practical shape today is one umbrella company with a registered trade name per venture. The entity is the party to the terms of service, the holder of the payment account, and the registrant of the domain. A named human is the beneficial owner, because the law requires a human beneficial owner, and busibody states that plainly rather than working around it. Consequences also land on the entity: rejection, complaint, and liability attach to the venture rather than to the owner’s personal name.

05Open problems

Open problems, stated.

Two problems in this category have no settled answer anywhere, and busibody does not claim to have settled them.

Agent KYC. Banking and incorporation require a human beneficial owner, so every busibody is legally a person’s company operated by agents. Exactly one vendor precedent exists for a legal entity created for an AI agent, from May 2026, and it is months old and untested.

Liability. An agent that speaks or spends as a business binds the entity it acts for. Terms of service and insurance remain owner decisions, per venture. The queue and the ledger reduce the surface, and they do not remove the responsibility.

When busibody holds a certification, it will be listed on this page. Until then the claims above are the ones we can defend, because they describe how the system is built.