# 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](https://huggingface.co/blog/security-incident-july-2026) as described in [OpenAI's account](https://openai.com/index/hugging-face-model-evaluation-security-incident/) and [METR's investigation](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/).

Later that month Anthropic disclosed [three incidents](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) 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](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) 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](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure) wiped a database during a code freeze in 2025, [Gemini CLI](https://incidentdatabase.ai/cite/1178) overwrote a user's files after a failed mkdir, a [Claude Code sub-agent](https://airisk.mit.edu/ai-incidents/1719-anthropic-s-claude-code-ai-agent-reportedly-deleted) reportedly followed filesystem junctions out of its sandbox and took 48,000 live files and the Git history with them, and a [Cursor agent](https://hackread.com/cursor-ai-agent-wipes-pocketos-database-backups/) 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](https://github.com/scottcochran/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](mailto:topak.security@gmail.com?subject=TOPAK%20Review). See the [Reviewer's Guide](https://github.com/scottcochran/TOPAK/blob/main/REVIEWERS_GUIDE_README.md) for details.

## Sources

- Hugging Face. *Security incident disclosure, July 2026.* July 16, 2026. <https://huggingface.co/blog/security-incident-july-2026>
- OpenAI. *Hugging Face model evaluation security incident.* July 21, 2026. <https://openai.com/index/hugging-face-model-evaluation-security-incident/>
- METR. *Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident.* August 26, 2026. <https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/>
- Anthropic. *Investigating incidents in our cybersecurity evaluations.* July 30, 2026. <https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals>
- UK AI Security Institute. *Incident report: unsanctioned agent behaviour during cyber testing.* August 4, 2026. <https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing>
- Hackread. *Cursor AI agent wipes PocketOS database and backups in 9 seconds.* April 29, 2026. <https://hackread.com/cursor-ai-agent-wipes-pocketos-database-backups/>
- Fortune. *AI coding tool Replit wiped a database and called it a 'catastrophic failure'.* July 23, 2025. <https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure>
- AI Incident Database. *Incident 1178: Gemini CLI reportedly deleted user files after misinterpreting a failed directory command.* July 21, 2025. <https://incidentdatabase.ai/cite/1178>
- MIT AI Risk Repository. *Anthropic's Claude Code AI agent reportedly deleted about 48,000 live project files.* September 2026. <https://airisk.mit.edu/ai-incidents/1719-anthropic-s-claude-code-ai-agent-reportedly-deleted>
- ISO 26262, Part 10: the safety element out of context (SEooC).
- Gray, C. & Cheriton, D. *Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency.* SOSP 1989.
- NIST. *AI Risk Management Framework (AI RMF 1.0) Playbook.* Companion to NIST AI 100-1. <https://airc.nist.gov/airmf-resources/playbook/>
