Build a forensic incident-report bundle for a security review or disclosure. Read-only — gathers evidence already available to the server (demo-mode state, paired Ledger summary, skill / pin-drift notice flags) and, if you supply wallet + chain with scope: 'wallet' or 'custom', the wallet's recen...
AI agents invoke build_incident_report to trigger actions in VaultPilot MCP. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
chain | string | — | Chain context for the wallet. Required when on-chain evidence is fetched (`scope: wallet` or `scope: custom`). Defaults to `ethereum` when omitted in those scop |
scope | string | — | Evidence-collection scope. `session` (default): notice flags fired this session, demo-mode state, paired Ledger summaries — no on-chain reads. `wallet`: same as |
redact | string | — | Redaction mode. Default `addresses` fuzzes every address-shaped field (EVM/Solana/TRON/BTC) to first-4/last-4 of meaningful chars so the bundle is safe to displ |
txHash | string | — | Transaction hash anchoring the incident to a specific tx. Surfaced verbatim in the bundle (with redaction applied to the user-facing shape per `redact`). v1 doe |
wallet | string | — | Wallet address to scope evidence to. Required when `scope` is `wallet` or `custom`. Format: EVM hex / Solana base58 / TRON T-prefixed base58. Detected automatic |
incident_class | string | — | What category of incident is being reported. Drives which evidence to fetch on top of the always-included session-level summary. `address_poisoning` adds allowa |
Parameters from the server's own tool schema.
build_incident_report triggers real processes with real consequences. An agent gone sideways doesn't fire it once — it starts dozens of builds, sends mass notifications, or burns through compute before anyone looks up.
Risk signalsBulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
Build a forensic incident-report bundle for a security review or disclosure. Read-only — gathers evidence already available to the server (demo-mode state, paired Ledger summary, skill / pin-drift notice flags) and, if you supply wallet + chain with scope: 'wallet' or 'custom', the wallet's recent on-chain tx history (uses the same data path as get_transaction_history, so address-poisoning suffix-lookalike heuristics are surfaced). Returns BOTH a structured envelope (machine-readable) and a narrative markdown string the user can paste into a GitHub issue / email / disclosure verbatim. REDACTION (default addresses): every address-shaped field is fuzzed to first-4 / last-4 of meaningful chars so the bundle is safe to display before the user has decided where to forward it. Use redact: 'all' to additionally bucket USD amounts to coarse ranges ($1k–10k etc.). Use redact: 'none' only when the user is ready to share full hex with a trusted security contact. v1 SCOPE: this tool only BUILDS the bundle; it does not submit anywhere. The user copies the narrative and routes it manually. A submit_incident_report companion that posts via the request_capability proxy is on the v2 roadmap (see claude-work/plan-incident-report-v2.md). Also deferred from v2: prepared-tx ring-buffer evidence ("last N prepared / broadcast txs"), so v1's tx evidence comes from on-chain history only. It is categorised as a Execute tool in the VaultPilot MCP MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
build_incident_report accepts 6 parameters: chain, scope, redact, txHash, wallet, incident_class. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for build_incident_report: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
build_incident_report is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the build_incident_report rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for build_incident_report. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
build_incident_report is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.