Research

Published software / rv0.4.0

Curatom Polyglot rv0.4.0

Owner-Controlled Capability Infrastructure for Machine Authorization

A machine can ask for narrow, temporary authority without receiving the operator’s underlying credentials. The request is approved or refused by the operator, the authority is consumed, execution crosses explicit trust boundaries, and the result returns as recorded evidence.

Abstract

Authority without credential transfer.

Curatom Polyglot is open-source DeepTech infrastructure for machine authorization and capability security. An operator-issued machine key permits a knock for a specific resource and permission, but it does not permit self-approval. The operator decides; approved authority is bounded and consumed before execution; signed evidence moves across the next trust boundary; and the outcome returns to owner-scoped state. The release studies human-in-the-loop control for AI agents without placing the operator’s reusable credentials in the machine or downstream executor.

Approach

A knock, a decision, a spent capability, an outcome.

The design separates permission to ask from authority to act. The kernel remains the enforcement point; orchestration and execution are replaceable downstream systems.

01

The machine knocks.

An operator-issued Curatom key identifies an owner context and lets a machine request a named resource, permission, reason and duration. Possessing the key does not approve the request.

02

The operator decides.

The Rust/WASM kernel records a time-bounded knock. The operator sees it in the Leptos interface and approves or refuses it.

03

Authority is spent.

Approval creates bounded capability authority tied to the request digest. The kernel consumes each approved resource and permission pair before any remote handoff; a second consumption fails.

04

Execution crosses a boundary.

The Worker sends HMAC-signed evidence of already-consumed authority to the Elixir/OTP orchestrator. The remote side does not receive a reusable live Curatom capability or the operator’s credential.

05

The outcome returns as evidence.

The orchestrator sends an authenticated outcome back to the Worker. Owner routing is checked before the result is recorded in the operator’s activity state.

Implemented architecture

Typed enforcement, explicit state, replaceable execution.

Capability kernel

Rust/WASM owns the capability rules: expiry, request-digest binding, owner scoping, single-use consumption, freezes, connectors, repositories and checkpoints. Cloudflare Workers translate HTTP requests into that typed core.

Owner-scoped state

A CuratomKernel Durable Object is addressed per owner. D1 carries account, authentication and ledger state; R2 carries artifacts, repository manifests, sketchpad bodies, receipts and content-addressed checkpoint blobs. A separate Scratchpad Durable Object is addressed per machine-key hash.

Operator interface

The operator surface is a Rust/Leptos application compiled to WebAssembly. It exposes account and passkey flows, keys, knocks, approvals, activity, outcomes, repositories, whitepaper and sketchpad views without giving the browser Cloudflare binding access or live capability secrets.

Signed orchestration

The Worker consumes authority before an HMAC-SHA256 handoff. Elixir/OTP verifies the job body and action attestation before adapter dispatch, then signs the callback that returns the outcome. The shipped HostOS adapter is a mock, not a production HostOS integration.

Valhalla sandboxes

Valhalla is a separate Worker and Cloudflare Container subsystem for disposable workspaces: provisioning, execution, read/write, snapshots and restores. Checkpoint manifests and SHA-256-addressed blobs persist in R2; disposable sandbox state is not treated as authoritative.

Repositories and working memory

rv0.4.0 includes repository inventory and materialization, key-scoped sketchpads, checkpoints and workspace snapshots. These surfaces use the same owner-routing model and return operator-visible records and receipts.

Lineage

One project lineage. Separate source implementations.

Curatom rv0.2.0. The earlier comfortcurators/Curatom repository was archived on Zenodo before the hackathon submission. Its archive remains independently citable at 10.5281/zenodo.22112980.

Curatom rv0.3.0. The same earlier repository later became the Google Cloud All Things Agentic hackathon evaluation and submission state. Its own submission record distinguishes the pre-existing rv0.2.0 work from additions made during the event.

Curatom Polyglot rv0.4.0. This release was built from scratch in the separate comfortcurators/Curatom-Polyglot repository. It carries forward the broad intent—explicit human authority over machine action—but it is not an incremental source-code upgrade of rv0.3.0. The version numbers record project lineage, not source compatibility or architectural continuity.

Read the canonical lineage note

Status / boundaries

Working release. Visible limits.

01

rv0.4.0 is a working research and engineering release—a vertical slice—not a claim of finished production infrastructure.

02

The active machine path uses an operator-issued bearer key. Independent signed machine identity, mTLS/JWKS identity and production request signatures are deferred.

03

Worker/orchestrator trust uses a shared HMAC secret. The Elixir replay guard is process-local and resets with the BEAM process; asymmetric attestations and crash-persistent replay protection are deferred.

04

The shipped HostOS adapter is a mock. Action timeouts and cancellation, a retained production end-to-end proof, distributed rate limiting, active Cloudflare Access deployment configuration and safer transport for URL-carried credentials or payloads remain explicit boundaries.

Citation

Cite the archived release.

Rajvansh, Yash. (2026). Curatom Polyglot (rv0.4.0) [Computer software]. COMFORT CURATORS PRIVATE LIMITED. Zenodo. https://doi.org/10.5281/zenodo.22855407