Security profiles

Find the profile that owns the effect you need, what it controls, what it refuses, and what the host must install for it.

On this page

A security profile names the component that performs an effect and everything that component needs to keep its promise. Mediation, retained information flow, durable recovery, and process confinement answer different requirements, so an application often composes several profiles on one operation.

Choose from the effect, then install that path's dependencies: the entrypoint, the authenticated caller source, the executor, the state authorities, the credential owner, and the recovery owner. When two teams each assume the other supplies one of those roles, the path is not ready to serve.

The effect you need decides where to start

Write one successful task in ordinary language and trace its resource accesses, then add its plausible unwanted variations: another repository, a public pull request in place of the team channel, a second refund for order-77. A suitable profile gives each variation an enforcement point and leaves the intended task usable.

Workload	Start with	Add when the application requires it
Inspect selected local tools	Governed MCP and retained receipts	Host tool restrictions and native confinement
Evaluate a policy inside an application	Portable evaluation with trusted inputs	State authorities and an effect-capable host
Read and delegate work on customer terms	Authenticated context and durable flow state	Destination clearance and bounded declassification
Use a provider credential	Broker reference and constrained request	Original durable capture and outcome reconciliation
Run an untrusted native tool	Verified launch and retained resource grants	Brokered access for credentialed external operations

A local coding host that launches a governed MCP server while keeping its own unrestricted shell still has that shell as a separate path to the workspace. A portable label check works inside an application, and the host still supplies authenticated context, durable principal and lineage state, and an adapter that preserves the declaration. The reader of customer terms, the pricing team's channel, and the public pull request each need their own tool flow declaration under the same profile.

A governed MCP connection pins two signed inputs before its child starts

The security-agent project runs this profile against the pricing project's workspace server. After python3 run.py has provisioned the launch material, register this command with a coding host:

Terminal · in security-agentbash

DIR="$(pwd -P)"
LAUNCH="$DIR/.chio/launch"
PYTHON="$(python3 -c 'import os, sys; print(os.path.realpath(sys.executable))')"
chio --receipt-db "$DIR/.chio/receipts.db" \
  --session-db "$DIR/.chio/session.db" \
  mcp serve --policy "$DIR/policy.yaml" --server-id workspace \
  --server-name "Larkfield pricing workspace" --server-version 1 \
  --signed-manifest "$LAUNCH/signed-manifest.json" \
  --manifest-public-key "$(cat "$LAUNCH/manifest-public-key")" \
  --cage-policy "$LAUNCH/cage-launch-policy.json" \
  --cage-policy-signer "$(cat "$LAUNCH/cage-policy-signer")" \
  -- "$PYTHON" "$DIR/server.py"

Each owner is visible: the edge authenticates and mediates the session, the policy scopes the workspace routes, the Python subprocess owns file I/O under workspace/, and the two SQLite stores retain session and decision history. The signed launch mode verifies the child without installing Linux cage confinement, and a host shell remains another path to the same file.

A missing launch input refuses construction

Terminalbash

chio mcp serve --policy policy.yaml --server-id workspace -- /usr/bin/true

Output

error: the following required arguments were not provided:
  --cage-policy <CAGE_POLICY>
  --cage-policy-signer <CAGE_POLICY_SIGNER>

The CLI exits 2 before any child starts. Repair the signed launch inputs instead of moving the call to an ungoverned server. This argument-parser refusal differs from a runtime authority failure: a flow-required tool also needs authenticated context and the host's complete durable security bundle, which a launch policy cannot supply.

Execution profiles

Six profiles, each named by the component that performs the effect, with what it controls and what the host installs for it.

Portable decision core

Controls: capability and policy evaluation over supplied inputs.
Host owns: I/O, identity acquisition, persistence, and dispatch.
Runs on: any host; portable label evaluation and the security-research project need no Linux process boundary. See Portable kernel core.

Governed MCP host

Controls: tool calls routed through the secured MCP edge.
Host owns: binding the session, configuring policy and durable stores, and preserving supported request metadata.
Runs on: the agent tutorial, with local persistent receipt and session stores.

Durable native host

Controls: admission, physical capture, guarded output, and recovery of the original operation.
Host owns: the complete security authority bundle, with live ownership retained through the return path. A release checkpoint controls which guarded response may be replayed after interruption.

Authenticated caller delivery

Controls: a reserved operation delivered to a pinned external executor.
Host owns: the executor ledger, signed reports, the dispatch nonce, and the original capture. The executor is a distinct authority: its signed report binds the original delivery and configured pin, and it cannot stand in for a native release owner.

Confined native tool

Controls: an authorized executable and the operating-system resources it may use.
Host owns: verifying launch authority and observing the enforced exec transition. A confined tool that makes credentialed calls keeps the prepared broker connection selected for that operation.
Requires: Linux x86_64, kernel 6.7 or later, Landlock ABI 4, seccomp filtering, and the process and descriptor facilities the cage helper uses. The launch handshake verifies what was installed, and an unsupported kernel or incomplete restriction produces an explicit refusal. See Process confinement.

Brokered provider request

Controls: credential use for an exact destination and a constrained request.
Host owns: keeping secrets and provider I/O in the broker, and retaining attempt and authority state, so durable operation ownership ties each use to an allowance and a recovery history. See Credential broker.

Consumer profiles and entry points

The consumer boundary ledger sorts the same space by which physical path dispatches the call. Its six profiles are the ones bypass resistance lists; use them to pick an Execution entry-point page.

Portable verification

An evaluator, never an execution path: Portable kernel core.

Harness

A synthetic or local connector with no advertised production authority, listed in bypass resistance.

Controls and their owners

Identity enters through the authenticated host.
Scope comes from signed capability authority.
Labels come from verified declarations, classified input, and retained state.
Process resources are controlled by a cage profile.
Credential material is owned by the broker.
Replay after interruption is controlled by a release checkpoint.

Combined components bind the same operation. A denial is never translated into a call on an ungoverned connector, evidence from a finished operation is never restored into a new live dispatch owner, and the constructor and restart paths enforce the same profile.

Adapter contracts

An adapter carries the complete supported authorization: operation identity, approval proposal, proof-of-possession material, flow declaration, and authenticated context where required. A translation that drops a security field changes the contract, so negotiation rejects that combination. An SDK can preserve a wire field without verifying its signature or owning its durable state, and a protocol conversion can carry an ordinary call while refusing one that needs an aggregate allowance, an approval set, or native release authority; check the role of the API you call.

Service start order

On the reference runtime, start order follows the systemd units and trust control's own startup check: the remote MCP edge hard-requires trust control, and when trust control runs with its authority-keyring configuration, its startup fails until the key-log witnesses and auditors are ready, with systemd retrying the unit until they are. Service roles gives the sequence.

Composition acceptance

Keep a deployment record naming the host entrypoint, manifest digest, policy identity, installed stores, executor pin, and target platform. Run an allowed call, an unsupported-profile refusal, a current-revocation denial, and a restart case through that entrypoint, and check that each refusal happens before launch or provider authority is acquired. Repeat the acceptance on upgrade against the new adapter, manifest, and runtime configuration together, since compilation shows API compatibility and only these runs show behavior. Continue with hardening and execution security.

Startup and admission refusals

First ask which authority the composition could not establish: a missing runtime bundle, an absent request-context resolver, an unsupported confinement platform, and an invalid destination contract need different repairs, and none of them is a reason to weaken policy. Record the entrypoint, declared requirements, installed authorities, and the stage that refused. If no protected effect was attempted, keep the record as evidence of the construction boundary. If a capture already exists, switch to the operation's recovery procedure first: installing a missing service does not authorize a new attempt for an operation already captured.

Each execution path refuses in its own words

A refusal tells you which profile stopped the call. Read it against the path that dispatched it.

Refusal contracts by execution path

What each profile refuses

A trusted native host's refusals are read in full on native secure invocation. At dispatch capture, the kernel's callback boundary around the native flow adapter discards what the adapter returned and substitutes one fixed reason, security dispatch outcome requires reconciliation: security native dispatch capture callback failed; authoritative recovery required, to which a credential rollback failure may be appended, so an authority mismatch and an unrecorded input taint found there read the same in the response.

A mediated protocol call is refused by its session credential, HTTP 401 on protected native hosts once a coding host's credential expires or is revoked; by a session presented on the wrong transport, origin, or identity, HTTP 403 on control surfaces; or by an extension its session never negotiated, JSON-RPC error -32602 on bypass resistance.

An ordinary kernel host installs no active defense, so it refuses a flow-required manifest before acquiring effect-capable launch authority: error[CHIO-CLI-ACTIVE-DEFENSE-REQUIRED]: a flow-required manifest needs an active-defense host, and this remote MCP edge installs no flow runtime, or the matching refusal on the stdio and wrapping paths.

Caller transport. A reservation is not permission to execute: every POST /v1/evaluate verdict body carries execution_authorized: false. A start or report the kernel cannot authenticate or finalize, a revoked capability, or a sidecar with no mediation kernel returns HTTP 409 chio_caller_delivery_rejected; a start the kernel denies returns HTTP 403 with "status": "deny" and its receipt. See caller delivery.
Portable evaluator. It decides and never dispatches. Given a governed intent, an approval token, a threshold proposal, or a supplemental authorization, the browser, mobile, and C++ adapters each return an error ending "portable evaluation cannot authenticate governed approvals or supplemental authorization" before evaluation. Portable kernel core lists every portable refusal.
Harness. It has no production path to refuse from, so a harness pass is evidence about the harness, never about confinement, hosted production, or hardware.

Next: harden the path you chose

Deployment hardeningClose the paths the kernel never sees before serving traffic.Execution securityFollow a permitted call from admission to one committed effect.

PreviousThreat Model NextAuthority Model