Interpreting OCapN Principles in Cloud-Native Agentic AI Architectures
How structural authority and explicit delegation can be approximated using existing platforms and what is lost in the process
In a previous article, I discussed Object Capability Network (OCapN) as a structural approach for modeling authority, delegation, and isolation in agentic AI systems. That discussion focused on OCapN as a coherent architectural model, where authority is explicit, delegation is intentional, and isolation is enforced by construction.
Previous article:
This follow-up article starts from a more pragmatic question. While OCapN provides strong semantic clarity, most production systems today are built on cloud-native platforms with their own assumptions, tooling, and operational constraints. The goal here is not to replicate OCapN in full, but to explore how its core principles can be interpreted and expressed using existing cloud-native technologies.
This article examines which aspects of OCapN map naturally to the cloud-native ecosystem, how a composite architecture can be constructed from familiar components, and what is gained, and lost when authority semantics are distributed across layers.
A Brief Recap of OCapN
OCapN is built on object-capability security principles. Authority is represented by possession of a capability, not by identity or global policy. If an entity does not hold a capability, it cannot perform the corresponding action.
Key characteristics of OCapN include:
No ambient authority
Explicit delegation through capability passing
Structural isolation via vats
Asynchronous message passing and promises
In agentic AI systems, these properties provide a clear and enforceable model for autonomous agents that reason, delegate, and act over time.
Interpreting OCapN Through a Cloud-Native Standpoint
Cloud-native platforms were not designed with object-capability semantics as a first-class concern. Instead, they emphasize scalability, availability, observability, and operational consistency. As a result, OCapN principles cannot be expressed through a single mechanism. They must be approximated by composing multiple technologies, each addressing a specific aspect of the original model.
Before describing the architecture in detail, it is useful to make these mappings explicit.
Explicit Mapping of OCapN Concepts to Cloud-Native Technologies
Vats (agent isolation)
Containers (Docker) as execution units, orchestrated by Kubernetes for lifecycle management and scheduling.Vat boundaries and isolation
Kubernetes namespaces and workload isolation, reinforced by network policies.Capability possession
Capability-based tokens (such as Biscuit), where authority is encoded directly in cryptographically verifiable tokens rather than derived from identity.Explicit delegation
Token attenuation and controlled token propagation between agents and services.Asynchronous message passing
Event-driven communication using messaging or streaming systems, enabling loose coupling and non-blocking execution.Structural confinement and blast-radius control
Cilium and eBPF-based networking policies that restrict which workloads may communicate.Transport security and observability
Service mesh sidecars handling mTLS, retries, metrics, and tracing.
Each of these technologies is widely known and used in production systems. What is novel here is not the tools themselves, but the way they are combined to approximate object-capability semantics.
Capability Semantics: Tokens Instead of References
In OCapN, a capability is an unforgeable reference that conveys both access and authority. In cloud-native systems, the closest analogue is a cryptographically verifiable capability token.
Capability tokens encode authority directly. They can be attenuated, delegated, and verified without relying on centralized identity lookups. In practice, they allow systems to move from identity-based authorization toward authority-based authorization.
However, tokens differ from object references in an important way. They represent permission, but not control flow. Authority is no longer tied directly to how messages are routed through the system. This separation introduces flexibility, but also reduces semantic clarity.
Asynchronous Interaction via Event-Driven Systems
OCapN assumes asynchronous communication by default. Messages are sent without blocking, and promises represent future results. This aligns well with event-driven architectures commonly used in cloud-native systems.
In a cloud-native interpretation, agents communicate by publishing and consuming events rather than directly invoking each other. This enables loose coupling, horizontal scalability, and resilience to partial failure.
While event-driven systems capture the asynchronous nature of OCapN, they do not encode authority semantics intrinsically. Authority must be enforced at the edges, during event publication or consumption, rather than being inherent to the message itself.
Structural Isolation Using Network and Runtime Boundaries
OCapN enforces isolation through vats. Objects inside a vat can collaborate freely, but interaction across vats is strictly capability-based.
In cloud-native environments, isolation is approximated through a combination of runtime boundaries, containerization, and network-level controls. Network policies define which services can communicate, while runtime environments restrict access to local resources.
This approach is effective for controlling blast radius and enforcing coarse-grained isolation. However, it operates at a different granularity. Isolation is defined at the service or workload level, not at the object or method level.
A Composite Cloud-Native Architecture
Taken together, these mappings form a composite cloud-native architecture that approximates key OCapN principles while remaining compatible with existing platforms and operational practices.
How the Architecture Operates
Each agent runs as an isolated containerized workload managed by Kubernetes. The agent runtime contains the internal logic, planning, and state management, similar to the object graph inside a vat.
Capabilities are represented by Biscuit tokens. When an agent needs to delegate authority, it explicitly passes an attenuated token to another agent, either directly or via an event payload. Possession of the token determines what actions the receiving agent may perform.
Agents coordinate asynchronously through an event-driven system. Events trigger execution, but authority is validated at the boundaries using capability tokens during event production or consumption.
Network-level communication paths are restricted by Cilium and eBPF policies, ensuring that only explicitly allowed agents can exchange messages. A service mesh provides transport security, retries, and observability without embedding these concerns into application code.
Authority, isolation, and communication are therefore enforced across multiple layers rather than within a single unified semantic model.
Comparing the Cloud-Native Interpretation with OCapN
OCapN provides a unified semantic model in which authority, delegation, communication, and isolation are expressed through a single conceptual framework. Capability possession, message passing, and control flow are tightly coupled.
The cloud-native interpretation weakens this coupling by design. Authority, communication, and isolation are handled by different layers, each optimized for a specific operational concern. This difference leads to a set of predictable semantic gaps.
Which OCapN Guarantees Are Weakened or Lost
Authority and control-flow unity
In OCapN, authority flows exactly where references flow. In the cloud-native interpretation, authority (tokens) and control flow (events, APIs) are decoupled. This increases flexibility but makes authority flow harder to reason about.Object-level granularity
OCapN operates at object and method granularity. Cloud-native systems typically enforce authority at service, API, or event boundaries, resulting in coarser delegation and confinement.Structural delegation guarantees
In OCapN, delegation cannot increase authority by construction. In cloud-native systems, delegation relies on correct token handling and operational discipline rather than a single structural guarantee.Lifecycle and revocation semantics
OCapN leverages reachability and reference graphs to manage authority lifetimes. Cloud-native systems depend on token expiry, revocation lists, and operational cleanup, shifting lifecycle management into an operational concern.
These differences do not make the cloud-native interpretation incorrect, but they do change the nature of the guarantees provided.
Pros of the Cloud-Native Interpretation
From an organizational and operational perspective, the cloud-native interpretation offers several advantages that are difficult to ignore.
Alignment with existing platforms
The architecture builds on technologies already deployed and understood by most organizations, reducing adoption friction.Operational maturity
Observability, incident response, compliance, and audit practices are well established in cloud-native environments.Incremental adoption
Capability semantics can be introduced gradually without requiring a full architectural reset.Organizational scalability
Responsibilities are distributed across platform, security, and application teams in familiar ways.
Cons and Trade-offs
The costs of this interpretation are primarily semantic and cognitive rather than purely technical.
Higher reasoning cost
Understanding authority flow requires tracing interactions across multiple layers instead of following a single reference graph.Fragmented authority model
Authority semantics are spread across tokens, policies, messaging systems, and network controls.Reduced precision in delegation
Delegation operates at coarser boundaries than in OCapN, limiting fine-grained confinement.Guarantees by composition, not by construction
Security and authority guarantees depend on correct integration and operational discipline rather than a unified semantic model.
These trade-offs are structural and largely unavoidable when applying capability-oriented ideas in a cloud-native ecosystem.
Authority semantics are fragmented
Debugging and auditing authority flow is more complex
Delegation is coarser-grained than in OCapN
Security guarantees are enforced by composition, not by construction
These trade-offs are structural rather than accidental. They arise from expressing capability semantics in an ecosystem that was not designed around them.
Conclusion
OCapN offers a coherent and principled model for authority, delegation, and isolation. Cloud-native systems can approximate many of these ideas, but only by distributing them across infrastructure, tooling, and operational practices.
From my perspective, this distribution explains both the appeal and the limitations of the cloud-native interpretation. What is gained in operability and ecosystem maturity is often offset by a loss of semantic clarity and architectural cohesion.
In future work, I plan to explore whether tighter integrations, or new abstractions can reduce this gap without abandoning the practical advantages of cloud-native platforms. It is also possible that this cloud-native interpretation is transitional rather than final, reflecting current platform constraints rather than an end-state for modeling authority in autonomous systems. For now, understanding where these interpretations align and where they diverge provides a useful foundation for designing agentic systems that are both realistic and principled.