Security: Falinkaz/smart402-python

Security

Report a vulnerability

SECURITY.md

Security and Trust Model

smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.

What the SDK sends to smart402

When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:

{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}

All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.

What the SDK does NOT send

  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above

You can verify this by reading the source:

Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.

What smart402 can do

  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data

What smart402 cannot do

  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access

The SDK trust boundary

The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:

  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response

It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.

Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.

Fail modes

You control what happens when smart402 is unreachable:

ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.

Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.

Data stored by the hosted service

When you use the hosted API at https://api.smart402.com:

Stored per evaluation:

  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)

Counterparty cache (shared across accounts for efficiency):

  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan

Never stored:

  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above

Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.

How to verify these claims

  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).

Reporting a vulnerability

Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.

Please don't open a public issue for a suspected vulnerability. Include enough to reproduce it — what you did, what happened, what you expected. A proof of concept helps. If you're unsure whether something counts, send it anyway.

Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous

These are honest targets, not an SLA, and we'll tell you if something is taking longer.

Supported versions

Fixes ship in a new patch release of the latest minor (0.5.x). Older versions don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the live API, so upgrading is the supported path.

Scope

In scope: this SDK, and the smart402 API it calls (api.smart402.com).

Out of scope: third-party services smart402 depends on — report those to the vendor — and volumetric denial of service; please don't load-test the production API. Signups are open, so test against your own account rather than someone else's.

Anything not answered here: security@smart402.com.

There aren't any published security advisories

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Security: Falinkaz/smart402-python
Security
Report a vulnerability

SECURITY.md

Security and Trust Model
smart402 is a risk evaluation service for AI agent payments. This document explains exactly what the SDK sees, what it sends, and what it cannot do, so you can verify these claims by reading the source.
What the SDK sends to smart402
When your agent encounters an x402 payment requirement, the SDK calls POST /evaluate with this data:
{
"agent_id": "your-agent-id",
"agent_wallet_address": "0x...",
"agent_framework": "langchain",
"wallet_provider": "local_evm",
"sdk_version": "0.1.0",
"payment_requirements": {
"amount": "0.10",
"token": "USDC",
"network": "eip155:8453",
"pay_to": "0x9dBA414637c611a16BEa6f0796BFcbcBdc410df8",
"scheme": "exact",
"description": "Weather data — 1 request"
}
}
All of these fields are visible to the counterparty or the x402 protocol anyway. The pay_to address is public. The amount and token are in the payment requirement served by the seller. The agent_wallet_address is the public key, not the private key.
What the SDK does NOT send
  • Private keys: the SDK never asks for them, never touches them
  • Wallet seed phrases: same
  • Signed transactions: signing happens after smart402 approves, in your wallet/signer
  • Raw transaction data: smart402 evaluates payment requirements, not signed transactions
  • Wallet balances: not requested, not sent
  • Other agent state: only the fields above
You can verify this by reading the source:
Or proxy the SDK's HTTP calls with mitmproxy and inspect what goes over the wire.
What smart402 can do
  • Return approve or deny for a payment
  • Log the evaluation: amount, token, counterparty address, decision, latency
  • Update your agent's spend counters for budget enforcement
  • Cache counterparty metadata (contract type, wallet age) from public Etherscan data
What smart402 cannot do
  • Sign transactions: it has no access to your private key
  • Initiate payments: it responds to your evaluation requests, never initiates
  • Modify payment parameters: it returns an approve/deny decision; your code decides what to do next
  • Redirect payments to a different address: the SDK does not modify pay_to
  • Access your wallet funds: no key, no access
The SDK trust boundary
The SDK is a thin HTTP client. The Python SDK is ~300 lines across 4 files. It does two things:
  1. Converts the x402 PaymentRequirements object to the smart402 request format
  2. Calls POST /evaluate and returns the response
It does not hook into wallet signing. It does not intercept or modify transactions. It does not hold state between calls beyond configuration. Your agent code decides what to do with the approve/deny response; the SDK does not enforce anything.
Zero network calls beyond the single POST /evaluate. No telemetry, no analytics, no side-channel requests.
Fail modes
You control what happens when smart402 is unreachable:
ModeBehavior
fail_open (default)SDK returns a synthetic approve; payment proceeds. You lose risk protection but keep functionality.
fail_closedSDK raises Smart402Unavailable; payment is blocked until the API recovers.
Set fail_mode="fail_closed" for high-value agents where safety is more important than uptime.
Data stored by the hosted service
When you use the hosted API at https://api.smart402.com:
Stored per evaluation:
  • Amount, token, network, counterparty address (pay_to)
  • Decision (approve/deny) and triggered rules
  • Latency and timestamp
  • Agent ID and account ID (your account, not your private key)
Counterparty cache (shared across accounts for efficiency):
  • Whether pay_to is a contract or EOA
  • Wallet age in days (derived from first transaction, via Etherscan)
  • Whether the contract is verified on Etherscan
Never stored:
  • Private keys
  • Signed transactions
  • Wallet balances
  • Any data not listed above
Isolation: All evaluation data is scoped to your account. Other accounts cannot see your evaluations, agents, or policies. Dashboard access is authenticated via Clerk.
How to verify these claims
  1. Read the SDK source: it's ~300 lines of Python. The entire outbound request is in client.py.
  2. Proxy the SDK: use mitmproxy or Charles and inspect the actual HTTP call.
  3. Check the request schema: models.py defines exactly what gets serialized.
  4. Run the tests: pytest tests/ (they use mock HTTP and confirm no unexpected calls are made).
Reporting a vulnerability
Email: security@smart402.com, or use this repository's private vulnerability reporting (Security → Report a vulnerability). Either reaches us; pick whichever you already have open.
Please don't open a public issue for a suspected vulnerability. Include enough to
reproduce it — what you did, what happened, what you expected. A proof of concept
helps. If you're unsure whether something counts, send it anyway.
Acknowledgementwithin 3 business days
Initial assessmentwithin 10 business days
Creditnamed in the fix notes if you want it, or anonymous
These are honest targets, not an SLA, and we'll tell you if something is taking
longer.
Supported versions
Fixes ship in a new patch release of the latest minor (0.5.x). Older versions
don't receive backported fixes: this SDK is pre-1.0 and is evaluated against the
live API, so upgrading is the supported path.
Scope
In scope: this SDK, and the smart402 API it calls (api.smart402.com).
Out of scope: third-party services smart402 depends on — report those to the
vendor — and volumetric denial of service; please don't load-test the production
API. Signups are open, so test against your own account rather than someone
else's.
Anything not answered here: security@smart402.com.
 There aren't any published security advisories