รักษาความปลอดภัยกระเป๋าเงินของเอเจนต์ของคุณก่อนที่จะเปิดใช้งาน
การนำการชำระเงินของตัวแทนไปสู่การผลิตไม่ใช่เช็คลิสต์เดียวกับการรวม API ปกติ เพิ่ม: การเลือกประเภทกระเป๋าเงินอย่างตั้งใจ นโยบายการใช้จ่ายที่ปรับแต่ง (ไม่ใช่ค่าเริ่มต้น) การหมุนเวียนความลับ API และเว็บฮุกตามจังหวะที่กำหนด การตรวจสอบบันทึกการตรวจสอบรายสัปดาห์ และคู่มือการตอบสนองต่อเหตุการณ์ที่ได้ฝึกซ้อมอย่างน้อยหนึ่งครั้ง หากไม่มีสิ่งเหล่านี้ คุณจะส่งและเรียนรู้ในทางที่ยาก
ก่อนที่คุณจะเริ่ม.
- การรวมเอเจนต์ที่ทำงานได้แบบ end-to-end ในการทดสอบ - ดู add-payments-to-agent และ test-without-real-money
- การควบคุมการใช้จ่ายได้รับการกำหนดค่า - ดู การควบคุมการใช้จ่าย (คู่มือนี้สมมติว่ามีนโยบายอยู่แล้ว).
- ผู้จัดการความลับ (AWS Secrets Manager, GCP Secret Manager, Vault, 1Password, ฯลฯ) - ความลับในไฟล์ .env ไม่เพียงพอ
- วิศวกรที่ระบุอย่างชัดเจนซึ่งมีการเข้าถึงผู้ดูแลระบบไปยังแดชบอร์ดกระเป๋าเงิน
- 15 นาทีของเวลาที่มุ่งเน้น รายการตรวจสอบด้านล่างนี้ไม่ใช่เป้าหมาย - ทำงานผ่านมันทีละบรรทัด.
ดำเนินการตรวจสอบก่อนเปิดตัว
สิบเอ็ดรายการ แต่ละรายการเป็นคำถามใช่/ไม่ใช่ที่มีเจ้าของเพียงคนเดียว หากรายการใดไม่ได้ตรวจสอบ อย่าเผยแพร่ - ทำงานกับรายการนั้นให้เสร็จก่อน ค่าใช้จ่ายของรายการที่พลาดในผลิตภัณฑ์มักจะมากกว่าค่าใช้จ่ายในการทำให้เสร็จในขณะนี้.
# 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.กำหนดการหมุน API key และ webhook secret
การหมุนเวียนรายไตรมาสเป็นจังหวะเริ่มต้น; หมุนเวียนทันทีในกรณีใด ๆ ที่สงสัยว่าเกิดการรั่วไหล การออกจากวิศวกรหลัก หรือเหตุการณ์ด้านความปลอดภัยที่อื่นในบริษัท รูปแบบหน้าต่างสองกุญแจช่วยให้คุณสามารถเปลี่ยนกุญแจได้โดยไม่มีเวลาหยุดทำงาน: สร้างกุญแจใหม่ ปล่อยไปทุกที่ ยืนยัน แล้วเพิกถอนกุญแจเก่า.
// 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 หมุนเวียนผ่านแดชบอร์ดในลักษณะเดียวกัน - เปิดใช้งานความลับที่สอง ปรับใช้ตัวจัดการใหม่เพื่อรับทั้งสอง จากนั้นยกเลิกความลับเก่า ทั้งสองจะมีรอบทุกไตรมาสพร้อมการเตือนในปฏิทิน
ตั้งค่าการตรวจสอบประจำสัปดาห์.
สามสิ่งที่ต้องดูทุกสัปดาห์: คู่สัญญาใหม่ (สิ่งใดก็ตามที่ไม่เคยเห็นมาก่อนสมควรได้รับการตรวจสอบความถูกต้อง 30 วินาที), การชำระเงินที่ถูกปฏิเสธ (การอนุญาตการใช้จ่ายทำงานของมัน - ตัวแทนติดอยู่ที่ไหนหรือไม่?), และการชำระเงินนอกเวลาทำการ (การชำระเงินที่ 3 โมงเช้าจากตัวแทนที่โดยปกติทำงานเฉพาะเวลาทำการเท่านั้นเป็นสัญญาณที่จับการโจมตีการฉีดได้เร็ว).
// 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})เขียน (และฝึกซ้อม) คู่มือเหตุการณ์
คู่มือการดำเนินการมีคุณภาพดีเพียงใดขึ้นอยู่กับว่าได้ทดสอบเมื่อใดล่าสุด ด้านล่างนี้คือเทมเพลต - คัดลอกไปยังวิกิของทีมคุณ แก้ไขตามความเฉพาะของคุณ และกำหนดเวลาฝึกซ้อม 30 นาทีในไตรมาสถัดไป ตั้งเวลา; แก้ไขสิ่งที่การฝึกซ้อมเปิดเผยว่าไม่มี.
# 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.ห้าสิ่งที่ทำให้ทีมติดอยู่ในเหตุการณ์การผลิตครั้งแรก
การปฏิบัติต่อเอเจนต์ใหม่เหมือนกับ 'เอเจนต์เก่า'
ทุกเอเจนต์จะได้รับโปรไฟล์ของตนเอง กุญแจของตนเอง และนโยบายการใช้จ่ายของตนเอง หากคุณใช้กุญแจซ้ำระหว่างเอเจนต์ 'เพราะมันคล้ายกัน' การประนีประนอมกุญแจเดียวจะทำให้ทุกเอเจนต์ได้รับผลกระทบในครั้งเดียว การสร้างโปรไฟล์เอเจนต์ใหม่ใช้การเรียก API หนึ่งครั้ง; การแยกต่อเอเจนต์นั้นคุ้มค่ากับเวลาหนึ่งนาทีที่ใช้ในการทำให้ถูกต้อง
การอนุญาตการใช้จ่ายที่ตั้งขนาดโดยการคาดเดา ไม่ใช่จากข้อมูล
เลือกจำนวนเงินที่กำหนดและขีดจำกัดต่อการทำธุรกรรมจากการคาดเดาและเกิดขึ้นหนึ่งในสองสิ่ง: ต่ำเกินไปและตัวแทนจะถึงขีดจำกัดกลางวันทุกวันในขณะที่คุณแก้ไขข้อผิดพลาด 'การชำระเงินถูกปฏิเสธ'; สูงเกินไปและการควบคุมก็เป็นเพียงการแสดง ภายในสัปดาห์แรกให้ดูการใช้จ่ายจริงในแต่ละวันและตั้งจำนวนเงินที่กำหนดที่ 2-3 เท่าของจำนวนนี้ - ไม่ใช่ 1 เท่า (แน่นเกินไป) และไม่ใช่ 100 เท่า (ไม่มีขีดจำกัดจริง) มันเป็นการเปลี่ยนแปลงในแดชบอร์ด ดังนั้นการปรับแต่งจึงมีค่าใช้จ่ายต่ำ.
ความลับการลงนาม webhook ไม่เคยถูกหมุน
เหตุการณ์ที่รั่วไหลความลับของ webhook หมายความว่าผู้โจมตีสามารถปลอมแปลง webhook ที่ดูเหมือนเหตุการณ์ payment.received ที่ถูกต้องตามกฎหมาย ซึ่งสามารถหลอกให้ตัวจัดการของคุณส่งมอบงานที่ไม่เคยได้รับการชำระเงิน หมุนเวียนความลับ (webhooks.rotateSecret) ในจังหวะเดียวกันกับคีย์ API (รายไตรมาส) หรือเมื่อใดก็ตามที่คุณสงสัยว่ามีการเปิดเผย และตรวจสอบการจัดส่งเสมอด้วย webhooks.verify กับความลับปัจจุบัน
บันทึกการตรวจสอบที่ไม่มีใครอ่าน
บันทึกการตรวจสอบจะจับสิ่งต่างๆ ได้ก็ต่อเมื่อมีคนดูมัน ทีมส่วนใหญ่เปิดใช้งานบันทึก แต่ไม่เคยดูมัน และพบปัญหาจากการร้องเรียนของลูกค้า กำหนดการตรวจสอบ 15 นาทีในแต่ละสัปดาห์: คู่สัญญาใหม่, การชำระเงินที่ถูกปฏิเสธ, การชำระเงินนอกเวลาทำการ ค่าใช้จ่ายน้อยมาก; เวลาที่ใช้ในการตรวจจับลดลงจากสัปดาห์เป็นวัน
ไม่มีการซ้อมในคู่มือเหตุการณ์
คู่มือการดำเนินการที่ไม่เคยถูกใช้งานเป็นเรื่องสมมติ เลือกวันที่รายไตรมาส จำลองสถานการณ์การรั่วไหลของกุญแจ วัดระยะเวลาที่ใช้ในการเพิกถอนและควบคุม การฝึกซ้อมครั้งแรกมักจะเปิดเผยสิ่งที่ขาดหายไป (วิศวกรที่รู้วิธีหมุนอยู่ในวันหยุด คู่มือการดำเนินการอยู่หลังลิงก์ Notion ที่หมดอายุ) ดีกว่าที่จะค้นพบสิ่งนั้นในการฝึกซ้อมมากกว่าตอน 3 โมงเช้าในระหว่างเหตุการณ์จริง
หลังจากที่ผ่านการตรวจสอบความปลอดภัย.
ความปลอดภัยไม่มีวันเสร็จสิ้น แต่ส่วนที่เหลือของสแต็คการดำเนินงานได้รับประโยชน์จากฐานข้อมูลที่สะอาด ทำให้การควบคุมการใช้จ่ายแน่นขึ้นเมื่อข้อมูลการใช้งานจริงสะสม ทำให้การจัดการ webhook แข็งแกร่งขึ้นเพื่อต่อต้านการโหลด และตรวจสอบตัวตนของเอเจนต์เพื่อให้คู่สัญญาไว้วางใจในโปรไฟล์สาธารณะของคุณ
ตั้งค่าการควบคุมการใช้จ่ายของเอเจนต์ที่สามารถอยู่รอดจากการฉีดคำสั่ง
รูปแบบ webhook ที่นักพัฒนาถามบ่อยที่สุด
รับป้ายการตรวจสอบ GitHub และโดเมน
เอกสารอ้างอิงเต็มรูปแบบที่ docs.blockchain0x.com. พจนานุกรมที่เกี่ยวข้อง: Coinbase Smart Wallet. พื้นผิวผลิตภัณฑ์: กระเป๋าเงินของเอเจนต์.