When Wallets Are More Than Private Key Storage: Designing Digital Asset Security for the Age of AI Transactions

As organizations and financial institutions increasingly adopt digital assets in real-world applications, wallet management is becoming far more complex than simply keeping private keys secure. This is especially true at the institutional level, where organizations may be managing high-value assets across multiple users and a large volume of transactions.

How, then, should institutional wallets be designed? How much authority should each user have? Which transactions should be automated, and which should require human oversight? More importantly, as AI agents become capable of trading, making payments, and executing on-chain transactions autonomously, how should organizations define the boundaries within which these agents can operate?

These questions were explored in the session “Wallet Control in Production: Policy Engines, Automation, and Institutional-Grade Guardrails” by Michael Lewellen, Head of Solutions Engineering at Turnkey, at REDeFiNE TOMORROW 2026. Michael shared his perspective on designing wallet infrastructure for institutions, as well as the growing role of automation and AI agents in financial infrastructure.

A Secure Wallet Is About More Than Securing the Private Key

Michael explained that one common perception of a wallet is that its primary purpose is to store private keys. In an institutional context, however, security needs to extend well beyond key storage.

This includes Authentication, which verifies who is accessing the wallet; Authorization, which determines what each user is permitted to do; and Transaction Signing, which ensures that the transaction being signed accurately reflects what the user intends to execute.

Unlike a personal wallet, where an individual owner may have full control over their assets, organizations need clearly defined roles, permissions, and policies. These controls determine who can move assets, from which wallet, to which address, and under what conditions.

Instead of Adding More Approvers, Design More Granular Permissions

One way organizations reduce risk is by requiring multiple people to approve a transaction — for example, two out of three or three out of five authorized users. But when every transaction requires multiple approvals, a security measure can quickly become an operational burden.

Michael suggested another approach: rather than adding approval steps to every transaction, organizations can use policies to define permissions based on the context of each activity.

For example, if a company regularly makes payments to the same group of vendors, their addresses can be designated as approved addresses. Relevant employees can then be authorized to transact with those addresses within predefined limits.

If a transaction exceeds a certain threshold — for example, USD 100,000 — the system could require an additional approver. Meanwhile, smaller recurring transactions could be automated under the same policy framework.

This approach means organizations do not necessarily have to choose between security and operational efficiency. Instead, they can design different levels of control based on the risk associated with each activity.

When AI Agents Can Make Financial Transactions, We Need to Define What They Must Not Be Allowed to Do

Another key topic was the use of AI agents for on-chain transactions, including payments, trading, and interactions with decentralized exchanges.

Michael noted that the principles for controlling AI agents are not fundamentally different from defining permissions for people or other software systems. Organizations need to start by determining what an agent actually needs to do and what level of risk they are prepared to accept.

For example, an AI trading agent might be authorized to buy and sell assets on a specific exchange, but it should not necessarily have permission to withdraw funds from that exchange or transfer assets to arbitrary addresses.

Policies can therefore act as guardrails around automation. Transactions requiring elevated privileges can be escalated for human review and approval.

Even as AI enables more processes to become automated, Michael emphasized that human-in-the-loop remains important, particularly when it comes to accountability and defining policies in the first place.

Lessons from Hacks: Security Needs Multiple Layers

Security incidents across the industry have also demonstrated why relying on a single layer of protection may not be enough. Attack vectors are not limited to private key theft; they can also target endpoints, software interfaces, or users themselves.

Policies can provide another layer of security.

If an organization specifies that a wallet used for daily operations can only transfer assets to approved addresses, a transaction attempting to send funds elsewhere can be blocked or require additional approval — even if a user has been deceived into approving the transaction.

Another important principle is to avoid using accounts with the highest level of privileges for daily operations. Instead, root users responsible for managing policies and permissions should be separated from users handling everyday transactions.

For Organizations Entering Digital Assets, Start by Building Internal Understanding

For financial institutions and organizations beginning their digital asset journey, Michael recommended starting with experimentation and building domain knowledge internally.

Teams should have the opportunity to work directly with the technology, understand their own risks and business flows, and then determine which infrastructure and security controls are appropriate before moving into production.

Another important consideration is choosing between non-custodial and custodial models.

A non-custodial model gives an organization greater control over its wallets, but that control comes with greater responsibility for security, access, and recovery. A custodian can take on some of those responsibilities, but this also means relying on the provider's security and availability.

As digital asset infrastructure increasingly connects people, software, and AI agents, wallet security is no longer just about asking, “Is the private key stored securely?”

It is also about designing who or what is allowed to perform which actions, under what conditions, and when additional oversight is required.

Policy engines and guardrails are therefore becoming an important part of enabling automation while maintaining the level of control and security required for institutional use.

Watch the full session: Wallet Control in Production: Policy Engines, Automation, and Institutional-Grade Guardrails

-------------------------
Source:

Adapted from the session “Wallet Control in Production: Policy Engines, Automation, and Institutional-Grade Guardrails” at REDeFiNE TOMORROW 2026.