AI agent change governance

Your agents are changing production.
Prove exactly what they did.

Auditors discount logs that can't prove their own integrity, and they're right to. A normal log is testimony: the operator's word for what happened. A sealed hash chain is evidence: anyone can recompute it, and a single altered byte breaks it. SwitchTender records what an agent changes before the change executes, holds it at a human gate, and signs the trail so a third party can check it without trusting your server.

What governed agent changes look like

Seven properties, each one testable against a running server. Together they turn agent activity into a record an auditor can rely on.

Fail-closed recording

Every mutation is written into the audit chain before its handler runs. If the record cannot be written, the change is refused with a 503 instead of performed silently. There is no path where an agent changes something and nothing is written down.

A receipt for every change

Every mutation returns an Audit-Receipt header naming its sequence and hash. Keep them. A receipt later proves the chain still holds that exact entry at that exact position, so an omission is detectable by the party it happened to.

One credential per agent

Secrets are sealed on the server and decrypt only at execution, so an agent holds exactly one credential: its SwitchTender token. It never sees an SSH key, a cloud login, or a vault password. Revoking that one token shuts the door.

A human approval gate, bound to content

Policies can hold an agent's runs for a person, refuse them outright, or key on the operation's assessed risk, or on whether an agent or a person asked, and the approval itself is a chain entry committing a digest of the exact change released. The executor refuses a change that drifted after the decision, so what a person approved is provably what ran. Community holds one require-approval policy, and it can be narrowed, to a single tool for instance, rather than having to hold everything. The full engine is Team: scoping a rule to agents or to a named actor, refusing a run outright, keying on risk, and requiring that the approver not be the requester.

Speaks MCP

An agent runtime that speaks the Model Context Protocol connects straight to switchtender mcp with its agent token. It serves six MCP tools: list templates, propose a run, list recent runs, and read a run, its log, and its evidence. There is no approve tool and no way to widen its own reach. --allow-adhoc adds a seventh that lets the agent compose a run of its own rather than launch a template an operator wrote, and even that one goes through the same approval policy. Hand it an admin token, which an agent could use to release its own runs, and the command exits instead of starting. Serving on one anyway means typing --allow-admin-token, which exists for a local trial and prints a warning naming the risk at every start. The safe setting is the one you get without asking for it, so the same gated, chained, fail-closed request a person makes is the only thing an agent can make.

Sealed offline verification

switchtender audit bundle emits the chain as a signed LoomSeal bundle. It verifies on a machine with no network and no SwitchTender install, against the key the server publishes at /.well-known/loomseal.json.

Actor-level provenance

Every entry names the actor behind it, whether it was a person or an agent (actor_type), and whose authority it used (on_behalf_of), all committed by the entry hash. The kind is declared when the token is minted, with --agent, rather than guessed from how a request looks, so an agent's changes stay attributable instead of blurring into a shared account. The live demo seeds a deploy-bot service account whose API and scheduled runs, and the audit entries behind them, are on screen right now. It is a plain operator account rather than an --agent token, so what the demo shows is the actor named on every run and entry. The agent kind is what you add when you mint the token yourself.

The one-credential architecture

An agent with a pile of credentials has a pile of doors. An agent with one credential has one, and SwitchTender puts a gate on it. --user binds the token to an account so it carries that account's role instead of acting as admin. --agent is what makes it an agent's credential: the ceiling moves onto the token itself, capped at operator whatever account it is bound to, so it can submit runs but can never manage identity, access, or secrets, and can never approve its own held run. It also declares the holder at mint time, so every entry the token writes is recorded as an agent rather than as an ordinary API token. Add one approval policy with no conditions and every run the agent submits waits for a person. That rule needs no license, so the walkthrough below runs end to end on a self-hosted install. Scoping a rule to agents alone, so people are not held with them, is part of the full policy engine and needs Team. Four commands take you from nothing to an agent whose entire history is evidence.

  1. 1

    Create the agent's operator account

    switchtender user new deploy-agent --role operator --db switchtender.db
  2. 2

    Mint the agent token, the only credential the agent gets

    --agent is not decoration. It caps the token at operator no matter what account it is bound to, and it marks every chain entry the token writes as actor_type: agent. Leave it off and you get an ordinary API token: the same entries record actor_type: token, indistinguishable from a person's script, and a rule scoped to agent runs never matches it. --agent requires --user, so the human the agent acts for is on the record. The TTL forces rotation, here monthly.

    switchtender token new --name deploy-agent --user deploy-agent --agent --ttl 720h --db switchtender.db
  3. 3

    Gate everything with one empty policy

    No conditions, so it matches every run, agents and people alike, and one policy is all Community holds. Add "actor_kind":"agent" to hold only the agent's runs and the same call answers 403 until the install carries a Team license, so the free path gates everything rather than gating agents alone.

    curl -s -X POST localhost:8080/v1/policies \
      -H "authorization: Bearer $ADMIN_TOKEN" \
      -H 'content-type: application/json' \
      -d '{"name":"gate-everything"}'
  4. 4

    Hand the auditor the bundle

    switchtender audit bundle --db switchtender.db --out evidence.json

The longer walkthrough, including the MCP wiring, is in the agent guide. This page is about external agents driving the API. The built-in advisory AI is a separate feature: it proposes text and never executes anything.

What the chain does not prove

The chain proves the record was not altered. It does not prove that every change in your infrastructure went through SwitchTender. A person or a process holding its own SSH key can still change a host behind the controller's back, and no audit system can write down what it never saw. For agents, credential scoping is what closes that gap. An agent that holds only a SwitchTender token has no way around the controller, so for that actor, the recorded history and the actual history are the same thing.

Put a gate and a logbook between your agents and production.