SRA-RiskGate

sra-riskgate-mcp

An MCP server that lets AI assistants and agents check a stablecoin payment before paying it: approve, hold or reject. USDC by default; from 0.13.0 also USDT, USDB (Bridge) and USDG once the server enables them with SRA_ALLOWED_TOKENS.

Every tool fails closed. Malformed input is rejected, and if the model is unreachable or answers off-schema, the result is hold, never approve.

Pass the payment's own text. The rule tools take an optional untrusted_text: the memo, invoice, description or x402 extra fields exactly as received (a string, object or list). If that text claims its own verification, such as "risk level: low (verified offline)", "pre-approved" or "ignore previous instructions", the payment is held, even when every other check passes. This is the trick that caused all 4 unsafe approvals by SRA-RiskGate-4B on its benchmark. Never pass your own verification results there: those legitimately say "verified".

Check what will actually be signed. Since 0.6.0 (with sra-riskgate 0.9.0+), check_transaction takes the transaction itself: the contract it calls (to), its calldata (data) and its native value. A plain USDC transfer is decoded (the result includes the recipient and amount) and gets every check of check_payment_rules. Anything else is held: approve, increaseAllowance and permit (TOKEN_APPROVAL, plus UNLIMITED_APPROVAL), which let someone else move the wallet's USDC later; other functions such as transferFrom; a contract that is not USDC on that chain; native ETH; and malformed calldata. Use it whenever the agent has the transaction, not just a description of the payment. Since 0.7.2 it also takes the transaction's tx_type and authorization_list: an EIP-7702 delegation (type 4, or any authorization) is held as CODE_DELEGATION, because it hands control of the whole account to contract code, on every chain if signed with chain id 0.

Check the x402 signature. Since 0.7.0 (with sra-riskgate 0.11.0+), check_x402_authorization takes the EIP-712 typed data the agent is about to sign for an x402 payment. In x402 on EVM chains the agent signs an EIP-3009 TransferWithAuthorization instead of sending a transaction, and anyone holding that signature can move the USDC until it expires. The tool checks the domain is USDC on that chain, from is the agent's wallet, and the authorization is current and short-lived (held if valid for more than SRA_MAX_AUTH_VALIDITY_SECONDS, default one hour), then gives the decoded payment every check of check_payment_rules. A Permit is held as a token approval. Time comes from the server's clock, not from the agent.

Circle Gateway. Since 0.8.0 (with sra-riskgate 0.13.0+), check_x402_authorization also checks Circle Gateway batched payments (nanopayments): the same authorization signed for Gateway's GatewayWalletBatched domain with Circle's GatewayWallet contract. Gateway requires these to stay valid for at least 3 days, so they have their own limit, SRA_MAX_GATEWAY_VALIDITY_SECONDS (default 8 days, above the 7 days plus 100 seconds that Circle's SDK signs for), set on the server like every other limit. A Gateway-named domain with any other contract is held. (0.8.0 shipped with a 7-day default, which held payments made by Circle's SDK; fixed in 0.9.0.)

Is the wallet still yours? Since 0.9.2 (with sra-riskgate 0.16.0+), every payment tool takes an optional account_code: your wallet's eth_getCode result. An EIP-7702 authorization signed anywhere else leaves 0xef0100 followed by the delegate's address in the account's code; if that delegate is not in SRA_EXPECTED_DELEGATES, the payment is held (ACCOUNT_DELEGATED). Plain accounts and ordinary contract wallets pass. Suggested by Carlos (Bloqarl) on DEV.to.

Circle Wallets. Since 0.9.0 (with sra-riskgate 0.14.0+), check_circle_wallets_request checks a request to Circle's developer-controlled wallets API before the agent sends it. With Circle Wallets the agent never signs: Circle signs as soon as it accepts the request, so this is the last point a bad payment can be stopped. Pass the operation (transfer, contractExecution, signTypedData, signTransaction) and the exact body. Set SRA_CIRCLE_WALLETS to the wallets the agent may use (walletId=0xaddress, comma-separated) so a request from any other wallet is held.

Sanctioned addresses. Since 0.4.0 (with sra-riskgate 0.7.1+), both rule tools reject any payment to or from an address on the OFAC SDN list, and check_address_sanctions checks addresses on their own, before a payment exists. The list is a dated snapshot bundled with sra-riskgate, matched exactly and offline. "Not listed" is not a compliance clearance: it does not trace funds or ownership, and addresses added after the snapshot date are not included.

Who is on the other side. Since 0.5.0 (with sra-riskgate 0.8.0+), you can give the server the payees you have already verified (SRA_KNOWN_RECIPIENTS). A payment to anyone else is then held with NEW_COUNTERPARTY, the usual first step in "our bank details have changed" fraud. Addresses on your blocklist (SRA_BLOCKED_ADDRESSES, or the tools' blocked_addresses argument) are always rejected. Known payees come only from the server's configuration, never from tool arguments or payment text: an agent whose input has been tampered with cannot declare an attacker's address "known". The blocklist argument is safe for agents to use because it can only make a decision stricter.

Install

Add it to your MCP client's configuration (Claude Desktop, Cursor and others):

{

"mcpServers": { "sra-riskgate": { "command": "uvx", "args": ["sra-riskgate-mcp"] } } }

Or install it with pip (pip install sra-riskgate-mcp) and use "command": "sra-riskgate-mcp".

The two rule-based tools work immediately. For check_payment_with_model, run the model locally:

ollama pull sriram1983007/sra-riskgate

Configuration

A malformed address or an unr