UHP security and trust boundaries

Note

Normative, not a certification: every UHP requirement below is taken from the 2026-09-28 specification (the Security chapter and the cross-referenced Architecture, Lifecycle, Tasks, Sessions, Files, Errors, Plugins, and Versioning chapters). HarnessRouter Community Edition is the reference implementation; deployment advice is labelled separately. Passing the conformance suite is not a security certification — the suite probes for path traversal (X-08) as a floor, not proof of safety.

1. Authentication and authorization boundaries

Review the effect boundary before exposing execution

If your product also needs discovery, health, configuration and explicitly permitted control of agents, compare SAMP’s manager-to-agent plane with the execution boundary below. A management permission and a UHP admission token describe different operations; neither implies unrestricted downstream authority.

For a repository-editing service, trace identity and authority from the caller through the configured harness to every tool and result. A valid bearer token proves only the admission step it was issued for; it does not establish safe workspace configuration, trusted instructions or a harmless tool effect.

Boundary	Evidence to require	Failure to test
Caller → server	Principal and object scope	Another principal’s harness/session/file cannot be reached
Server → configured harness	Selected runtime, model and effective permissions	Unknown or mismatched identity is refused rather than substituted invisibly
Harness → tools/processes	Actual declared tool surface and sandbox policy	Workspace instructions cannot silently grant undeclared authority
Shared project → session	Read-only Environment mount and private writable workspace	A session cannot change a shared built layer or leak another session’s output
Result → client	Terminal cause and scoped artifact retrieval	Partial or accepted work is not displayed as completed

Use workspace trust for configuration admission, tool-surface coherence for the model-visible interface and execution finality when acceptance must be distinguished from committed effects. The matrix is an integration review derived from the versioned UHP boundaries; the separate adjacent standards below do not replace those obligations.

The specification scopes authorization at the level of the principal that created an object, not at a per-endpoint granularity beyond authentication itself.

• A server MUST authenticate every endpoint except GET /v1/uhp (the unauthenticated discovery document).
• A server MUST NOT distinguish “no such token” from “token not permitted here” in a way that lets a caller enumerate valid tokens.
• A server MUST NOT echo a credential — the caller’s or a provider’s — in any response body, error message, event, log line, or artifact.
• A server SHOULD support revoking a credential, and revocation MUST take effect for new requests immediately.

Provider credentials (implementation guidance). The credential a server uses to reach a model provider is the most valuable secret in the system, and the agent’s own sandbox is the least trustworthy place in it. The specification therefore advises: do not place a provider credential where the agent’s tools can read it; if a harness must receive a credential, issue a short-lived, single-session one and be able to revoke it independently of the underlying key; and MUST NOT accept a caller-supplied upstream URL for a brokered request without validating it against a configured allow-list — an unvalidated upstream turns the server into an SSRF proxy carrying its own credential.

Emerging agent enrollment, identity, authentication, authorization, and assurance drafts — adjacent, not normative UHP

Agent enrollment, identity, authentication, delegated authority, per-action authorization, and pre-action assurance are moving quickly outside UHP. The following documents are useful to track because they target distinct trust layers around agent systems, but none is part of UHP and none is an IETF standard.

Proposal	Verified status	Relevant mechanism
draft-ietf-wimse-aims-00 — AI Identity Management System (AIMS)	Active WIMSE Working Group Internet-Draft; published 15 Sep 2026; draft header states Informational intent; work in progress. It replaces the earlier individual draft-klrc-aiagent-auth series.	Treats AI agents as workloads and composes existing identity/security standards rather than defining a new wire protocol. AIMS spans identifiers, credentials/provisioning, transport/application authentication, OAuth delegation/authority, monitoring/remediation, policy and compliance.
draft-kavian-agent-enrollment-protocol-04 — The Agent Enrollment Protocol (AEP)	Active IETF individual Internet-Draft; published 4 Sep 2026; intended status Standards Track; work in progress.	Defines a narrow HTTP machine-first enrollment/bootstrap layer: unauthenticated /.well-known/aep inspection, DID-based agent identity enrollment, per-request client-assertion JWTs, status, optional session-credential grants and revocation. It explicitly excludes action authorization, KYC, payments/checkout and legal policy.
draft-wei-aic-identity-cert-02 + draft-wei-aic-jwt-02 — AI Agent Identity Certificate (AIC) X.509 and JWT profiles	Active IETF individual Internet-Drafts; X.509 and JWT profiles both dated 2 Oct 2026; both have Experimental intent and no formal standing in the IETF standards process.	Defines the same agent↔principal binding, capability/delegation and authorization-constraint model in two carriers: an X.509 v3 extension for transport/TLS and offline validation, plus a companion nested-JWS JWT profile for HTTP/web/OAuth contexts where client certificates are unavailable.
draft-chen-oauth-agent-authz-use-cases-03 — Agent Authorization use cases and gap analysis	Active IETF individual Internet-Draft; published 25 Aug 2026; intended status Informational; work in progress; no formal IETF standing.	Requirements/gap analysis rather than a protocol. It identifies recurring OAuth 2.x gaps for agent systems around authorization context, multi-hop delegation chains and mass/task revocation, plus dynamic/JIT authority, bounded constraints, cross-agent audit/task context, cross-domain delegation and execution-layer evidence.
draft-asor-wimse-agent-delegation-chain-01 — Verifiable Attenuated Delegation for AI Agent Chains	Active IETF individual Internet-Draft; published 3 Sep 2026; no formal IETF standing. The document header states Standards Track intent; work in progress.	Defines an OAuth/JOSE Agent Delegation Chain for depth ≥2 delegation: RFC 9068 JWT access tokens carry RFC 9396 authorization_details, each child commits to its parent, holder binding uses DPoP, and an offline verifier enforces monotonic authority attenuation, bounded depth and monotonic expiry.
draft-prakash-aip-01 — Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems	IETF Individual Submission Internet-Draft; published 19 Aug 2026; intended status Informational; work in progress	Defines Invocation-Bound Capability Tokens (IBCTs). Compact mode uses JWT with Ed25519 for single-hop interactions; chained mode uses Biscuit tokens with append-only blocks and Datalog policy evaluation for multi-hop delegation. The draft specifies bindings for MCP, A2A and generic HTTP.
draft-fane-opena2a-aip-03 — OpenA2A Agent Identity Protocol (AIP)	IETF Individual Submission Internet-Draft; published 30 Sep 2026; intended status Standards Track; work in progress	A separate OpenA2A identity/trust proposal using the same “AIP” abbreviation. Its design centers cryptographic agent identity, structured capabilities and trust signals.
draft-saha-aadp-04 — Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents	Active IETF individual Internet-Draft; published 27 Sep 2026; document header states Standards Track intent; work in progress.	Defines a two-phase authorization contract between a Policy Decision Point (PDP) and Policy Enforcement Points (PEPs), with machine-readable verdicts, fail-closed obligations, atomic budget reservations, approval lifecycle, idempotency and evidence. It is designed to compose with identity/token layers rather than replace them.
draft-zagarella-autonomy-governor-01 — Pre-Action Risk-Graded Assurance for Agent Interactions	IETF Individual Submission Internet-Draft; published 24 Aug 2026; intended status Informational; work in progress	Defines a pre-action interface that derives a risk-graded assurance requirement, gates execution until that requirement is met, and records the decision for audit. Revision -01 also describes an informative autonomy-asymmetry reference design: failures raise assurance immediately (“fast-down”), while sustained verified success can relax it gradually (“slow-up”).

Caution

AIMS is now a WIMSE Working Group draft, not an IETF standard or a new wire protocol. draft-ietf-wimse-aims-00 replaced the earlier individual draft-klrc-aiagent-auth series on 15 September 2026 and is listed by the Datatracker as a WIMSE WG Document. Its scope remains composition and best-practice guidance for existing WIMSE, OAuth 2.0 and related standards rather than invention of a new agent-authentication protocol. Working Group adoption materially raises its standards-process maturity, but it is still an Internet-Draft / work in progress rather than an RFC.

AEP fills a different gap from authorization protocols. It addresses the machine-first provisioning step by which an autonomous agent becomes enrolled and recognized by an HTTP service, then optionally bootstraps a session credential. Its baseline flow is Inspect → Enroll → Status → optional Grant → Revoke, with authenticated commands using an agent-signed client assertion. The draft explicitly leaves action authorization and policy decisions outside scope. UHP 2026-09-28 authenticates callers to a UHP server but does not define a cross-service agent-enrollment protocol, so AEP is adjacent identity/bootstrap work rather than a UHP extension or adoption signal.

AIC is a credential/profile proposal, not an enrollment service or general authorization protocol. The X.509 draft binds an agent cryptographic identity to a responsible principal and carries capability/delegation metadata and constrained authorization evidence that can be evaluated at the TLS layer; the JWT companion carries the same semantic model at the application layer and defines PKI- and OAuth-oriented issuance/exchange paths. Both documents explicitly remain individual Experimental Internet-Drafts, and their policy/capability semantics are not a universal authorization language. UHP 2026-09-28 does not define an AIC certificate/JWT profile or require AIC-style principal binding, so no UHP↔AIC dependency or adoption relationship is established.

The OAuth agent-authorization gap-analysis draft is a problem statement, not another authorization mechanism. Revision -03 explicitly says it does not propose new solutions or protocols. Its value is to make the problem surface concrete across personal, enterprise and security use cases: high-level user intent can become detached from later permission prompts; multi-agent delegation lacks a standard verifiable multi-hop chain; and incident response lacks standardized task/bulk revocation and common cross-agent audit context. Those gaps help explain why adjacent work such as AIMS/WIMSE, AuthZEN, XAA/EMA, AADP and delegation-token proposals exist, but the draft does not select or standardize any of them. UHP 2026-09-28 likewise does not define those cross-domain OAuth authorization semantics.

Google Cloud Agent Identity and auth manager — deployed adjacent implementation (checked 4 October 2026)

Google Cloud now provides a deployed identity and outbound-authentication stack for agents. Agent Identity became Generally Available on 22 April 2026 and assigns each deployed agent a unique SPIFFE identity plus a short-lived X.509 certificate. Google documents certificate-bound access tokens for Google Cloud access, OIDC ID tokens for direct external-service authentication, and audit attribution that can preserve both agent and end-user identity when the agent acts on a user’s behalf.

The 18 June release note concerns the Agent Identity API Preview, a separate milestone. On 22 August 2026, Google made Agent Identity auth manager and the Agent Identity APIs (agentidentity.googleapis.com and agentidentitycredentials.googleapis.com) Generally Available. The auth manager is a centralized credential vault and outbound-authentication broker for 3-legged OAuth, 2-legged OAuth and API keys. Google ADK can retrieve and inject credentials for external tool and MCP-server calls, while IAM policy can scope which SPIFFE-based agent principals may use each auth provider.

Credential exposure depends on the deployment path. The auth manager overview describes credentials returned to the agent/ADK for outbound calls; the Agent Identity overview separately describes a Gateway + Gemini Enterprise path in which end-user credentials are decrypted at the gateway and withheld from the agent. A centralized vault alone is therefore not proof that tools can never see a raw credential. Decommissioning also needs IAM cleanup: deleting an agent leaves its bindings behind, and a replacement gets a new principal even with the same display name.

Google’s MCP authentication guidance explicitly lists Agent identity alongside user and workload identities for Google and Google Cloud MCP servers. For production workloads, Google recommends a separate agent or workload identity instead of a human user identity so permissions can be limited and actions can be attributed independently.

Note

Vendor infrastructure, not UHP or MCP protocol behavior. Agent Identity establishes a Google Cloud principal and auth manager brokers outbound credentials. Neither is a UHP requirement, an MCP core primitive, an IETF/OpenID standard, or evidence of native UHP adoption by Google. A UHP deployment can place an identity/credential broker around a harness or tool boundary, but no standardized UHP↔Google Agent Identity binding is established here.

The Agent Delegation Chain draft is one concrete response to that multi-hop delegation gap, but it is not an adopted WIMSE solution. draft-asor-wimse-agent-delegation-chain-01 profiles OAuth JWT access tokens so each delegated hop can only narrow authority relative to its parent and the ultimate enforcement point can verify the chain offline. Authority is expressed with RFC 9396 authorization_details; par_hash binds each child to one exact parent; DPoP binds a token to its holder; depth and expiry cannot expand downstream; and status-list machinery can be used for revocation. The draft says it is designed to satisfy the cross-organization delegation attenuation requirement, complement AIMS, and converge with existing attenuating-agent-token work. It remains an individual I-D with no formal IETF standing. UHP 2026-09-12 defines no equivalent cross-agent delegation-token chain, so this is adjacent authorization/delegation architecture rather than a UHP extension or adoption signal.

Caution

“AIP” is currently ambiguous. At least these two independent August 2026 drafts use the name Agent Identity Protocol. A reference should name the specific draft or say OpenA2A AIP where appropriate. An Internet-Draft is a work in progress that may be updated, replaced or abandoned; intended status is not equivalent to IETF approval.

AADP targets a different layer from the AIP drafts. Its PEP sits where a governed action actually happens — for example a tool wrapper, protocol proxy, API gateway or runtime supervisor — and consults a PDP before acting. The draft defines autonomy tiers from read-only observation through reversible/capped autonomous action to human-confirmed execution, and its authorization decision depends on mutable state such as budgets, live reservations, approvals and a kill switch. A search of the current UHP 2026-09-28 protocol source finds no PDP/PEP or autonomy-tier contract; this is therefore adjacent security architecture, not a UHP extension or adoption claim.

The Pre-Action Risk-Graded Assurance draft addresses a narrower but distinct question: not simply whether an action is authorized, but how much assurance must be satisfied before that action proceeds. It defines common audit semantics across human re-authentication, agent-action oversight and computational-resource selection. Its -01 autonomy-asymmetry loop uses VERIFY outcomes as feedback, escalating assurance immediately after failure and allowing relaxation only after sustained success. The draft presents that loop as an informative reference design; concrete risk scoring, thresholds and control mapping remain deployment choices. UHP 2026-09-12 defines no equivalent assurance-grading or adaptive-autonomy contract, so this remains adjacent governance/security work rather than a UHP feature.

Verifier binding: identity, authority, session state and evidence are different claims

A new protocol-neutral review draft makes a useful boundary explicit. draft-bu-agentproto-security-principal-binding-07 — Security Principal and Verifier Binding for Agent Communication Protocols was published 15 September 2026 as an active individual Internet-Draft with Informational intent and no formal IETF standing. It does not define another agent protocol, token format, authorization system, audit log or transparency service. Instead, it defines a claim-to-verifier discipline for reviewing agent protocols and their security evidence.

The core rule is that a carrier is not the claim it carries, and one verified claim must not silently upgrade into another. The draft separates human/organizational authority, live agent-instance identity, tool/resource identity, delegated authority, session continuity and action evidence. For each security-relevant row, the reviewer records the claim, carrier, verifier, binding, freshness rule, failure behavior and accepted result, then keeps specification status, implementation status and evidence type/coverage separate. A successful verifier should therefore return only the constrained fact it established — for example, session-bound token possession — rather than an implied conclusion such as “the target action is authorized.”

Revision -07 further makes composition review structural: dependency closure prevents an aggregate result from becoming stronger than its verified inputs; machine-readable mappings bind stable row identifiers to exact row artifacts; unresolved freshness/failure checks remain distinguishable; and parsing or reproducing a same-source artifact is classified as local consistency rather than independent verification. The draft also states the inverse explicitly: carrying or forwarding a receipt, attestation, pointer or other artifact is not the same as verifying its authority, provenance, current status, independence or policy sufficiency.

For UHP, this is external review guidance, not normative protocol behavior. It is nevertheless a useful discipline when evaluating authentication, principal-scoped objects, sessions, delegation systems and runtime-evidence integrations around a UHP deployment: a UHP session id is not delegated authority, a signed evidence record is not authorization, and implementation/test evidence for one revision should not silently upgrade another revision or another security claim. No UHP↔principal-binding protocol dependency or native adoption is established.

Runtime verification, signed action receipts, and effect-boundary evidence — adjacent, not normative UHP

Three August/September 2026 Internet-Drafts make a per-action accountability stack more explicit: runtime evidence generation, signed action recording/transparency, and executor-side evidence consumption/enforcement. They are adjacent proposals, not UHP requirements or IETF standards.

Proposal	Verified status	Relevant mechanism
draft-correctover-ccs-09 — Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls	Active IETF individual Internet-Draft; published 14 Sep 2026; intended status Experimental; work in progress. The current text records one reference implementation in two deployment forms plus one independently developed third-party interoperability profile.	Defines seven runtime-verification dimensions (Structure, Schema, Latency, Cost, Identity, Integrity, Security), a receipt with detached Ed25519 signatures over RFC 8785 canonical JSON, three verdicts (allow, deny, escalate) and four executor lifecycle states (confirmed, dispatched, indeterminate, unknown). Revision -09 makes the draft self-contained: AEB and CAID move to Informative References while the native artifact requirements they motivate are restated normatively inside CCS.
draft-noa-scitt-ai-agent-receipt-01 — A SCITT Profile for AI-Agent Action Receipts	Internet-Draft in the SCITT work area; published 15 Aug 2026; intended status Standards Track; work in progress	Profiles the published SCITT architecture (RFC 9943) for one signed record per governed agent action. A receipt carries the action, recorded principal class, recorded verdict and optional policy identity; it is hash-chained, can be carried bare or in COSE_Sign1, and can be registered as a SCITT Signed Statement with a Transparency Service. The profile explicitly does not prove correctness, complete or true inputs, prior authorization, downstream success or physical effect.
draft-schrock-action-evidence-boundary-07 — The Action Evidence Boundary for Consequential Agent Effects (AEB)	IETF Individual Submission Internet-Draft; published 25 Sep 2026; intended status Informational; work in progress	Defines an executor-side ordered processing model: native artifact verification → exact-action correlation → evidence satisfaction → separate local authorization → durable consumption/reservation → dispatch/invocation → closed effect outcome or authenticated reconciliation. It deliberately defines no new receipt/token format, policy language or registry.

The current AEB -07 strengthens uncertain-effect handling with a durable same-action fence: fresh authority or a different evidence path cannot admit another attempt while the previous one is in flight or uncertain. Release before provider entry requires proof that entry never occurred. This addresses duplicate effects after ambiguous dispatch; it is separate from receipt signature validity and from the UHP request-idempotency capability.

CCS -09 keeps the evidence profile distinct from authorization while making its own conformance requirements self-contained: AEB and CAID are now informative references, and the native artifact requirements previously motivated through them are stated normatively within CCS itself. The current draft retains detached Ed25519 signing over RFC 8785 canonical JSON and clarifies that its implementation experience is one reference implementation in two deployment forms plus one independently developed third-party interoperability profile. CCS produces and propagates runtime verification evidence. The SCITT Action Receipt profile standardizes a signed record of what was recorded at the governed boundary and, when registered, lets a SCITT Transparency Service add independently auditable transparency; the draft explicitly names AEB as adjacent rather than a dependency. AEB then defines the executor-side ordering needed before and after a consequential effect. A verified receipt therefore must not be substituted for authorization or proof that the external world changed.

UHP 2026-09-28 does not define a CCS-style runtime-evidence contract, a SCITT COSE_Sign1 per-action receipt / transparency-registration profile, or an AEB-style effect-boundary composition contract. UHP events can expose tool activity within the task lifecycle, but that is a different concern from signed action evidence, transparency and executor-owned one-time effect control. These drafts are also distinct from ATIF, which standardizes portable whole-trajectory records for evaluation/replay rather than per-action verification evidence or enforcement ordering.

OpenID AuthZEN authorization profiles — adjacent, not normative UHP

The OpenID AuthZEN Working Group now provides a more mature standards path for externalized authorization than the independent Internet-Drafts above. Authorization API 1.0 is an OpenID Final Specification, published 11 Jan 2026 in the specification header and standardizes the PEP-to-PDP decision exchange. Two newer Working Group drafts extend that base in ways directly relevant to autonomous agents and MCP, but neither is a UHP requirement and neither changes the UHP 2026-09-28 security contract.

AuthZEN work	Verified status	Relevant mechanism
Authorization API 1.0	OpenID Final Specification, published 11 Jan 2026	Standard PEP ↔ PDP authorization requests and decisions using the Subject-Action-Resource-Context (SARC) model.
Access Request and Approval Profile (ARAP) — current working draft	OpenID AuthZEN Working Group draft; Standards Track label	Keeps a denied decision denied, but lets a machine-readable requestable denial start an asynchronous access-request task. Approval does not itself grant access: the PEP re-evaluates through the PDP, which remains authoritative at enforcement time. The profile explicitly targets autonomous callers that discover new resources or authority requirements during long-running work.
COAZ-MCP — Draft 1	OpenID AuthZEN Working Group draft; Standards Track label; published 13 Feb 2026	Binds MCP JSON-RPC messages to AuthZEN decisions. It defines default mappings for MCP methods and optional per-tool x-authzen-mapping declarations, allowing an MCP gateway or server to act as the PEP and consult an AuthZEN PDP before an MCP message takes effect.

These documents solve different pieces of the authorization stack. COAZ-MCP maps what an MCP operation means for policy evaluation; ARAP standardizes what happens after a denial is requestable and requires asynchronous governance. AADP independently proposes a stateful per-action authorization protocol with budgets, reservations and approval lifecycle. They should not be collapsed into one protocol family merely because all use PEP/PDP terminology.

Note

MCP boundary: COAZ-MCP is an OpenID AuthZEN binding for MCP, not part of the released MCP core specification. Likewise, AuthZEN support does not imply UHP adoption. A deployment can combine UHP, MCP and AuthZEN at different boundaries: UHP for client-to-harness execution, MCP for harness-to-capability interaction, and AuthZEN for policy decisions at an enforcement point.

Cross-App Access and MCP Enterprise-Managed Authorization — adjacent, deployed

Cross-App Access (XAA) is the application-ecosystem name for a delegated OAuth pattern in which an application obtains access to another application’s API through an Identity Provider (IdP) both sides already trust for SSO. The current IETF OAuth Working Group document draft-ietf-oauth-identity-assertion-authz-grant-04 realizes that pattern with an Identity Assertion JWT Authorization Grant (ID-JAG). It remains an active Internet-Draft / Working Group document, not an RFC. The underlying draft-ietf-oauth-identity-chaining-17 is likewise still an Internet-Draft, although it has advanced to the RFC Editor queue with Proposed Standard intent.

MCP applies that pattern through its stable Enterprise-Managed Authorization extension (io.modelcontextprotocol/enterprise-managed-authorization). The MCP client asks the enterprise IdP for an ID-JAG and exchanges it at the MCP server’s authorization server for a scoped access token; policy and revocation can therefore remain centralized at the enterprise IdP. This is current MCP extension behavior, not merely a roadmap item.

On 24 Aug 2026, Okta announced General Availability of Agent SSO, powered by XAA. Okta says the product models XAA-supported agents as first-class identities and replaces hard-coded credentials/broad OAuth authorizations with short-lived, identity-governed tokens for sanctioned applications, APIs, tools and MCP servers. That is concrete implementation/adoption evidence for XAA/EMA, not a UHP requirement and not evidence of UHP adoption.

Caution

XAA is user-delegated, not a general autonomous-agent credential. Okta’s developer guidance says the XAA flow originates from an active human user session and explicitly says not to use XAA for autonomous agents, scheduled/background jobs, or M2M processing without an end-user context. That limitation is important when comparing it with workload-identity work such as AIMS/WIMSE.

XAA/EMA and AuthZEN solve different problems and can coexist. XAA/EMA governs cross-domain token acquisition and enterprise IdP-mediated delegation; AuthZEN externalizes authorization decisions between a PEP and PDP. Neither standardizes UHP’s client-to-harness execution contract.

The MCP Core Maintainers’ 22 August roadmap independently prioritizes further agent identity/delegation and enterprise security work such as DPoP, Workload Identity Federation and token exchange. Those roadmap items are future-direction signals; the already-stable Enterprise-Managed Authorization extension should not be downgraded to roadmap-only status.

HTTP route-scoped credential proof: x401 — adjacent draft, not normative UHP

x401 0.2.0 is a Draft HTTP proof-requirement protocol for a different question from authentication or action authorization: what credential-backed attribute must be proved before this specific HTTP resource can be accessed? Examples in the specification include personhood, residency, membership, accreditation, entitlement, organizational standing and workload-identity attributes.

The Verifier carries a composed Digital Credentials API request in PROOF-REQUEST, using OpenID4VP/DCQL to describe the required credential evidence. The Agent obtains the credential result from a local or remote Credential Manager and retries the protected route with PROOF-RESPONSE; PROOF-RESULT carries x401-specific verifier outcomes. A deployment may optionally exchange a successfully verified result for a short-lived OAuth token so the presentation does not have to be repeated on every request.

Caution

Proof requirement is not a universal agent identity or payment protocol. x401 does not define a new credential format, replace OpenID4VP/OpenID4VCI, mandate a single Agent Identifier or binding scheme, or define general authorization policy. Payment remains 402 Payment Required plus a separate payment protocol. The x401 specification also leaves Agent binding optional, so satisfying a credential requirement must not automatically be interpreted as proving which software agent made the request unless the deployment adds an accepted binding mechanism.

UHP 2026-09-28 authenticates callers and scopes UHP objects, but it does not define a machine-readable route-level credential-proof challenge for attributes such as residency or accreditation. An HTTP deployment could in principle place an x401 gate around a UHP-facing or adjacent resource, but this guide has verified no standardized UHP↔x401 binding, dependency or adoption relationship.

2. Object and resource scoping

• Every object — harness, response, session, container, file — MUST be scoped to the principal that created it.
• A request for an object outside the caller’s scope MUST return 404, never 403. A 403 confirms the id exists, which is exactly what an enumerating attacker wants (Architecture §5).
• Scope MUST be enforced on every operation, not only on read. Cancel, delete, continue, and download are all object access.

Implementation guidance. The conformance suite cannot fully verify scoping with a single credential. An implementer SHOULD run the equivalent check with two principals: create an object as A, then attempt every operation on it as B, and confirm each returns 404.

3. Files and workspace boundaries

An agent can be persuaded to write a file with chosen content and a chosen name, so everything that serves artifacts MUST treat them as hostile.

• Artifact downloads MUST be served with X-Content-Type-Options: nosniff; without it, an artifact named x.html becomes stored XSS against the client’s own origin (Files §3).
• Artifacts SHOULD be served from a different origin than the console or application UI, so a successful injection cannot reach first-party cookies or storage.
• A server MUST NOT allow a container_id / file_id pair to address anything outside its container. Path traversal through artifact ids is called out as the most likely serious vulnerability in a UHP implementation; the conformance suite probes for it (X-08).
• A server SHOULD cap artifact size and count per session.

Note

Implementation hardening observed (HarnessRouter v0.8.2, self-host path): the reference implementation now enforces a “session write-wall” — agent CLI processes run under per-session UIDs and can write only their own session workspace, keeping product-owned data paths out of agent reach; shared scratch locations (/tmp, /var/tmp, /dev/shm) remain writable at mode 1733 so tools such as LibreOffice keep functioning. This is an implementation-level control in one product, not a normative UHP protocol requirement and not a security certification; independent UHP servers remain free to implement workspace isolation differently.

Browser network policy depends on who owns the browser

HarnessRouter’s v0.29.0 self-hosting guide distinguishes the provisioned service from an operator-supplied Chrome DevTools Protocol endpoint configured through HR_BROWSER_CDP_URL.

Browser mode	Network boundary	Other relevant limits
Provisioned/vendor browser	Refuses private, loopback, link-local and cloud-metadata targets	Vendor session/limits and supported Console live view
Operator’s own Chrome via CDP	Can reach the operator’s network; vendor private/local refusal is lifted	Site allow/deny lists still apply; separate context per task; no vendor metering or Console live view

An isolated browser context separates cookies and tabs; it does not establish a network-isolation boundary. Review the CDP endpoint’s exposure and the host’s network authority before enabling this mode. The vendor refusal must not be presented as a guarantee for an operator-owned browser, and neither mode is a normative UHP sandbox requirement. See Runtime Plugins for the setup and service-plane distinction.

4. Error and information-leakage hygiene

• error.message MUST be safe to show a user: no credentials, internal hostnames, file paths, or stack traces (Errors §1).
• A server SHOULD log the detail it withholds, returning a correlation id in error.detail so an operator can diagnose what a caller cannot see.
• (Repeated from §1) a server MUST NOT echo any credential in a response body, error message, event, log line, or artifact.

5. Harness, tool, and prompt-injection risk

A harness that reads a web page, a repository, or an uploaded file may encounter instructions addressed to it. UHP cannot prevent this, and the specification says so plainly rather than pretending otherwise.

What the protocol provides, and a client SHOULD use:

• disabledTools on a configured harness — the smallest tool set is the smallest injection surface.
• max_step and timeout_seconds — a bounded task cannot be induced into an unbounded one.
• Separate harnesses for separate trust levels; a harness that reads untrusted input SHOULD NOT be the same configured harness that holds privileged tools or MCP servers.
• The event stream — tool calls are visible as they happen, so a client can surface or gate them.

A server MUST NOT claim that any of this makes an agent safe to point at untrusted input. Prompt-injection resistance is the client’s responsibility, not a protocol guarantee.

Shell parsing is an authorization boundary — source-pinned Qwen evidence

A shell permission rule is only as sound as the parser that decides which commands the shell will actually execute. Qwen Code PR #11765, merged on 23 September 2026 as 7e568a2c586e9c7b3c87ed38cacdca81297cac4a, fixes a concrete fail-open mismatch in compound-command segmentation. With only Bash(echo *) allowed, a command such as echo 'a\' ; touch /tmp/qwen-poc could previously be treated as one allowed echo segment even though Bash executes touch as a second command. Because the second command never became its own policy segment, an explicit deny rule for that second command could also be bypassed.

The root cause is a useful general harness-security pattern: the policy parser and the execution interpreter disagreed about quoting semantics. In plain Bash single quotes, a backslash is literal; it does not escape the closing quote. Qwen’s pre-fix splitter treated the backslash as an escape and therefore lost the real command boundary. PR #11765 distinguishes plain single quotes from ANSI-C $'…' quoting and scans under both the corrected and pre-fix readings, splitting wherever either reading finds an operator. That makes the security boundary monotonic relative to the prior parser: the new segmentation may be more conservative, but it is not allowed to lose a boundary that the old reading would have enforced.

This produces a reusable design rule for agent harnesses that offer shell allow/deny policy:

1. Authorize executed segments, not a display string. Permission evaluation must operate on the same security-relevant command boundaries the shell will execute.
2. When parser equivalence is incomplete, fail closed. If the policy layer cannot model comments, heredocs, backticks, substitutions or quoting exactly, uncertainty should lead to an ask/deny or conservative extra boundary rather than silently merging commands into an allowed prefix.
3. Deny evaluation needs the same visibility as allow evaluation. A parser bug that hides a trailing command can bypass both an allow prompt and an explicit deny rule.
4. Track state changes from real executable segments. False parsing of a non-executed cd can also corrupt working-directory or write-target attribution even when it does not directly widen permission.
5. Use the real shell as a differential oracle. Policy parsers should be fuzzed and regression-tested against the interpreter they are trying to constrain, with mutation tests for each boundary rule.

The fail-closed trade-off is real. The upstream PR explicitly records comment/heredoc/backtick cases where scanning both readings can create a false deny or false ask even though Bash would execute only one command. It also leaves command substitution, environment-variable tricks and spellings that fool both readings out of scope. Upstream reports 553 permission-manager tests passing, 1,656 tests across the permission/shell/monitor/shell-utils suites, mutation guards for the new parser branches and a 150,000-line differential fuzz; direct local validation was on macOS, while Windows and Linux were not locally run by the contributor.

Caution

This is Qwen host/runtime security behavior, not UHP wire semantics. At the 23 September source cutoff, Qwen Code stable was v0.24.4 and PR #11765 was post-release development behavior. Current CLI stable is v0.24.7; a fresh 4 October GitHub ancestry check confirms merge 7e568a2c is included in that tag. The upstream test/fuzz counts above remain tied to the reviewed fix, rather than a rerun on the latest release. The fix does not revise UHP, MCP, ACP or A2A, does not establish native Qwen UHP adoption, and does not establish a new HarnessRouter Qwen-specific conformance result. The transferable lesson is the authorization boundary: a harness cannot safely grant a shell command based on a parser that may see fewer executable commands than the shell itself.

Harness Plugins: third-party code is an execution boundary

UHP 2026-09-12 adds normative security rules for optional Harness Plugins. A plugin can contribute instructions and executables written by a third party, so installing one extends the harness’s trust boundary to the plugin author.

• A stdio MCP server declared by a plugin MUST run inside the same sandbox that runs the agent, with no more privileges than the agent. It MUST NOT run on the server host and MUST NOT be launched through a shell.
• A server MUST expand only ${PLUGIN_ROOT} and ${PLUGIN_DATA}, only in args, env, and cwd; it MUST NOT perform other placeholder or environment-variable expansion for plugin launch configuration.
• A plugin command or cwd that resolves outside the plugin root is invalid rather than a permitted escape.
• Plugins are installed by whoever manages the harness (Full class), never per request. A request may narrow tools; it must not widen the execution surface by introducing a plugin or MCP server.
• A skill inside a plugin is prompt content and remains subject to the prompt-injection boundary above. Before installation, a client SHOULD show the manifest’s author, homepage, and repository, and after installation it SHOULD surface components reported as skipped.
• A server exporting a harness as a plugin package MUST omit auth and headers; an exported package is intended to leave the server boundary.

These are UHP protocol requirements for plugin-capable implementations, not claims that a plugin is safe, reviewed, signed, or trustworthy merely because its package is valid.

Environments: shared state needs enforced isolation

UHP 2026-09-28 extends the security contract to Environments. The Security chapter at v0.29.0, checked 4 October 2026, requires:

• an enforced read-only Environment mount; an instruction asking the agent not to write is insufficient;
• builds running with a task’s toolchain, network and privileges, without access to other Environments or sessions;
• confinement of file paths, archive members and repository trees to the Environment root, with escaping links and absolute paths dropped.

Deployment review: test both the build and the running session boundary. A successful read-only task test alone does not establish that a build script cannot reach another tenant. Keep generated output in the session workspace; do not promote it into a shared Environment without the owner’s intended build/publication operation. These checks are implementation guidance, not additional UHP endpoints.

6. Resource exhaustion and concurrency

• A server MUST bound task duration, and MUST report incomplete rather than completed when a budget stopped the work (Lifecycle §3).
• A server MUST refuse a second concurrent task in the same session (session_busy) — two agents in one working directory is not a defined state and is also a cheap way to multiply cost.
• A server SHOULD rate-limit task creation per principal and SHOULD expose remaining budget through rate_limit_error responses rather than failing opaquely.
• A server MUST bound upload size and reject with file_too_large rather than truncating; a silently truncated input produces a confident, wrong answer.

7. Cancellation, retry, duplicate execution, and idempotency

These concerns are governed by several chapters together. The normative facts:

• Cancellation. A running task is cancelled with POST /v1/responses/{response_id}/cancel and a running session with POST /v1/sessions/{session_id}/cancel; deleting a session (DELETE /v1/sessions/{session_id}) cancels any in-flight task first; /v1/traces/{session_id} is a compatibility alias. A server MUST refuse a second concurrent task in the same session, which also prevents duplicate concurrent execution (§6).
• Idempotency. When the idempotency capability is advertised, a submit can carry an Idempotency-Key header so a retried submission does not create a duplicate task (Tasks chapter).
• Retry. A conformant client MUST treat an unknown error code as its type; an unrecognised server_error is still retryable, and rate_limit_error exposes remaining budget rather than failing opaquely (Versioning client rules).

Interpretation: idempotency and the single-concurrent-task rule are the protocol’s mechanisms against accidental duplicate execution; they are controls on the request/response contract, not on the agent’s internal behaviour.

8. Transport

• TLS MUST be used except on loopback.
• A server SHOULD send Strict-Transport-Security.
• A server serving any HTML MUST send X-Frame-Options: DENY or an equivalent frame-ancestors 'none' policy.

9. Data handling and retention

• Session artifacts and transcripts MUST be unreachable after the session is deleted.
• A server SHOULD document its retention period. “Indefinite” is an answer; silence is not.
• Session sharing, where implemented, MUST be read-only and revocable, and MUST NOT expose credentials or another principal’s data (Sessions §5).

10. Client and server trust responsibilities

Party	Responsibilities stated by the specification
Server	Authenticate all endpoints but discovery; never echo credentials; scope every object to its creator and return 404 (not 403) for out-of-scope access; serve artifacts with nosniff from a boundary that contains traversal; keep error.message safe and log the withheld detail; bound task duration, concurrency, and upload size; use TLS and frame-protection; erase artifacts on session deletion; make sharing read-only; sandbox plugin stdio MCP servers, constrain plugin expansion/path resolution, and omit auth/headers from exported plugin packages.
Client	Treat prompt injection as in-scope; configure least-privilege harnesses (disabledTools, max_step, timeout_seconds, separate trust levels); monitor the event stream; retry unknown server_error codes and honour rate_limit_error; use Idempotency-Key when offered; verify scoping with a two-principal test; review plugin provenance fields and surface skipped plugin components.

11. Reporting a vulnerability

Vulnerabilities in the reference implementation or in the specification follow private disclosure, not a public issue; see the repository’s security policy. A specification bug that makes a secure implementation impossible is treated as a vulnerability, not as a documentation defect.

Documented vs interpretation

Documented (explicit in 2026-09-28)	Not stated — do not assume
Authentication on all endpoints but GET /v1/uhp; no credential echo; token-enumeration resistance; immediate revocation.	A specific auth scheme, token format, or MFA requirement.
Per-principal object scoping with 404 (not 403) for out-of-scope; traversal contained to the container.	Per-object ACLs, role-based access control, or tenant isolation beyond principal scoping.
nosniff on artifacts; different-origin serving advised; size/count caps advised; safe error.message.	A content-security-policy mandate or a specific artifact-scanning requirement.
Tool-injection controls via harness config; server must not claim safety; bounded steps/timeouts.	That UHP detects or neutralises prompt injection.
Plugin stdio MCP servers stay inside the agent sandbox; only ${PLUGIN_ROOT} / ${PLUGIN_DATA} may expand in args/env/cwd; plugin root escapes are invalid; per-request plugin widening is forbidden; exported packages omit auth/headers.	That package validity proves plugin safety, signature/trust-chain requirements, marketplace review, or any particular host scanner/admission policy.
TLS except loopback; HSTS advised; X-Frame-Options: DENY / frame-ancestors 'none'; erasure on session delete.	Encryption-at-rest mandates, audit-log formats, or CORS policy specifics.

Related pages

Read governance and versioning, conformance, architecture, Harness Plugins, the HTTP API map, the specification guide, UHP vs MCP, and the glossary.

Primary sources

• Current AEP -04
• Current AIC X.509 -02
• Current AIC JWT -02
• Current OpenA2A AIP -03
• Current AADP -04
• Current AEB -07
• HarnessRouter v0.29.0 self-host browser policy

The older individual draft links retained below identify prior revisions; current revision/status decisions above were rechecked on 4 October 2026.

• UHP 2026-09-28 Security at v0.29.0
• UHP 2026-09-28 Environments at v0.29.0

The September sources below preserve the provenance of inherited requirements and dated implementation case studies.

• UHP 2026-09-12 Security considerations
• UHP 2026-09-12 Harness Plugins
• UHP 2026-09-12 Architecture (object scoping, §5)
• UHP 2026-09-12 Lifecycle (authentication §2, task states §3)
• UHP 2026-09-12 Tasks (idempotency)
• UHP 2026-09-12 Sessions (sharing §5, cancellation)
• UHP 2026-09-12 Files (artifact boundaries §3)
• UHP 2026-09-12 Errors (error hygiene §1)
• UHP VERSIONING.md (client retry rules)
• IETF Datatracker: AI Identity Management System — draft-ietf-wimse-aims-00
• IETF Datatracker predecessor: AI Agent Authentication and Authorization — draft-klrc-aiagent-auth
• IETF Internet-Draft: Agent Enrollment Protocol (AEP) — draft-kavian-agent-enrollment-protocol-03
• IETF Datatracker: AI Agent Identity Certificate (AIC) X.509 profile — draft-wei-aic-identity-cert-00
• IETF Datatracker: AIC JSON Web Token profile — draft-wei-aic-jwt-00
• IETF Datatracker: Agent Authorization use cases and gap analysis — draft-chen-oauth-agent-authz-use-cases-03
• Google Cloud IAM release notes — Agent Identity and auth manager GA
• Google Cloud Agent Identity overview
• Google Cloud Agent Identity auth manager overview
• Google Cloud: Authenticate to Google and Google Cloud MCP servers
• IETF Internet-Draft: Verifiable Attenuated Delegation for AI Agent Chains — draft-asor-wimse-agent-delegation-chain-01
• IETF Datatracker: Security Principal and Verifier Binding for Agent Communication Protocols — draft-bu-agentproto-security-principal-binding-07
• IETF Internet-Draft: Correctover Conformance Shape (CCS) — draft-correctover-ccs-09
• IETF Internet-Draft: SCITT AI-Agent Action Receipts — draft-noa-scitt-ai-agent-receipt-01
• SCITT Architecture — RFC 9943
• IETF Internet-Draft: Action Evidence Boundary (AEB) — draft-schrock-action-evidence-boundary-04
• OpenID AuthZEN Authorization API 1.0 Final Specification
• OpenID AuthZEN Access Request and Approval Profile — Draft 1
• OpenID AuthZEN COAZ Framework — Draft 1
• OpenID AuthZEN COAZ-MCP binding — Draft 1
• MCP Enterprise-Managed Authorization extension
• MCP: Enterprise-Managed Authorization is stable (18 Jun 2026)
• IETF OAuth WG: Identity Assertion JWT Authorization Grant / XAA
• IETF OAuth WG: OAuth Identity and Authorization Chaining Across Domains
• Okta: Agent SSO GA powered by Cross App Access (24 Aug 2026)
• Okta Developer: Cross App Access
• MCP Core Maintainers: The New MCP Roadmap (22 Aug 2026)
• x401 Draft 0.2.0 — HTTP Proof Requirement Protocol
• x401 specification repository
• IETF Internet-Draft: Agent Identity Protocol — draft-prakash-aip-01
• IETF Internet-Draft: OpenA2A Agent Identity Protocol — draft-fane-opena2a-aip-02
• IETF Internet-Draft: Agent Action Decision Protocol — draft-saha-aadp-02
• IETF Internet-Draft: Pre-Action Risk-Graded Assurance — draft-zagarella-autonomy-governor-01
• Qwen Code PR #11765 — shell command segmentation permission fix
• Qwen Code issue #11764 — Bash allow/deny boundary bypass
• Qwen Code merge commit 7e568a2c
• Qwen Code v0.24.4