Verified Digital Agents → Blocks → ACP

ACP — Agent Control Plane

Governance as code. The rules live in git, change through review, are tested adversarially, ratified by a named human, then signed and distributed as a bundle agents verify and evaluate locally.

Live · signed A2A card + REST · federated approval identity staged, not yet live · MCP planned, not live

Governance-aware wrapper on git — not a rebuild of it

Git already does version control, diff, review, branch protection and history. ACP does not reimplement any of it. The value is what sits above and below git:

Compliance Guard — an honest diff of what a change actually does to the rules.
Adversarial test suite — governance is attacked before it ships, not after.
Non-engineer approval surface — because a compliance officer should not be reviewing a raw diff.
Signed bundle distribution — versioned, content-hashed, verifiable offline.
Witness-anchored evidence tied to the commit.

What git is deliberately NOT used for

Not a runtime distribution channel. Agents never git pull. ACP builds a signed, content-hashed bundle from approved state; agents fetch, verify, cache and evaluate locally.

Not the evidence layer. Git history is mutable by a repo admin. Witness is the tamper-evident record.

Not the human surface. A non-engineer approver does not review a diff.

Authority comes from git, not a parallel RBAC

Who may author and who may approve is read from CODEOWNERS and branch protection — the mechanisms your engineering org already maintains. A second permissions system would drift from the first, and the drift would be invisible until an audit.

The ratification gate

Risk-driving values are raised to HITL, resolved by an authorised person, and sealed. ACP's activation gate is then fed by that sealed resolution — and it fails loud:

Activation is REFUSED if:
  · HITL cannot be reached                    (never assumed to be a pass)
  · the decision is resolved but seal PENDING (resolved is not anchored)
  · the sealed statement does not bind every ratified value
  · the deciding actor does not hold authority under CODEOWNERS

See the gate on demo data → Demo data

The parts you can adopt independently

Published to npm, usable without adopting the rest:

`@getvda/evaluator-sdk`	The runtime enforcement SDK an agent embeds: fetch → verify → cache → evaluate → seal, locally. Framework-agnostic and fail-static — it carries no standing credential and cannot mint a bundle that verifies.
`@getvda/test-suite`	The governance CI suite. Runs as a required status check in your own pipeline — schema validation, Compliance Guard, adversarial governance tests. Offline: no tokens, no network.
`@getvda/governance-schema`	The VDA-MD contract the other blocks agree on.

Also published: @getvda/bundle, @getvda/distribution, @getvda/witness, @getvda/compliance-guard.

Python, and the DeepAgents middleware

pip install getvda-evaluator — Apache-2.0, zero runtime dependencies.

It carries a middleware for LangChain DeepAgents that binds wrap_tool_call, so governance gates actions rather than model calls: a model deciding to do something is not yet doing it, and an evidence trail of intentions is not an evidence trail of conduct.

from deepagents import create_deep_agent
from getvda_evaluator.middleware import build

agent = create_deep_agent(
    tools=[...],
    middleware=[build(
        environment="ref-env",
        bundle_source=fetch_signed_bundle,   # ACP
        sealer=seal_to_witness,              # Witness
    )],
)

Two behaviours to know. It fails static — if governance cannot be fetched or verified the action is refused, because an agent still acting when its rules are unreachable is ungoverned while appearing governed. And an unmapped tool is denied, not exempt: a tool does not escape governance because nobody wrote a mapping line. Exemptions are declared in writing.

Two implementations, one contract. The TypeScript SDK and the Python port are held to a single conformance suite, checked in CI and inside ACP's deploy gate. Two evaluators that disagree give two answers to “was this allowed”, and an evidence product with two answers has none. The contract ships inside the sdist so it can be audited without cloning the repo.

Honest status

Live: reading governance, preparing changes, running the test suite, the approval surface, activating versions, serving signed bundles. Staged: federated approval identity — approvals are recorded, but identity is not yet federated to a customer IdP. Planned, not built: an MCP surface.