Managed Runtime Attestation for Agent Harnesses

Short answer

Reachability, identity and readiness are different facts. A control plane that launches or reconnects to a managed agent runtime should not treat “the endpoint answered” as proof that it is the intended process generation, owns the intended lease and workspace, or is ready to execute work.

Qwen Code’s current development line provides a useful staged example. PR #12409, merged on 21 September 2026 as df3f9732a62bd261c6965283ab0da3b5cba1b97f, defines a private Hosted Harness generation fence. PR #12447, merged on 22 September as c822995d3ac8e024221a1be36297ed87b1c359f0, defines a closed Managed Runtime v2 attestation contract. PR #12506, merged on 23 September as 4836b5e3109632aa352ddbac4400599f41ba9ddf, turns that contract into a minimal separately owned worker process. PR #12522, merged later on 23 September as 94104d5565b1d45de3d5e724215410fa26582ec7, adds the bounded Java attestation client and is the checked Qwen main commit at this verification cutoff.

These changes are post-release current-main behavior. Qwen Code stable remains v0.24.4, published 22 September 2026. The work is also intentionally incomplete: attestation exists, but acquire/execute, Broker reconcile/CAS integration, the process-local ready gate, cross-language process E2E and deployment fault-injection remain separate follow-up gates.

This is Qwen host/runtime architecture. It does not revise UHP, ACP, MCP or A2A wire semantics, does not establish native Qwen UHP adoption, and does not create a fresh HarnessRouter Qwen validation result.

A runtime needs more than one identity fence

Managed execution crosses several identities that are easy to collapse incorrectly:

Identity	What it protects	Qwen evidence
Harness process generation	A restarted harness must not inherit the old process’s authority.	Hosted Harness bootId in PR #12409
Deployment capability set	Both sides must agree on the selected model/tool/policy configuration identity.	Canonical SHA-256 capabilityDigest
Runtime lease generation	A stale or replaced worker must not satisfy the current lease.	leaseId + positive epoch
Workspace generation and scope	A proof for one workspace generation must not authorize another.	tenant/workspace/generation/CWD/digest/isolation fields
Provision operation	A late response from an older provisioning attempt must not satisfy the new one.	provisionRequestId

The general invariant is:

A control plane should accept a worker only when the proof binds the exact runtime generation and scope it intended to create or recover.

Authentication alone is weaker. A bearer credential can prove that a caller knows a secret while still leaving ambiguity about which process generation, workspace incarnation or deployment capability set is on the other side.

Process-generation fencing belongs below session traffic

PR #12409 defines a private Hosted Harness protocol envelope with protocol version 1, one fresh non-persistent RFC UUID bootId per process generation, and a canonical sha256:<64 lowercase hex> capability digest.

Private session requests carry both the protocol version and the boot ID. The contract fails closed when the caller omits or presents an unsupported protocol version, supplies a malformed generation identifier, or presents a valid identifier from another process generation. The reviewed mapping is 426 for protocol negotiation failure, 400 for malformed boot identity and 409 for a stale generation.

That separation is important because a long-lived control plane can outlive a harness process. Reusing only the endpoint address or bearer token after restart can make a new in-memory process look like the original session owner. A generation fence makes process replacement observable instead of implicit.

The bootId is not a secret. Bearer authentication remains a separate requirement, and the capability digest is configuration identity rather than a credential.

One route manifest should own both admission and registration

The attestation contract in PR #12447 was motivated by a concrete split-brain routing bug in the preview implementation: Express registered POST /internal/managed-runtime/v2/attest, while an outer raw HTTP gate maintained a second route list. The handler existed, but the outer gate could still return 404.

The merged design gives the exact method, path, protocol version, body limits and cache policy to one typed route manifest consumed by both layers:

POST /internal/managed-runtime/v2/attest
protocolVersion = 2
requestBodyLimitBytes = 16384
responseBodyLimitBytes = 16384
cacheControl = no-store

Query strings, trailing slashes, alternate methods and undeclared paths fail rather than being normalized into an allowed operation. New operations are added only with their real handler instead of pre-advertising speculative routes.

The reusable lesson is broader than HTTP routing: security admission and application dispatch should derive from the same operation inventory whenever possible. Two independently maintained allowlists can both look correct in isolation and still disagree in production.

Authenticate before parsing untrusted payloads

The v2 route uses bearer authentication plus exact lease headers and a closed JSON body. The request binds protocolVersion, provisionRequestId, tenantId, workspaceId, workspaceGeneration, workspaceCwd, capabilityDigest and isolationClass.

The reviewed boundary is deliberately strict:

• credentials and lease headers are checked before JSON parsing;
• request and response payloads are capped at 16 KiB;
• compressed or unsupported payload forms fail rather than bypassing the wire-byte limit;
• unknown body fields are rejected;
• the bearer token is never returned and is compared with equal-length constant-time comparison;
• every response carries Cache-Control: no-store; and
• lease or immutable scope disagreement is an identity conflict rather than a retryable readiness condition.

Closed payloads matter for cross-language control planes. If one implementation silently accepts an identity field that the other ignores, both sides can pass independent tests while authorizing different objects. Qwen therefore stores language-neutral schema and fixtures that are consumed from both TypeScript and Java test surfaces.

PR #12447 reports 49 focused TypeScript cases through a real node:http listener and 29 Runtime Broker Maven tests, with repository build and typecheck also passing in the upstream review. That is bounded implementation evidence, not production certification.

Bootstrap secrets and ready records should flow in opposite directions

PR #12506 adds the hidden qwen managed-runtime-worker process boundary. It accepts exactly one closed boot document over standard input, with a 32 KiB limit and a 30-second close deadline. The per-generation bearer token travels in that boot document rather than appearing in command arguments or a long-lived environment variable.

After validation, the worker binds an operating-system-assigned IPv4 loopback port and emits one closed ready record on standard output. The record contains the loopback URL and fencing identity but not the bearer token. The worker exposes only the declared attestation route and closes its listener on SIGINT or SIGTERM.

This creates a useful bootstrap pattern:

control plane
    │
    ├── bounded secret-bearing boot input ─────► worker
    │
    ◄── token-free endpoint + fencing identity ─ worker
    │
    └── authenticated attestation request ─────► worker

The worker intentionally does not load a model, Harness, tool manifest, Session or workspace execution engine. “Attestation worker is ready” therefore means only that the identity-proof boundary is available.

PR #12506 reports 136 focused tests across the worker, shared contract and CLI bootstrap suites plus repository build and full workspace typecheck on the reviewed head. Direct local execution was macOS; Windows and Linux local execution remained untested in that PR.

The client must bound time, bytes and retry classes

PR #12522 adds the Java attestation client without importing the preview transport’s broader execution surface. The client sends the canonical request and accepts a successful proof only when the returned identity matches the intended lease, provision seed and workspace scope.

It also prevents two transport failures from becoming control-plane ambiguity:

1. the response body is collected through a bounded subscriber so a peer cannot force an unbounded allocation; and
2. the request deadline also covers a peer that sends headers and then stalls the body, while caller cancellation propagates to the exchange.

Failure classes are intentionally not all retryable. The shared contract treats credential failures, protocol failures, identity conflicts and route incompatibility as fail-closed conditions. Connection failures and 5xx remain retryable transport/service conditions. In particular, 404 is incompatibility, not “not ready yet.” Blindly retrying it could hide a version or route mismatch forever.

This distinction is reusable in any managed-runtime broker: retry only failures that plausibly become correct without changing identity, configuration or protocol compatibility.

Attestation success is still not execution readiness

The current Qwen work stops before the most dangerous inference: a valid attestation does not mean the runtime may execute tools. PR #12522 explicitly leaves prepare, execute, cancel and release out of scope and does not write the attestation result into the Broker service.

The design still requires later ordering around physical reconcile, attestation, durable database compare-and-swap and the process-local ready gate. Cross-language process E2E, restart/CAS behavior, deployment identity and fault injection also remain later acceptance gates.

A robust host should therefore keep at least these states distinct:

process started
  → endpoint published
  → identity attested
  → durable ownership committed
  → execution capability admitted
  → ready for work

Collapsing these into one ready=true flag makes it difficult to prove what a successful check actually authorized.

Application attestation is not hardware remote attestation

Qwen’s source explicitly scopes the v2 proof as an application identity envelope. It does not establish TPM, TEE, secure-boot or hardware-rooted remote attestation. A loopback worker can rely on local process ownership assumptions; a cross-host deployment still needs an authenticated and confidential transport plus appropriate workload identity and network policy.

The term “attestation” should therefore be qualified in architecture reviews. Ask what root of trust produced the evidence and what an attacker would need to compromise to forge it. A signed hardware quote, an mTLS workload identity and an application-level lease echo are materially different assurances even when all three are called attestation.

Relation to UHP, ACP, MCP and HarnessRouter

This page describes an internal managed-runtime control boundary. It is adjacent to external interoperability protocols but does not change them.

• UHP standardizes the product/server/harness execution boundary. Qwen’s private runtime attestation is not a UHP method or conformance requirement.
• ACP standardizes client↔agent interaction. The Java↔managed-worker proof described here is private Qwen control-plane traffic, not an ACP session operation.
• MCP standardizes model-context integrations and related extensions. It does not supply this runtime-generation lease proof.
• A2A addresses agent-to-agent interoperability and does not replace host-local runtime ownership fencing.
• HarnessRouter remains separately versioned reference-implementation evidence. Nothing in these Qwen PRs establishes a new HarnessRouter Qwen adapter validation or native Qwen UHP adoption.

See runtime capacity control, session recovery, routing identity, remote harness execution and Qwen Code for adjacent ownership and lifecycle boundaries.

Practical review checklist

When reviewing managed-runtime attestation, verify:

1. Process generation is explicit: restarts create a new fence rather than inheriting session authority from an endpoint address.
2. Capability identity is bound: deployment model/tool/policy selection has one canonical identity.
3. Lease and workspace generations are included: a proof for one logical name cannot satisfy a replacement generation.
4. Route admission and registration share one inventory: outer gates and inner handlers cannot drift independently.
5. Authentication precedes parsing: unauthenticated peers do not gain unnecessary parser exposure.
6. Payloads are closed and bounded: unknown identity fields, oversized bodies and ambiguous encodings fail closed.
7. Bootstrap credentials are not echoed: secret-bearing input and public ready metadata have separate channels.
8. Ready records are narrowly scoped: endpoint publication is not described as tool-execution readiness.
9. Retry policy follows failure meaning: identity, credential, protocol and incompatibility errors are not treated as transient service failures.
10. Timeout covers the body: a peer cannot hold attestation open indefinitely after sending headers.
11. Cancellation propagates: abandoning the control-plane operation releases the underlying exchange.
12. Attestation strength is named accurately: application identity proof is not relabeled as TPM/TEE remote attestation.
13. Durable commit follows proof: later reconcile/CAS logic must fence stale provisioning operations before the execution gate opens.
14. Protocol boundaries remain honest: private host/runtime controls are not presented as UHP, ACP, MCP or A2A semantics.

Primary sources

• Qwen Code PR #12409 — Hosted Harness private protocol
• Qwen merge commit df3f9732
• Qwen Code PR #12447 — Managed Runtime attestation contract
• Qwen merge commit c822995d
• Qwen Code PR #12506 — attestation-only Runtime worker
• Qwen merge commit 4836b5e3
• Qwen Code PR #12522 — Java Runtime attestation client
• Qwen merge/current-main commit 94104d55
• Qwen Code v0.24.4