8. IROA Secure Execution Space

IROA’s default remote runtime is a resettable secure execution space provided by IROA or an approved operator—not the user’s computer. It supports users without a smartphone or PC and handles long-running or high-compute work.

Per-request Task Capsules running across isolated Nodes and producing verifiable proof

8.1 Requests that need secure execution

Examples include institutional booking and cancellation, long waiting-list or delivery checks, multi-service comparison, long forms and accessible document conversion, robot-side planning, and approved asynchronous work while a device is disconnected.

8.2 Isolated workspace per request

Each task receives a fresh browser or container and encryption key, allowlisted domains, tools, actions, cost, and time, approved images and updates, remote attestation, restricted logging, and deletion of cookies, temporary files, and keys at completion. Operators cannot access raw conversation, health, or booking data.

A Task Capsule binds seven controls:

request declaration with purpose, service, success condition, and expiry;
one-time capability limited by domain, tool, action, and cost;
credential-vault link using official authentication, passkey, or short token;
policy sandbox controlling file, network, message, payment, and transfer;
mandatory user-confirmation points;
Result Receipt proving booking, submission, or payment outcome; and
Deletion Receipt proving disposal of temporary credentials, cookies, and keys.

Receipts do not publish raw personal data. Only non-identifying policy version, runtime state, or integrity proof may be retained where necessary.

8.3 Execution-space types and trust levels

Level	Example	Permitted requests
N0 public compute	Verified de-identified compute pool	Public information and synthetic or de-identified processing
N1 managed execution	IROA secure space or registered operator	Low-risk isolated web tasks and long tracking
N2 approved access point	Kiosk, welfare center, companion	Booking, ordering, bounded identity, human connection
N3 institution	Hospital, municipality, welfare institution	Sensitive work within contract and qualification
N4 personal approval	Watch, mobile, passkey, in-person check	Credential use and final approval

A higher level does not automatically permit more personal data. Purpose, consent, data class, and current attestation must all match.

8.4 Identity, passwords, and OTPs

Execution spaces do not receive full account authority, passwords, or OTPs. Passkeys, OAuth, device or institutional confirmation, and verifiable credentials disclose only the necessary qualification. Payment or legal effect requires confirmation through a separate channel. Automation stops when safe separation is impossible.

8.5 Personal computers are optional

A user may choose local execution for already-authenticated services or private files, but owning, installing, powering, or maintaining a PC is never a condition for IROA access. Local execution runs only an explicitly enabled request and can be disconnected at any time.

8.6 Companion and robot execution

Wake word, accessibility preferences, short conversation, and safety policy should remain on-device where practical. Larger reasoning receives only necessary inputs and one-time authority.

A home companion device safely handing a complex request to a human supporter

Robotics advances from fixed speakers, displays, kiosks, and telepresence; to bounded mobility trials; and only then to narrowly reviewed physical assistance after safety, insurance, ergonomics, institutional, and field validation. Default face recognition, continuous recording, coercive tracking, unauthorized door opening, object movement, and physical contact are prohibited.

8.7 Data in use

Encryption at rest and in transit is not enough. Sensitive work must also minimize plaintext in memory, isolate processes and operators, constrain debugging and screenshots, rotate keys, and expose deletion and incident evidence. Higher-risk technologies require independent review before production claims.