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

Declare what the directive can invoke. Prefer an explicit allowlist over denying individual tools. These lists are a declaration only: reef-core does not enforce them yet.

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

Budgets

Budgets are spending limits in satoshis. A budget stops a run when its recorded spend reaches max_sats. The run can spend somewhat more than max_sats before it stops, and a stopped run fails. A declared budget also makes a pod easier to approve inside a team. On the hosted service, the operator sets a per-run ceiling, and a pod with no [budget] gets a default limit.

[budget]
max_sats = 500

Deliverables and your data

A user sees only their own agents, run logs, proofs and deliverables. Users can download only declared deliverables. This rule applies to every pod. A file that [[output.deliverables]] does not list gets HTTP 404. A pod that declares no deliverables serves no files. See [output].

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 tool calls it recorded, the cost it recorded, and how its memory changed. It does not show that the list of tool calls is complete, and the cost is not checked against the model provider's bill. 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. The zero-knowledge tier is not available on the private beta.

Trusting a pod you can't personally audit

Commissioning a reefpod means you pay for a declared run with a spending limit. You do not buy the author's prompts or technique. A publisher can keep the pod's internals proprietary. One way is a closed pod, which keeps its body out of public view. 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 declares a pod's secrets (by name), tool access, and budget up front, so a reviewer can read these boundaries before a run.
• 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 reef-core recorded it costing and touching.

These three hold even for a pod whose prompt you have never read. pod.toml declares the boundary table above. The table says what is enforced today. The rest is the reputation and provenance layered on top of it.

What reef-core does not protect yet

Read these limits before you run a pod against sensitive data:

• Every field that a pod reads goes to the model provider as part of the prompt.
• tools_allowed and tools_denied are declarations only. Nothing enforces them yet.
• A run can spend somewhat more than max_sats before it stops.
• On the private beta, only approved publishers can publish pods. Every beta user can run them. The private beta does not rely on confining pod code. It relies on controlling who may publish 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

Safe publishing checklist

• Does this pod need every secret it declares? Remove any it does not.
• Are secrets declared by name only, never embedded?
• Does tools_allowed declare the tools the pod needs? (Declaration only: not enforced yet.)
• 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?