June 6, 2026 · Changkun Ou
Agent harness design: the governance fabric
June 6, 2026
This is a companion to Agent harness design: trade-off analysis, which frames the agent platform as a set of separable primitives. That overview names four primitives the ecosystem commonly agrees on and argues that two more deserve to be separated out. The first, model access, is the easy case. This post makes the harder one: that there is a distinct governance fabric, and that it is not the identity fabric wearing a different hat.
This is the riskier claim of the two, so it is worth stating the objection first and answering it directly, rather than asserting a sixth box and moving on.
The contract
A governance fabric resolves three things, and nothing else.
Resolve this agent definition to its effective, attenuated capability set. Decide whether this action is permitted for this agent at this delegation depth, and whether it needs human approval. On delegation, enforce that a child agent's capability set is a subset of its parent's.
In symbols, the load-bearing invariant is C_child ⊆ C_parent: authority can only ever shrink as work is handed down a delegation chain, never grow. Everything else, who the caller is, where code runs, which model answers, what the harness decides to send, belongs to a different primitive.
Isn't this just the identity fabric?
The objection is fair, and it is the reason this primitive is contestable. The identity fabric already owns capability tokens, on-behalf-of delegation, attenuable tokens like Macaroons [1] and Biscuit [2], the agent_id in its caller tuple, and attribute-based access control. If identity already issues attenuable, scoped, delegatable tokens, what is left for a separate fabric to own?
The line is precise, and it holds:
- Identity owns authentication, principal resolution (which human, which workload), token issuance and exchange (the mechanism of scoping and attenuation), resource-access authorization, and tenancy. It answers "who is this caller, and may this principal touch this resource?"
- Governance owns the agent as a versioned, owner-signed document, the declared capability set that document carries, the delegation topology (who may spawn whom, with what hop limit), and the placement of human approval across the fleet. It answers "what is this agent permitted to do, whom may it delegate to, and which of its actions must a person sign off?"
The two are co-designed at exactly one seam: governance declares that a child's capability set must be a subset of its parent's; identity's token-scoping enforces that subset when the child actually calls out. Declaration and enforcement are different jobs, and in a mature organization they are owned by different teams: the platform or agent-safety team writes the agent documents and the delegation rules, the identity team runs the broker that mints the scoped tokens.
The decisive test is a question identity cannot answer alone: what was this agent allowed to do at the moment it took that action? The answer is not a token scope. It is a prompt, a tool list, a budget, and a set of approval steps, the agent's document, as it was versioned at that instant. Identity never held that document. A platform with a perfect identity fabric and no governance fabric can tell you which token was presented; it cannot tell you what the agent was for.
The agent is a document
The genuinely-not-identity core of this primitive is that an agent is a record, not a running process. A coding agent, a reviewer, a nightly digest agent: each is a named, owned, versioned document that states its system prompt, the tools it may reach, the model binding it uses, its budget, and the approval steps that apply to it. Latere's Topos is one implementation of this idea; it is an illustration here, not the argument.
Treating the agent as a document buys properties that a process cannot offer. You can read it before it runs and again after it finishes. You can diff two versions. Every change is signed, so attribution survives. You can hand it to someone in compliance who has never seen the codebase and they still get the whole picture. Most importantly for the question above, the document is the thing that answers "what was this agent allowed to do," because the allowance is the document, under version control, at a point in time.
The contrast is with agents defined in code and instantiated at deploy time. There, the agent's powers are an emergent property of whatever the program wired up, readable only by reading the program, and unversioned as a unit. That is the registry-drift failure mode: the agent's authority is real and consequential but has no canonical, auditable record. The governance fabric's first job is to make the agent definition a first-class, versioned, owner-signed artifact.
Capability attenuation
The second job is enforcing that authority only ever narrows on the way down. This is the object-capability discipline applied to agents: a holder of authority may pass on a strict subset of what it holds, never more, and may not grant itself back what it gave up. Attenuable-token designs like Macaroons [1] and Biscuit [2] are the formal grounding, caveats can only further restrict a token, never widen it, and the governance fabric is where that discipline is declared at the agent level rather than the token level.
The clearest shipping instance today is small but real: Claude Code forbids plugin-shipped subagents from declaring hooks, mcpServers, or permissionMode [3]. A plugin author is not a harness administrator, so a delegated agent cannot grant itself capabilities its parent context withheld. That is attenuation enforced at the authoring boundary. Start a helper with network-write withheld and that capability is gone for everything below it, permanently; a request for something off the list comes back denied and stops there, with the refusal recorded next to the rule that caused it.
The failure this prevents is privilege escalation by delegation. Without an enforced C_child ⊆ C_parent, a sub-agent can end up operating with more authority than the agent that spawned it, which means a prompt injection deep in a delegation chain runs at the top of the chain's authority. The widely-cited GitHub MCP incident [4] is this shape at the token layer: a broadly-scoped credential, reachable through a delegated path, turned into a cross-repository exfiltration primitive under indirect prompt injection. Attenuation is the structural answer; it has to be declared somewhere, and that somewhere is the governance fabric.
Delegation topology
The third job is bounding the shape of delegation itself: which agents may spawn or hand off to which others, and how deep the chain may go. Orchestration runtimes such as supervisor or swarm frameworks express topology, but they express it as execution, the running graph of who calls whom. Governance owns the constraint on that graph: the hop limits, the spawn permissions, the rule that a chain cannot loop back on itself without bound.
The cost of leaving topology unconstrained is concrete. A LangChain pipeline looped between two agents for eleven days and produced a roughly $47,000 bill because no hop limit or budget ceiling bounded the delegation [5]. At the quality layer, the MAST taxonomy of multi-agent failures [6] makes "inter-agent misalignment" a top category, structural, not incidental, and not solved by composition frameworks alone. And the topology should not be assumed beneficial by default: under equal thinking-token budgets, single-agent systems have been shown to match or outperform multi-agent ones on multi-hop reasoning [7], and framework-level design choices alone can swing coordination success dramatically [8]. Governance is where a platform decides, and records, when delegation is worth its coordination tax and how far it may run.
Approval placement
The fourth job is deciding where in the fleet's action space a human sits. This is distinct from the runtime mechanism of pausing, which belongs to the execution runtime: the runtime owns the pause verb (the cooperative checkpoint at which a session can suspend and await a decision), while governance owns the policy of which actions, by which agents, above which thresholds, require that pause. A production system runs two policy surfaces that are easy to conflate: resource-access policy (can this identity read this resource, owned by identity) and action-risk policy (may this agent send this email, owned by governance). Engines like OPA [9] and Cedar [10] can implement either; the separation is about ownership, not technology.
The trade-offs here are about human attention, not machine correctness. Gates placed too aggressively train reviewers to approve without reading; gates placed at the harness's convenient boundaries rather than at the fleet's real risk points enforce nothing useful; a gate with no on-call path becomes a blocker the moment the approver is asleep. Placement is the decision, and it is a fleet-level decision: the same agent reused across a chat surface, a coding surface, and a ticketing surface should carry its approval policy with it, which is only possible if the policy lives in the agent's document rather than in each surface's code.
The market is thin, and that is part of the argument
Honesty about the state of the world: there is no mature, vendor-neutral category called "governance fabric" the way there is for sandboxes (E2B, Daytona, Modal) or identity (Okta, Auth0, SPIFFE). The pieces exist, attenuation in object-capability tokens, agent registries in orchestration frameworks, policy engines like OPA and Cedar, but a system that holds the agent-as-versioned-document and enforces attenuation and delegation bounds as one concern is still rare. Topos is an attempt at exactly that surface.
A thin market is not evidence against the primitive. It is what an under-served primitive looks like before it is named. The failures it would prevent, privilege escalation by delegation, registry drift, unbounded topology, misplaced approval, are already happening and already documented; they are simply being absorbed, badly, by whichever neighboring system happens to be nearest. Naming the seam is the first step to owning it.
Where this leaves the human
The thread through why Latere exists is that the most important intelligence in an autonomous system is the one you cannot see: the person who set the direction, drew the boundaries, and decided when to step in. The governance fabric is where those boundaries are written down. The agent document is the boundary made readable. Capability attenuation is the boundary made enforceable as work is handed off. Approval placement is the point where a person steps in, declared once and carried everywhere the agent runs.
That is the whole bet, stated structurally. An agent you can read, whose authority only shrinks as it delegates, and whose risky actions pause for a person, is an agent that runs at full speed while the judgment that makes it run correctly stays human and stays visible. Governance is the primitive that keeps that sentence true when one agent becomes a fleet.
References
[1] A. Birgisson et al. "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud." NDSS 2014. Google Research
[2] C. Brunel et al. "Biscuit: Decentralized Authorization with Attenuable Tokens." biscuitsec.org
[3] Anthropic. "Claude Code Plugins and Subagents Reference." code.claude.com
[4] Invariant Labs. "GitHub MCP: Ambient Authority and Cross-Repo Token Scope Creep." May 2025. invariantlabs.ai
[5] DEV Community. "The $47,000 Agent Loop." 2025. dev.to
[6] M. Cemri et al. "Why Do Multi-Agent LLM Systems Fail?" NeurIPS 2025 Datasets and Benchmarks Track. OpenReview
[7] "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets." April 2026. arXiv:2604.02460
[8] "Understanding Multi-Agent LLM Frameworks: A Unified Benchmark and Experimental Analysis." 2026. arXiv:2602.03128
[9] CNCF. "Open Policy Agent (OPA)." openpolicyagent.org
[10] AWS. "Cedar Policy Language." cedarpolicy.com