safe402

Demo

About

SAFE402 is a security verification layer for AI agents that discover and use third-party tools such as MCP servers, agent skills, APIs, plugins, x402 services, and autonomous financial tools. The core problem is that an agent may discover a tool that claims to be harmless while actually performing undeclared actions such as reading environment secrets, accessing the filesystem, interacting with a wallet, spawning processes, or sending data to an unexpected network destination. SAFE402 verifies what a tool claims it can do against what it actually does. When an agent discovers a new tool, SAFE402 can analyze its code, execute it inside an isolated sandbox with synthetic secrets, wallets, credentials, files, and RPC endpoints, and observe its real behavior. The system converts those observations into a standardized capability manifest covering network, filesystem, secrets, wallet, process, and RPC access. It then compares declared and observed capabilities, calculates a risk score, explains any mismatches, and returns a machine-readable ALLOW, REVIEW, or BLOCK decision. Verification is bound to an exact tool version and content hash so a previously verified release cannot automatically make a changed version trusted. The long-term goal is to make security verification a native part of agentic discovery: before an autonomous agent installs a tool, grants it access, pays it, or allows it to interact with a wallet, SAFE402 gives the agent verifiable evidence about what that tool actually does. The project is designed around one simple principle: AI agents should not blindly trust the tools they discover. SAFE402 gives them a security checkpoint before execution.

How it's made

SAFE402 is built as a modular security pipeline around an AI agent. A discovered tool first goes through a static scanner that looks for behaviors such as filesystem access, network requests, environment-variable access, shell or process execution, wallet or RPC interaction, suspicious dependencies, dynamic code execution, obfuscation, prompt injection, tool poisoning, and other agent-specific attack patterns. Static analysis alone is not treated as sufficient, so the tool is then executed in an isolated sandbox using controlled synthetic resources such as fake API keys, fake environment variables, decoy credential files, a fake wallet, and fake RPC endpoints. This lets SAFE402 observe whether the tool attempts actions that were never declared without exposing real user secrets. Those observations are passed into a capability engine that normalizes behavior into categories such as NETWORK READ/WRITE, FILESYSTEM READ/WRITE/EXECUTE, SECRETS ENV/CONFIG/CREDENTIALS, WALLET READ/SIGN/TRANSACT, PROCESS SPAWN/EXECUTE, and RPC READ/WRITE. A risk engine compares declared capabilities against observed capabilities and produces both a 0–100 risk score and human- and machine-readable reasons. The final result is returned through the SAFE API and SAFE MCP server as an ALLOW, REVIEW, or BLOCK decision tied to the exact tool version and content hash. For partner technologies, SAFE402 uses Chainlink CRE Confidential Workflows as the confidential verification layer for sensitive audit execution. The intent is to run adversarial tests and behavioral monitoring without exposing sensitive test fixtures, while producing a capability manifest, risk result, tool hash, and cryptographic attestation that can be verified externally. Hedera Consensus Service is used as the public verification registry. SAFE402 records compact verification data such as the tool ID, exact version, content hash, manifest hash, risk score, status, attestation hash, and timestamp. This creates an immutable audit history so agents can verify that a specific version was actually checked rather than trusting a generic “verified” label. The Graph is used as the security-intelligence layer. It indexes relationships between tools, versions, developers, audits, capabilities, attestations, incidents, and reputation so agents can query questions such as whether a previous version failed an audit, whether a developer has shipped tools that accessed wallet functionality, or which verified tools have no filesystem or wallet capabilities. x402 is used so the AI agent itself can pay for verification. Instead of a human checkout flow, SAFE402 can return a 402 Payment Required response, allow the agent to pay automatically, and then continue the verification workflow. World AgentKit is used for optional human-backed auditor or agent identity, allowing SAFE402 to distinguish anonymous automated participants from agents operating on behalf of a unique human. One of the more notable parts of the project is the adversarial sandbox design. Rather than only scanning code for suspicious strings, SAFE402 deliberately gives the tool believable but fake secrets, wallets, sensitive files, and credentials and watches what it tries to access or exfiltrate. This makes the security decision based on observed behavior, not just what the tool says about itself.