Security

Motebit's security posture is not a feature bolted on — it is the architecture. Identity is a cryptographic boundary, governance is enforced at the surface, and every claim the system makes is independently verifiable. This page is the consolidated reference: how to report a vulnerability, how sensitive data is handled, how keys are managed, and the threats the design defends against.

Responsible disclosure

If you discover a security vulnerability, email security@motebit.com. Please include reproduction steps and the affected surface (CLI, desktop, mobile, relay, or a specific package). Do not open a public issue for a security report.

We aim to acknowledge reports promptly and to coordinate disclosure. Motebit is built in the open — the protocol specs and reference implementations are public — so a vulnerability in the reference code is verifiable by anyone, and a fix is verifiable in the same way.

Data sensitivity & privacy

Every piece of stored state carries a sensitivity level, and the level governs where the data is allowed to travel:

Stored state at medical, financial, or secret never syncs to a relay and is never assembled into the context sent to a cloud model — enforced at storage, retrieval, sync, and context assembly, fail-closed (on a classification error the memory is rejected, not leaked). Tool results are scanned for secret patterns (keys, tokens, card numbers, seed phrases) and redacted before they reach the model.

What governs the live conversation is the session sensitivity tier: when a session is at medical/financial/secret (you set it, or a sensitive document on the slab raises it), every call to a non-sovereign provider is blocked — the model gets nothing until you switch to an on-device provider or de-escalate. The system does not auto-classify the content of your own live messages, so this is a control you hold, not magic detection: to keep a sensitive conversation local, mark the session (or use an on-device provider) before you type it. As an additive floor, obvious credential-class secrets (API/cloud keys, bearer tokens, JWTs, private keys, seed phrases, connection strings, passwords) typed directly into an unmarked cloud session are masked before they reach the model — the model almost never needs to see a raw credential. Deliberately not auto-masked: SSNs and card numbers (often legitimately used — mark the session instead) and medical content (not pattern-detectable). Those stay user-controlled.

Retention is governed too. Deleted data produces a signed deletion certificate, and sensitivity ceilings on what may persist (or sync to a relay) are interoperability law, not a configuration preference. See Governance for the enforcement model.

Keys & identity

Your motebit's identity is an Ed25519 keypair. The public key (and the motebit_id derived from it) is shareable; the private key is the root of all authority.

• At rest. On mobile the private key lives in the iOS Keychain / Android Keystore. On desktop it lives in the OS keyring, with an owner-only (0600) local fallback file when a keyring write cannot be confirmed (access-controlled, not application-encrypted — verified-keyring-only writes on signed builds are tracked hardening). On the CLI it is encrypted with your passphrase using PBKDF2 (600,000 iterations, SHA-256) and AES-256-GCM. It never crosses the network and never enters the non-secret config metadata.
• Recovery. A recovery seed re-derives a sovereign identity. A sovereign motebit_id is a cryptographic commitment to its genesis key, so the binding between an id and its key is checkable offline by anyone.
• Rotation & succession. Keys can be rotated; a signed succession chain (old and new keys both sign) preserves continuity, so a rotated key does not orphan past receipts.
• Hardware attestation is additive. Secure Enclave / TPM / StrongBox attestations raise an identity's assurance score — they never replace the Ed25519 key, and their absence never blocks a software identity. Software identity is the floor.

See Identity & crypto for the full key lifecycle.

Governance & the policy gate

Every risky action is gated against the owner's signed policy before it runs. Tools are classified into risk bands (R0_READ … R4_MONEY), and two thresholds decide the outcome:

• max_risk_auto — the ceiling for actions that run automatically.
• deny_above — the ceiling above which actions are blocked unconditionally.

Between them lies the approval band: the agent may reason about the action but cannot execute it without explicit operator approval. If a threshold is missing or the ordering constraint is violated, the daemon refuses to start — fail-closed by default.

Money is the strongest case. An R4_MONEY tool call can only ever auto-execute when the turn carries a cryptographically verified standing-delegation grant — a signed artifact, never a configuration flag, a trust level, or anything the model recalls or claims. Absent that grant, money always routes to approval. There is no switch that disables this branch. See Governance and Daemon & approvals.

Threat model

Motebit's design defends against three classes of attack a sovereign agent network must withstand:

• Sybil resistance. Trust is first-person and bilateral — keyed to a specific pair of identities, accumulated from signed receipts — never a global reputation score that mass-minted identities could inflate. Minting an identity is free; earning trust with a specific counterparty is not.
• Prompt injection. Memory carries machine-assigned provenance (user-stated, agent-inferred, tool-derived, peer-agent) — never model- or peer-authored — so a recalled fact cannot smuggle in authority it never had. Memory may inform; only signed artifacts authorize.
• Token binding. Bearer tokens are audience-bound: a token minted for one endpoint is rejected by another. A token scoped to submit a task cannot be replayed against the endpoint that reads its result.

Verifiability

Every claim motebit makes about itself is checkable without trusting motebit. An execution receipt verifies offline against the producer's public key; an identity binding is provable from the motebit_id alone; the operator's transparency posture is published and signed.

The shortest demonstration is the Developer Quickstart — sign a receipt and verify it in one file, no relay and no account. That is the security model in miniature: the proof travels with the artifact.