philippeabraxas-jpg/tbp-networkTheory and implemantation of the TBP protocol to secure networked AI in small to open web networks
Network-level implementation of the Teleological Bounding Protocol (TBP) — attested governance of AI agent actions over a network, from a single machine to enterprise deployments up to WWW scale.
« Existing access control decides whether you get in; TBP decides what you're allowed to do once inside — and proves it. We govern capabilities, not models. »
Never a partnership by trust — only by an attested handshake. That is the goal: the inter-entity handshake (spec §3) lets entities that do not trust each other prove policy, history and liveness to each other. The handshake itself is not built yet (#33). What this repository contains today is what comes before it and what it will rest on — the PEPs, the cell broker and registries, NAC, supervision, the deployment guides — which extends TBP's governance from a single machine to a small network of machines under one organization.
Not for production. Throw-away keys, machines you can lose, no real data. It exists so that you can try to break TBP before a production release does.
TBP-NETWORK ships a simple deployment to run and attack before a production release exists. Three machines,
each deployed by one script: M1 the cell (brokerd and its OPA), M2 an application server (pepd and a
small application), M3 an agent. It tests that the whole thing works — an agent enrolled by its certificate,
a decision over mutual TLS, a token checked by a server, the server's posture governed by the controllers — with the
real binaries and the real enforcement; only the key ceremony is simplified. A one-machine variant lets you look at
the cell alone.
Everything is in deploy/dev-test/: what each machine is for and why, the exact procedure from fresh Debian 12 machines, the scenario to test, where to attack, what it does and does not prove — and how to send us your numbers and comments for each environment you try, which we want. Anything exploitable goes through SECURITY.md, not a public issue.
TBP does not close every hole; it audits every hole. That's not a limitation to work around, it's the founding postulate (spec §1: "we do not close every hole; we rank holes by impact and mitigate proportionally — governance is allocation, not completeness"). TBP is not a self-sufficient security system — it doesn't replace SELinux, firewalls, IAM, or OS-level sandboxing, and it never will by design. What it does is narrower and non-negotiable: no governed action executes without a cryptographically provable decision, and no decision — allow or deny — escapes the audit chain unprovable and uncorrupted. TBP is a governance and attestation layer over whatever enforcement stack a deployment already has, not a substitute for it.
How much TBP restricts is a deployment choice, not a protocol property. Between allow-all (monitor mode, everything logged, nothing blocked) and deny-all sits a whole spectrum, shaped by which OPA rule packs a cell loads, which scale (below) it operates at, and how far it pushes plan contracts, quorum, and the (planned) risk-scoring layer (#177–#181). A personal lab and a regulated production cell can run the identical protocol at very different points on that spectrum, and that's by design, not a gap — see "Next planned work" below for the rule-pack / posture presets planned for the per-scale admin console.
Exactly two things don't move, at any point on that spectrum:
tbp4.2.1/README.md.
These are the categories where a bad action isn't reversible by
revoking access after the fact; no deployment posture, rule pack, or
scale ever relaxes them.Everything else — how wide the allowed envelope is, how much friction an operator accepts, which compositions require a human signature — is a choice between complexity, operational need, and what a given deployment can actually run, not a property of the protocol itself.
Note on language: the reference specification is now
docs/spec-en-v1.0.md (English) — this is the
document code and audits should be built against. Its version number
resets to 1.0 deliberately: it's a clean restart into a citable, versioned
document (§13: "versioned conservatively; changes pass through signed,
attested transitions"), not a continuation of the working note's own
count — the higher-numbered working note is not the newer document. The
author's working note — denser, less linear, useful for design-rationale
digging, but not the one to cite — exists in two languages:
docs/spec-v1.4.10.md (English) and
docs/spec-v1.4.10.fr.md (original French).
The same convention applies across the repo: every document originally
written in French now has an English primary at its original path, with
the French original kept beside it as <name>.fr.md. The glossary
(docs/glossaire.md) is still French-sourced (§14 of the French doc is
its terminology source of truth) with an English gloss column for
readability — this is unchanged.
The full specification is docs/spec-en-v1.0.md
— it is the source of truth for any design or configuration decision in
this repo. This README only summarizes what's needed to get oriented;
when in doubt, the spec governs. The working note
(docs/spec-v1.4.10.md, English translation of the French original) is
not superseded content-wise — it's the same protocol, developed there
first — but it is not the citable reference going forward.
Useful landmarks for reading it:
docs/glossaire.md — one canonical term per
concept, to be used consistently across the code and docs of this repo
(see CONTRIBUTING.md).