# 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.

## 01 · 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.queued     10:42:07   parked, waiting on the owner
· · ·                               three hours pass, nothing moves
outbound.send.approved   13:54:31   actor: owner
outbound.send.sent       13:54:33   executed by the body
Nothing in this figure moved without the human's answer.
```

## 02 · 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.

The spend gradient, from tightest to loosest:

| stage | meaning |
|---|---|
| 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.

## 03 · 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.captured        09:14:02   actor: site
outbound.teaser.generated 09:31:40   actor: body
outbound.send.queued      10:42:07   actor: body
outbound.send.approved    13:54:31   actor: owner
outbound.send.sent        13:54:33   actor: body
Rows are appended, never edited. Every table the business reports from is rebuilt from rows like these.
```

## 04 · 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.

## 05 · 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.