deadbyte-mcp 0.8.7

package/docs/EXECUTION.md

@@ -0,0 +1,330 @@
+# DEADBYTE V0.6 CONTAINED EXECUTION CONTRACT
+
+## Purpose
+
+V0.4 crosses one boundary only: from a proven Windows containment backend to one useful, fixed execution capability.
+
+It deliberately does **not** expose a general shell or arbitrary executable launcher.
+
+## Capability
+
+MCP tool:
+
+`contained_transform`
+
+Compile-time operation-to-executable registry:
+
+- `uppercase_ascii` -> `contained-transform-v1` -> `bin/contained-transform-worker.exe`
+- `lowercase_ascii` -> `contained-transform-v1` -> `bin/contained-transform-worker.exe`
+- `reverse_bytes` -> `contained-reverse-v1` -> `bin/contained-reverse-worker.exe`
+
+Input and output are workspace-relative paths validated by the existing path policy. The output is create-new only.
+
+The user cannot supply:
+
+- executable path
+- command line
+- argv list
+- environment block
+- shell
+- PowerShell
+- cmd.exe
+- AppContainer capability names
+- Job limits
+- host paths
+
+## Fixed worker registry
+
+The package contains one trusted launcher and two fixed package-local worker binaries:
+
+- `bin/deadbyte-exec.exe`
+- `bin/contained-transform-worker.exe`
+- `bin/contained-reverse-worker.exe`
+
+`deadbyte-exec.exe` does not accept a worker path. `ResolveWorkerSpec()` maps only a known operation id to a compiled worker id and sibling executable basename. The MCP caller cannot provide either value.
+
+The signed receipt includes the selected worker id and SHA-256. Contained execution evidence also binds `worker_registry=compile-time-operation-to-executable`, the selected worker id, executable basename, and launcher SHA-256. The independent verifier recomputes the selected package-binary hash and operation semantics.
+
+## Import boundary
+
+1. Node resolves the named workspace.
+2. Node resolves one existing input below that workspace.
+3. Node reads at most 1 MiB into host memory.
+4. Node sends those bytes on stdin to `deadbyte-exec.exe`.
+5. The launcher writes a new `import.bin` inside an ephemeral AppContainer profile.
+
+The AppContainer worker never receives the original workspace path and the host workspace is not mounted into the sandbox.
+
+## Process boundary
+
+The launcher creates a regular AppContainer with:
+
+- zero capabilities
+- `PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES`
+- `PROC_THREAD_ATTRIBUTE_JOB_LIST`
+- atomic Job assignment at process creation
+- `JOB_OBJECT_LIMIT_ACTIVE_PROCESS = 1`
+- `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`
+- `JOB_OBJECT_LIMIT_PROCESS_MEMORY`
+- 128 MiB process memory limit
+- no `JOB_OBJECT_LIMIT_BREAKAWAY_OK`
+- no `JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK`
+- UI Job restrictions
+- no broken `PROC_THREAD_ATTRIBUTE_CHILD_PROCESS_POLICY`
+
+This follows the V0.3.13 target proof lineage.
+
+## Runtime self-checks
+
+The fixed worker checks during every contained transform:
+
+- `TokenIsAppContainer` query succeeds and is true
+- `TokenCapabilities` query succeeds
+- capability count is zero
+- regular AppContainer can read the AAP canary
+- host-only canary remains unreadable
+- process is in a Job
+- a normal child payload cannot reach sentinel exit 66
+- an explicit `CREATE_BREAKAWAY_FROM_JOB` payload cannot reach sentinel exit 66
+- imported file read succeeds
+- transform succeeds
+- sandbox output create-new write succeeds
+
+The worker writes `execution-proof.json` inside the private profile and exits zero only if all required checks pass.
+
+## Export boundary
+
+After worker exit:
+
+1. Trusted launcher reads `export.bin` from the private profile, max 1 MiB.
+2. Launcher returns it as base64 in one JSON measurement.
+3. Node validates the complete execution measurement.
+4. Node decodes the bytes.
+5. Node creates the requested workspace output with `wx` / create-new semantics.
+6. Node writes an authenticated receipt.
+
+The sandbox process never opens the host output path.
+
+## Independent verification
+
+`evidence_verify` verifies:
+
+- canonical receipt self-hash
+- Ed25519 signature
+- key id
+- input snapshot hash
+- output hash
+- stdout hash
+- stderr hash
+- selected worker id and hash
+- contained launcher hash
+- contained execution evidence contract
+- independent recomputation of the selected allowlisted transform from the immutable input snapshot
+
+The verifier rejects a receipt whose output bytes do not equal its independently recomputed transform even if hashes inside the receipt were otherwise internally consistent.
+
+## Non-claims
+
+This V0.4 capability does not establish safety for arbitrary commands or arbitrary binaries.
+
+It is intentionally a fixed semantic worker with a compile-time operation registry so the complete host/import/sandbox/export/evidence chain can be proven before widening executable authority.
+
+
+## Windows stdin pipe EOF contract
+
+`deadbyte-exec.exe` reads the explicit host import from redirected stdin. On a
+Windows anonymous pipe, closure of the final write handle is observed by
+`ReadFile` as `FALSE` with `ERROR_BROKEN_PIPE`. V0.4.1 treats only that error as
+normal end-of-stream. Other `ReadFile` failures remain fatal. The Node host then
+requires `result.input_bytes === inputBytes.length` before export is accepted.
+
+
+## V0.4.3 environment boundary
+
+The trusted host launcher (`deadbyte-exec.exe`) is allowed to inherit the normal
+Windows host environment because Windows AppContainer process creation itself may
+need host-side environment state. That environment is not forwarded wholesale to
+the contained worker.
+
+Immediately before creating the worker, the launcher calls
+`CreateEnvironmentBlock(&workerEnvironment, nullptr, FALSE)`. With a null token and
+`bInherit = FALSE`, the worker receives a fresh system-only Unicode environment
+block. `CreateProcessW` receives that block explicitly together with the fixed
+`workerCopy.c_str()` application path.
+
+This preserves the trust split:
+
+- host control plane: normal Windows environment
+- AppContainer payload: system-only environment
+- no user-controlled executable path
+- no user-controlled environment block
+- no host workspace mount
+
+
+V0.4.3 Windows environment contract
+-----------------------------------
+The AppContainer worker receives a sanitized Unicode environment derived from
+CreateEnvironmentBlock(NULL, FALSE), plus exactly one required hidden per-drive
+current-directory entry matching the private run directory (for example
+`=C:=C:\...\deadbyte-v04-exec`).  This preserves the Win32 CreateProcessW
+current-directory contract without inheriting arbitrary host environment values.
+The validator requires `worker_environment=appcontainer-bootstrap-allowlist-plus-drive-cwd` and
+`worker_drive_current_directory_set=true`.
+
+## V0.4.4 AppContainer bootstrap environment
+
+V0.4.3 target evidence showed that adding the hidden per-drive current-directory
+entry did not clear Win32 error 203. V0.4.4 narrows the next change to the user
+environment state that Windows AppContainer creation actually depends on.
+
+The trusted launcher reads its host environment but copies only this fixed list
+into the worker environment block:
+
+- `Path`
+- `SystemDrive`
+- `SystemRoot`
+- `TEMP`
+- `TMP`
+- `LOCALAPPDATA`
+- one synthesized `=<drive>:=<private runDir>` entry
+
+No arbitrary host environment variables are copied. The block is sorted
+case-insensitively and double-NUL terminated before `CreateProcessW`.
+
+The execution validator requires:
+
+- `worker_environment=appcontainer-bootstrap-allowlist-plus-drive-cwd`
+- `worker_localappdata_present=true`
+- `worker_environment_allowlist_exact=true`
+- `worker_drive_current_directory_set=true`
+
+This remains a fixed-worker execution path; there is still no user executable,
+argv, shell, or user-provided environment surface.
+
+
+## V0.4.5 fixed operation registry
+
+V0.4.4 target evidence established the end-to-end execution chain. V0.4.5 widens only semantic
+authority, not executable authority. The same fixed native worker contains exactly two transforms:
+`uppercase_ascii` and `lowercase_ascii`. The operation id is checked independently at every layer:
+MCP schema, Node executor, native launcher, AppContainer worker evidence, contained-result validator,
+signed receipt execution evidence, and independent verifier semantic recomputation. Any other id is
+rejected before execution.
+
+
+## V0.4.6 fixed executable registry
+
+V0.4.5 target evidence proved the two-operation semantic dispatcher end to end through both direct contained execution and the MCP tool. V0.4.6 adds one second package-local executable without exposing executable selection directly.
+
+Registry:
+
+- `uppercase_ascii` -> `contained-transform-v1` / `contained-transform-worker.exe`
+- `lowercase_ascii` -> `contained-transform-v1` / `contained-transform-worker.exe`
+- `reverse_bytes` -> `contained-reverse-v1` / `contained-reverse-worker.exe`
+
+Every layer rejects worker identity drift. The caller still supplies only an operation enum, workspace-relative input/output paths, and the existing bounded timeout. There is no executable path, argv list, shell, or environment input.
+
+
+## V0.4.7 build-generated worker manifest attestation
+
+V0.4.6 target evidence proved three semantic operations through two package-local native worker binaries over both direct and MCP contained execution paths. V0.4.7 does not widen caller authority. It adds a target-build evidence layer named `bin/WORKER-REGISTRY.txt`.
+
+The canonical manifest binds:
+
+- schema `deadbyte.worker-registry.v1`
+- manifest version `0.4.7`
+- policy `compile-time-operation-to-executable`
+- `deadbyte-exec.exe` SHA-256
+- each operation -> worker id mapping
+- each worker id -> executable basename mapping
+- each worker executable SHA-256
+
+Before a contained launch, Node parses the exact manifest key set, checks the source compile-time registry against it, and hashes the launcher plus both worker binaries. The native launcher independently parses the same manifest, hashes those binaries with Windows BCrypt SHA-256, verifies the selected worker mapping, copies the selected worker into the ephemeral AppContainer profile, and verifies that copied image hash again before `CreateProcessW`.
+
+Runtime evidence and the signed receipt include:
+
+- `worker_manifest=WORKER-REGISTRY.txt`
+- `worker_manifest_sha256`
+- `worker_manifest_verified=true`
+- `worker_source_sha256`
+
+The independent verifier reopens the build manifest and current package-local runtime images and requires those hashes and mappings to match before semantic verification succeeds. This is local build/runtime attestation only; it is not remote or hardware attestation and does not defend against a fully compromised Windows host.
+
+## V0.5.0 invocation challenge + request digest binding
+
+V0.5.0 does not widen the operation or executable registry. It closes the
+fresh-invocation trust loop before any future authority expansion.
+
+For each contained execution Node generates a fresh 32-byte random challenge and
+computes `invocation_request_sha256` over canonical JSON with these exact fields:
+
+- `schema=deadbyte.invocation.v1`
+- `challenge`
+- `operation`
+- input snapshot SHA-256
+- worker registry manifest SHA-256
+- selected worker id
+- selected worker source SHA-256
+
+`deadbyte-exec.exe` receives the challenge and digest as host-internal arguments,
+hashes the imported bytes independently with BCrypt, reconstructs the canonical
+request, and refuses worker creation if the digest differs. The selected worker
+receives the same challenge/digest and writes them into its proof. The Node result
+validator requires the top-level launcher evidence and worker proof to match the
+fresh challenge for the current execution before output export or receipt signing.
+
+The signed receipt binds these fields. The independent verifier recomputes the
+request digest from the authenticated input snapshot hash plus current manifest and
+worker evidence. Pre-V0.5.0 contained receipts with no invocation fields remain
+verifiable under their historical contract. Partial invocation evidence is rejected.
+
+This is anti-stale-result binding, not a global receipt-consumption database. Old
+receipts remain valid historical evidence.
+
+### One-shot Windows gate
+
+`npm run gate:windows` runs the complete target proof sequence in one PowerShell
+5.1-compatible batch and stops on the first failure:
+
+1. source/adversarial tests
+2. MCP protocol smoke
+3. native containment/execution build
+4. frozen containment regression smoke
+5. direct contained execution smoke
+6. MCP-contained execution smoke
+
+The direct and MCP-contained smokes also require unique challenges across executions;
+the direct path repeats the same uppercase operation/input and requires a different
+challenge and request digest while preserving the same semantic output hash.
+
+
+## V0.6 active network-denial evidence
+
+V0.6 adds an active per-invocation loopback TCP denial probe without widening the operation registry. The trusted launcher binds a listener to `127.0.0.1` on an ephemeral port and first proves the endpoint is live with a successful host-side connection. The listener remains open while the AppContainer worker attempts the exact same endpoint.
+
+A V0.6 contained result is accepted only when the host positive control succeeded, the worker attempted the connection, the contained connection did not succeed, a non-zero Winsock error was observed, and `active_network_denial_ok=true`. The receipt and independent verifier bind this evidence.
+
+The proof is intentionally local and deterministic: it does not depend on Internet availability or DNS. Combined with `capability_count=0`, it provides active runtime evidence for the network boundary that previously existed only as a declared-capability claim. It is not represented as exhaustive proof of every possible protocol, brokered path, or compromised-host condition.
+
+Network evidence fields include:
+
+- `network_policy=zero-capabilities-plus-active-loopback-denial`
+- `network_probe_schema=deadbyte.network.loopback.v1`
+- `network_probe_target=127.0.0.1`
+- `network_probe_host_control_ok=true`
+- worker proof `network_probe_attempted=true`
+- worker proof `network_connect_succeeded=false`
+- worker proof `network_connect_error>0`
+- worker proof `active_network_denial_ok=true`
+
+## V0.6 execution-authority boundary
+
+`contained_transform` remains a strict semantic operation API. The MCP schema is a strict object and rejects extra execution-control properties. The native launcher separately requires one exact ordered argv shape generated by the trusted Node control plane.
+
+Rejected authority includes executable paths, worker paths, worker IDs, argv arrays, command lines, shell selection, caller-provided environment, AppContainer capability selection, Job-policy overrides, and host workspace mapping. `authority:smoke` tests both the MCP boundary and a direct native attempt containing an extra `--worker C:\Windows\System32\cmd.exe` override. The native attempt must exit 64 before worker execution.
+
+V0.6 therefore closes authority evidence without adding `command_run`.
+
+## V0.6 one-shot target gate
+
+`npm run gate:windows` runs source/adversarial tests, MCP protocol smoke, native containment build, execution-authority smoke, regular AppContainer smoke, direct contained execution smoke, and MCP-contained smoke in one fail-fast PowerShell 5.1-compatible gate.

package/docs/NETWORK.md

@@ -0,0 +1,64 @@
+# DEADBYTE V0.6 ACTIVE NETWORK PROOF
+
+## Goal
+
+Replace the old claim `network_capabilities=0` with an observed runtime denial
+measurement that has a positive control and does not depend on Internet or DNS
+availability.
+
+## Probe construction
+
+For every contained execution the trusted host launcher:
+
+1. initializes Winsock;
+2. binds a TCP listener to `127.0.0.1:0`;
+3. reads the assigned ephemeral port;
+4. connects to that listener from the trusted host process;
+5. accepts the host connection, proving the endpoint is live;
+6. keeps the listener open;
+7. launches the zero-capability AppContainer worker;
+8. passes only the numeric probe port as a fixed internal worker argument.
+
+The worker creates a nonblocking TCP socket and attempts
+`127.0.0.1:<probe-port>`. A successful connection is a containment failure. The
+worker can pass only after an attempted connection is denied with a non-zero
+Winsock error.
+
+## Required evidence
+
+Top-level launcher evidence:
+
+- `network_capabilities=0`
+- `network_policy=zero-capabilities-plus-active-loopback-denial`
+- `network_probe_schema=deadbyte.network.loopback.v1`
+- `network_probe_target=127.0.0.1`
+- `network_probe_port` is a valid TCP port
+- `network_probe_host_control_ok=true`
+
+Worker proof evidence:
+
+- `network_probe_attempted=true`
+- probe target and port match the launcher evidence
+- `network_connect_succeeded=false`
+- `network_connect_error>0`
+- `network_connect_timed_out` is recorded
+- `active_network_denial_ok=true`
+
+Node validates these fields before export/signing. The independent verifier
+requires the complete set for V0.6 receipts.
+
+## Why loopback
+
+The probe provides a deterministic live endpoint under the same host's control.
+Microsoft documents AppContainer network isolation as capability-mediated and
+exposes explicit APIs for configuring which AppContainer SIDs may send loopback
+traffic. A successful host positive control plus denied contained connection is
+therefore useful active evidence of the boundary without depending on external
+network health.
+
+## Scope
+
+This proves denial of the tested live loopback TCP connection for each accepted
+invocation while the token reports zero capabilities. It does not claim packet-
+level observation of every network protocol, brokered service, kernel compromise,
+or fully compromised host.

package/docs/R221-STRICT-OUTPUT-CONTRACT.md

@@ -0,0 +1,24 @@
+DEADBYTE MCP V0.8.0 / R22.1
+===========================
+
+STRICT OUTPUT CONTRACT
+----------------------
+R22.1 adds explicit MCP outputSchema metadata to all 15 valid tools while
+preserving the R22 authority model and V0.8.0 signed task-receipt identity.
+
+Every tool advertises a root object schema with additionalProperties=false.
+Handlers also validate structuredContent locally before returning it, including
+isError responses that the MCP SDK intentionally does not output-validate.
+
+The HTTP Bridge preserves both inputSchema and outputSchema when re-registering
+downstream tools. The four exact valid catalogs remain 5, 8, 12, and 15 tools.
+No new executable, argv, shell, environment, host-root, or auto-arm authority is
+introduced.
+
+VERIFICATION
+------------
+The public R22.1 gate requires all exposed tools to carry strict output schemas,
+then executes proof, contained AppContainer work, durable agent execution, and
+signed receipt verification through the public HTTPS MCP path.
+
+The normal privileged host-plane state remains DISARMED.

package/docs/REFERENCES.txt

@@ -0,0 +1,117 @@
+PRIMARY REFERENCES
+==================
+
+Microsoft Learn — Launch an AppContainer
+https://learn.microsoft.com/windows/win32/secauthz/implementing-an-appcontainer
+
+Microsoft Learn — UpdateProcThreadAttribute
+https://learn.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
+
+Microsoft Learn — AppContainer isolation overview
+https://learn.microsoft.com/windows/win32/secauthz/appcontainer-isolation
+
+Microsoft Open Specifications — NTSTATUS values
+https://learn.microsoft.com/openspecs/windows_protocols/ms-erref/
+
+V0.3.9 CHILD CONTROL
+- Microsoft Learn: UpdateProcThreadAttribute
+  PROC_THREAD_ATTRIBUTE_CHILD_PROCESS_POLICY
+  PROC_THREAD_ATTRIBUTE_JOB_LIST
+- Microsoft Learn: JOBOBJECT_BASIC_LIMIT_INFORMATION
+  JOB_OBJECT_LIMIT_ACTIVE_PROCESS
+  JOB_OBJECT_LIMIT_BREAKAWAY_OK
+  JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK
+- Microsoft Learn: Process Creation Flags
+  CREATE_BREAKAWAY_FROM_JOB
+
+V0.3.13 ATOMIC JOB CANDIDATE
+---------------------------
+Microsoft Learn: UpdateProcThreadAttribute — PROC_THREAD_ATTRIBUTE_JOB_LIST
+Microsoft Learn: Job Objects — CreateProcess children remain in the job by default
+Microsoft Learn: JOBOBJECT_BASIC_LIMIT_INFORMATION — ACTIVE_PROCESS_LIMIT
+Microsoft Learn: Process Creation Flags — CREATE_BREAKAWAY_FROM_JOB requires BREAKAWAY_OK
+
+V0.3.13 TOKEN / MODE EVIDENCE
+-----------------------------
+Microsoft Learn — GetTokenInformation
+https://learn.microsoft.com/windows/win32/api/securitybaseapi/nf-securitybaseapi-gettokeninformation
+
+Microsoft Learn — TOKEN_INFORMATION_CLASS
+TokenIsAppContainer
+TokenCapabilities
+TokenIsLessPrivilegedAppContainer
+https://learn.microsoft.com/windows/win32/api/winnt/ne-winnt-token_information_class
+
+Microsoft Learn — DoNotAddAllApplicationPackagesToRestrictions
+ALL_APPLICATION_PACKAGES is used on files, registry keys, and other resources
+to grant access to processes running in AppContainer.
+https://learn.microsoft.com/windows/win32/com/donotaddallapplicationpackagestorestrictions
+
+V0.3.13 design:
+- do not treat an unavailable LPAC-specific query as proof of regular mode
+- preserve the query's Win32 error
+- require active ALL_APPLICATION_PACKAGES access behavior for regular mode
+- require LPAC-specific token query success plus AAP denial for LPAC mode
+
+
+V0.4 CONTAINED EXECUTION REFERENCES
+-----------------------------------
+Microsoft UpdateProcThreadAttribute / PROC_THREAD_ATTRIBUTE_JOB_LIST:
+https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
+
+Microsoft Job Objects and breakaway semantics:
+https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects
+
+Microsoft Process Creation Flags / CREATE_BREAKAWAY_FROM_JOB:
+https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags
+
+V0.4.1 WINDOWS ANONYMOUS-PIPE EOF
+---------------------------------
+Microsoft Learn — ReadFile function, Pipes section:
+For an anonymous pipe whose write handle has been closed, ReadFile returns FALSE
+and GetLastError returns ERROR_BROKEN_PIPE.
+https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile
+
+Microsoft Learn — Anonymous Pipe Operations:
+ReadFile can return when all write handles to the anonymous pipe have been closed.
+https://learn.microsoft.com/en-us/windows/win32/ipc/anonymous-pipe-operations
+
+V0.4.3 environment/process creation references
+---------------------------------------------
+Microsoft CreateProcessW
+https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
+
+Microsoft CreateEnvironmentBlock
+https://learn.microsoft.com/en-us/windows/win32/api/userenv/nf-userenv-createenvironmentblock
+
+Microsoft System Error Codes 0-499 (ERROR_ENVVAR_NOT_FOUND = 203)
+https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
+
+V0.4.4 LOCALAPPDATA/AppContainer environment references
+-------------------------------------------------------
+Microsoft Learn - Launch an AppContainer
+https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer
+  - AppContainer profile is exposed through LOCALAPPDATA.
+  - TEMP and TMP are rerouted under the AppContainer profile.
+
+Chromium Windows sandbox target_process.cc
+https://chromium.googlesource.com/chromium/src/+/e879db3b2fa4d06359ec4d6a7d9419d73e49838f/sandbox/win/src/target_process.cc
+  - filtered target environment keeps Path, SystemDrive, SystemRoot, TEMP, TMP, LOCALAPPDATA.
+  - source comment: LOCALAPPDATA is needed for App Container processes.
+
+V0.6 ACTIVE NETWORK-DENIAL REFERENCES
+-------------------------------------
+Microsoft Learn — AppContainer isolation
+https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation
+  - AppContainer network access is capability-mediated.
+
+Microsoft Learn — NetworkIsolationSetAppContainerConfig
+https://learn.microsoft.com/en-us/windows/win32/api/netfw/nf-netfw-networkisolationsetappcontainerconfig
+  - Configures AppContainer SIDs permitted to send loopback traffic.
+
+Microsoft Learn — NetworkIsolationGetAppContainerConfig
+https://learn.microsoft.com/en-us/windows/win32/api/netfw/nf-netfw-networkisolationgetappcontainerconfig
+  - Retrieves AppContainer SIDs permitted to send loopback traffic.
+
+V0.6 uses a host-positive-control loopback listener and requires the contained
+connection attempt to be denied. It does not depend on public Internet or DNS.

package/docs/TRUST.md

@@ -0,0 +1,46 @@
+# TRUST MODEL
+
+V0.2 introduces one authority unavailable to the task workspace: an Ed25519
+private signing key.
+
+Private key default:
+
+```text
+%USERPROFILE%\.deadbyte-mcp\trust\ed25519-private.pem
+```
+
+Public key default:
+
+```text
+%USERPROFILE%\.deadbyte-mcp\trust\ed25519-public.pem
+```
+
+The verifier identifies the configured public key by SHA-256 of DER-encoded
+SPKI and requires the receipt key_id to match.
+
+This protects evidence authenticity only while the private key remains secret
+and the verifier's public-key configuration remains trusted.
+
+It does not prove which physical machine executed the operation and does not
+protect against a fully compromised host.
+
+## V0.8 / R22 agent authentication
+
+The same Ed25519 trust key authenticates multiple explicitly separated message
+domains. A signature from one domain is not accepted as another:
+
+```text
+DEADBYTE-RECEIPT-V1\0
+DEADBYTE-AGENT-PLAN-V1\0
+DEADBYTE-AGENT-EVENT-V1\0
+DEADBYTE-AGENT-CANCEL-V1\0
+```
+
+Agent plan and event SHA-256 values remain integrity/addressing structures, not
+authentication. The runtime verifies the Ed25519 envelope before trusting plan or
+event contents. Therefore recomputing a plan digest or a complete event hash chain
+does not forge authenticated state.
+
+Cancel requests are also signed before they may become a signed task_cancelled
+event. This prevents an unsigned workspace file from being promoted into trusted
+agent history.

package/docs/V070-HARDENING.md

@@ -0,0 +1,48 @@
+# V0.7 HARDENING CONTRACT
+
+## Done means observed, not configured
+
+A lifecycle state file is never authoritative. Runtime state must be derived from
+observed process identity and health probes. PID alone is insufficient because
+Windows reuses process IDs.
+
+A runtime identity tuple is:
+
+`pid + creation time + image path + image SHA-256 + instance nonce`
+
+## Receipt V2
+
+V2 adds signed request and runtime identity envelopes. Canonical JSON remains the
+signature input. V1 verification remains supported for historical evidence.
+
+## Zero-trust export
+
+The contained result is decoded, length-checked, and semantically recomputed on
+the host before `open(..., 'wx')`. This is deliberately separate from the later
+independent evidence verifier.
+
+## Non-claim
+
+A runtime nonce is signed process identity evidence, not hardware attestation.
+The active loopback denial remains a bounded network observation, not a proof of
+every possible host/network compromise model.
+
+## Boundary conditions
+
+The path policy closes pre-existing traversal, symlink/junction escape, ADS, DOS device,
+and Windows alias surfaces before I/O. It does not claim to defeat a hostile concurrent
+host process racing directory reparse-point replacement between validation and Node file I/O.
+Eliminating that host-level TOCTOU class requires a future native handle-relative filesystem
+boundary; V0.7 does not pretend otherwise.
+
+The controller is intentionally outside the capability trust path. Its local launch config is
+trusted administrator input and is never exposed as an MCP tool argument. PID ownership is
+accepted only when PID, creation time, image path, and image SHA-256 still match the ledger.
+
+The V0.7 source package does not claim a Windows native PASS until `npm run gate:windows` is
+observed on the Windows target.
+
+## Public transport gate
+
+The V0.7 controller uses the SDK Streamable HTTP client pinned to protocol 2026-07-28 for
+public smoke tests. A plain HTTP status code is not treated as MCP evidence.