Walletguard

WalletGuard is an agent-friendly transaction firewall for a world where AI agents can be prompt-injected or tricked into interacting with malicious contracts.

An agent proposes a transaction as an intent with chainId, vault, target, calldata, value, and expectations. A Chainlink CRE workflow then evaluates that intent using deterministic rules and simulation signals using Tenderly (with Alchemy fallback) via our risk service. The workflow outputs an allow/warn/block decision plus a deterministic VaultReceipt and receiptHash. That receiptHash can be enforced onchain: the WalletGuardVault only executes transactions when called by its configured executor and when the receiptHash is fresh (replay protection). This makes execution conditional on verifiable safety checks, and makes risk explainable with clear flags and reasons.

We also demonstrate Confidential Compute in the CRE workflow: secrets (riskApiKey) are injected into the workflow so API keys never need to live in an agent runtime. The result is a practical pattern for “agents as planners, not key-holders,” while still enabling transactions or DeFi interactions through a gated vault.

Chainlink CRE workflows

• walletguard-intent: intent → confidential secret injection → risk-service call → deterministic receipt + decision
• walletguard-analyze: report-style analysis using deterministic rules

Confidential Compute / Secrets injection

• The workflow retrieves riskApiKey via CRE secrets injection and uses it to authenticate to the risk-service endpoint.

Risk engine (apps/risk-service)

• Combines fast heuristics (allowlists, approval checks, selector decoding, value sanity) with simulation-based signals:
  • Tenderly full traces (delegatecall paths, internal value transfers, reentrancy indicators, internal target allowlist)
  • Alchemy simulation fallback
• Normalizes these into a riskScore + flags + explain text.

Onchain contracts

• WalletGuardVault: holds funds, enforces target/selector allowlists, maxValuePerTx, and replay protection via usedReceiptHash. Only creExecutor can call execute(...).
• ReportRegistry: minimal anchor for report hashes (optional).