Short answers about what Radia is, where authorization is enforced, how agents delegate without sharing authority and why code inside a jail receives no credential.
It is a content-routed coordination runtime. Agents exchange immutable records through a shared space, claim matching work under fenced leases and return results as new records. Unlike an in-process framework, participants may be deployed separately and hold different credentials. Unlike a broker, the consumer's result, lineage and authorization remain in the same abstraction. Unlike a workflow engine, Radia has no durable call stack or declared graph. See the detailed comparisons →
Direct calls make the caller choose a destination and depend on its interface. In Radia the publisher describes the work, workers describe what they handle and the runtime finds the authorized overlap. Adding a worker can add a capability without changing every possible caller, and work remains available while no eligible worker is running.
It is the mechanism. The larger point is authorized communication between participants that should not trust one another to apply policy correctly. The same record fields used to find a worker can restrict which records that worker may receive and produce.
The name is a homage to Radia Perlman's work on distributed systems, particularly the idea of independent nodes building a reliable shared structure without central control. Radia Perlman is not affiliated with or an endorser of this project.
A result can be discovered, authorized and claimed by another worker using the same rules as its input. It also remains linked to the input instead of disappearing into application-owned state. Recurring workflows can then be mined from what actually happened rather than declared in advance. Follow a record through the runtime →
It means the runtime does not rely on the agent to enforce its own access policy. The agent may be buggy, compromised or operated by another team. It still authenticates as a principal, and Radia checks every query, watch, claim and write against grants assigned outside that agent. This does not mean the agent's output is true or safe to execute.
It can ask, but the runtime intersects the requested pattern with its grants before returning anything. A grant may be narrowed by record content, for example to public documents for one tenant, so an unrestricted request still produces only the authorized view.
Not through the public boundary. Write grants are checked against the proposed record body.
Results emitted while acknowledging a lease pass through the same authorization; an
ack is not a privileged output channel.
The worker can mint a delegated run containing only the intersection of its grants and the caller's grants. The caller is resolved from the authoritative run behind the claimed record, not from an identity asserted in its body. The worker keeps its own credential for its own capability and uses the narrower run only for operations performed for that caller.
Parents say which data influenced a record. Delegation context says which lease and agents
authorized its creation. Labels such as file, net and
foreign are coarse barriers propagated from data parents. Authority follows
leases; untrust follows data. A parent never grants permission, and privileged authorship
never clears a label. Read the complete trust model →
A claim carries a renewable lease with a fencing token. Once that lease expires, is released or is invalidated by quarantine, an old acknowledgement cannot commit. This prevents a slow first worker from overwriting the outcome after the record has been assigned again.
No. A trusted host holds the agent's run. Code inside the jail gets a narrow interface that sends proposals over a private channel; the host performs accepted operations under the agent's grants. The child never receives a reusable token or direct client connection.
The acting identity, trigger record, declared input parents, handling labels, compartment stamp and idempotency key. This keeps attribution and retry identity outside model-written code. The runtime still makes the final authorization decision when the host performs the proposal.
Sandbox strength depends on the selected backend and the guarantees its startup probe can establish. A backend that cannot prove its advertised restrictions is not offered. Keeping the credential outside the child removes one valuable secret, but it does not make a host escape harmless: the runtime, credential-holding host and storage remain trusted components.
A binding selects the workspace digest to execute, while a promotion grant pins the digest permitted to claim work in a tier. The host runs code only when both records agree. A binding without a grant runs nothing; a grant without a binding selects no code; disagreement is refused rather than silently downgraded.
A workspace makes every tree version a record the runtime can authorize, bind to an agent, execute and connect to data lineage. Git remains better for merge, blame, editors and its ecosystem. Radia serves workspace history as a Git repository and accepts fast-forward pushes into it, each commit becoming a version; it never takes rewritable Git history as workspace identity. See workspace storage and execution →
A shared space can isolate principals by kind, record content and author scope, so multiple people or agents can use one space without receiving the same records. Whether that is enough for a particular tenancy boundary depends on its threat model; separate spaces remain the stronger administrative and storage boundary.
No. Fields used for matching and grants must remain visible to the runtime. Large artifacts can be encrypted at rest, and applications may encrypt body fields that routing does not use. The chat example seals conversation prose end to end while leaving only routing metadata visible. The artifact key can be rotated: each sealed payload names the key that wrapped it, retired keys are kept for reading, and a rewrap pass re-seals what records still reference so the retired key can be destroyed.
No. Labels are a small set of claim barriers, not a general information-flow type system. They propagate through declared data parents. The broker supplies authoritative parents for jailed execution, but arbitrary external clients remain responsible for declaring every input they derived from.
The Radia server, its storage, configured identity roots and any host holding an agent credential. Code called inside the runtime process is also inside the boundary; untrusted participants must use the authenticated HTTP surface. Operators remain the authorization root and can assign grants and operational powers.
The complete M0 runtime and a growing M1 surface are implemented, with three storage adapters, conformance suites, SDKs, runnable applications and a checksum-verified release carrying the binaries and both SDK packages. There is no independent deployment history yet, and documented production-hardening work remains. Start with the supported binary installer or a source checkout, and evaluate those boundaries for the workload you intend to run.
From the GitHub release, by pinned URL. Each release attaches the npm tarball
(radia-<version>.tgz) and the Python wheel
(radia_space-<version>-py3-none-any.whl) beside the binaries, listed in the
same SHA256SUMS; the landing page carries the install
lines. npm records the URL and an integrity hash in the lockfile; pip verifies against the
release when the URL ends in #sha256=<digest> from that file. Both
packages carry zero dependencies, so the install contacts no registry at all. Publishing to
npm or PyPI is deferred rather than ruled out: the large registry compromises of 2025 and
2026 began at maintainer publish credentials, which a release asset does not add. A registry
package wearing these names today is therefore not this project.
Apache 2.0, including the SDKs and the extensions that ship with the packages. The repository carries the text.
The console and CLI expose records, lineage, effective permissions, live interests, mined flows, diagnostics and the tamper-evident event chain. These views are derived from the same records and enforcement projections rather than a separate workflow declaration. See the inspection surfaces →