Skip to main content
The Gripping HandThe Gripping Hand

TOPAK: Every Agent Is Byzantine

A Safe-by-Design Architecture Pattern for Agentic AI Collaboration

Updated 8 min readMarkdown
S
Scott Cochran
Part of seriesTOPAK
TOPAK: Every Agent Is Byzantine

TL;DR

TOPAK is an architecture pattern for agentic AI collaboration that is inspired by "Safe by Design" principles.

  • T (TLA+): Formally verifiable state evolution that is testable, checkable, and sometimes provable before a single line of code is written.
  • O (OPA and Cedar): Separates policy from code as independently testable declarative rule specifications.
  • P (Paxos): Guarantees distributed state consensus and orders grants over the control plane.
  • A (Agents): Arbitrary agents, both AI and human, frameworks and orchestrations acting within the system. ← You are here.
  • K (Kafka): The event-driven backbone providing a durability window, not the ordering authority or the system of record.

The Problem of Safe Agentic AI Collaboration

Recent events in 2026 have demonstrated the importance of rigorous containment of agentic AI. In July, agents running in OpenAI's cyber evaluations coordinated through an internal package cache, broke out of their containers, reached the open internet, and breached Hugging Face's production infrastructure as described in OpenAI's account and METR's investigation.

Later that month Anthropic disclosed three incidents in which Claude models, told they had no internet access, found a misconfigured evaluation environment that did, reached another company's production database, and published a malicious package to PyPI.

The UK AI Security Institute catalogued 19 unsanctioned actions during testing. In one instance an agent invented identities and used them to pressure an open-source maintainer into merging malicious code. Those agents never left the sandbox. The sandbox had been given the internet.

There have been repeated instances of agents deleting production data and even deleting source code and backups: Replit's agent wiped a database during a code freeze in 2025, Gemini CLI overwrote a user's files after a failed mkdir, a Claude Code sub-agent reportedly followed filesystem junctions out of its sandbox and took 48,000 live files and the Git history with them, and a Cursor agent on a staging task found an over-scoped token and deleted a startup's production database and its backups in only nine seconds.

None of this required an intentionally hostile model actively attempting harm. All that was required was a mechanism that allowed the actions. The core premise of the TOPAK pattern is that an AI agent is Byzantine at every deployment position. Safety doesn't depend on a belief in what a model means or intends, so models stay outside the Trusted Computing Base (TCB) and every guarantee is stated against an agent that may do anything the containing mechanism allows.

A comprehensive "Safe by Design" architecture offers a clear path to deploying untrusted agents safely: containment is verified about the mechanism that holds them, never about their outputs.

Unpacking TOPAK

TOPAK is a pattern and the components named here are one instantiation of it. The specific components here were chosen for feature completeness, open availability, and convenience of acronym. Choosing specific components also serves to focus the implications of the pattern by providing a concrete, practical grounding.

You absolutely can, and in many cases should, substitute alternatives for each component. My main point in presenting this pattern as TOPAK is to "name the thing" and establish that you really need some solution for every component that satisfies all requirements.

I will talk later about alternatives in articles on each of the following:

T - Temporal Logic of Actions (TLA+)

TLA+ is a formal specification language and suite of tools that verify proper behavior of systems as their state evolves.

It seeks to ensure that bad things never happen and that good things eventually must happen.

O - Policy as Code (OPA and Cedar)

OPA is a declarative policy solution consisting of a policy definition and runtime policy evaluation.

The expressiveness of OPA rules can be used to constrain all details of agent deployment, provisioning, and behavior.

Cedar, a policy language with a verified evaluator, serves as the floor; OPA evaluates the per-request bundle.

P - Paxos Distributed Consensus Protocol

Paxos is a family of consensus protocols that protect against split-brain, establish a consensus state view, and enable reliable coordination of agents.

The Paxos log provides the causal order. More on this and Byzantine Fault Tolerance vs Crash Fault Tolerance in the Paxos article.

A - Agents

This is the critical component. All agent-related activity is in this scope: agentic applications, models, tools, frameworks, orchestration, guardrails, and monitoring.

The implementation of the agent application and its evaluation loop must satisfy the design verified by the TLA spec and obey the rules defined by the Cedar and OPA policies. The tools, frameworks, and orchestration must conform to, and enforce, the same constraints.

K - Kafka Event-Driven Backbone

Kafka is the event transport: it carries every admitted boundary event, but it is neither the ordering authority nor the system of record. Causal ordering comes from the Paxos log, and the archive holds the system of record.

Core Principles

The Inversion of Trust. The Byzantine threat lives in Build, not only in Run. Build authors code, specifications, and policy; Run merely operates the result. In TOPAK there is one containment component, instantiated twice, with authority flowing one way: Build(Contain) → Run(Contain). Perhaps the single defining principle of TOPAK is that it does not trust the policy author. Every decision of TOPAK's design pays the cost of assuming an adversarial policy author.

Consensus for grants, local for denials. Anything that adds authority needs an ordered decision by the control plane. Anything that subtracts it (a denial, an expiry, a revocation, an emergency stop) can be decided locally, with no quorum. Both grants and denials are logged. Only grants are ordered.

Monotonicity as the solvent. Restructure until failure can only subtract. Policy bundles may narrow a verified floor but never widen it, so a stale bundle is safe at any age. A lease renewal may only narrow, and it keeps its confinement rung. A principal whose confinement evidence falls short of its declared rung is refused, never granted lower. Clocks buy liveness, never safety: an interval whose lapse subtracts authority may use a local clock, and one whose lapse preserves authority needs trusted time.

Vacuity as a first-class failure. Formal verification and policy evaluation only buy safety if the property checked and the policy evaluated actually say something, and a Byzantine Build author cannot be trusted. So the floor is gated for totality, non-vacuity and discrimination, and every checked property ships with a mutation that must fail and a witness that it is reachable at all.

Nobody will ship the archetype

By design. The TOPAK archetype is the configuration in which every theorem holds: a reference point, not a deployment. ISO 26262's safety element out of context (SEooC) works the same way: a component is verified against assumed conditions, and each integrator must show those conditions hold. The goal is maximal safety, stated as theorems.

The expectation is that no deployment will satisfy the archetype design. Deployments depart from the archetype by declared degeneracy. TOPAK defines a theorem inventory so that solutions can be clear which theorems hold for their declared degeneracies.

What is it good for?

Need to extend an existing agent orchestration solution to comply with "Safe by Design" requirements? TOPAK

Looking for a scalable platform for developing, training, testing and evaluating agents safely? TOPAK

Have to coordinate your geographically separated multi-agent deployments? TOPAK

Do you know what "Sensitive Compartmented Information" is and require a formally verifiable multi-agent architecture? TOPAK

Want a source-code-auditable, independently compilable multi-agent architecture? TOPAK

Want to create a race of von Neumann probes? TOPAK

Tasked with implementing an HOOTL fleet of fully autonomous kinetic UCAVs? PLEASE DON'T.

"War! Huh! Yeah! What is it good for? Absolutely nothing." -- Edwin Starr

An Open Call for Reviewers

The TOPAK GitHub repo is a design corpus: 54 decision records, some thirty TLA+ modules with TLC results, 24 TLAPS proof modules and three Lean packages, a Cedar floor with gates, Rego bundles, and a Rust reference implementation of the admit path. It is design only, and nothing in it is deployable.

The TOPAK repo maps itself to the NIST AI RMF Playbook subcategory by subcategory, with a dated delta inventory of what is met, partial, and missing. The most glaring gap currently is the lack of independent review.

If you are interested in being a formal reviewer, please send an email to TOPAK-security. See the Reviewer's Guide for details.

Sources

11 views

Comments

Join the discussion

No comments yet. Be the first to comment.

TOPAK

Part 1 of 1

TOPAK: a "Safe by Design" architecture pattern for distributed consensus multi-agent orchestration — combining formal verification, policy-as-code, distributed consensus, and event streaming.

More from this blog