Beveilig je agent wallet voordat je live gaat.
In productie gaan met agentbetalingen is niet dezelfde checklist als een normale API-integratie. Voeg toe: een bewuste keuze van het type wallet, een afgestemd uitgavenbeleid (geen standaardinstellingen), rotatie van API- en webhook-geheimen op een vastgestelde frequentie, een wekelijkse audit-log review, en een incident-respons runbook dat minstens één keer is geoefend. Zonder deze, verzend je en leer je het op de harde manier.
Voordat je begint.
- Een werkende agentintegratie end-to-end op test - zie add-payments-to-agent en test-without-real-money.
- Uitgavenbeheersing geconfigureerd - zie uitgavenbeheersing (deze gids gaat ervan uit dat er al een beleid is).
- Een geheimbeheerder (AWS Secrets Manager, GCP Secret Manager, Vault, 1Password, enz.) - geheimen in .env-bestanden zijn niet genoeg.
- Een duidelijk geïdentificeerde on-call engineer met admin-toegang tot het wallet-dashboard.
- 15 minuten gefocuste tijd. De checklist hieronder is niet aspiratief - werk het regel voor regel door.
Voer de checklist voor de lancering uit.
Elf items. Elk item is een ja/nee vraag met een enkele eigenaar. Als een item niet is aangevinkt, ga dan niet live - werk dat item eerst af. De kosten van een gemist item in productie zijn altijd groter dan de kosten van het nu afmaken.
# 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.Plan de rotatie van API-sleutels en webhook-geheimen.
Kwartaal is de standaardcadans; draai onmiddellijk op een van de volgende: vermoedelijke lek, vertrek van de hoofdingenieur, beveiligingsincident elders in het bedrijf. Het twee-sleutel vensterpatroon stelt je in staat om sleutels zonder downtime te wisselen: maak de nieuwe sleutel, implementeer deze overal, verifieer, en intrek dan de oude.
// 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-handtekeningsecrets draaien op dezelfde manier via het dashboard - schakel een tweede geheim in, herdeploy de handler om beide te accepteren, en trek dan de oude in. Beide met een kwartaalcyclus met kalenderherinneringen.
Stel de wekelijkse auditreview in.
Drie dingen om elke week naar te kijken: nieuwe tegenpartijen (alles wat nog niet eerder is gezien verdient een 30-seconden sanity check), afgewezen betalingen (de uitgavenmachtiging deed zijn werk - is de agent ergens vastgelopen?), en betalingen buiten kantooruren (een betaling om 3 uur 's nachts van een agent die nominale alleen tijdens kantooruren draait, is het soort signaal dat injectie-aanvallen vroeg opvangt).
// 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})Schrijf (en oefen) het incident runbook.
Een runbook is alleen zo goed als hoe recent het is getest. Hieronder staat de sjabloon - kopieer het naar de wiki van je team, bewerk het voor jouw specifics, en plan een 30-minuten oefening in het volgende kwartaal. Timen; fix whatever the drill reveals as missing.
# 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.Vijf dingen die teams vangen in hun eerste productie-incident.
Een nieuwe agent behandelen als 'precies zoals de oude'
Elke agent krijgt zijn eigen profiel, zijn eigen sleutels, zijn eigen uitgavenbeleid. Als je sleutels hergebruikt tussen agents 'omdat ze vergelijkbaar zijn', kan een enkele sleutelcompromittering elke agent tegelijk in gevaar brengen. Het opzetten van een nieuw agentprofiel kost één API-aanroep; de isolatie per agent is de minuut waard die het kost om het correct te doen.
Uitgaven toestemming bepaald door schatting, niet door gegevens
Kies de toelage en per-transactie limiet op basis van een gok en er gebeurt een van de twee dingen: te laag en de agent bereikt elke dag halverwege de dag de limiet terwijl je 'betaling afgewezen' debugt; te hoog en de controle is theater. Kijk binnen de eerste week naar de werkelijke dagelijkse uitgaven en stel de toelage in op 2-3x dat - niet 1x (te krap) en niet 100x (effectief onbeperkt). Het is een dashboardwijziging, dus opnieuw afstemmen is goedkoop.
Webhook-handtekening geheim nooit geroteerd
Een incident dat de webhook-geheimen lekt betekent dat een aanvaller webhooks kan vervalsen die eruitzien als legitieme payment.received evenementen, wat je handler kan misleiden om werk te leveren dat nooit betaald is. Draai het geheim (webhooks.rotateSecret) op dezelfde frequentie als API-sleutels (kwartaal) of elke keer dat je vermoedt dat er blootstelling is, en verifieer altijd leveringen met webhooks.verify tegen het huidige geheim.
Auditlogs die niemand leest
Een auditlog registreert alleen dingen als iemand ernaar kijkt. De meeste teams schakelen de log in, kijken er nooit naar en ontdekken problemen via klantklachten. Plan een wekelijkse beoordeling van 15 minuten: nieuwe tegenpartijen, afgewezen betalingen, betalingen buiten kantooruren. De kosten zijn klein; de tijd om te detecteren daalt van weken naar dagen.
Geen oefening op het incidentenhandboek
Een runbook dat nooit is geoefend is fictie. Kies een kwartaaldatum, simuleer een scenario met een gelekte sleutel, tijd hoe lang het duurt om in te trekken en te bevatten. De eerste oefening onthult altijd iets dat ontbreekt (de engineer die weet hoe te roteren is op vakantie, het runbook staat achter een verlopen Notion-link). Beter om dat in een oefening te ontdekken dan om 3 uur 's nachts tijdens een echt incident.
Na de beveiligingspas.
Beveiliging is nooit af, maar de rest van de operationele stack profiteert van een schone basislijn. Verstevig de uitgavencontroles naarmate de werkelijke gebruiksgegevens zich ophopen, versterk de verwerking van webhooks tegen belasting en verifieer de identiteit van de agent zodat tegenpartijen jouw publieke profiel vertrouwen.
Stel agent uitgavencontroles in die prompt-injectie overleven
De webhook-patronen waar ontwikkelaars het meest naar vragen
Verdien de GitHub- en domeinverificatiebadges
Volledige referentie op docs.blockchain0x.com. Gerelateerde woordenlijst: Coinbase Smart Wallet. Productoppervlak: Agentportemonnees.