From Proxy.Me: Agentic AI Digital Apprentices, Appendix C
The mechanism layer behind mesh coordination. How to govern topology, federation, direct connections, identity, libraries, authority, constraint, evidence, change, and drift.
This appendix is the mechanism layer of mesh governance. Chapter 17 covers the conceptual picture: the two topologies, the federation of separate meshes, the roles of control towers and sentinels, and the signal flag vocabulary. Chapter 21 opens the governance discussion. The material here assumes the reader has both in hand, and turns to how each aspect is operated in practice.
Mesh governance has a form, a function, and a behavior. The sections below describe each aspect at the level an architect, security lead, or audit team would need to implement, operate, or review it.
The mesh topology is a living fabric. Proxies are added as new Roles are defined. Proxies are retired as Roles change or disappear. Authorization lists are updated as the work evolves. Each change must be tracked, approved, and versioned. A topology that drifts without record is a topology no one actually governs.
Joining is itself a governed event. The enterprise must govern three things at admission time: which Proxies are permitted to join the mesh, which Proxies are permitted to form a mesh together, and which existing nodes a new Proxy may connect to. A node that appears on the network is not a node that belongs in the mesh until it has been admitted through a controlled process.
The work graph can be shaped, not just recorded. Policies can require human approval before certain path segments form. Rules can forbid specific sequences of Proxies, even when each connection along the way is permitted by the mesh topology. Security layers can encrypt the contents of a path, authenticate each hop, and tokenize identity as it moves along. Constraints of this kind reduce the set of paths the work graph can include, so the evidence trail is not only observed but actively bounded.
The mesh topology must be discoverable by the mesh itself. A Proxy about to route work to another Proxy needs to confirm that the coordination is permitted. A platform that observes the mesh needs to verify that actual coordination matches declared coordination. Discrepancies are not always failures. They are always signals that something has changed and may need review.
On an ongoing basis, the enterprise needs a current mesh topology, a current work graph, a changelog, and the ability to answer a short list of questions on demand. Which Proxies exist. What each one can reach. Which Proxies each one may talk to. Which paths have actually been travelled. What has changed since the last review.
What crosses a boundary between meshes is itself a governance event. Identities, authority, and reasoning artifacts do not pass freely. Each crossing is policed by the bridge, the gateway, or the clearinghouse that sits between them. A Proxy authorized inside one mesh is not automatically authorized in another. A work graph that ends at the edge of one mesh is continued on the other side only if the crossing is recorded and approved.
Node mobility is also a governed event. Control towers manage the transitions. When a node joins a mesh, the control tower onboards its local state: it checks the node's identity, applies the authorization lists, extends the mesh topology, and begins collecting its activity into the work graph. When a node leaves, the control tower terminates the local state: it revokes local access, archives the node's evidence, and removes the node from the authorization lists so that other Proxies do not continue to route work to it in that mesh.
Federation and networking are not the same thing, but they interact. A mesh often lives inside a virtual private cloud. A mesh is often bridged between VPCs through a controlled gateway. A mesh that spans office locations often uses the enterprise VPN. The governance of the mesh does not replace the governance of the underlying network. It rides on top. Each layer keeps its own controls. Each layer produces its own evidence. Together, they define what is permitted and what actually happens.
Proxies, once admitted and authorized to work together, can communicate directly through standard agent-to-agent protocols such as Google's Agent-to-Agent (A2A). What a pair of Proxies may do over a direct connection is defined by a security configuration carried on the link.
The configuration specifies which modes of exchange are permitted: structured messages only, persistent streams, file transfer, or a combination. For file transfer, it specifies the allowed file types, size caps, encryption requirements, and scanning requirements. For streams, it specifies the maximum duration, the data classifications allowed, and the conditions under which the stream must be torn down. Two Proxies that are authorized to coordinate are not necessarily authorized to do so across all modes. The configuration is part of the authorization.
Every direct session begins with mutual authentication. Each Proxy verifies the other's identity before the session opens. Sessions are signed, protected against replay, and encrypted in accordance with the enterprise's posture. A channel that cannot be authenticated does not open.
Direct connectivity does not bypass the mesh's other controls. Every exchange over a direct channel writes into the work graph. Rate limits, circuit breakers, and kill switches apply to direct channels the same way they apply to any other coordination. The cumulative authority of a flow counts the direct exchanges alongside everything else. Signal flags raised on either side are visible to the other. Direct is a performance and shape choice. It is not a governance concession.
When the security posture changes, direct connections already in flight inherit the change. A policy update that narrows what two Proxies may send to each other takes effect on the next session, and in-flight sessions either conform or are torn down according to the policy's own rules. Connections are not grandfathered into a posture the enterprise no longer holds.
A bridge is a specialized form of direct connection with an authorized Proxy on each side for handoff. It is a named entity in the mesh topology. The pair of Proxies it connects, the types of work it is permitted to carry, and the delegation model it operates under are all declared when the bridge is established. A bridge is not implied by the existence of two Proxies that happen to be able to reach each other. It is created deliberately.
The "work on my behalf" framing is reflected in how identity propagates across a bridge. The handing-off Proxy declares which authority travels with the work. The receiving Proxy accepts or rejects the handoff based on whether it is permitted to act under that authority. Some bridges carry the full delegation of the originating Persona. Some bridges require the receiving Proxy to re-identify under its own authority once the work has crossed. The rule is explicit for each bridge and is part of the mesh topology.
Every use of a bridge is captured in the work graph as a named crossing, with the identity, the delegation, the Scenario in effect, and the payload class that crossed. Reviewers asking "what crossed this bridge, on whose behalf, and under what authority" should be able to answer the question from the evidence without reconstructing it from ordinary log entries.
Bridges can be rate-limited, throttled, or closed independently of the Proxies on either side. A bridge is a control point. If a misuse pattern appears at the bridge, the bridge can be suspended without taking either Proxy off the mesh entirely. The same logic applies in reverse: an otherwise healthy Proxy whose bridge has been suspended is not available to do that specific handoff, even though its other connections continue to function.
Bridges at mesh boundaries, between federated meshes, or between a mesh and an older system reachable only through translation, are governed under the same pattern. The pair of authorized Proxies and the declared handoff are the constants. What differs is the scope of the crossing and the policies that apply to the payload.
When a Proxy acts, the enterprise must know who is acting. When a Proxy hands work to another Proxy, the enterprise must know on whose behalf both of them are acting. Identity is not a field at the edge of the mesh. It travels with the work, and it must remain traceable at every node.
A Proxy may act under its own identity, under a service account, under rights inherited from the Role, under rights delegated by the Persona currently holding the Role, or under rights inherited from the environment. Zero Standing Privileges layered with just-in-time ephemeral grants is the best practice. When that Proxy routes work to another Proxy, the question is which of these identities carries forward, which does not, and under what authorization.
Mesh governance must define the rules of identity propagation. Some flows should carry forward the Persona's delegation unbroken, so that the final action is still performed on the original Persona's behalf and can be audited back to them. Other flows should re-identify at each hop, so that each Proxy acts under its own authority rather than inheriting someone else's. Neither is right in all cases. What matters is that the rule is explicit and observable.
Authentication between Proxies is part of the same concern. Each Proxy-to-Proxy exchange must be authenticated, signed, and protected against replay. A mesh that trusts identity claims without verifying them is one in which any compromised node can impersonate any other.
Approved PoVs, Lenses, Veto Lenses, and Scenarios are distinguished from drafts. Retired entries are marked so that no Proxy keeps leaning on reasoning the enterprise has chosen to move past. Each library pull is recorded. Each submission of a new artifact undergoes review. Nothing becomes canon without a designated approver accepting it. Approval is a governance event, not a personal preference.
Approval can be centralized or local, and every path requires curation. A centralized approval is made at the parent level and inherited by every mesh beneath it; it applies to artifacts the enterprise wants applied uniformly, such as an organization-wide Veto Lens, an enterprise Scenario, or a PoV representing a corporate position. A local approval is made inside a single mesh, line of business, or function; it suits artifacts shaped by domain expertise closest to the work, such as a product-specific Lens or a regional Scenario adjustment. Both paths produce the same obligation: every artifact in circulation has a named curator, a review cadence, and a retirement path. An approved artifact nobody owns is a gap, not an asset.
When an approved artifact changes, the Proxies that depend on it are notified, and the change is reflected the next time they reason. When a Lens or Veto Lens is retired, any Proxies still using it are flagged. When a PoV, a Veto Lens, or a Scenario fails a later review, the work graphs that relied on it become candidates for re-examination.
In a hierarchical federation, libraries inherit. A parent mesh holds artifacts shared across the whole. Child meshes inherit and extend. An override in a child mesh is a governed exception, recorded as such, not an accidental divergence.
An ungoverned library is a place where weak reasoning spreads fast and quietly. A governed library, centrally or locally curated, is how the enterprise lets strong reasoning scale.
The mesh accumulates authority as work moves through it. A single Proxy may have modest permissions. A chain of Proxies coordinating on a single flow may have combined permissions that no single Role was ever intended to authorize. This is cumulative operational authority. It cannot be governed if it cannot be measured.
Measurement requires accounting. Each Proxy in a flow contributes its data access, actions, and reach to the combined total. The mesh must be able to calculate that total for any proposed flow and compare it against thresholds. When the total crosses a threshold, the flow should be blocked, escalated for human approval, or rerouted through a sequence of Proxies whose combined authority is lower.
The thresholds themselves are a governance choice. The enterprise determines at what level of combined authority human review is required. It decides which combinations of permissions are never allowed to co-occur in a single flow. It decides where the caps sit. The mesh enforces those decisions. It does not make them.
Blast radius is the companion metric. For any proposed flow, the enterprise must be able to answer a simple question. If this flow fails, goes wrong, or is misused, what is the potential impact? Blast radius is not just about the data accessed. It includes systems modified, communications sent, and downstream Proxies' decisions based on what they received. Authority measures capacity. Blast radius measures consequence.
Visibility and measurement are the sensing layer. Constraint is the control layer. Mesh governance must be able to stop, throttle, reroute, and quarantine activity, not just observe it.
Circuit breakers halt specific coordination patterns when they exceed a defined threshold or when anomalies appear. Rate limits cap the volume of work flowing across a given path. Bulkheads isolate parts of the mesh so that a failure in one zone does not propagate into another. Kill switches allow an operator to stop a specific Proxy, a specific class of flows, or the mesh as a whole.
These mechanisms are most useful when they are tested, rehearsed, and ready. An untested circuit breaker is an assertion, not a control. The enterprise should exercise its constraint mechanisms on a regular cadence, with reviewed outcomes, the same way it exercises backup and recovery.
Detection of dangerous runtime patterns also belongs in this layer. Loops between Proxies, where two nodes pass work back and forth without making progress, must be detected and broken. Runaway fan-out, where a single event triggers an expanding wave of downstream work, must be throttled before it exhausts resources. Deadlocks, where Proxies wait on each other indefinitely, must be timed out and resolved. Each of these failure modes is rare in normal operation and routine during incidents, which is when the controls must work.
Constraints are not all static. Scenarios are raised at the organization level and propagated down to the meshes and the nodes within them. When the organization raises a new Scenario, the active operating stance reaches the mesh, and the mesh reconfigures to match. An active Scenario may disallow certain activities, reserve others for itself alone, defer some to a later time, change rate limits, or narrow which Proxies may form connections with which others. Every constraint mechanism, circuit breakers, rate limits, authority caps, and connection permissions, must be Scenario-aware.
When a Scenario is raised or lowered, the constraint layer reconfigures as part of the transition, and work already in flight is handled according to the new stance. In-flight work can be slowed, stopped, held in place, or cancelled outright when the new Scenario requires that it not continue. The response is not the same as rejecting new work. It is how the mesh handles what was already moving when the stance changed.
A mesh that cannot explain itself cannot be audited. Every action a Proxy takes, and every Proxy-to-Proxy exchange, must produce evidence that can be reconstructed after the fact. This is more than logging. It is replayable evidence.
The work graph is the primary structure of that evidence. Each step in a flow should carry the identity in effect, the PoV that shaped the decision, the veto lenses that applied, the inputs consulted, the action taken, and the outputs produced. The chain of these steps across a multi-Proxy flow is the work graph for that flow. Given that graph, a reviewer should be able to answer what was known, what was decided, by whom, under what authority, and why.
Immutability matters. Evidence that can be edited after the fact is not evidence. The work graph and its supporting records should be append-only, tamper-evident, and retained in accordance with the enterprise's regulatory posture.
Evidence must be addressable at the flow level, not just the Proxy level. A single Proxy's log is rarely the complete story. The question a reviewer usually needs to answer concerns the flow, and the evidence system must return that flow as a coherent work graph.
The mesh is not static. Proxies are added and retired. Authorization lists change. Policies are revised. Partitions are redrawn. Each of these changes is a governance event, and the mesh must have a change control process commensurate with its reach.
New Proxies enter the mesh through an onboarding process. That process confirms the Proxy's Role, its identity model, its connections, its authorization lists, and its governance posture. A Proxy that enters the mesh without this review is one the enterprise has not chosen to authorize.
Retired Proxies are decommissioned through a process. That process revokes the Proxy's identities, archives its evidence, and removes it from authorization lists so that other Proxies do not attempt to route work to a node that has been removed.
Between these bookends, all changes to the mesh should flow through a controlled pipeline: test, review, stage, deploy, monitor. The same discipline that applies to production software applies here. Changes that bypass the pipeline are drift, and drift accumulates.
Individual Proxy governance already includes the discipline of reasoning review. In the mesh, drift can also occur in coordination patterns, in semantic alignment between Proxies, and in the relationship between declared topology and actual behavior.
The enterprise must monitor for unintended coordination patterns. Two Proxies that begin exchanging work through a path the topology does not authorize is a signal. A Proxy that begins routing work to nodes outside its authorization list is a signal. A pattern of escalation that starts bypassing human review is a signal.
Semantic drift is equally important. When coordinating, Proxies develop subtly different interpretations of the same scenario; their individual reasoning can remain internally consistent while their combined output diverges from what the enterprise intended. Detecting this requires comparing PoVs across related flows and watching for signs that the shared context has fractured.
Topology-to-work-graph reconciliation closes the loop. The mesh topology says what the mesh is permitted to do. The work graph says what the mesh actually did. The reconciliation between the two is where the drift becomes visible and can be corrected. Without it, a mesh can appear compliant on paper but behave differently in practice.
Chapter 17 introduces the control tower and the sentinel as observation roles. The operational detail below covers the full set of responsibilities they carry.
A control tower aggregates topology, work graph, authority accounting, and drift signals across a mesh or a group of federated meshes. A sentinel watches what the control tower cannot see directly: segments, firewalled partitions, bridges into slower or offline systems. Sentinels authenticate and report, and may hold evidence locally when connectivity is limited or summarize activity without exposing internal traffic.
Proxies query control towers and sentinels as part of their work. A Proxy can learn which services and systems are reachable, offline, or degraded, and what the current flow rates are. The Proxy uses these answers to defer, reroute, throttle, or escalate.
The mesh carries messages and notifications to the Proxy nodes. When a shared dependency fails, when an approval is granted or denied, when a policy changes, or when a scheduled job completes, the notification reaches the Proxies that need to know. Delivery is routed through the mesh itself, using the same topology that governs work. A Proxy receives what it is authorized to receive, and nothing more.
Control towers and sentinels collect and maintain event history logs. The logs capture what each Proxy did, which flags were raised, which messages were delivered, which queries were answered, and what the mesh itself observed at the same time. These logs can feed into a security information and event management platform that correlates events across the wider technology estate, so mesh activity becomes part of the enterprise's security picture.
Each Proxy broadcasts what it can do, what knowledge it holds, what authority it carries, and what systems and data it can reach. The control tower assembles these broadcasts into a searchable catalog of the mesh's capabilities. Routing and allocation schemes are configurable: first available, most resourced, nearest, least loaded, or a combination. The enterprise picks the scheme. The control tower applies it.
Control towers manage LIFO and FIFO stacks and queues that let Proxies hand off work in a defined order. A Proxy adding to a queue does not need to know who will pick it up. A Proxy pulling from a queue does not need to know who put the work there. The control tower maintains order, fairness, and integrity.
A Proxy can declare an SLA for the work it handles: how long the flow should take, which deadlines apply, and what quality thresholds apply. The control tower monitors the flow against the declared SLA. If the SLA is missed, the control tower can abort the flow, reroute it, or escalate for human attention. The declaration is the Proxy's. The enforcement is the mesh's.
The signal flag vocabulary is governed at the mesh level. Flags are versioned. New flags go through review before becoming canon. Retired flags are marked so that no Proxy continues to rely on signals the enterprise has chosen to move past. The flag vocabulary is one of the shared artifacts the mesh maintains on behalf of all its Proxies.
Mesh governance is not a single tool. It is a set of capabilities that must be designed, built, and operated alongside the mesh itself. Topology services, work graph stores, join and formation controls, identity propagation rules, direct-connection security configurations for agent-to-agent protocols, shared PoV, Lens, and Scenario libraries, authority accounting, circuit breakers, change pipelines, drift monitors, signal flag vocabularies, message and notification delivery, capability catalogs, coordination primitives, SLA monitoring, event history logs that integrate with enterprise security and monitoring platforms, and the control towers and sentinels that watch across distance all belong to this layer. They need to be integrated so that the enterprise can see, measure, constrain, explain, and correct the mesh as a whole.
None of these capabilities replaces individual Proxy governance. The reasoning and reach of each Proxy still must be curated and contained. But above that, the mesh needs its own layer.
"A mesh without this shape runs faster than its governance can keep up with. The point of mesh governance is not to slow the mesh down. It is to keep speed and visibility in balance, so that the enterprise can trust what the mesh produces at the pace the work requires."
Appendix D walks the apprentice lifecycle and the price of persistence.
Appendix D About the Book