Security & trust

konareef is built around explicit, declared trust boundaries. A reefpod states what it can access, what it can spend, and what evidence it produces. Every run leaves a verifiable custody proof. This page is for builders who ship pods and for evaluators who decide whether a pod is safe to run against company data.

The trust model at a glance

Secrets

Pods never contain secret values. They declare the secret names they require. reef-core injects the values from its vault at spawn time. This keeps credentials out of source control, out of the published bundle, and out of proof logs.

[dependencies]
secrets = ["OPENAI_API_KEY", "GITHUB_TOKEN"]   # names only — never values

Tools

Constrain what the directive can invoke. Prefer an explicit allowlist over denying individual tools.

[directive]
template      = "./prompts/system.md"
tools_allowed = ["web_search"]
tools_denied  = ["shell"]

Budgets

Budgets are hard caps in satoshis. They stop runaway cost and runtime. They also make a pod easy to approve inside a team.

[budget]
max_sats          = 500
per_call_cap_sats = 100
daily_cap_sats    = 2000

Proof

Every run on reef-core produces a signed custody proof. The proof binds what reef-core recorded the pod as doing: the model it used, the tools it called, what it cost, and how its memory changed. Each of those is checked against the limits the manifest declared. You can re-verify proofs offline:

konareef verify ./bundle            # re-verify a konareef-bundle
konareef verify ./bundle --strict   # stricter signature/attestation checks

For privacy-sensitive pods, konareef supports disclosure policies. They control how much of a run the proof reveals. This is selective disclosure through --disclosure-policy, backed by a zero-knowledge bundle. Choose the policy that reveals only what a verifier needs.

Trusting a pod you can't personally audit

Commissioning a reefpod means you pay for a declared, budget-capped run. You do not buy the author's prompts or technique. A publisher can keep the pod's internals proprietary. A commissioner does not need to read them to trust the outcome. Three things carry that trust instead of a manual code review:

• konareef's audit filter — pod.toml forces every pod to declare its secrets (by name), tool access, and budget before it can run. The runtime enforces those boundaries no matter what the prompt tries to do.
• The publisher's public reputation — a publisher identity signs every pod (a real cryptographic keypair, not an anonymous upload). Bad behavior is attributable to a known, rotatable identity, not a disposable one.
• Pod history and provenance — versions are immutable once published, and every run leaves a signed custody proof. You can check a pod's track record before you commission the next run: what it cost, what it touched, and whether it ever went out of bounds.

These three hold even for a pod whose prompt you have never read. konareef's audit filter enforces the boundary table above. The rest is the reputation and provenance layered on top of it.

Good vs. bad

Over-broad — vague, hard to approve, over-permissioned:

[dependencies]
secrets = ["OPENAI_API_KEY", "AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY", "GITHUB_TOKEN"]

[directive]
task = "Do whatever it takes."
# no tool limits, no budget

Least-privilege — narrow, bounded, reviewable:

[dependencies]
secrets = ["GITHUB_TOKEN"]

[directive]
template      = "./prompts/system.md"
tools_allowed = ["web_search"]

[budget]
max_sats       = 250
daily_cap_sats = 1000

Safe publishing checklist

• Does this pod need every secret it declares? Remove any it does not.
• Are secrets declared by name only, never embedded?
• Is the tool surface restricted with tools_allowed?
• Is a [budget] declared with a sensible max_sats?
• Does [output] declare clear success/failure conditions?
• For sensitive workflows, did you choose a disclosure policy so proofs do not leak inputs?
• Does konareef pod validate pass cleanly?