Object-Capability Security

Object-capability (OCap) security is an approach to distributed systems security in which authority is conveyed exclusively through object references — not through centralized access control lists or ambient authority. It eliminates an entire class of “confused deputy” attacks by making it structurally impossible to articulate an action you’re not authorized to take. Presented at NoConsensus.wtf 2025 in the context of the Wetware project, a secure off-chain execution environment for distributed applications. (→ NoConsensus.wtf 2025 — Overview)

The Problem: Ambient Authority (Louis Thibault / Wetware)

Ambient authority: a program can name and request access to any resource in its environment, regardless of whether it was authorized to use it. Classic example: a program can attempt to open /etc/passwd — whether it succeeds is checked after the request is articulated.

Problems this creates in distributed systems:

  1. Performance: a naive permission system calls out to a policy oracle on every operation, stalling the pipeline with round-trips.
  2. Concurrency hazard: policy changes race with application logic — it’s very hard to guarantee a policy update takes effect before a specific pipeline step.
  3. Non-composability: global ACLs affect all users simultaneously; you can’t compose services with different policies without them interfering.
  4. Confused deputy: a trusted component (the deputy) can be tricked into using its authority on behalf of an unauthorized caller.

The confused deputy attack: if you can name a resource but don’t hold a reference to it, you can ask an authorized deputy to access it for you. This is the structural root cause of many injection attacks (SQL injection, SSRF, etc.).

The Solution: Object-Capability Model

In the OCap model, authority = possession of an object reference:

  • Objects communicate only by calling methods on references they hold.
  • References are unforgeable (generated as cryptographic UUIDs or equivalent).
  • If you don’t hold a reference to an object, you cannot name it, cannot call it, and cannot ask a deputy to call it on your behalf.

This collapses naming and authorization into a single primitive: you have either both or neither.

The Vat Model (E Language / OCapN)

Wetware implements a vat: a single-threaded event loop with an object heap and asynchronous message passing.

Properties:

  • Single thread: one event processed to completion before the next starts. Eliminates intra-process concurrency hazards.
  • No suspendable coroutines: the stack runs to completion. No suspended state that could be interrupted by a concurrent event.
  • Async RPC via promises: method calls return immediately with a promise. The caller doesn’t block. The event loop maps incoming messages to heap objects.

Promise pipelining (time travel optimization): if you call method foo on a remote object and immediately call bar with the result of foo as an argument, you can pass the promise identifier (not the resolved value) to bar. When the server receives bar, it sees the promise for foo and knows foo’s result is local — no second round-trip needed. At network scale, this pattern significantly reduces latency.

Attenuated Composition (Caretaker Pattern)

Unattenuated composition: Alice passes Bob a direct reference to Carol. Bob now has all of Carol’s capabilities, forever. Unrevocable.

Attenuated composition (caretaker):

  1. Alice creates a Caretaker object that holds a reference to Carol.
  2. Alice passes Bob a reference to the Caretaker, not to Carol directly.
  3. Bob calls methods on the Caretaker, which checks an enabled boolean before forwarding to Carol.
  4. Alice can revoke Bob’s access by setting enabled = false — the Caretaker drops all further messages.

Extensions: Caretakers can filter specific methods (method attenuation), allow only one call (use-once capabilities), or log all accesses for auditing. This is the fundamental pattern for composable, revocable authority in OCap systems.

Wetware: Off-Chain OCap Execution (Louis Thibault)

Wetware applies OCap principles to off-chain distributed applications:

wetware run <binary>

Runs a binary in a “fully gelled process” where the only possible communication channel is the OCap VAT network. No filesystem access, no arbitrary network sockets, no ambient environment.

Result: when you eliminate every way to name a resource except through the shared reference graph, the property Phil Daian describes as “ambient authority” becomes structurally impossible. The guest binary literally cannot articulate a request for resources it hasn’t been granted a reference to.

Practical consequence: the entire class of confused-deputy attacks is factored out. An attacker who wants an unauthorized resource cannot ask a deputy to fetch it — they have no way to encode the request.

Connection to Blockchain Design

Smart contracts already implement a primitive form of OCap: you can only call contracts you have addresses for, and msg.sender authentication is a form of reference-based authority. But the analogy breaks down with:

  • Global state (any contract can read any storage slot with sufficient gas).
  • Ambient authority via CALL with arbitrary targets.
  • Non-composable access control (e.g., calling a smart contract to check permissions introduces the concurrency and composability problems described above).

Off-chain services (searchers, builders, MEV bots) are entirely in the ambient authority world. Wetware attempts to bring OCap discipline to this layer.

Connections

Open Questions

  • Can Wetware’s single-threaded vat model achieve sufficient throughput for high-frequency block-building workloads?
  • Does the OCap model compose with TEE security properties, or do they require different enforcement mechanisms?
  • Is promise pipelining practically usable across high-latency WAN connections in a block-building context?