Governance API
1. Quickstart
- Create a free account (no card, no sales call) and note your organization.
- In AI Inventory — Assets on the account page, register an asset of kind
agentormcp_server. - Click Activate for Control Plane on that asset — you'll get an API key, shown once. Copy it now.
- Call
POST /api/control-plane/evaluatewith that key before your agent takes an action (see below).
That's the whole integration. There's no separate "developer portal" signup — the same free account that runs the Workbench issues the key.
2. Authentication
Send your key as a standard bearer token:
Authorization: Bearer agtk_<your key>
Content-Type: application/json
A few things worth knowing about how this key behaves, all verified live when this was built:
- The key is authoritative for identity. Whatever
agentname you put in the request body is ignored — every logged action uses the real name you registered the asset under. You cannot spoof a different agent's identity by changing the request body. - An unrecognized key is rejected outright (
401) — it never silently falls back to anonymous/unauthenticated behavior. - Suspending or revoking the key (from the account page, any time) makes the very next call using it return a
denydecision before any policy logic runs — a real per-agent kill switch, not just a documentation-level suspension. - Your traffic is isolated to your own organization's ledger — it never appears in the public anonymous demo ledger, and no other organization can see or act on your asset, even by guessing a valid ID.
3. Request & response
Minimal request — only tool and action_type are required:
curl -X POST https://autogovern.io/api/control-plane/evaluate \
-H "Authorization: Bearer agtk_<your key>" \
-H "Content-Type: application/json" \
-d '{
"action": {
"tool": "customer-db",
"action_type": "db_write",
"target": "accounts/12345",
"payload": "update billing_email to new@example.com",
"records_affected": 1
}
}'
| Field | Type | Notes |
|---|---|---|
action.tool | string | What's being called (e.g. an API, a database, a payment processor). |
action.action_type | string | One of read, search, summarize, classify, external_api, message_user, email_send, db_write, permission_change, db_delete, code_deploy, payment. Anything else is treated as a moderate-risk unknown action. |
action.target | string | Optional — what the action affects. |
action.payload | string | Optional — scanned and redacted for PII/secrets before it's stored; the raw value is never persisted. |
action.reversible | boolean | Optional — defaults from the action type if omitted. |
action.sensitivity | 0–3 | Optional data-sensitivity hint. |
action.records_affected | number | Optional blast-radius hint. |
Response:
{
"decision": "review",
"authorizationProfile": "cp-strict-2026.09",
"riskScore": 42,
"riskBand": "medium",
"reversible": false,
"actionLabel": "Write to a system",
"matchedControls": [ { "id": "human_oversight", "label": "Human approval before execution", "refs": "EU AI Act Art. 14 · NIST GOVERN" } ],
"matchedPolicies": [],
"reasons": [ "Irreversible action on sensitive data — human approval required" ],
"ledger": { "id": 4021, "seq": 4021, "hash": "…", "prev_hash": "…" },
"agentIdentity": { "public_id": "ast_xxxxxxxxxxxx", "name": "customer-support-agent", "kind": "agent", "key_status": "active" }
}
4. Handling the decision
allow— proceed with the action.review— stop and use your integration’s human approval workflow. The public demo decision endpoint cannot approve registered-agent traffic. Partner integrations use their scoped v1 decision endpoint; a recorded approval is not a single-use execution token.deny— do not proceed. Checkreasons[]for why (a policy match, a risk threshold, or your own key being suspended/revoked).
Every successful authenticated evaluation is written to the tamper-evident, hash-chained ledger regardless of decision — see your organization's own slice of it at GET /api/auth/org/:orgId/assets/:assetId/ledger while signed in, or verify the whole chain's integrity (no per-row content, just validity) at GET /api/control-plane/verify.
Production failures stop execution. Authenticated calls use cp-strict-2026.09. Missing control state, invalid active policies, or a failed audit write return HTTP 503 with decision: deny and an error code: control_state_unavailable, invalid_active_policy, or audit_unavailable. Do not execute on an error, timeout, or missing ledger receipt. Matching allow policies cannot weaken baseline controls; approval flags require review. Free-text policy conditions must be migrated to supported structured rules.
Partner retries reevaluate current controls, including the kill switch. An idempotency key no longer replays a cached decision; each successful retry has a new ledger entry. Your executor must prevent duplicate downstream effects.
5. Node & Python snippets
No published package — these are small, dependency-free, single-file wrappers you can vendor directly into your project. Copy the code below or download the file. Updated SDKs require the strict production response and reject incomplete receipts. Node uses a 10-second request timeout; Python uses a 10-second socket timeout. Deploy the updated server before upgrading clients.
// see /sdk/node/autogovern.js
const { AutoGovernClient } = require('./autogovern');
const gov = new AutoGovernClient({ apiKey: process.env.AUTOGOVERN_API_KEY });
const result = await gov.evaluate({
tool: 'customer-db',
action_type: 'db_write',
target: 'accounts/12345',
payload: 'update billing_email to new@example.com',
});
if (result.decision === 'allow') {
// proceed
} else {
console.log('Blocked:', result.decision, result.reasons);
}
⬇ Download autogovern.js
# see /sdk/python/autogovern.py
from autogovern import AutoGovernClient
import os
gov = AutoGovernClient(api_key=os.environ["AUTOGOVERN_API_KEY"])
result = gov.evaluate({
"tool": "customer-db",
"action_type": "db_write",
"target": "accounts/12345",
"payload": "update billing_email to new@example.com",
})
if result["decision"] == "allow":
... # proceed
else:
print("Blocked:", result["decision"], result["reasons"])
⬇ Download autogovern.py
Deployment manifests
Administrators can enroll a dedicated workload key with POST /api/v1/broker/deployments using governance:decide. Send requesterKeyId, a unique requestKey, and configuration containing label, provider, modelRevision, codeDigest, and promptDigest. Digests must be lowercase SHA-256 values. Obtain the key’s numeric ID from your authenticated organization key list.
The immutable revision expires after 30 days and permits only the supervised private-note tool. Read it at GET /api/v1/broker/deployments/:id with ledger:read. Requests automatically bind its ID and digest. Replacing or revoking it blocks outstanding actions; submit a fresh proposal for independent review. To revoke, send {"manifestDigest":"returned digest"} to POST /api/v1/broker/deployments/:id/revoke with an administrator’s review key.
Existing unenrolled keys remain compatible; enroll every pilot workload key. A revoked enrollment cannot fall back to unbound requests. Completed receipts remain readable. Model revisions and artifact hashes are administrator declarations; this registry does not attest external runtime behavior or certify model capabilities. Keep administrator keys out of agent runtimes.
Enforced private-note tool
The broker executes one registered tool: private_note.create. It saves the reviewed text privately in your workspace. The server owns the database access, derives the action risk, and commits the note and audit receipt together. It cannot run arbitrary URLs, shell commands, or external tools.
- Open Account → API access & audit → Governance API keys. The requester needs a key issued by a current member, admin, or owner. The reviewer needs a key issued by a different current admin or owner. Two keys issued by the same user cannot satisfy independent review. Keep reviewer keys out of agent runtimes.
- Send the proposal below to
POST /api/v1/broker/requestswith the requester’s Governance API key. This returns a pending request, its exact stored arguments, its ID, andrequestDigest. Review the returned text: detected sensitive values are redacted before storage. - The reviewer reads
GET /api/v1/broker/requests/:idand sends{"decision":"approve","requestDigest":"returned digest"}toPOST /api/v1/broker/requests/:id/decisionusing their own key. Usedenyto reject it. - The original requesting key sends
{"requestDigest":"returned digest"}toPOST /api/v1/broker/requests/:id/execute. The broker checks current controls, approval, key status, and roles before writing. A successful receipt contains the note ID and audit sequence. Read the note withGET /api/v1/broker/notes/:id.
{
"tool": "private_note.create",
"arguments": { "text": "Review the model inventory before the next release." },
"runId": "inventory-review-01",
"requestKey": "note-proposal-01"
}
Requests expire after 15 minutes. An admin or owner’s review key can revoke a pending or approved request at POST /api/v1/broker/requests/:id/revoke with its digest. Controls changing, including a kill-switch stop and release, require a fresh proposal and approval. Duplicate execution calls return the same receipt; they do not create another note.
Proposal and execution require governance:evaluate; review and revocation require governance:decide; request/note reads require ledger:read. Use organization Governance API keys for these endpoints; registered-agent SDK keys and environment bootstrap keys are not supported. Keys issued through Account currently receive all standard scopes; integrations can request narrower scopes through the existing key-issuance API.
Approval identifies the issuing user of the reviewer credential. Your review service must authenticate the human using that credential; a bearer key alone does not prove human presence. This first adapter covers private SQL notes only. Other tool calls still require their own enforced integration.
6. Rate limits
Authenticated calls (with a valid, active key) are limited to 300 requests/minute per key. Unauthenticated calls to the same endpoint (the public Workbench demo) stay at the original 60 requests/minute per IP — unchanged, so this doesn't affect anyone just trying the Workbench without an account. There's no separate paid tier to raise this further today; if your real usage needs more, tell us.
7. What's verified vs. what you control
- Verified by us: your key resolves to exactly the agent/MCP-server identity you registered; a suspended or revoked key cannot receive allow; your ledger data is isolated from every other organization and from the public demo.
- You control: what counts as an "action" worth checking (call this before anything consequential, not just once at startup), what you do with a
reviewdecision through your integration’s approval workflow, and enforcement at the tool boundary. Production integrations must stop if this endpoint is unreachable; the updated SDKs throw an error. The checkpoint cannot stop an agent that bypasses it or retract an action already dispatched. - This governs a single action at a time — it's not a full agent framework, and it doesn't execute anything on your behalf. It only tells you what a documented, deterministic policy engine thinks should happen next.
8. Contact
Questions, higher-volume needs, or found a bug in this API: info@autogovern.io.