UHP security and trust boundaries

1. Authentication and authorization boundaries

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.

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.

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.

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/traces/{session_id}) cancels any in-flight task first. 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

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

Related pages

Read governance and versioning, conformance, architecture, the HTTP API map, the specification guide, and the glossary.

Primary sources

• UHP 2026-08-11 Security considerations
• UHP 2026-08-11 Architecture (object scoping, §5)
• UHP 2026-08-11 Lifecycle (authentication §2, task states §3)
• UHP 2026-08-11 Tasks (idempotency)
• UHP 2026-08-11 Sessions (sharing §5, cancellation)
• UHP 2026-08-11 Files (artifact boundaries §3)
• UHP 2026-08-11 Errors (error hygiene §1)
• UHP VERSIONING.md (client retry rules)