# One approved provider request through a Chio process This source kit connects a trusted request issuer and a worker to the native broker process host. The operation creates an issue at an authorized HTTPS endpoint. The broker owns the provider credential and connection; the worker receives a private process descriptor and a prepared request. Use Rust 1.94.1+, Python 3.11+, `jq`, and the `chio` CLI of the same release. The project depends on the published `chio-core-types` and `chio-secret-broker` crates. Native broker execution and credential provisioning require the supported Linux profile. The archive contains application source only. It does not bundle the runtime or qualify an arbitrary installed version. ## Components | File | Role | | --- | --- | | `configure_host.py` | Build a complete native host configuration from retained operator deployment inputs. | | `policy.yaml` | Allow two `native-broker/send` calls under a one-hour parent grant. | | `src/main.rs` | Issue a five-minute, one-use broker capability for the exact issue body and destination. | | `src/provision.rs` | Compute an administrative provisioning intent; submit it with independently supplied governed approvals; verify and retain the original mutation receipt. | | `send.py` | Submit one prepared call through the authenticated process socket and retain its response and receipt. | | `inspect_issue.py` | Decode the retained provider body after independently verifying the original call. | The two Rust binaries are trusted operator programs. The worker must not receive their private input directories. In particular, request approval requires the accepted issuer key; the worker cannot approve its own request by choosing a key. ## Build Pull the project and build it: ```sh chio new security-broker --example security-broker cd security-broker cargo build --locked --bins umask 077 mkdir operator evidence ``` The names below are concrete working paths, not preinstalled files. Copy the example plans into `operator`, populate them from the selected deployment, and keep the resulting directory private. Plan paths resolve relative to each plan. ## Supply the broker deployment Credential Custody and the reference-runtime deployment own service assembly: the canonical v5 daemon configuration, four broker databases, independently anchored migration ledger, separate sealed master/signing descriptors, trusted authority endpoint, governance approvers, service accounts and Linux confinement. Starting a unit does not provision these inputs or approve a migration. `operator/deployment.json` follows `deployment.example.json`: - `daemon_config`: the retained operator-selected daemon configuration. Its `trustedCapabilityIssuer`, `trustedAuthority`, `brokerIdentity`, tenant, audience, adapter and placement become this host's independent pins. - `launch_directory`: the signed native launch assets for the actual broker MCP executable and arguments. The cage policy includes the private broker socket and expected daemon PID/UID/GID for the current supervised epoch. - `launch_record`: the retained JSON result of `chio security provision-reference-runtime`; `cagePolicyPublicKey` pins the launch policy. Use the separately authenticated provisioning result, not a value supplied by the worker or copied out of the policy being verified. - `broker_mcp_binary`: the matching installed `chio-broker-mcp` executable. - `authority_seed_file`: the separate retained admission-authority seed, in the hexadecimal format consumed by the native process host. Its public key must match `trustedAuthority`. This is not the broker receipt signer or master key. - `revocation_authority_domain`: the independently selected domain used by that deployment's liveness and revocation authority. - `state_directory`: the new process state directory. The daemon's `authoritySocketPath` must equal this absolute directory plus `broker-authority.sock`. - `isolation_epoch_id`: the retained operator-selected isolation epoch for this host. Generation starts at 1 in this example; do not reset live state to reuse it. - `ipc_timeout_ms`: the host's broker IPC timeout; default 3,000 ms. - `fence_ttl_ms`: the native flow policy lifetime; default 10,000 ms. Capture must finish before this policy expires. Both settings accept integers from 1 through 30,000 ms, matching the native host's bounds. Select them from the deployment's observed latency and retain them with its configuration. The daemon has its own IPC and authority RPC settings; changing this plan does not change the daemon. These deadlines are separate from the signed provider request's three-second timeout and the caller proof's sixty-second freshness window. A longer configured policy lifetime does not disable current-authority checks or renew an expired proof. A transport timeout can leave the original outcome unresolved. The assembler selects a simple `PRIVATE_INPUT` classifier rule to demonstrate a private compartment. It is not a comprehensive data classifier. Install the deployment's actual classifier and flow floor for general inputs. This example uses the ungoverned native key profile; a governed keyring deployment also needs its configured key history and independent verifier, not an omitted keyring. The supervisor must coordinate the host and daemon: determine the intended daemon's peer identity, provision its signed launch binding, initialize and prepare the stopped host, then start the serving host's authority endpoint and release/start the daemon. Confirm broker readiness before admitting the worker. Never copy a dead broker's PID into a new launch policy. The process-boundary verification harness uses a start gate to make this ordering explicit; the production service manager supplies its own lifecycle coordination. ## Provision the credential through the administrative path Credential creation is a separate governed operator action. Run the provisioning binary under the authorized Linux admin identity, with access to the broker's private socket. The provider credential is a private, singly linked file owned by that operator; the program reads its exact bytes without trimming a newline. Do not put it in an argument, environment variable, request plan or worker tree. Create a private provisioning plan with these fields: | Field | Source | | --- | --- | | `socket_path` | Absolute normal IPC socket from the daemon configuration. | | `expected_pid`, `expected_uid`, `expected_gid` | The supervisor's live daemon peer identity. | | `tenant_scope` | Daemon tenant. | | `trusted_receipt_signer` | Independently provisioned broker public key. | | `credential` | `{ "provider": "generic-https", "credentialId": "issue-writer", "version": 1 }`, or the exact provider/id/version being provisioned. | | `secret_file` | Private file containing the provider-owned demonstration credential or real authorized credential. | | `authorization_file` | Canonical `GovernedAdminAuthorizationEnvelope` from the deployment's threshold approval workflow. | | `response_file` | A new private path for the original broker response. | ```sh target/debug/provision-credential intent operator/provision.json \ > operator/provision-intent.json ``` Submit that exact intent digest, tenant and credential version to the configured governance workflow. Its approved tokens must bind the same subject, request, intent and threshold proposal, with the required independent approvers and a current expiry. Save the canonical envelope at `authorization_file`. This program deliberately has no command to invent approvals or their proposal history. Existing governance supplies the authorization, and the daemon verifies and durably consumes it. Obtain these approvals before preparing the short-lived caller proof. Apply them only after the serving host and broker are ready, as shown under Submit and inspect. Before transmitting secret bytes, the client checks the socket's owner, mode and stable identity plus Linux peer PID/UID/GID. It retains the original response before interpretation, then verifies the mutation receipt's signature, trusted signer, tenant, credential, exact intent, approval digest and applied outcome. A timeout leaves the administrative outcome unresolved; retain the original intent and approvals for the owner's status/reconciliation procedure. ## Initialize the host and retain independent pins ```sh python3 configure_host.py --deployment operator/deployment.json --output operator/host chio process init --config operator/host/host.json --state .chio \ --aggregate-invocations 2 > operator/init.json jq -r '.kernel_key' operator/init.json > operator/kernel.pub jq -r '.action.parameters.runtime_id' .chio/process-bootstrap.json > operator/runtime-id ``` The host contains one route, `native-broker/send`. The policy limits each grant to two calls; initialization establishes a separate aggregate allowance of two. Keep `operator/host/host.json`, the original bootstrap and the independent public pin with the operator's records. The worker does not supply verifier trust. ## Approve and prepare an issue Copy `request-plan.example.json` to `operator/request-plan.json`. Select the authorized HTTPS issue endpoint of your code host; the plan names Larkfield's pricing repository at `issues.example.com`. Set the credential reference to the exact version selected by the approved provisioning plan. The issuer seed is a private **raw 32-byte** file whose public key matches the host's quota issuer. This encoding differs from the host authority seed's hexadecimal input. Review `issue.json` before signing it; even whitespace changes the body digest. ```sh target/debug/issue-request operator/request-plan.json chio process prepare-broker-call --state .chio --process root \ --operation-key create-issue \ --capability approved-issue/broker-capability.json \ --request approved-issue/provider-request.json \ --out approved-issue/prepared.json chio process credential --state .chio --process root \ --socket "$PWD/process.sock" --out worker.json chio process serve --state .chio --socket "$PWD/process.sock" ``` Run the preparation commands while the host is stopped. Preparation signs the request using the retained process key; it performs no provider request. Keep the original prepared bytes and operation key. The proof's 60-second freshness window applies to admission, so arrange the supervised service readiness before asking the worker to submit. An expired unused preparation needs explicit new operator preparation; a submitted operation must first be reconciled, not freshly signed. ## Submit and inspect With host and broker ready, the authorized operator applies the approvals obtained earlier from another terminal: ```sh target/debug/provision-credential apply operator/provision.json ``` After its receipt verifies, hand the worker the descriptor and prepared file and submit promptly within the proof's 60-second freshness window. Do not begin a human approval workflow after signing that proof. ```sh python3 send.py --connection worker.json --prepared approved-issue/prepared.json \ --operation-key create-issue --output evidence/create-issue jq '{request_id, verdict, terminal_state, output}' evidence/create-issue/response.json ``` The client exits 0 for an allowed completed value, 2 for a retained non-completed or denied response, and 1 for a transport, framing or persistence failure. It writes no process bearer to the evidence files. It never changes the operation key or proof, retries the provider, or declares a transport failure a rollback. The response contains the bounded provider result; inspect its status and application identifier separately from cryptographic completion. After stopping the process host, package and verify the original call: ```sh chio process attest-call --state .chio \ --request evidence/create-issue/request.json --context evidence/create-issue/context.json \ --response evidence/create-issue/response.json --out evidence/create-issue/observation.json RUNTIME_ID=$(cat operator/runtime-id) chio process verify-call --artifact evidence/create-issue/observation.json \ --trusted-kernel-pubkey operator/kernel.pub --runtime-id "$RUNTIME_ID" \ --request evidence/create-issue/request.json --context evidence/create-issue/context.json \ --trusted-broker-host-config operator/host/host.json ``` After verification, decode the bounded provider body: ```sh python3 inspect_issue.py evidence/create-issue/response.json ``` This preserves the original file and reports `http_status` separately from `provider_result`. It decodes the byte array as JSON, preserving non-ASCII text. A completed call can contain a provider error; inspect the returned issue identifier and status before treating the application work as successful. The inspection program does not verify receipts or authorize another attempt. Keep a provider-owned request/result observation when exercising delivery. It must identify the issue body/path and application result without recording the credential. Signature comparisons and a successful build do not demonstrate delivery. A controlled TLS fixture is scoped to its selected test trust root; it does not establish arbitrary production provider availability or OS isolation.