CUA Safety Model

How the Computer Use Agent is sandboxed, constrained, and audited. Every action is verified by deontic safety gates before execution. Safety EU Only

1. Sandbox Boundaries

The Computer Use Agent (CUA) operates in a sandboxed browser environment with strict isolation controls. The sandbox enforces hard limits at the infrastructure level, not just by policy.

Boundary	Constraint
Network isolation	Only allowlisted domains are reachable. All other network requests are blocked at the sandbox level.
File system	No local file access. The CUA cannot read, write, or enumerate files on the host machine.
Clipboard	Read-only. The CUA can read clipboard contents when needed for task context, but cannot write to the clipboard.
Session isolation	Each CUA session is independent. No cross-session data sharing, no persistent state between sessions.
Timeout	Sessions auto-terminate after 30 minutes of inactivity. No indefinite background execution.
Action limit	Maximum 100 actions per session. Prevents runaway automation loops.
Screenshot size	Maximum 5 MB per screenshot. Oversized captures are rejected.

2. Allowlisted Domains

The CUA can only navigate to pre-approved EU institutional portals. Navigation to any domain not on this list is blocked before the request leaves the sandbox.

Domain	Portal	Purpose
`ted.europa.eu`	TED eProcurement	Public procurement notices
`ec.europa.eu`	European Commission	Policy documents, consultations
`eur-lex.europa.eu`	EUR-Lex	EU legislation
`data.europa.eu`	EU Open Data Portal	Dataset search
`europarl.europa.eu`	European Parliament	Legislative observatory
`curia.europa.eu`	Court of Justice	Case law
`epo.org`	European Patent Office	Patent search
`echa.europa.eu`	ECHA	Chemical safety
`ema.europa.eu`	EMA	Medicine approvals
`ecb.europa.eu`	ECB	Monetary policy
`simap.ted.europa.eu`	SIMAP	Supplier registration
`hilma.fi`	Hilma	Finnish public procurement

Custom domains can be allowlisted via the API with appropriate authorisation. Allowlist changes require an administrator-level API key and are logged in the audit trail.

3. Prohibited Actions (M1)

The following actions are classified as M1 (MUST NOT) and are blocked by the deontic safety gate before they can execute. These prohibitions cannot be overridden by user configuration.

Financial transactions

No payment processing, no fund transfers. The CUA cannot interact with payment forms, banking interfaces, or cryptocurrency wallets.

Authentication as user

The CUA cannot log in as the user to third-party services. It cannot enter credentials, use stored passwords, or complete OAuth flows on behalf of the user.

Data exfiltration

Cannot copy data from portals to external destinations. Data extracted from allowlisted portals stays within the Pauhu® environment and is subject to EU data residency rules.

Form submission without approval

All form submissions require human-in-the-loop confirmation. The CUA prepares forms but cannot submit them autonomously. See HITL Gates below.

DOM manipulation

Cannot inject JavaScript or modify page source. The CUA interacts with pages through simulated user actions (clicks, typing, scrolling), not through programmatic DOM access.

Cookie and session theft

Cannot read or transmit authentication cookies. Session tokens from visited portals are sandboxed and inaccessible to the CUA or any external process.

Non-allowlisted navigation

Cannot navigate outside allowlisted domains. Redirects to non-allowlisted domains are intercepted and blocked. See Allowlisted Domains above.

Automated CAPTCHA solving

When the CUA encounters a CAPTCHA, it pauses and requests human intervention. No automated CAPTCHA-solving services or techniques are used.

4. Human-in-the-Loop (HITL) Gates

Critical actions require explicit human approval before execution. The CUA pauses at defined checkpoints and waits for the user to review, edit, and confirm.

Pre-submission confirmation

Before any form submit action, the CUA pauses and displays a confirmation modal showing all field values that will be submitted. The user sees exactly what the CUA intends to send.

User can edit

Each field in the confirmation modal is editable. The user can correct values, add missing information, or remove unwanted entries before approving the submission.

Explicit approval required

An “Approve & Submit” button must be clicked to proceed. There is no auto-submit, no timeout-based approval, and no implicit consent. The user must take a deliberate action.

Cancel stops the session

Cancelling a confirmation stops the current action chain. The CUA does not retry or attempt alternative approaches after a cancellation. The user retains full control.

Rollback capability

The user can roll back to any previous completed step in the session. Each step is recorded as a checkpoint with a screenshot, allowing the user to review the entire execution history and revert if needed.

5. Audit Trail

Every CUA action is logged with full context for compliance and review purposes. The audit trail is append-only and cannot be modified after creation.

Field	Description
Timestamp	ISO 8601 format with timezone. Millisecond precision.
Screenshots	Before and after each action. Visual proof of what the CUA saw and what changed.
Action type	The action performed: click, type, scroll, navigate, select, hover.
Target element	The DOM element targeted, including coordinates and accessible name.
Action status	Lifecycle tracking: `pending` → `confirmed` → `executing` → `completed` or `failed`.
User decision	For HITL gates: approved or rejected, plus any edits the user made before approval.
Session ID	Unique identifier for correlating all actions within a single CUA session.
Portal and task	The portal being accessed and the task description provided by the user.

Audit logs are retained for 90 days. They are accessible via the /v1/cua/stats API endpoint and through the session replay viewer (CuaReplayViewer) in the dashboard.

6. Data Handling

All data captured during CUA sessions is handled in accordance with EU data residency requirements and GDPR obligations.

Aspect	Policy
Storage location	Screenshots are stored in EU-jurisdiction R2 storage. No data leaves the EU.
Encryption at rest	All screenshots are encrypted with AES-256-GCM.
PII handling	No personally identifiable information is extracted from screenshots. They are retained as visual records only.
Auto-expiry	Screenshots auto-expire and are permanently deleted after 30 days.
Right to deletion	Users can request immediate deletion of all session data at any time, in accordance with GDPR Article 17 (right to erasure).

Security — how Pauhu protects your data
System Architecture — zone model, data pipeline, orchestration
API Reference — authentication, endpoints, error codes