Sichern Sie Ihre Agenten-Brieftasche, bevor Sie live gehen.
Die Produktion mit Agentenzahlungen ist nicht dieselbe Checkliste wie eine normale API-Integration. Fügen Sie hinzu: eine bewusste Wahl des Wallet-Typs, eine abgestimmte Ausgabenrichtlinie (nicht die Standardwerte), die Rotation von API- und Webhook-Secret in einem festgelegten Rhythmus, eine wöchentliche Überprüfung des Audit-Logs und ein Incident-Response-Runbook, das mindestens einmal geübt wurde. Ohne diese Dinge versenden Sie und lernen auf die harte Tour.
Bevor Sie beginnen.
- Eine funktionierende Agentenintegration von Ende zu Ende im Test - siehe add-payments-to-agent und test-without-real-money.
- Ausgabenkontrollen konfiguriert - siehe Ausgabenkontrollen (dieser Leitfaden geht davon aus, dass bereits eine Richtlinie vorhanden ist).
- Ein Geheimnismanager (AWS Secrets Manager, GCP Secret Manager, Vault, 1Password usw.) - Geheimnisse in .env-Dateien sind nicht genug.
- Ein klar identifizierter Bereitschaftsingenieur mit Admin-Zugriff auf das Wallet-Dashboard.
- 15 Minuten fokussierte Zeit. Die folgende Checkliste ist nicht aspirational - arbeite sie Zeile für Zeile durch.
Führen Sie die Checkliste vor dem Start aus.
Elf Punkte. Jeder ist eine Ja/Nein-Frage mit einem einzelnen Eigentümer. Wenn ein Punkt nicht abgehakt ist, gehen Sie nicht live - arbeiten Sie diesen Punkt zuerst ab. Die Kosten für einen übersehenen Punkt in der Produktion sind immer höher als die Kosten, ihn jetzt abzuschließen.
# Pre-launch security checklist for agent wallets.
[ ] Wallet type chosen with reasoned trade-offs (smart wallet vs EOA).
[ ] Spend permission set in the dashboard: an allowance per period + a per-transaction cap.
[ ] API keys scoped to the minimum the agent needs (read_wallet_metadata / pay_bills / receive_money).
[ ] All API keys stored in a secret manager (not env files committed to git).
[ ] Test keys and live keys cannot be swapped (boot-time prefix check in place).
[ ] Webhook secret rotated within the last 90 days (webhooks.rotateSecret).
[ ] Webhook URL pointed at production, not a tunnel.
[ ] Audit review scheduled; alerting in place for unusual events.
[ ] A spike of rejected payments triggers an alert (>5/hour from one agent).
[ ] Incident runbook exists, has been read by someone other than the author.
[ ] One person other than you knows how to revoke an API key in < 5 minutes.Planen Sie die Rotation des API-Schlüssels und des Webhook-Geheimnisses.
Vierteljährlich ist der Standardrhythmus; sofortige Rotation bei Verdacht auf Leck, Abgang des leitenden Ingenieurs, Sicherheitsvorfall an anderer Stelle im Unternehmen. Das Zwei-Schlüssel-Fenster-Muster ermöglicht es Ihnen, Schlüssel ohne Ausfallzeit zu wechseln: Erstellen Sie den neuen Schlüssel, setzen Sie ihn überall ein, überprüfen Sie ihn und widerrufen Sie dann den alten.
// One-time key rotation script. Run quarterly, on lead departure, on suspected leak.
import { createClient } from "@blockchain0x/node";
const client = createClient({ apiKey: process.env.BLOCKCHAIN0X_API_KEY! });
async function rotate() {
// Scope the new key to only what the agent needs.
const fresh = await client.apiKeys.create({
name: `prod-${new Date().toISOString().slice(0, 10)}`,
scopes: ["read_wallet_metadata", "pay_bills", "receive_money"],
});
console.log("NEW KEY:", fresh.secret); // Store in secret manager NOW.
// Wait until the new key is deployed and verified working, THEN:
// await client.apiKeys.revoke(OLD_KEY_ID); // (or apiKeys.rotate in one call)
}# One-time key rotation script. Run quarterly, on lead departure, on suspected leak.
from blockchain0x import Client
import datetime, os
client = Client() # reads BLOCKCHAIN0X_API_KEY
def rotate():
fresh = client.api_keys.create(body={
"name": f"prod-{datetime.date.today().isoformat()}",
"scopes": ["read_wallet_metadata", "pay_bills", "receive_money"],
})
print("NEW KEY:", fresh["secret"]) # Store in secret manager NOW.
# Wait until new key is deployed and verified, THEN:
# client.api_keys.revoke(OLD_KEY_ID) # (or api_keys.rotate in one call)Webhook-Signaturgeheimnisse rotieren ähnlich über das Dashboard - aktivieren Sie ein zweites Geheimnis, setzen Sie den Handler neu ein, um entweder zu akzeptieren, und ziehen Sie dann das alte zurück. Beide im vierteljährlichen Rhythmus mit Kalendereinladungen.
Richten Sie die wöchentliche Prüfungsüberprüfung ein.
Drei Dinge, die Sie jede Woche im Auge behalten sollten: neue Geschäftspartner (alles, was zuvor nicht gesehen wurde, verdient eine 30-sekündige Überprüfung), abgelehnte Zahlungen (die Ausgabenberechtigung hat ihren Job gemacht - ist der Agent irgendwo stecken geblieben?), und Zahlungen außerhalb der Geschäftszeiten (eine Zahlung um 3 Uhr morgens von einem Agenten, der nominal nur während der Geschäftszeiten läuft, ist das Signal, das frühzeitig Injektionsangriffe erkennt).
// Weekly audit query over the webhook events YOU persisted (payment.received /
// payment.sent). There is no transactions.list API - your own store is the log.
const since = Date.now() - 7 * 24 * 60 * 60 * 1000;
const events = await db.paymentEvents.findMany({ where: { receivedAt: { gte: since } } });
const newCounterparties = events.filter((e) => e.counterpartyFirstSeen);
const offHours = events.filter((e) => {
const h = new Date(e.receivedAt).getUTCHours();
return h < 5 || h > 22;
});
// Reconcile anything that looks off against the chain:
// const tx = await client.transactions.get(event.txHash);
console.log({ newCounterparties, offHours });from datetime import datetime, timedelta, timezone
# Query your own persisted webhook events - the SDK has transactions.get(id),
# not a list endpoint, so your event store is the audit log.
since = datetime.now(timezone.utc) - timedelta(days=7)
events = db.payment_events.where(received_at__gte=since)
new_counterparties = [e for e in events if e.counterparty_first_seen]
off_hours = [e for e in events if not (5 <= e.received_at.hour <= 22)]
# Reconcile against the chain when something looks off:
# tx = client.transactions.get(event.tx_hash)
print({"new_counterparties": new_counterparties, "off_hours": off_hours})Schreiben (und üben) Sie das Vorfall-Runbook.
Ein Runbook ist nur so gut, wie es zuletzt getestet wurde. Unten ist die Vorlage - kopieren Sie sie in das Wiki Ihres Teams, bearbeiten Sie sie für Ihre spezifischen Anforderungen und planen Sie eine 30-minütige Übung im nächsten Quartal. Messen Sie die Zeit; beheben Sie alles, was die Übung als fehlend aufzeigt.
# Incident response runbook - Agent wallet compromise (suspected or confirmed)
## Trigger
Any of:
- Unrecognised counterparty receiving > $10 USDC.
- > 50 rejected payment attempts from one agent in an hour.
- Engineer reports they cannot account for a recent payment.
- A leaked API key surfaces in a public scan.
## Step 1 - Stop the bleeding (< 5 minutes)
- Revoke the suspect API key: dashboard, or apiKeys.revoke / apiKeys.rotate.
- Revoke the agent's spend permission in the dashboard (allowance to zero).
- A revoked key cannot move funds and a revoked permission authorizes nothing.
## Step 2 - Preserve evidence (< 15 minutes)
- Pull the last 24h from the dashboard activity log and your stored events.
- Note the agent's spend permission as it was at the time of the incident.
- Note the timestamps of any unrecognised payments and their txHash on Base
(fetch with transactions.get).
## Step 3 - Communicate (< 30 minutes)
- Inform the on-call lead and finance.
- If customer funds are affected, draft a notification template (do not send
until investigation is far enough along to be accurate).
## Step 4 - Root cause and remediation (24-72 hours)
- Determine: leaked key, compromised webhook secret, prompt-injection
bypass, integration bug, or other.
- Rotate every secret that could have been exposed.
- Tighten the spend permission (lower the allowance or per-transaction cap).
- File a post-mortem with timeline, RCA, and follow-ups.Fünf Dinge, die Teams bei ihrem ersten Produktionsvorfall erwischen.
Einen neuen Agenten als 'genauso wie den alten' behandeln
Jeder Agent erhält sein eigenes Profil, seine eigenen Schlüssel, seine eigene Ausgabenrichtlinie. Wenn Sie Schlüssel zwischen Agenten wiederverwenden, 'weil sie ähnlich sind', wird ein einzelner Schlüsselkompromiss alle Agenten gleichzeitig gefährden. Das Erstellen eines neuen Agentenprofils erfordert einen API-Aufruf; die Isolation pro Agent ist die Minute wert, die es kostet, es richtig zu machen.
Ausgabenberechtigungen basieren auf Schätzungen, nicht auf Daten
Wählen Sie das Budget und die Obergrenze pro Transaktion aus einer Schätzung aus, und eines von zwei Dingen passiert: zu niedrig, und der Agent erreicht jeden Tag zur Mittagszeit das Limit, während Sie 'Zahlung abgelehnt' debuggen; zu hoch, und die Kontrolle ist Theater. Innerhalb der ersten Woche schauen Sie sich die tatsächlichen täglichen Ausgaben an und setzen das Budget auf 2-3x davon - nicht 1x (zu eng) und nicht 100x (praktisch unbegrenzt). Es ist eine Dashboard-Änderung, also ist das Nachjustieren günstig.
Webhook-Signaturgeheimnis wurde nie rotiert
Ein Vorfall, der das Webhook-Geheimnis preisgibt, bedeutet, dass ein Angreifer Webhooks fälschen kann, die wie legitime payment.received-Ereignisse aussehen, was Ihren Handler dazu bringen kann, Arbeiten zu liefern, die nie bezahlt wurden. Rotieren Sie das Geheimnis (webhooks.rotateSecret) im gleichen Rhythmus wie API-Schlüssel (vierteljährlich) oder jedes Mal, wenn Sie eine Offenlegung vermuten, und überprüfen Sie immer die Lieferungen mit webhooks.verify gegen das aktuelle Geheimnis.
Prüfprotokolle, die niemand liest
Ein Prüfprotokoll erfasst Dinge nur, wenn jemand es sich ansieht. Die meisten Teams aktivieren das Protokoll, schauen nie hinein und erfahren von Problemen durch Kundenbeschwerden. Planen Sie eine wöchentliche 15-minütige Überprüfung: neue Geschäftspartner, abgelehnte Zahlungen, Zahlungen außerhalb der Geschäftszeiten. Die Kosten sind gering; die Zeit zur Erkennung sinkt von Wochen auf Tage.
Keine Übung im Vorfallshandbuch
Ein Runbook, das noch nie geübt wurde, ist Fiktion. Wählen Sie ein vierteljährliches Datum, simulieren Sie ein Szenario mit einem geleakten Schlüssel, messen Sie, wie lange es dauert, um zu widerrufen und einzudämmen. Die erste Übung zeigt immer etwas Fehlendes (der Ingenieur, der weiß, wie man rotiert, ist im Urlaub, das Runbook ist hinter einem abgelaufenen Notion-Link). Besser, das in einer Übung zu finden als um 3 Uhr morgens während eines echten Vorfalls.
Nach dem Sicherheitsausweis.
Sicherheit ist nie abgeschlossen, aber der Rest des operativen Stacks profitiert von einer sauberen Basislinie. Straffen Sie die Ausgabensteuerungen, während tatsächliche Nutzungsdaten anfallen, härten Sie die Webhook-Verarbeitung gegen Lasten und überprüfen Sie die Identität des Agenten, damit Gegenparteien Ihr öffentliches Profil vertrauen.
Richten Sie Ausgabensteuerungen für Agenten ein, die Eingabeaufforderungsinjektionen überstehen
Die Webhook-Muster, nach denen Entwickler am häufigsten fragen
Verdienen Sie die GitHub- und Domain-Verifizierungsabzeichen
Vollständige Referenz unter docs.blockchain0x.com. Verwandtes Glossar: Coinbase Smart Wallet. Produktoberfläche: Agenten-Wallets.