Authenticated identity

Each identity outlives a different thing

A long task outlives worker processes and network connections, and its transport credential can change while its original operations still need recovery. Several tasks can share one service account and still hold separate grants and histories.

Chio keeps the identities apart. The tenant is an isolation decision, the session is authenticated interaction context, the operation is one retained piece of work, and the durable actor is distinct from the credential used to reach it. A host can replace a failed worker without making its task a newly entitled actor, and incident response gets a precise target, since a connection, a process, and a grant each need a different withdrawal.

The host establishes these bindings before it interprets tool arguments. A worker may request a file path or attach a tracing label; choosing another tenant or a sibling's authority would change whose work is performed, so that choice belongs to the host.

The host pins the session before it normalizes the call

The host authenticates the transport and pins the resulting session context, retaining tenant, agent, session anchor, and authentication epoch together. The kernel uses that context when it evaluates authority and signs evidence. A change in authentication creates a new binding, and requests already admitted keep the one they started with.

In a multitenant service, request-local state ends with its request, and an old operation may be reconciled long after its HTTP request closed. Its retained context names the original tenant, whichever request happens to be running now.

pub struct SessionRequestStart {
    pub session: SessionAnchorSnapshot,
    pub lineage: RequestLineageRecord,
}

pub struct RequestLineageRecord {
    pub request_id: RequestId,
    pub session_anchor_id: String,
    pub auth_epoch: u64,
    pub parent_request_id: Option<RequestId>,
    pub operation_kind: OperationKind,
    pub started_at: u64,
    pub terminal_state: Option<OperationTerminalState>,
}

The repository host selects the process, and the arguments select a path

The Execution host opens the retained runtime, takes the tenant and isolation epoch from its trusted security profile, creates the reviewer process with its original capability, and issues the worker a connection credential. Tool arguments supply only the requested relative path.

fn worker_service(
    state: &Path,
    kernel: ChioKernel,
    capability: &CapabilityToken,
) -> Result<WorkerService> {
    let runtime = ProcessRuntime::open(state.join("process.db"), Arc::new(kernel))?
        .with_security_profile(ProcessSecurityProfile {
            tenant_id: "larkfield".into(),
            isolation_epoch_id: "review-epoch-1".into(),
            generation: 1,
        })?;
    runtime.create_root(
        "reviewer",
        capability,
        ProcessLimits {
            max_processes: 1,
            max_depth: 0,
            max_calls: 16,
            state: Default::default(),
        },
    )?;
    let service = WorkerService::new(runtime);
    service.revoke_credentials("reviewer")?;
    Ok(service)
}

The example owns one fixed tenant, larkfield; tenant selection is outside its API. On restart the service revokes the reviewer's old credentials before it publishes a fresh connection. The runtime ID reopens unchanged, the tenant and isolation epoch must match the retained profile, the process stays reviewer, and the capability ID and subject key are retained with current admission still required. The bearer is replaced and the previous one withdrawn, and an operation key is reused only for the same logical request.

Trace IDs, display names, and user tags serve correlation and decide nobody's right to spend, disclose, or execute. Chio commits to their bytes in the original request without promoting them into signed authority fields. A host can report that evaluation failed, while the kernel's signing identity, policy identity, tenant, and decision semantics stay the kernel's; the signed observation binds the normalized operation and the authenticated session.

jq '{runtime_id, process_id, capability_id}' .chio/connection.json
jq '{capability_id, tool_server, tool_name,
  attribution: .metadata.attribution,
  process: .metadata.chio_process}' read-pricing.receipt.json
chio receipt verify --input read-pricing.receipt.json \
  --trusted-kernel-pubkey .chio/kernel.pub

{
  "capability_id": "cap-01a0f85a-0bf0-72c0-8f4d-a154ff94813a",
  "tool_server": "workspace",
  "tool_name": "read_file",
  "attribution": {
    "delegation_depth": 0,
    "grant_index": 0,
    "issuer_key": "3bf50433b9c903b55d4f873cb962745fb68b2707874ea2da45ae35221007f8bb",
    "subject_key": "7f009c64ebc2d385372daa944160feb9319f29a3f7e272f709231eeacc4a3590"
  },
  "process": {
    "attempt": 1,
    "operation_key": "read-lib-v1",
    "process_id": "reviewer",
    "recovery_policy": "known_outcome_only",
    "request_sha256": "886e5f29b0694ed7c0535361e91e694d3574facf46da546e2ff8a3e157e3f6eb",
    "runtime_id": "9a416ca8-f356-4cef-bb67-f59705dfd850"
  }
}

Delegation and recovery keep the original binding

Inside a registered native connection, the kernel passes a ToolInvocationContext whose constructor is private to the kernel. This integration function reads the admitted route, subject, and capability commitment from it:

use chio_kernel::runtime::ToolInvocationContext;

#[derive(Debug)]
pub struct AdmittedCaller {
    pub request: String,
    pub server: String,
    pub tool: String,
    pub capability: String,
    pub subject: String,
    pub capability_hash: String,
}

/// Called from the registered native connection with the kernel's context.
/// Serialized arguments cannot construct ToolInvocationContext.
pub fn inspect_caller(context: &ToolInvocationContext) -> AdmittedCaller {
    AdmittedCaller {
        request: context.request_id().into(),
        server: context.server_id().into(),
        tool: context.tool_name().into(),
        capability: context.capability_id().into(),
        subject: context.subject_key().into(),
        capability_hash: context.capability_hash().into(),
    }
}

These are correlation fields the kernel selected, distinct from a transferable attestation; the serving host establishes tenant and session context separately. Keep the original authenticated context beside durable operation state, so a reconnect that copies a request ID still carries the original tenant and epoch.

A delegated capability narrows an existing chain, and its subject and target servers and tools stay consistent with the intended recipient. After restart, recovery checks the retained operation against the original context and the new serving fence, never against caller-supplied fields. For authenticated caller delivery, the configured executor signs the report, and a matching request ID is insufficient: the report also needs the original delivery, nonce, request commitment, and retained physical capture. Delegation boundaries covers the checks that keep a child inside its parent.

The swarm example refuses a task presented by the wrong worker

A planner and a writer share a mailbox and hold separate task authority. The Security swarm example provisions one credential per process and binds each call it prepares to that process. Run it in a fresh extracted directory with its required Chio commands on PATH:

python3 run.py
python3 inspect.py

peer: deny; chio_swarm_authority_rejected
authority: exact retry returned original; mailbox contains 2 messages

You should see the peer refused with chio_swarm_authority_rejected and two messages in the mailbox. The inspector reads the returned receipt's runtime failure code and independently counts the stopped mailbox: the wrong-worker attempt adds no message, and the planner and writer add one each. The test behind it copies the writer's exact operation and presents it with the planner's credential, and the frame below it is what the runner sends:

peer = swarm.invoke("triage-417", swarm.calls["fixer-417"])
original = swarm.run_planned("triage-417")
after = swarm.run_planned("fixer-417")

assert refused(peer, "chio swarm-bound runtime admission denied")
assert runtime_failure_code(peer) == "chio_swarm_authority_rejected"
assert sent_sequence(original) == "1"
assert sent_sequence(after) == "2"

frame = (json.dumps({"protocol": PROTOCOL,
                     "credential": self.credentials[process],
                     "operation": operation}, separators=(",", ":")) + "\n").encode()

swarm is the prepared host in the downloadable runner, and its invocation method sends the credential outside the operation. The process name selects a credential the host issued, which a caller cannot retag the way it could an agent_id argument, so copying the prepared payload leaves its authenticated owner behind. The run covers process and task binding on this socket host; HTTP tenant authentication and filesystem confinement are separate controls.

A mismatch is refused and kept as a rejected attempt

Compare the operation's session anchor and epoch with the current authenticated context, then the capability subject, target server and tool, and executor pin. Keep a mismatch as a rejected attempt; the original operation keeps its own record.

A negative test starts from one valid operation, keeps its request, capability, session binding, and result, and changes one identity at a time: the tenant, the authenticated agent, the session epoch, the capability digest, or the expected executor. Each substitution is refused with a binding failure, and the substituted operation neither consumes nor releases the legitimate operation's resources.

A lost response is a separate case. A matching retry may retrieve the original completion under the recovery contract, while a changed payload under the same request ID retrieves nothing that would authorize the changed effect; Replay protection covers how the kernel classifies the exact retry. Diagnostics compare commitments before anyone exports private request data: the operator learns that a session or capability digest differs, and the authorized verifier keeps the private material.

Next: narrow what the caller may do