Bun Protocol

Connectors, signing, protected data, webhooks and audit

Routed from skills/SKILL.md. The authoritative operation list is api-reference.md.

What is served at the operation layer

Data and files (tenant-scoped, RLS-protected):

Inbound webhooks:

Audit:

Messaging:

What is not served

NOT-SERVED-FAMILY: bun.connector.* bun.encryption.* bun.kms.* NOT-SERVED: bun.data.upsert bun.file.list bun.webhook.replay bun.audit.delete

There is no bun.connector.* family. The connector is a package (bunprotocol/connector/), not an operation namespace — signing, encryption, KMS wrapping, RLS role management and the PostgreSQL adapter live there and are reached through the data, file and deploy operations. Do not emit bun.connector.sign or similar.

The four things the connector guarantees

  1. Commands are signed. Sign/verify and pack/unpack are covered by property-based tests (30 Hypothesis properties, 6,000 examples, zero defects). The negative cases are the point: a flipped GCM tag byte must raise DecryptionError.
  2. Data at rest is encrypted under a KMS-wrapped key. Re-wrapping is proven OpenBao to OpenBao. Cross-vendor KMS switch is not proven — do not assume it.
  3. Row-level security is FORCE'd and exercised as a non-owner role. See tenants.md.
  4. Webhooks are verified, deduplicated and order-checked as separate operations. Signature verification is not folded into receive; call verify.

Audit

bun.audit.query returns redacted records — hashed identifiers, no plaintext. Do not write code that expects to recover a subject identifier from an audit row. bun.audit.record declares requires_auth: no so that unauthenticated failure paths remain auditable.

Same content for machines: connectors-signing.md · llms.txt