Skip to content
reveno / Harness
PTJoin the waitlist

HARNESS · HOW IT WORKS

The policy decides before any action.

Every agent request goes through the same checks, in the same order. If one fails, the request is denied and the reason becomes a receipt.

IN ONE PICTURE

The decision comes before the action.

Every request leaves allowed, waiting for a person or denied. There is no fourth exit.

The decision before the actionThe agent request reaches the policy, which checks for an identified owner, scope for the data, the workspace boundary, an allowed provider and whether the action is sensitive. There are three outcomes. Allow: the action proceeds. Ask for approval: a person decides in the browser, and a decline or an expired wait becomes a denial. Deny: the action does not run and the reason is recorded. Every decision becomes a receipt signed with Ed25519 and chained to the previous one. If the policy does not answer, time runs out or there is an error, the action is denied even without a receipt.Agent requesttool, inputand input hashPolicy decidesidentified ownerscope for the datainside the workspaceallowed providersensitive action?Allowthe action proceedsin the workspaceAsk for approvala person decidesdeclined or expired: denyDenythe action does not runreason recordedFail closedno answer, timeoutor error: denySigned receiptEd25519, chainedto the last receiptThe decision before the actionThe agent request reaches the policy, which checks for an identified owner, scope for the data, the workspace boundary, an allowed provider and whether the action is sensitive. There are three outcomes. Allow: the action proceeds. Ask for approval: a person decides in the browser, and a decline or an expired wait becomes a denial. Deny: the action does not run and the reason is recorded. Every decision becomes a receipt signed with Ed25519 and chained to the previous one. If the policy does not answer, time runs out or there is an error, the action is denied even without a receipt.Agent requesttool, input and input hashPolicy decidesidentified ownerscope for the datainside the workspaceallowed providersensitive action?Allowthe action proceeds in the workspaceAsk for approvala person decidesdeclined or expired: denyDenythe action does not runreason recordedFail closedno answer, timeoutor error: denySigned receiptEd25519, chainedto the last receipt
Fig. 1 The decision before the action. Every request takes one of three exits, and every decision leaves a signed receipt. When the policy cannot decide, the answer is no, with or without a receipt.Source: rule of the Cloud IDE gateway 0.4.0 (live since 2026-11-02) and of runtime 0.1.0. Own drawing, generated at build time.

What fail closed means for a buyer

If the policy does not answer, takes too long or errors, the action does not happen. The risk of a technical failure is a stopped agent, never a loose one. When the path itself goes down there may be no receipt left, but a missing receipt never turns into permission.

How it is built in the Cloud IDE

The managed Claude Code hook has a hard 120 second deadline counted from its start, caps every call to the time left and denies before the ceiling. The managed settings tell Claude Code to block if the hook itself fails ("onFailure": "block") and require the version that has that option. The limits that remain open are on the trust page.

01 / ORDER OF CHECKS

Fail closed, in six steps.

It is the Harness control plane rule, the same in Python and in JavaScript.

  1. 01

    Identity

    Does the request have an authenticated owner? No owner, nothing runs.

    authentication_required
  2. 02

    Scope for the data

    Does the owner role cover the data class: public, internal, confidential or personal?

    scope_required
  3. 03

    Runtime

    Executing requires the runtime to be enabled. Planning does not.

    runtime_not_enabled
  4. 04

    Workspace isolation

    Is the target inside the workspace root? Directory traversal is denied.

    workspace_boundary_violation
  5. 05

    Provider

    Does the skill use a known, enabled provider? Direct outbound network stays blocked.

    external_provider_blocked
  6. 06

    Approval

    Sensitive actions wait for a person, and the requester does not approve.

    human_approval_required
Fig. 2 The order of checks. The first check that fails decides, and its code goes into the receipt.Source: /policy-engine.js, the same rule the demo uses, pinned by the control plane test vectors.

02 / RECORDED REASONS

Every result has a code.

The code goes into the receipt. That is how the decision can be audited later.

Control plane decision codes
CodeWhat it meansResult
preview_onlyPlanning or reading was allowed; nothing was changed.allowed
execution_not_implementedEvery check passed; in this phase execution is simulated.simulated
human_approval_requiredSensitive action without a person's approval.waits
authentication_requiredRequest without an identified owner.denied
scope_requiredThe owner role does not cover the data class.denied
runtime_not_enabledExecuting without an enabled runtime.denied
workspace_boundary_violationTarget outside the workspace root.denied
external_provider_blockedSkill with direct outbound network.denied
provider_disabledProvider blocked in the policy.denied
Fig. 3 The decision codes. Three possible results besides a denial: allowed, simulated and waiting for a person.Source: reason codes in /policy-engine.js; verify-release.sh refuses to publish if any is missing.

03 / VERIFY A RECEIPT

Paste the JSON and recompute.

Export the receipts in the demo and paste them here. The verifier recomputes every hash in your browser and points to the first receipt that does not match. Today the receipt is a chained SHA-256 hash; key signing comes with early access.

Create receipts in the demo

Discover · open and freeAgents & SkillsSkills, agents and MCP servers with origin and triage.Operate · early accessHarnessThe cloud IDE where every agent runs with an owner and a receipt.Decide · early accessEvidenceSynthetic data to test the decision before you invest.