Vihang Patel.

Personal build · checked 11 October 2026

Governed agent
control plane.

I built a governed agent control plane to connect delegated work with identity, permissions, durable ownership and release control. This work uses my personal time and infrastructure.

This is a self-published architecture account. The examples use fictional inputs; no employer data, clients or workflows are included.

Authority, evidence and recovery

The architecture essay · Completion needs readback

The product problem

Once an agent can change things, its answer is only one part of the product. The system needs to know who authorised the action, who owns the next step and whether the intended state exists. I wanted those facts to survive a model or runtime change.

The alternative was to put tools, approvals and memory inside each assistant. That is simpler to start, but spreads authority across sessions and makes a handoff hard to inspect. A shared control plane adds coordination overhead in exchange for explicit boundaries.

The architecture

Governed agent control planeAn owner request reaches a runtime and authenticated tool gateway. A work ledger preserves ownership. Evidence memory supplies context. A separate reviewer checks a proposed change before the executor acts. Verification feeds an outcome receipt back to the ledger. Model routing is separate from tool access.Owner requestRuntime + gatewayidentity / tool accessModel routingseparate inference pathWork ledgerEvidence memoryIndependent reviewerexact proposed effectExecutor + verificationreceipt back to ledger
A responsibility map; arrows show handoffs rather than private network topology.

What the evidence supports

Live means observed usage with readback in the stated scope. Piloted means a bounded trial. Designed means the published architecture describes the target behaviour; operational acceptance is not claimed for that scope.

ComponentStatusDemonstrated behaviour and limitation
Tool gatewayLiveAuthenticated public-record work and ledger reads/writes were exercised through a shared MCP access surface. Model inference routing is a separate path; this does not establish all-runtime acceptance.
Work ledgerLiveRevision-guarded updates and independent readback preserve the next actor and current task state. A completed issue does not itself prove a deployed result.
Provenance memoryLiveRecall returns evidence identifiers and source metadata. Retention records provenance; an asynchronous queue receipt is not completed storage. Tenant isolation is not claimed here.
Independent review and release verificationLiveThe site release used a distinct reviewer, exact-head hosted review, signed commits, deployment readback and behavioural checks. The broader fleet is a separate acceptance scope.
Runtime identity and model-tier routingDesignedThe architecture specifies identities at runtime boundaries and separate model tiers. Complete runtime-canary and denial coverage is not established by this public write-up.
Instruction containmentDesignedRetrieved content is treated as evidence rather than permission. The fictional denial flow below explains the boundary; systematic injection-resistance results are not published.
Simulation and consolidated observabilityDesignedA design direction for replay, recovery, authority violations, human attention and total cost. A unified view and public evaluation reports are still open work.

Evidence checked 11 October 2026: authenticated tool calls, task revision/readback, provenance-bearing recall and the reviewed site-release receipt. These are my operational records, not independent certification. Registry size and configured runtime support are not presented as proven capacity.

A fictional task, including the denial path

  1. An owner asks to update the opening hours of a community library.
  2. The ledger records the branch, expected revision and next actor. The executor retrieves the attributed source.
  3. A retrieved page says to change an unrelated account setting. That text supplies no permission; the proposed operation stops at the scope boundary.
  4. A distinct reviewer inspects the hours change. A rejection returns the task with the reason; the executor does not perform the rejected effect.
  5. After approval, the executor applies the bounded change and reads the destination. If the record is correct but the public page is stale, the receipt records partial completion and the repair that remains.

This flow illustrates the design. It is not a reported trial or a universal defence against malicious prompts.

The tradeoffs

Centralised ownership reduces ambiguous handoffs but creates a coordination dependency. Review makes consequential changes slower. Provenance increases storage and retrieval complexity. A fail-closed boundary needs a useful recovery path, otherwise its queue becomes the product.

What remains open

Simulation coverage and a consolidated observability view remain gaps. Agent VITALS is planned evaluation work addressing them: replay, outcome verification, authority violations, human attention and total cost. Public repository links and results will follow an actual public release; no performance result is claimed here.

The private operations gateway is separate from this site’s public read-only evidence tools.

Reference points

MCP authorization informs the access boundary. SLSA verification guidance informs artifact checks, without a certification claim. Anthropic’s agent-evaluation guidance informs the next evaluation work. These references explain the framework; they do not verify this personal system.