VulSight

AI agent payment security

Security for AI agents that move money.

VulSight helps teams place a policy check between an AI agent and the systems that execute payments. Each proposed transaction is checked against customer-defined rules before it can be signed.

Discuss a security pilotSee how it works
Official Geth advisoryCVE-2026-26314

VulSight

Payment authorization
Policy active

Transaction request

Vendor payout

$24,800USDC
Agent
invoice-agent
Rail
Base
Mandate
md_vendor_1842
  1. Proposal
  2. Mandate
  3. Inspect
  4. Decision
RecipientMandate check

Authorized0xA882...11E7

Requested0x71A4...9C2E

DENY

Recipient mutation denied
Signer locked
Reason
recipient.allowlist_mismatch
Evidence
evt_7f42c9
Keys isolated from agent

Every payment passes the same control path

  • Typed request
  • Policy check
  • Exact approval
  • Isolated signer

AI agent payment authorization framework

One control path between a prompt and a payment.

Authorization principle

Identity says who the agent is. Policy says what it may do. VulSight is designed to verify that the exact action reaching execution is still the action the principal authorized.

Authorization traceOne request through the control boundary
  1. 01

    Principal authority

    Mandate

    Purpose, budget, recipient, and expiry define the ceiling.

    • Purpose
    • Budget
    • Recipient
    • Expiry
  2. 02

    Agent intent

    Proposal

    The agent submits one typed request without signing authority.

    • Typed action
    • No keys
    • No self-approval
  3. 03

    VulSight boundary

    Verify + decide

    VulSight checks the mandate, action, and live state outside the model.

    • Exact action
    • Policy
    • Live state
    AllowHoldDeny
  4. 04

    Customer-controlled

    Signer

    Customer-held authority applies only to the approved payload.

    • Exact payload
    • Scoped authority
  5. 05

    Existing stack

    Payment rail

    An approved payload is submitted to the selected rail; execution and settlement status are recorded.

    • Card
    • Bank
    • Stablecoin
    • x402
05 / 05
Settlement recorded
Payment rail

An approved payload is submitted to the selected rail; execution and settlement status are recorded.

ReadsMandate + proposed action + live state
ReturnsDecision + reason code + evidence ID
Never needsRaw keys or control over policy

The authority split

Keep financial authority outside the model.

AI reasoning can be probabilistic. Payment authorization should not be. Each control separates the model's proposed action from the authority to execute it.

Explore the authorization framework
  1. 01

    The agent proposes

    The model produces one typed action with bounded inputs. It receives no raw key, reusable credential, control over policy, or direct rail path.

    Intent, never authority
  2. 02

    Policy authorizes

    Rules outside the model evaluate the exact network, asset, recipient, amount, budget, expiry, and action type. Anything unmatched is denied.

    Same input. Same decision.
  3. 03

    An isolated signer executes

    The signer validates authorization against the payload it actually receives. Any change to a bound field invalidates the authorization.

    Approval cannot drift
  4. 04

    Operators retain control

    Policy administration, revocation, recovery, and emergency stops stay outside the agent runtime. The agent cannot expand or restore its own authority.

    Recovery stays external

One transaction / Two outcomes

A valid signature cannot fix a compromised transaction.

Where controls fail

A signer can validate a payload perfectly and still execute the wrong intent. The missing layer is an independent boundary that binds authority to the exact action.

Without an authority boundaryCryptographically valid. Operationally wrong.
  1. Retrieved invoice carries an untrusted instruction.
  2. The agent replaces the trusted payment destination.
  3. The payment tool accepts arguments chosen by the model.
  4. The signer executes a technically valid payload.
Signer saw bytes. It never saw intent.
With the VulSight boundaryUntrusted context can propose. It cannot authorize.
  1. The agent submits one typed transaction proposal.
  2. Policy checks recipient, asset, budget, network, and expiry.
  3. Authorization binds to the exact signable payload.
  4. The isolated signer rejects every unauthorized mutation.
Change a bound field. Reauthorize.

Infrastructure proof / Public record

Our authorization work is grounded in published blockchain security research.

Why the evidence matters

Agent payments inherit the failure modes of blockchains, wallets, protocols, models, and application code. Our public record shows the discipline behind the product: trace attacker influence to execution, prove impact, and harden the boundary.

Inspect the public record

Go Ethereum peer-to-peer message handling

Geth denial-of-service vulnerability via a malicious peer message

The vendor advisory identifies affected versions through 1.16.8 and credits Waleed Ahmed from vulsight.com with the report.

Reachable impact
A specially crafted message can force an affected node to shut down or crash.
Published outcome
Geth fixed the issue in versions 1.16.9 and 1.17.0 and published an advisory rated High.
Read the findingOpen official advisory

Independent rankings with direct sources.

Ethereum
#15
Execution layer · Checked Jul 20, 2026
, opens in a new tab
Cantina
#16
Public profile · Checked Jul 25, 2026
, opens in a new tab
HackenProof
#23
Overall rank · Checked Jul 24, 2026
, opens in a new tab
Immunefi
#67
Overall rank · Checked Jul 24, 2026
, opens in a new tab

Selected bounty outcomes

Material failures found across systems that move value.

  1. Public acknowledgement

    critical
    Smart contracts / Immunefi
    Reward$300K

    Critical vulnerability with fund loss impact

    A flaw in smart contract logic exposed more than $100M in TVL to potential fund loss. The project and exploit path remain confidential.

    Value at risk
    $100M+ TVL
    Classification
    Critical
    Disclosure
    Name withheld under disclosure terms

  2. VulSight-reported confidential result

    critical
    Blockchain network / Confidential program
    RewardApprox. $150,000

    Lock inversion deadlock capable of halting the chain

    A lock inversion deadlock could halt chain progress without automatic recovery, requiring operator intervention to restart the network.

    Impact
    Chain halt
    Recovery
    Manual restart
    Disclosure
    Target withheld
    Private evidenceVulSight reports this result from confidential program documentation; no public source is available.

  3. Public acknowledgement

    high
    Blockchain network / HackenProof
    Reward$50K

    Vulnerability capable of halting a blockchain network

    A flaw capable of halting a blockchain network was reported while the exploit path remains under disclosure restrictions.

    Impact
    Chain halt
    Program
    HackenProof
    Disclosure
    Network withheld

  4. Public acknowledgement

    high
    Blockchain network / HackenProof
    Reward$40K

    Four vulnerabilities capable of halting one blockchain network

    Four distinct ways to halt a blockchain network were reported, with $40K in combined rewards.

    Findings
    4
    Impact
    Chain halt
    Disclosure
    Target withheld

Agent payment security pilot

Secure one agent transaction flow before it moves money.

We map the authority boundary, replay adversarial cases in shadow mode, and return an enforcement decision. Customer funds stay untouched during validation.

Discuss a security pilotView the engagement model
  1. 01

    Map the boundary

    Agent · action · rail · signer

  2. 02

    Replay adversarial cases

    Shadow mode · no fund movement

  3. 03

    Decide enforcement

    Enforce · redesign · stay manual