The Agent Can Move the Money. It Still Does Not Hold the Keys.

Everyone covering this week's BNB Chain update is going to lead with the part that is easiest to explain: agents built on BNB Agent Studio can now get paid, not just spend. That is real, and it is the headline BNB Chain itself chose. It is also not the part that holds up under a second look.

The part worth sitting with shipped five days later, on 18 August 2026, when BNB Chain added Altana as a wallet option for agents. Altana is not a payments feature. It is an answer to a narrower and harder question: once a builder lets an autonomous agent hold a wallet, how much of that wallet's authority does the agent actually get to carry.

Two dates, one development

BNB Agent Studio v2 launched on 13 August 2026 under the tagline Your Agents, Your Rules. The initial release closed a gap in the platform's first version, launched in July 2026, in which agents could spend but not earn: v2 lets an agent be hired and paid directly, with funds settling through a receiving interface that completes an existing commerce flow end to end. It also added a TypeScript SDK alongside the platform's Python option and a Paymaster that covers testnet gas, removing a manual funding step. None of that is the subject of this piece. It is the context BNB Chain shipped the actual subject inside.

On 18 August 2026, BNB Chain announced that Altana had joined BNB Agent Studio v2 as a second wallet option, distributed through a Chainwire press release and covered the same day by outlets including CryptoBriefing and Bitcoin World. That is the development this record is about, and it is one development, not several. The 13 August platform release, the 18 August Altana integration, and the wire distribution of that integration are the same underlying vendor move described from different angles, not independent pieces of evidence that a wallet architecture exists.

What Altana actually is

Altana, previously named Functor Network, is described as a self custodial Smart Agentic Wallet. Self custodial is doing real work in that phrase: the builder who sets up the wallet retains the underlying private keys. The agent is never handed a copy of them. What the agent gets instead is a session key, a credential scoped to a specific set of allowed actions rather than to the wallet's full authority.

Reporting describes that session as bounded by three things set by the owner in advance: a spending limit, an allowlist of contracts or destinations the agent may interact with, and a time bound after which the session expires on its own. Altana's architecture is described as using EIP-7702-compatible session keys, an Ethereum standard for delegating scoped execution authority without transferring account ownership, and the resulting permissions are said to live in what Altana calls an on chain Keystore, described as a neutral, publicly verifiable registry. That registry is the mechanism behind a claim worth taking seriously on its own terms: that what an agent is currently authorized to do is something any outside party, not just the agent's own operator, can check by reading the chain rather than by trusting a dashboard or an operator's word.

Revocation is described the same way. Ending a session is reported as a single on chain transaction that takes effect immediately, without rotating the underlying keys and without moving the funds themselves. That is a meaningfully different shape of control than disabling an API credential and hoping nothing cached it: the authority is described as recorded and checked in the same place, so removing it does not depend on every downstream system noticing the change.

Where each control actually sits

It matters, precisely, which surface each of these properties belongs to, because the temptation is to describe all of it as something BNB Chain built. It is not. The spending limit, the allowlist, the time bound, the on chain Keystore and the one transaction revocation are properties of Altana, the third party wallet BNB Agent Studio now offers as an option. BNB Chain's own contribution at the platform layer is narrower: it is exposing Altana as a choice alongside the platform's existing wallet option, Trust Wallet AgentKit, and letting a builder pick the authority model that fits the agent they are building. The platform did not itself invent bounded session keys. It integrated a wallet that already implements them and put the choice in front of every builder using the studio.

That distinction is not pedantry. An allowlist enforced by Altana's session key mechanism is a property of every agent that uses Altana, regardless of which platform embeds it. A builder using Altana outside BNB Agent Studio entirely would, on this description, get the same bound. The platform integration is what makes that option available inside BNB Chain's tooling by default. It is not the thing doing the bounding.

The claim that matters most, stated at its actual size

The central claim in BNB Chain's own framing is that the agent cannot widen its own permissions because it does not possess the authority required to do so. That sentence deserves to be preserved exactly as scoped, because it is easy to round up into something larger than what is being described.

What is being claimed is structural: creating a session, extending its budget, or replacing it with a broader one is an action that belongs to the owner's side of the system, exercised through the owner's retained keys, not an action exposed to the agent at all. On that description, an agent that is manipulated, through a bad instruction, a poisoned tool response or anything else, into trying to spend more than its session allows does not succeed by virtue of being clever about it. It fails because the wider authority to say yes to a bigger session simply is not a thing the agent holds, in the same sense that a person cannot approve their own passport application by asking nicely.

What is not being claimed, and what nothing in the corroborated reporting supports, is that Altana's implementation has been independently audited, that its smart contracts have been proven free of the kind of exploit that has emptied other on chain wallets before, or that the session key mechanism itself cannot be defeated by a flaw in its own code rather than by an agent that simply asks for more. Moona Intelligence found no independent security audit, no formal verification result and no third party enforcement testing of Altana's session key mechanism in the material reviewed for this piece. The claim survives at the level BNB Chain states it: a boundary on what authority the agent is handed, not a proven guarantee about what a sufficiently motivated attacker could still do to the system that enforces that boundary.

Altana and Trust Wallet AgentKit are answers to different questions

BNB Agent Studio now offers two wallet options, and the reporting is consistent that they are positioned for different jobs rather than as a secure choice and a lesser one. Trust Wallet AgentKit, TWAK, is described as the option for an agent that needs to sign continuously, without a person or a session boundary interrupting it, the shape of authority a genuinely autonomous, always on agent needs. Altana is described as the option for an agent whose authority should stay visibly bounded: a yield agent that harvests and restakes returns without ever holding the ability to withdraw principal, or a lending agent that can top up collateral without the ability to pull it back out.

Reading that as TWAK being insecure and Altana being the safe version misreads what BNB Chain is doing. It is exposing two different authority models and letting the builder match the model to how much autonomy a given agent actually needs. An agent that has to act every few seconds without waiting on a session refresh has a real reason to want continuous signing. An agent managing a user's principal has a real reason to want a boundary that survives the agent being wrong. Moona Intelligence is not aware of evidence that either architecture is categorically more or less exploitable than the other in practice; what exists is two different tradeoffs, offered side by side, for two different jobs.

This is not the AWS and Solv Labs question, and not the Alipay question

Moona Intelligence has already covered two adjacent shapes of this problem, and it is worth being precise about why this is a third one rather than a restatement of either.

When AWS and Solv Labs published a governed payments workflow on Amazon Bedrock AgentCore, the question was whether an organization could later prove why one specific payment, already inside an authorized envelope, was allowed to settle. Solv Labs' ORACLE engine evaluates a proposed transaction against policy at the moment it is proposed and binds a signed record to that specific evaluation. That is a check performed on each transaction as it happens. Altana does not describe anything like it. Nothing in the reporting suggests Altana evaluates the wisdom or the destination legitimacy of an individual transaction the way ORACLE does. What Altana describes is set once, before any transaction: the shape of what the agent is allowed to do at all, for the life of the session. AgentCore's own payment sessions, which carry a spending limit and an expiry enforced outside the agent's code, are the closer analogue, and the OpenClaw session AWS described in a later post, where a human creates a session the runtime cannot extend or replace, is close to the pattern Altana describes for BNB Chain. The evidence layer that answers why a specific payment cleared is a separate question this record does not attempt to answer for Altana, because nothing in the corroborated material claims Altana produces one.

When Alipay launched its agentic commerce platform and the AHA protocol, the question was how far a single human's original authorization travels once several separate agents, from different companies, hand a request forward hop by hop before a payment executes. That is a propagation problem: authority crossing organizational boundaries between parties that share no operator. Altana describes something structurally simpler. One owner, one wallet, one agent, one session, bounded in advance. There is no chain of agents in the material reviewed here, and no claim that Altana's session keys solve, or even address, what happens to a bound when a request passes through a second or third agent outside the owner's control. That remains, on the evidence available, Alipay's problem to answer, not Altana's.

What Altana actually contributes to this publication's running thread is narrower than either: a description of pre delegated, bounded authority, set once by an owner who retains the underlying keys, checked from outside the agent through a public on chain record, and revocable without touching the wallet's funds or its keys. Moona Intelligence has not previously covered a wallet architecture built specifically around that combination, and none of the existing records claim it.

What is established, and what is not

It is worth separating four different things this record could have claimed and did not. Altana's design, as described by BNB Chain and corroborated across independent reporting, is documented: scoped session keys, an on chain Keystore, spending limits, allowlists, time bounds and one transaction revocation are all specified with consistent detail across multiple sources. The integration is a publicly available implementation: Altana is live inside BNB Agent Studio v2 today, a builder can select it, and existing agents on the platform were reported to continue running without migration through the change. What is not established here is demonstrated enforcement, meaning independent testing of whether the session key boundary holds under adversarial conditions, and production adoption specific to Altana, meaning how many of BNB Chain's agents are actually using it rather than the platform's other wallet option. BNB Chain has reported that the platform as a whole hosts more registered agents than any comparable network, a figure that predates Altana's addition and describes the whole platform, not the fraction of it running on this specific wallet. Treating platform scale as evidence of this specific control being exercised at scale would overstate what has actually been shown.

Where the actual test sits

The question this publication keeps returning to, across payments, propagation and now wallets, is not whether an agent can be given the ability to act on money. That question is already settled across enough vendors that it is no longer interesting on its own. The question is whether the organization or person who owns the money can hand an agent the ability to act on it without also handing over the ability to decide, later, that the agent should be allowed to act on more of it. Altana's design, as BNB Chain describes it, answers that question by trying to make the second ability something the agent structurally never held in the first place. Whether that design survives contact with a genuinely adversarial agent runtime is a claim nobody, including BNB Chain, has yet published evidence for. What has shipped is the boundary. What remains unverified is how it holds.