Whitepaper / Network and Trust

Security and Risk

The protocol design answers a narrow question: who is commercially accountable when a defined service misses its claim. Secure execution still depends on data protection, runtime controls, payment infrastructure, and financing risk. This chapter draws that line. Ghast Protocol is in development, so the table is not a certification, an audit, or a statement that a Workbench task is “verified” in the protocol sense.

Risk boundaries

Read each row as a pair. The middle column is what the design offers. The right column is what a reader must not infer. A Creator Bond, described in $GHAST Utility, is a proposed lock against a breach. It is not insurance and not a guarantee that the work will be delivered. A Challenge Bond raises the cost of a careless dispute. It does not make a coordinated flood of disputes impossible. Financing uses eligibility, loss allocation, and an underwriting stake, as Capability Financing describes, and still says capital is at risk and returns are not guaranteed. That sentence is a boundary. It is not a solicitation.

The bond, slash, burn, and stake rows are proposed functions. They are not live. No reader can post a bond or earn a slash reward today. Token Allocation does not change that. A share of a proposed supply is not a security control that is switched on.

Verification boundary

“Verified” means that evidence met a particular claim through the applicable process. Its scope is exactly that claim. Delivery speed, correctness, benchmark execution, profitability, and workflow integrity are separate properties unless the Defined Claim explicitly covers them.

Evidence and Verification is the procedure. This chapter is the warning on the label. A buyer who wanted a profitability promise would need that promise inside the claim, with evidence that can actually show it. A buyer who wanted proof that the hidden prompts were never exposed would be asking for something the Privacy Model deliberately does not publish. Selective disclosure protects the method. It also means verification cannot see the method. Both sentences are true, and the design accepts the tradeoff rather than pretending one review can do both jobs.

Capabilities therefore use narrow, testable claims. Verifiable Delivery applies where meaningful criteria and evidence can be defined. Defined Claims is where a promise is made narrow enough to test. Capability Examples stay inside bounded outcomes for the same reason. A claim that says “do good work” fails the first row of the table. It never enters verification, because there is nothing to compare.

Non-deterministic output is its own row because many model results are not bit-for-bit repeats. The design response is bounded criteria and tolerances: a range, a required test, a cited source, a diff that matches a stated rule. Where a service cannot state such a criterion, objective verification varies and may not be available. The whitepaper does not solve that by calling the output verified anyway.

Runtime and infrastructure security

Execution by agents can introduce unauthorized tool use, prompt injection, credential exposure, malicious inputs, and unintended external actions. Runtime protection requires sandboxing, permissions, secrets management, monitoring, and human approval alongside claims and settlement controls.

Those controls are product and infrastructure work. Ghast Workbench already asks for permissions, shows tool activity, and lets a person review a diff or a Team delivery before accepting it. That review is a human checkpoint in the live product, described in Ghast Agent Team and in the user guide. It is not Protocol verification. A person accepting a teammate’s file is not producing a Capability History entry. Security and Risk should not be quoted as if the desktop app had become the protocol.

Contract and custody failure sit outside commercial accountability. A clear claim does not repair a broken custody path or a contract bug. Governance and Upgrades requires dangerous components to name their authority, approval path, key model, and emergency powers. Naming them is a design requirement. It is not a statement that a deployment has passed a review. There is no Protocol deployment.

Related-party and circular activity can distort the demand a financing summary sees. Filters in Reputation and Delivery History are the design response. The boundary on the right of the table remains: sybil identities and collusion can still distort observed demand. A reader of a future summary would still need the evidence scope, versions, time window, and calculation basis. A filter is not omniscience.

How to use the table

Use the table when a later sentence sounds larger than the claim. “Accountable” means payment and a proposed bond resolve against the Defined Claim, not that every harm is compensated. “Private” means the method stays Creator-controlled under the disclosure boundary, not that every byte stays on one machine. Workbench model requests can leave the device for a configured provider. That product fact is documented on the Workbench page and is untouched by this table. “Final” means protocol-final after the challenge path, not that a provisional result is safe to treat as done.

The Problem explains why opaque delivery fails a buyer. This chapter explains why a verified claim still is not a universal warranty. Both limits belong in the same book. Protocol remains in development. Until it is built, the operational security that matters is the security of the live Workbench client: installers, permissions, model providers, and the controls in the user guide.