Agent Registries & Kill Switches: ship trust in milliseconds

Agent Registries & Kill Switches: ship trust in milliseconds
Photo by Mitchell Luo / Unsplash

TL;DR


A registry is a "known-good agents" list that your partners can trust at a glance.
Don't let anybody list anything; require a lightweight owner verification and simple permissions/limits.

Make trust queriable with a tiny /verify endpoint that returns status and the core fields in <100ms.

Design the kill switch to stop harm fast without breaking the whole experience.
This combo is the base layer for an agentic internet that actually works in production.


The moment we stop emailing spreadsheets

In Part 1, I argued that if a bot can act, it needs a passport. A small card that says who it belongs to, what it's allowed to do, where it can operate, and who to call if something goes sideways.

This article is about the next step: how others can trust your agent in millisecondswithout a meeting, a spreadsheet, or three weeks of back-and-forth.

That's what a registry does.


What is an Agent Registry?

An Agent Registry is a public list of agents you vouch for. It's not fancy. It's just portable truth:

  • Owner and contact: "Acme Support Team" + "security@acme.com"
  • Role: "Tier-2 Support Bot"
  • Permissions and limits: "Refund ≤ $100, Export ≤ 10K rows, No PII"
  • Where it can operate: "US-NY, US-CA, EU-DE"
  • Status: "Active / Suspended / Revoked"
  • Receipts: "Every refund has a signed record."

Partners and platforms check the registry and move on. No guesswork. No cosplay.


"Why a registry? Can't anyone just list agents?"

Short answer: No. Identity without accountability is a costume party. Imagine just accepting an ID card like a Driver's license from anyone and not needing ID to be from trusted issuers like States, Countries, etc.

With Agent Registries, keep it simple and borrow what already works in finance:

  • Know Your Bot (KYB): who owns it and why it exists
  • Know Your Creator (KYC): link the agent to a real person or org
  • Permissions & limits: make budgets and data access explicit
  • Signed receipts: log refunds/exports/deletions with proofs
  • Kill switch: suspend in one click-status updates everywhere

This isn't red tape. It's how you pass security reviews and get to "yes" from partners and users.


The flow: how agents get verified, added, and kept fresh

Here's the smallest useful workflow. Anyone can ship this in weeks, not months or years.

1) Issue the passport

Create a human-readable card + a machine-checkable record with: owner, role, permissions, limits, regions, contact, and status.

2) Submit to the registry (owner-verified)

The owner (or delegated admin) lists the agent. A lightweight owner check happens once (reuse existing vendor records if you have them). The agent gets a registry ID.

3) Make it verifiable

Expose a tiny /verify endpoint (or use the shared one) that returns core fields and status in a compact response.

GET /verify?agent_id=agt_tmpl_mfuzqhwt_fkcm84
→ 200 OK
{
  "status": "active",
  "owner_display": "Acme Support",
  "role": "Tier-2",
  "capabilities": [{"id": "payments.refund"}, {"id": "data.export", "params": {"max_rows": 1000}}],
  "limits": {
    "refund_usd_max_per_tx": 10000,
    "refund_usd_daily_cap": 100000,
    "max_export_rows": 1000,
    "allow_pii": false
  },
  "regions": ["US-NY", "US-CA"],
  "assurance_level": "L2",
  "updated_at": "2025-01-16T12:34:56Z"
}

Agent Verification Endpoint with target latency of <100ms P95

4) Keep it fresh

Every change to permissions/limits bumps updated_at and emits a webhook so integrators stay in sync. No surprises.

5) Rotate or revoke

Keys rotate without breaking the agent's identity. If something smells off, flip the status to "suspended" and let policy do the rest.


Suspension without drama (designing the kill switch)

Suspension should be a soft stop, not a hard crash.

Design goals

  • Immediate stop to risky actions (refunds/exports/payments)
  • Graceful degrade: read-only or narrowed permissions while you assess
  • Clear messaging: "This agent is suspended. Contact: security@acme.com."
  • Fast rollback when fixed

Playbook

  1. Flip the registry status to suspended via POST /api/admin/status
  2. Downgrade scopes automatically (policy engine does this)
  3. Notify owners & integrators (webhook + email/Slack)
  4. Show it wherever the agent appears (About-this-bot page, UI badge)
  5. Audit the reason with a signed event

Real implementation: Ideal switches update status in <10ms and propagate globally within 15 seconds using Cloudflare's edge network.


A quick story (what this prevents)

A retailer's support agent issued three $500 refunds in an hour. Finance couldn't tell which agent did it or who owned it. Nobody knew the limit. Everyone guessed.

With a registry and passports in place, the refund limit (≤ $100), owner contact, and signed receipts are obvious, and the team suspends the agent in one click while they investigate. No spreadsheets. No finger-pointing. Just control.

Numbers from a prospective implementation:

  • Verification time: P95 < 100ms globally
  • Cache hit rate: 85%+ (L1 edge cache)
  • Suspension propagation: <15 seconds global
  • API availability: 99.99% uptime

Agent registries as the base layer for an agentic internet

Protocols will multiply. Frameworks will argue. Some teams will go decentralized; others will stay web2. That's fine.

A neutral registry with portable passports and a dead-simple verify path works across all of it:

  • Interoperable: human-readable, machine-checkable
  • Portable: agents move between platforms without redoing trust
  • Composable: agents can call agents after they verify each other
  • Neutral: chain-agnostic today; ready for ZK/FHE integrations tomorrow

You don't need a new religion. You need a fast yes.

An Architecture for Agent Registry and Verification

What's next (and how to follow along)

  • Part 3: Signed Receipts - how to sign refunds & data-export actions, how long to keep them, and how to stream them into your finance/security tools
  • Part 4: The Verify API - one page, TS/Python snippets, and an edge-friendly reference
  • Part 5: Policy Packs - copy-paste limits for Support Tier-2 and Billing Assistants

If you've not already done so, read the first article in the Series: AI Passports: A Foundational Framework for AI Accountability and Governance. See you in the next one!

Read more