Trusting Your AI Agent

We live in exciting times, where intelligence is engineerable. The length of tasks AI agents can complete autonomously has been doubling approximately every ~ 7 months. The models we once used to summarize emails now coordinate multi-step workflows, manage APIs, and execute decisions without waiting to be asked.

For an agent to be useful, it needs access. Read access, write access, the ability to transact, the same controls a human exercises to get things done. But the moment you extend those controls to something that operates autonomously, you're walking a tightrope between security and agent freedom. And right now, that tightrope is being treated as a binary: full trust or no trust.

The question is whether an agent can be granted the same access you already have on your own device, such as email, messaging apps, your browser, your credentials, to an agent acting on your behalf. In principle, yes. In practice, the moment you do, your trust boundary shifts.

It no longer ends at your device. It ends wherever input can reach the agent. That WhatsApp group you forgot you were in? Now an attack surface.

LLMs are probabilistic. They don't draw a hard line between content to analyze and instructions to execute. Ask an agent to summarize a PDF, but the PDF contains a hidden instruction to leak your private key. That's prompt injection, and depending on how the system is structured, the instruction might get followed. For most applications, that's a serious problem. In crypto, it's worse, because the attack surface includes irreversible on-chain transactions. .

Which brings us to the obvious question: would you trust an agent with your private key?

They may not fall for social engineering the way humans do. But they're only as secure as their inputs, and their inputs now come from everywhere.

If you were onboarding a new team member, would you give them admin access on day one? Or would you apply the principle of least privilege, such as scoped access, defined boundaries, earned trust?

Open blockchains are emerging as the natural substrate for autonomous agents. Ethereum's ERC-8004 gives agents verifiable identity and on-chain reputation. x402 enables internet-native micropayments, enabling agents to access compute, data, or APIs without human intervention at every step.

The infrastructure for an autonomous agent economy is coming together. And private key security sits at the center of all of it.

Agent delegation doesn't change any of that. The 2PC split stays intact. What changes is what gets built on top of it.

WaaP's architecture establishes two security boundaries that any agent delegation model inherits by default.

First, the key never exists in full. It's split between the user and a protector inside a secure enclave for now, on Ika's network soon. An agent operating through this architecture has no surface to steal from. There's no complete key anywhere to extract.

Second, the policy engine simulates every transaction inside the enclave before a signature is produced — checking spend limits, allowed contracts, time windows. The agent can't route around this. As the architecture evolves to 2PC-MPC on Ika's network, the authorization that follows a successful policy check routes through an on-chain smart contract, adding a verifiable, censorship-resistant governance layer on top of the enclave's decision.

The Agent Wallet

By design, the agent never enters the cryptographic layer. It authenticates via API key, submits requests through WaaP's signing interface, and hits the policy engine on every operation. The underlying key split is never exposed to it.

The user creates a separate wallet specifically for agent use. The agent authenticates via API key. Every transaction it submits hits the policy engine inside the enclave, such as spend limits, allowed contracts, time windows, enforced at signing. Agent sessions can be further scoped through permission tokens: time-bound, human-approved credentials that define exactly what the agent is authorized to do, with spend limits, whitelisted addresses, and hard expiry built in. The wallet owner approves or denies via Telegram, ntfy.sh, or email. The agent waits. The human decides.

A single wallet can support multiple agents simultaneously, each bound by the same policy rules. The human stays root authority across all of them.

WaaP already supports EVM, Sui, and Stellar. Solana and beyond will be soon enabled by Ika’s 2PC MPC, further decentralizing the signing infrastructure and making the wallet censorship-resistant by design.

An agent operating within this model inherits the principle of least privilege by default, without any additional trust assumptions. Policies can be customized per agent — spending rules, whitelisted contracts, transaction limits, conditional approvals. And because the agent transacts through WaaP's signing layer, it inherits the full security stack built for human users: blind signing protection, clickjacking resistance, and malware detection.

The guardrails don't need to be rebuilt for agents. They're already there.

The specifics of how permissions are scoped per agent and how the signing interface evolves are work in progress. The foundation, dedicated identity, policy enforcement, human override, is already built.

Here's what that looks like at 4am.

Agents can run yield strategies, arbitrage cross-chain price discrepancies, rebalance portfolios across Sui and Solana. Here's what that looks like at 4am.

ETH/USDC is moving. The funding rate on your perpetual has flipped negative and your Uniswap v3 position is out of range. By morning you've accumulated impermanent loss and missed the window.

Your agent catches it. It has a time-bounded permission token: $2,000 spend cap, whitelisted to three contracts – Uniswap v3 router, your preferred aggregator, the AAVE pool you use for short-term parking. The policy engine simulates the transaction inside the enclave, checks the contract, checks the value, confirms the time window. Everything passes. Transaction goes through.

Then the agent spots a better rate on a contract not on your whitelist. It can't execute. Policy engine blocks it, flags it for human approval. The agent waits.

You wake up, review it, confirm. Agent executes.

It didn't act beyond its remit. It held a scoped capability, and when it needed to go further, it waited. That's not a limitation. That's the architecture working.

That's delegated custody. Not handing an agent your keys and hoping for the best. Giving it a precisely bounded window to act, enforced at the signing layer, not in a terms of service.

Verified Guardrails

The agent economy isn't coming. It's being built right now, on infrastructure that was never designed with this in mind. The default assumption, that agents need full key access to be useful, is the wrong starting point.

Least privilege is the starting point, not the solution. In a world where transactions are irreversible and agents operate faster than humans can intervene, security requires layered controls and zero trust assumptions at every level of the stack.

As Shady El Damaty, co-founder of human.tech, put it: agents should be thought of as holding capabilities, not keys. The human is root authority. The agent is a co-pilot. That's not a constraint on what agents can do, it's the condition under which they can be trusted to do more.

There's a deeper layer to this. WaaP derives keys from human identity, web accounts today, biometrics later,  via vOPRF protocol, anchored to Human Network over time. This creates a verifiable link between the agent and the human principal behind it. The chain of custody is cryptographically bound to a human. The agent acts, but the identity behind every action is yours through delegated personhood.

The patterns being set today will define how the agent economy handles security for years. Getting the architecture right at the foundation matters more than building defensive rails once the horse is out of the barn.

We're building the foundation for agentic wallets. If you're building on top of it, start with the WaaP CLI, or reach out directly.