What this example demonstrates
- Build the customer harness as an immutable, content-addressed OCI artifact.
- Adopt the exact artifact only in a deployment where the custom-harness capability is available and qualified.
- Select the harness lane through Agent and Environment configuration. A material Agent change creates a new AgentVersion for future Sessions.
- Start an ordinary Checkfu Session. The trusted driver supervises ACP and translates accepted observations into canonical Session events.
- Keep model access, tools, approvals, Usage, credentials, recovery, and retention under Checkfu authority regardless of the harness implementation.
Security and recovery boundaries
Customer code, dependencies, protocol shims, and install hooks are adversarial workload code. They run inside the workload boundary, not inside the trusted Runner. Raw provider Credentials and reusable model-provider keys do not enter the harness, model context, events, or sandbox. The harness receives only short-lived authority appropriate to the admitted Run. Standard retention can preserve accepted Session events and explicitly retained custody. Under ZDR, admitted execution can stream only through eligible live custody, and execution content is not written to durable sinks. Recovery restores only qualified checkpoints or retained artifacts; it does not infer missing sandbox state. Usage, not harness logs, is authoritative for Budget enforcement. Check capability status before presenting custom OCI execution as supported.Pinned source boundary
The ACP template distributed bycheckfu harness init acp delegates framing
and dispatch to the official ACP SDK. Its protocol handle remains process-local
and never replaces the Checkfu Session. It declares no session restoration or
MCP transport:
path=apps/cli/templates/acp/server.mjs
session/new. Extend your own agent with the actual tool connection and qualify
the release before declaring those capabilities. See Bring a custom
harness for packaging and the complete journey.