WAIaaS brings 684 tests to self-hosted AI wallet infrastructure

The WAIaaS project has released an open-source, self-hosted Wallet-as-a-Service designed specifically for AI agents, backed by a suite of over 684 test files. Published on September 28, 2026, this infrastructure allows developers to run wallet operations locally using Docker, ensuring private keys never leave their own hardware. The release emphasizes strict policy enforcement and comprehensive testing to mitigate the financial risks associated with automated agent transactions.

What happened

WAIaaS is a 15-package monorepo that provides a complete wallet infrastructure for AI agents without relying on third-party custody. The core of the system is a daemon that runs in a single Docker container, binding to localhost by default to prevent external exposure. This setup includes support for auto-provisioning, Docker Secrets for secure credential management, and automatic updates via Watchtower. The project aims to remove the friction typically associated with self-hosting crypto infrastructure by offering a quick start process that requires only three commands to clone the repository and launch the service.

The software architecture separates concerns through a seven-stage transaction pipeline: validate, auth, policy, wait, execute, and confirm. Each stage is covered by the project’s extensive test suite, which spans packages for actions, adapters, admin interfaces, command-line tools, and software development kits. The daemon exposes 39 REST API route modules that handle wallet creation, session management, decentralized finance actions, and non-fungible token transfers. By running this stack locally, users retain full control over their keys and avoid the rate limits or opacity of hosted services.

Security is enforced through a three-layer authentication model and a robust policy engine. The system uses master authentication for high-level operations, owner authentication for human approval, and session authentication for the AI agent itself. This separation ensures that a compromised agent session cannot alter fundamental policies or create new wallets. The policy engine supports 21 different policy types across four security tiers, allowing users to define strict spending limits, delay thresholds, and approval requirements for various transaction types.

Key details

• The project includes over 684 test files across 15 packages to ensure reliability in financial operations.
• The daemon runs as a non-root user with UID 1001 and binds to 127.0.0.1:3100 by default.
• Transactions pass through a seven-stage pipeline including validation, policy checks, and execution confirmation.
• Three authentication methods are supported: masterAuth for system ops, ownerAuth for human approval, and sessionAuth for agents.
• The policy engine features 21 policy types with instant, notify, delay, and approval security tiers.
• Integration with AI agents is facilitated via Model Context Protocol servers and TypeScript or Python SDKs.

Background

Self-hosting wallet infrastructure has historically been complex, often requiring significant operational overhead similar to managing a private email server. Most developers previously relied on hosted services for convenience, accepting custody risks and potential vendor lock-in. WAIaaS addresses this by containerizing the entire wallet service, making it accessible to teams with basic Docker knowledge. The use of Docker Secrets and auto-provisioning further simplifies secure deployment on virtual private servers or homelab environments.

The Model Context Protocol (MCP) is a standard that allows AI assistants to connect to local data and tools. By providing an MCP server, WAIaaS enables AI agents like Claude Desktop to interact with the local wallet daemon directly. This means the agent can query balances or propose transactions without sending sensitive data to external APIs. The dry-run feature allows users to simulate transactions against the local policy engine before executing them on the blockchain, providing a safety net for automated actions.

Why it matters

For teams running AI agents that handle financial assets, the risk of bugs is not merely theoretical but directly tied to monetary loss. An off-by-one error in a spending limit or a race condition in transaction execution can result in irreversible fund drainage. The 684+ test files in WAIaaS serve as an auditability signal, allowing engineers to verify that the code behaves as expected before deploying it. This level of transparency is critical for organizations that require certainty about how their software handles private keys and transaction approvals.

The policy engine’s default-deny posture ensures that transactions are blocked unless explicitly allowed by configured rules. This fail-closed approach is essential for autonomous agents that might otherwise execute unintended actions. By defining specific limits for perpetual futures leverage, lending positions, or token transfers, teams can constrain their agent’s behavior within safe boundaries. The ability to simulate these policies locally before live execution adds a layer of confidence that hosted solutions often lack.

Furthermore, the separation of authentication layers protects the system from partial compromises. If an AI agent’s session token is exposed, the attacker cannot change system-wide policies or create new wallets because those actions require master authentication. Similarly, the owner can intervene via signature-based approval even if other credentials are compromised. This defense-in-depth strategy is vital for maintaining sovereignty over digital assets in an automated environment.

What you can do

• Clone the WAIaaS repository and start the daemon using Docker Compose to evaluate the local setup.
• Configure spending limit policies with instant, notify, and delay tiers to control agent transaction sizes.
• Use the dry-run API endpoint to simulate transactions and verify policy enforcement before execution.
• Integrate the MCP server with your AI agent framework to enable local wallet interactions without external APIs.
• Implement Docker Secrets for production deployments to keep master passwords out of environment variables.
• Review the 684+ test files to understand the expected behavior of the policy engine and transaction pipeline.