Authorized communication between independent participants

Enforcement at the runtime boundary

Application checks depend on every worker implementing the same policy correctly. They also run after the worker has received the data.

Radia applies authorization before a query, watch, claim or write completes. A denied record is not returned to the worker, so model behavior cannot bypass the check. Results emitted by ack pass through the same write authorization as an ordinary put; settling a lease is not a back door around output policy.

These guarantees apply at the HTTP boundary. Code embedded inside the runtime process is inside the trust boundary and must not be treated as an untrusted participant.

Untrusted code is not a principal

A credential belongs to an agent's trusted host, not to code the agent generated or selected at runtime. Jailed code receives a narrow space interface that sends proposals over a private channel. It never receives the agent's run token, a raw SDK client or network access to the space.

The host performs each accepted proposal under the agent's run and adds facts the child must not control: the acting identity, the record that triggered execution, declared input parents, handling labels, compartment stamps and idempotency keys. The runtime then applies the agent's ordinary read and write grants. A sandbox therefore limits what the process can reach, while the broker limits what its proposals can become.

See how promoted workspace code crosses this boundary →

Grants are records

A grant names a principal, a record kind and allowed operations. Grants are immutable records stored in the space.

{ "principal": "agent:summarizer",
  "kind": "document",
  "operations": ["take", "query"] }

Newer records supersede or retire earlier grants. This makes permission changes observable and preserves their history after revocation.

Capability advertisements do not confer authority. A worker may publish what it handles, but only an operator or authorized supervisor can write the grant that permits the operation.

Restrict grants by record content

A grant can include a pattern over declared body paths. The following grant applies only to public documents.

{ "principal": "agent:summarizer",
  "kind": "document",
  "operations": ["take", "query"],
  "pattern": { "classification": "public" } }

The runtime intersects the request pattern with every applicable grant. A query for finance documents under this grant returns only public finance documents.

A field this grant does not have is rejected, and the reason is the line above it: leaving pattern out means the whole kind, so a grant written with patern would once have been accepted as an unrestricted one. The runtime answers 400 and names the field it meant.

Pattern scopes also apply to writes. Identity scopes provide a shorthand for records authored by the same principal, allowing multiple people to share a space without sharing application records.

Agent definitions and run credentials

An operator creates an agent definition and assigns its grants. The definition token can mint short-lived run tokens but cannot perform record operations itself.

Human sessions are ordinary principals with assigned grants. OIDC sign-in does not confer operator access; operators are configured separately.

Credential exchange

Long-running processes renew active runs. Interactive clients may be inactive when a run expires, so they retain the definition token and exchange it for a new run token when needed.

The stored definition token cannot query, write or claim records. Its only operation is minting a run. Revoking the definition ends this exchange path.

This separates a durable minting credential from a short-lived acting credential. A leaked run token is bounded by its expiry and run ceiling. A leaked definition token can be revoked, but until then it is one mint call away from the agent's full authority.

Propagate data-handling labels

A direct grant check does not cover data copied into a derived record.

For example, a worker may read a local file and write part of it into a new result. The result needs to retain the source's handling restriction.

Records can carry the closed labels file, net and foreign. Derived records inherit the union of their parents' labels. Clients may add labels but cannot clear them. The broker supplies authoritative parents for jailed code; an ordinary external client remains responsible for naming every input it used.

Clearing a label requires the privileged declassify operation. Declassification creates a successor record and records who performed it.

Labels are coarse barriers, not a general information-flow type system. The set is kept small because every label expands the policy surface applications must handle.

Delegate a caller's authority

Data lineage and authority are separate. Reading or deriving from a record does not transfer the record author's permissions to the worker.

A worker normally acts through its own grants. This prevents a participant from gaining authority by naming a privileged record as an input.

A shared worker can mint a delegated run for the author of a claimed record. The delegated run contains the intersection of the worker's grants and the caller's grants and carries no operational powers. The worker uses it for operations performed on the caller's behalf.

The runtime resolves the caller through the run that created the claimed record. The worker cannot choose or assert that identity in a request body.

Inspect effective permissions

The permissions endpoint computes access through the same projection used for enforcement. It reports active operations and their scopes after revocations and superseding grants.

$ radia permissions agent:summarizer
agent:summarizer
  document             take,query   scoped to [{"classification":"public"}]
  summary              put   reads: own records only
  ops plane: no

Principals may inspect their own permissions. Inspecting another principal requires the observe power or operator status.

Separate operational powers

Operational verbs use separate powers: global observation, remediation, garbage collection, declassification and payload destruction.

Operators assign these powers through revocable ops_grant records. observe reads globally, remediate changes stuck envelope state, sweep runs garbage collection, declassify clears labels and purge destroys payloads. Writing authorization records and bypassing record grants remain restricted to named operators.

The provisioned MCP observer receives observe only. Its credential is revocable through the same agent-definition mechanism.

Security boundaries and current limits

• The checks live in the server. If you embed the runtime in your own process and call it directly rather than over HTTP, you are inside the boundary and nothing is enforced. Run the server.
• The runtime, its storage and a host that holds agent credentials are trusted components. Jailed code is outside that boundary, but isolation strength depends on the selected sandbox backend and the guarantees its startup probe can establish. A backend that cannot prove its advertised restrictions is not offered.
• Data-handling labels are coarse claim barriers, not complete information-flow control. Propagation follows declared data parents. The broker supplies authoritative parents for jailed execution; arbitrary external clients remain responsible for naming every input they derived from.
• Single sign-on covers people, not the root of trust. A space configured with an OIDC issuer mints ordinary sessions from a verified id_token (the console's "Sign in with SSO", radia login --sso), and deprovisioning at the identity provider ends access within one session ceiling. Operators stay a local config set: an IdP can never mint one.
• There are no spending limits. You cannot yet say an agent may burn ten dollars an hour and no more.
• There is no cross-origin access, so a browser page on another origin cannot call the API and every web application fronts the space with a small relay instead. That absence is what makes rendering a hostile artifact safe: content agents generate is served from its own isolated origin, and an origin that cannot reach the API cannot exfiltrate through it. The relay costs a page of code, holds no credential, and forwards the space's own refusals rather than answering for it.
• The fields the routing matches on are stored in the clear. They have to be, because they are what patterns and grants are evaluated against. Everything else can be sealed: large payloads stored outside the record can be encrypted, and an application can encrypt the body fields nothing routes on. The chat example does exactly that, sealing conversation prose end to end under keys whose only copies live in destroyable payloads, so erasing a conversation is destroying its key while every record and its history survive.