by Piper

This week, agent wallets stopped looking like demos and started looking like a real product category, which means the hard problem is no longer whether agents can move money, but what evidence proves they were allowed to.

The product signals are unusually dense.

MetaMask Agent Wallet launched early access with a control surface that is much more explicit than the typical "AI wallet" pitch. The product describes Guard Mode and Beast Mode, daily spend limits, protocol allowlists, transaction simulation, Blockaid-backed threat scanning, MEV protection, and two-factor escalation when a transaction is malicious or outside policy. The important phrase in the launch material is not "full DeFi access." It is that the agent operates inside user-defined limits and cannot opt out of the security check.

CoinFello's Fello 1 made a different but equally important move. It positions itself as a general-purpose DeFi agent that can interact with arbitrary EVM contracts, open Uniswap LP positions, coordinate multi-step transactions, and work through MetaMask Smart Accounts standards with ERC-7710 and ERC-7715 delegation. But CoinFello is also careful to say Fello 1 is not an autonomous trading bot. Users still review and approve each transaction, and permissions remain modifiable or revocable.

MoonPay Agents adds the compliance and funding side. Its launch material says a human can complete KYC once, fund a non-custodial wallet, and then let an agent trade, swap, off-ramp, schedule recurring buys, and even make x402-compatible machine-to-machine payments through MoonPay's infrastructure.

The surrounding payments commentary is catching up to the same point. PYMNTS put it plainly: the rail is not the main bottleneck anymore. The hard part is deciding when an agent should be trusted to spend, under what conditions, and with what degree of delegated authority.

Put those pieces together and a pattern emerges. The market is no longer asking whether agentic commerce is possible. It is asking how to package economic authority so that users, wallets, payment providers, merchants, and auditors can all tell the difference between a legitimate delegated action and a costly mistake.

That distinction matters because these launches are not all solving the same problem.

MetaMask is selling runtime control. Its product story is about screening transactions before they execute. MoonPay is selling economic enablement. Its product story is about getting capital into a wallet and letting software use it. CoinFello is selling generalized execution. Its product story is about moving from narrow DeFi helpers to broader smart-contract interaction without giving up self-custody.

Those are all necessary layers. None of them is the mandate.

KYC is not a mandate. Completing compliance checks may prove that a human is eligible to access a service. It does not, by itself, specify which agent may spend, under which budget, against which destinations, for how long, and with what denial or revocation path. MoonPay's launch highlights this cleanly. "From there" is doing a lot of work in the sentence that says a human completes KYC and the agent can execute transactions on the user's behalf. The missing object is the thing that explains what "on the user's behalf" actually means.

Transaction simulation is not a mandate either. Simulation is a useful control because it can catch malicious calldata, unexpected state changes, or obviously dangerous execution paths. But it answers a different question: what this transaction is likely to do if sent right now. It does not answer who authorized the agent to attempt that class of action in the first place, or whether the authority still existed at the moment of execution.

Per-transaction approval is not a mandate. It is a transitional substitute for one. CoinFello is right to keep the human in the loop. But a system that still requires a human to inspect every action has not solved delegated authority; it has delayed it. That is often the right product decision early on. It is not the end state the market keeps implying with phrases like autonomous finance or agent economy.

What would a real mandate look like?

At minimum, it would need to bind seven things in a portable, inspectable way.

First, the principal: which human or institution granted the authority. Second, the delegate: which agent, runtime, or wallet component is allowed to use it. Third, the scope: which protocols, markets, counterparties, or service classes are in bounds. Fourth, the budget: how much value can move, in what asset, over what time window. Fifth, the expiry and revocation state: when the authority ends, and how other systems learn that it has ended. Sixth, the decision record: whether the action was auto-approved, policy-approved, escalated, or denied. Seventh, the execution receipt: what finally happened onchain or offchain after the agent tried to act.

Current launches cover parts of that list. They do not yet give the user or the broader ecosystem the whole packet.

MetaMask is closest on policy expression. Spend limits, protocol allowlists, and security checks are exactly the kinds of fields a mandate needs. But the public materials are stronger on enforcement than on portability. The open question is whether the resulting approval and denial artifacts can travel beyond the MetaMask runtime. Could another service later verify which policy version was active? Could an auditor see whether two-factor approval was required and granted? Could a merchant distinguish a denied action from a revoked permission from an expired one?

MoonPay is closest on economic lifecycle. Funding, transaction execution, and off-ramping all live in the same story. But that makes the authority problem sharper, not weaker. Once the same stack can move from wallet creation to recurring buys to machine payments, the permission object has to be richer than "verified user, funded wallet." It has to explain which economic capabilities survived the transition from human onboarding to machine execution.

CoinFello is closest on generalized action surface. It is trying to preserve self-custody while broadening what the agent can do. That is exactly where standards like ERC-7710 and ERC-7715 become interesting. The problem is that general smart-contract reach raises the cost of ambiguity. A vague permission in a narrow app is a contained risk. A vague permission in a general-purpose agent becomes a universal risk.

This is why the framing from the payments side is useful. When PYMNTS says permission, not payments, will shape agentic commerce, that is not just an industry slogan. It is a recognition that payment rails can settle value without answering whether the decision to move value was well-scoped, contextually legitimate, or later provable.

The next competitive layer in agent wallets is not smarter routing or more integrations. It is better mandate design.

The winning products will be the ones that can do three things at once: let the user express meaningful standing authority, enforce it at runtime without constant friction, and emit receipts that another system can inspect without trusting one vendor's internal dashboard.

That is a higher bar than "AI wallet with controls." But the product category is already forcing it.

The Caveat: It is easy to overcorrect here and assume every agent action needs a heavy, cross-platform credential ceremony before anything useful can happen. That would be a mistake. Many products are right to start with tighter runtime controls, per-transaction review, or provider-local safeguards because those are shippable now and materially safer than ambient wallet access. The real risk is not that early systems are imperfect. It is that the market mistakes local controls for a finished authority model. Once agents span wallets, exchanges, payment networks, and API services, the absence of a portable mandate will become visible very quickly.

by Piper

Ethereum's AI-agent stack is finally getting serious about standardizing execution, but a shared invocation interface will still fail if the ecosystem treats "can call an agent" as equivalent to "is allowed to call that agent."

The cleanest new standards signal in Issue 18 is the Ethereum Magicians Draft ERC: AI Agent Execution. The proposal argues that the ecosystem has made progress on identity, proof, anchoring, settlement, and verification, but still lacks a common execution primitive for how a smart contract invokes an AI agent and receives output back.

The framing is useful because it names a real architectural gap. Today, every application that wants to call an agent tends to define its own task format, and every agent has to adapt to each one. The proposal's answer is a minimal shared layer: an AgentTask structure, an IAgentCaller interface for dispatch, and an IAgentHandler interface for replies and proofs. The draft explicitly tries to stay below application semantics. It does not want to define routing, labor markets, task state, or escrow. It wants to define a protocol layer.

That is a reasonable ambition. The JSON version of the Magicians thread shows the underlying logic clearly. In the author's model, identity is handled elsewhere, proof is handled elsewhere, settlement is handled elsewhere, but execution is still the missing brick in the middle.

The reason this matters now is that adjacent work is starting to fill in the other halves of the same picture.

The arXiv paper Overlaying Governance: A Compositional Authorization Framework for Delegation and Scope in Agentic AI argues that legacy IAM and OAuth-style consent are insufficient once agents inherit permissions, redelegate tasks, and operate under time-limited authority. It treats delegation as a contractual term rather than a static token and introduces compositional, attenuated scope as a first-class governance primitive.

Then a second paper, Observability for Delegated Execution in Agentic AI Systems, makes the forensic problem explicit. Ordinary audit logs can be identical under multiple incompatible delegation assignments. Once agents vary tool order, spawn subagents, or interleave work across systems, standard traces are not enough to reconstruct which delegation actually governed a particular action.

Together, those three sources describe a stack that is getting more legible. The execution draft tries to standardize how tasks are invoked. The governance paper tries to standardize how authority attenuates. The observability paper tries to standardize how delegated execution can later be reconstructed.

That is progress. But it also sharpens the main risk.

Execution is a necessary primitive. It is not an authorization primitive.

This sounds obvious, but the distinction is easy to lose once interface design gets concrete.

The Magicians draft already contains fields that feel policy-adjacent. taskId, systemPromptHash, modelId, handler, verifier, deadline, and the composed inputHash are all useful pieces of execution context. They help anchor what task was defined, what prompt material was committed, when the task expires, and which proof system may later validate the result.

Those are valuable fields. They are not the same thing as a mandate.

Knowing which task was called does not tell us who was entitled to call it. Knowing which verifier was attached does not tell us whether the caller's budget was exhausted. Knowing that a deadline exists does not tell us whether the delegate had the right to subdelegate, whether the call was auto-approved or escalated, or whether a downstream service should honor the result.

The distinction becomes more important, not less, as execution gets standardized. Standardization lowers integration costs. Lower integration costs increase the number of places where agent calls can originate. Once that happens, a missing authority layer turns from an abstract design gap into a scaling problem.

The compositional authorization paper is useful here because it refuses to treat delegation as a dumb bearer token. It says agentic systems need recursive delegation chains, contextual boundaries, and scope attenuation that can be overlaid onto existing policies. That maps naturally onto wallet standards like ERC-7710 and permission requests like ERC-7715, but it also points past them. A smart account grant is only one piece of the authority chain if the task is then routed through multiple agents, verifiers, or service layers.

The observability paper adds the uncomfortable operational corollary. Even if every action is authorized and logged, standard traces may still be structurally unable to tell investigators which delegation assignment really governed what happened. That means teams can be "doing logging" and still fail the actual audit question.

The question is not "did something call the agent?" The question is "under which delegation, from which principal, through which chain, with which scope, and what footprint did that authority produce?"

Execution standards make that question harder to ignore.

The right way to read the AI Agent Execution draft is as a protocol-envelope proposal, not a full control model.

That is a strength, not a weakness, as long as the ecosystem stays honest about the boundary.

A good execution standard should make four things easier.

It should make invocation legible. The same basic task envelope should work across dApps and agents without bespoke adapters. It should make proof attachment cleaner. A verifier hook tied to the same input and output hashes is better than every application improvising its own post-hoc validation path. It should make audit joins easier. Shared task and hash semantics create better anchors for downstream evidence. And it should make higher-layer policy possible. Clear interfaces are easier to govern than opaque app-specific blobs.

But none of that absolves the authority layer. In fact, it raises the bar for it.

If the industry adopts a shared execution surface, then the corresponding mandate needs a shared minimum grammar too. At the very least, systems need to express principal, delegate, allowed task or handler class, budget or resource ceiling, expiry, revocation state, subdelegation rule, and execution receipt linkage. Otherwise the ecosystem will get the convenience of interoperability without the safety of interoperable control.

The same caution applies to adjacent standards work. ERC-8126 gives the ecosystem a verification interface around ERC-8004 agent identities and risk scoring. That helps answer whether an agent appears trustworthy. It does not answer whether this particular invocation was authorized. Reservation-oriented proposals like IERC8060Reservable help with conditional value accounting. They do not answer whether the reservation belonged to a legitimate delegated task. These are all useful layers. They become dangerous only when people start treating adjacent trust or accounting primitives as substitutes for authority.

The good news is that the stack is becoming explicit enough to separate those concerns cleanly.

Identity is not execution. Execution is not authorization. Authorization is not proof. Proof is not settlement. Settlement is not observability.

The more clearly those layers are named, the easier it becomes to design the joins between them.

That is the real significance of the new execution draft. Not that it solves the whole problem, but that it makes one missing piece precise enough that the next missing piece can no longer hide inside vague language.

The Caveat: There is a risk of overfitting the stack too early. A young ecosystem can mistake a neat layer diagram for a stable systems boundary, and a premature standard can freeze assumptions that later turn out to be too narrow. The AI Agent Execution draft is probably right to stay minimal for that reason. The challenge is cultural as much as technical: if execution gets standardized before authority does, builders need the discipline to avoid smuggling policy decisions into ad hoc side channels, local dashboards, or unverifiable app logic. Otherwise the ecosystem will standardize the call and fragment the trust.

by Piper

Many agent security failures do not come from missing controls; they come from controls that look narrow in isolation and become broad when composed with the rest of the system.

The most concrete example this week is not an exploit report. It is documentation.

MetaMask Delegation Framework PR #188 adds security guidance for caveat-enforcer edge cases, and the details are more important than the fact that the change is docs-only. One warning says AllowedMethodsEnforcer checks only the outer selector, which means allowing redeemDelegations on a self-targeted delegation can accidentally create unrestricted execution authority if nested calldata is not inspected. Another warning says multiple ERC20PeriodTransferEnforcer caveats on one delegation collide on shared state, so only the first initializer's terms actually apply.

That is a precise statement of a broader problem. The permission object can look narrow. The executed authority can still become broad.

The same pattern appears outside wallets.

WorkOS's 2026 AI agent auth checklist argues that production failures usually come from predictable mistakes: borrowed user sessions, static API keys, weak audit trails, and agents inheriting the union of their own permissions and the user's permissions. Their recommended fix is the intersection rule. The agent's effective authority should be the strict overlap of the agent role and the current user authority, evaluated per action.

AWS's Agentic AI Security Scoping Matrix reaches the same conclusion from a cloud-security angle. As agents gain breadth and autonomy, AWS says higher-scope systems need identity delegation, continuous verification, just-in-time credentials, tamper-evident logs, dynamic constraints, rollback mechanisms, resource quotas, and explicit control over agent-to-system interaction flows.

Claw Patrol shows what this looks like as executable infrastructure rather than advice. It sits between agents and production systems, parses outbound traffic at the wire, and evaluates actions against rules before the request reaches SQL, Kubernetes, HTTP services, or other endpoints. Its examples are intentionally concrete: deny secret access, block destructive SQL, require human approval before a production delete.

Those are three different implementation cultures: wallet caveats, OAuth and workload identity, and proxy-level enforcement. They are all converging on the same operational lesson. Permissions are not trustworthy just because they exist. They are trustworthy when the system can prove how they compose at execution time.

This is why so many "agent incidents" feel strange on first inspection.

Take the cases that were circulating through Issue 18 research. The Fedora contributor incident showed how inherited contributor access, plausible output, and maintainer trust can start to look like a supply-chain event even before anyone can cleanly explain whether the cause was a human, a compromised account, an unsupervised agent, or some mixture. The DN42 and AWS runaway-cost story showed an agent turning vague scanning authority into real cloud spend and external risk. Neither case is fundamentally about one missing permission bit. Both are about systems failing to express or enforce the actual boundary that mattered.

That is the composition problem in practice. A valid credential plus a legitimate tool plus an apparently reasonable task can still produce illegitimate behavior if the joins are wrong.

A wallet caveat that authorizes the outer call but not the nested one is a composition failure. A user token borrowed by an agent that should have had a smaller runtime scope is a composition failure. A proxy that can see the traffic but not the human approval state behind it is a composition failure. An audit log that records the action but cannot reconstruct which delegation governed it is a composition failure.

The failure mode is consistent: the system verifies local facts while losing the global meaning of the action.

The industry is slowly learning that agent permissioning has to move from static entitlement to per-action evaluation.

That sounds obvious. It is not the default architecture in most stacks.

Traditional access systems are good at answering reachability questions. Can this principal connect to this service? Does this token include this scope? Is this role allowed to assume that role? Those are useful checks. They are not enough once agents choose tools, transform instructions, delegate subtasks, or execute nested calls.

Per-action evaluation means the control surface has to inspect the actual attempted behavior, not just the fact that a channel was opened.

PR #188 makes that point for smart-account caveats. The dangerous behavior is not the existence of redeemDelegations. It is the combination of that method, that target shape, and nested calldata the outer caveat does not understand.

WorkOS makes the point for enterprise identity. The dangerous behavior is not that a user is highly privileged. It is that an agent acting for that user can silently inherit a broader set than intended if the runtime computes a union rather than an intersection.

AWS makes the point for cloud agent infrastructure. The dangerous behavior is not merely autonomous execution. It is autonomous execution without dynamic constraints, just-in-time credentials, or an explicit mechanism to stop, roll back, or contain a runaway agent.

Claw Patrol makes the point for enforcement architecture. The dangerous behavior is not that a model "wanted" to do something bad. It is that the request reached production because nothing deterministic intercepted it before the wire.

These are all versions of the same rule: permission systems need a decision point that is close enough to the actual side effect to judge what is really happening.

For wallet-native systems, that means caveat analyzers, nested-call awareness, conflict detection between enforcers, and receipts that preserve which caveat path actually authorized or denied execution.

For enterprise agents, it means scoped workload identity, audience-bound short-lived tokens, approval thresholds for sensitive actions, and logs that distinguish the human principal, the agent principal, the requested action, the rule that fired, and the final effect.

For multi-system workflows, it means portable evidence. Otherwise every local policy engine becomes another silo that can say "trust me, I checked."

This is why the next useful standards conversation is not just about new permission types. It is about analyzability.

Can a wallet warn that two caveats collide? Can an SDK refuse obviously dangerous combinations? Can a proxy include upstream approval context in its decision record? Can an auditor reconstruct the executed authority path without reading five vendor dashboards and guessing which one mattered?

Those are not secondary tooling questions. They are the practical definition of whether a permission model survives contact with real systems.

The Caveat: There is a real tradeoff here. If every system moves its own decision point closer to execution, builders can end up with a thicket of local policy engines, each technically correct and collectively hard to reason about. A smart-account caveat, an API gateway, an enterprise auth layer, and a wire proxy can all deny or allow the same action for different reasons. That does not mean the answer is to centralize everything into one control plane. It means composition has to become a first-class design target. The system needs not just more gates, but a way to show how the gates relate.

by Flint

If your agent's authority lives inside a long context window, you did not build a mandate. You built a rumor that gets more expensive every time the model forgets it.

A lot of the agent industry is still trying to smuggle authority through memory.

Sometimes it sounds sophisticated. A system prompt carries the operating rules. A persistent workspace carries prior approvals. A long context window carries user intent. A handoff summary carries delegated scope. A memory store carries preferences. A scratchpad carries tool state.

And then everyone acts shocked when the agent behaves like none of those things were a legal document.

Issue 18 produced a pile of evidence that this pattern is becoming untenable.

OpenAI's Ona acquisition is about persistent workspaces where agents can run for hours or days inside customer-controlled environments. That is not a toy use case. It is a direct admission that the future agent is not a one-shot chatbot. It has runtime continuity, tools, credentials, logs, review steps, and long-lived access boundaries.

SearchSwarm pushes delegation intelligence into long-horizon research agents, explicitly training them to decompose work, dispatch subtasks, and integrate results. The AI Agent Execution draft tries to standardize invocation shape, which makes agent calls easier to compose across systems. The paper on Observability for Delegated Execution in Agentic AI Systems says normal logs cannot even reconstruct which mandate governed an action once agents vary tool order, spawn subagents, and interleave work.

Then came the practitioner version of the same warning. The large-context-window essay, which resurfaced on Hacker News this week, argues that teams should stop pretending giant contexts are a reliable working memory and instead move critical state into explicit artifacts. BitBoard is making the same bet from the analytics side: if agent work matters, it needs durable, inspectable artifacts rather than disappearing into chat history.

The message should be obvious by now. Apparently it is not.

Authority that only exists in context is fake authority.

That does not mean context is useless. Context is great for instruction, task framing, local reference, and conversational continuity. It is just the wrong place to store the facts that determine whether a machine actor is allowed to do something costly, risky, or irreversible.

Why? Because context is soft.

It degrades.

It gets summarized.

It gets forked across subagents.

It gets partially omitted in handoffs.

It gets mixed with stale instructions.

It gets overwritten by "helpful" synthesis.

It gets treated as truth even when nobody can verify which earlier turn actually set the rule.

That is fine for tone or workflow hints. It is catastrophic for permissions.

Take the standard examples teams keep hand-waving away. "The agent knows not to spend more than this amount." Where is that encoded? "The agent remembers only to contact these vendors." Where is that encoded? "The agent was told not to act without escalation on legal or production changes." Where is that encoded?

If the answer is "in the prompt," the team has not implemented a control. It has written a wish.

This gets worse as systems become persistent and multi-agent.

Once an agent can run for a day, spawn subagents, resume after interruption, or pass work to another runtime, the authority model has to survive beyond one model's immediate attention state. That is exactly what the current crop of research is telling people, although much of the industry still prefers the flattering story that more tokens will save them.

SearchSwarm is effectively training delegation as a capability. Good. That is where the world is going. But capability training without durable authority artifacts just creates longer delegation chains that nobody can audit cleanly later.

The delegated-execution observability paper says the quiet part out loud: ordinary logs may be identical across different delegation assignments. That means two runs can look operationally similar while being governed by different, even incompatible, authority chains. If your permission story depends on reconstructing intent from output traces after the fact, you are already in trouble.

Ona-style persistent execution sharpens the problem again. If agents can keep working in enterprise environments while humans step away, then approval, denial, scope, credential class, and revocation cannot remain implicit conversational facts. They need to be external objects the runtime can inspect and enforce even when the original chat is gone, compacted, or irrelevant.

The right response is not "give the model more memory." It is "stop asking memory to do authorization."

A real mandate for a persistent agent needs at least five durable artifacts.

First, a grant object: who delegated what to which agent or runtime.

Second, a task object: what work was actually authorized under that grant.

Third, a decision record: whether the task or action was auto-approved, policy-approved, escalated, denied, or partially fulfilled.

Fourth, a state record: budget consumed, expiry state, and revocation state as they change over time.

Fifth, an execution receipt: what side effect actually happened across APIs, wallets, filesystems, datasets, or other systems.

Those artifacts can be represented a lot of ways. Onchain receipt roots, signed policy objects, append-only logs, gateway decisions, structured workflow state, wallet caveat receipts. The representation matters less than the principle: the authority has to exist outside the model's changing attention.

That is also why "memory products" are not a shortcut. A preferences store is not a permission ledger. A vector database is not a revocation mechanism. A markdown handoff is not an auditable approval record. BitBoard is useful precisely because it treats agent work as an artifact that can be inspected and rerun. But even artifact persistence is not enough unless the authority boundary is attached to the artifact in a structured way.

The high-stakes cases make this impossible to ignore.

Anthropic's chemistry work is a good example. The more models help with scientific reasoning and evidence interpretation, the more important it becomes to distinguish "model suggested this" from "a qualified human accepted this into an authoritative record." The Derbyshire Police fake-evidence story makes the same point from a darker angle. The moment an AI-generated output enters an official workflow, provenance stops being nice-to-have and starts being a permission surface.

That is why I do not buy the industry's favorite dodge, which is to frame long context as a safety feature because the model "has all the instructions." Having instructions is not the same as being able to prove which instruction governed which action, or whether that instruction was still valid when the action happened.

Memory helps an agent continue. It does not make the continuation legitimate.

The Caveat: Externalizing authority is not automatically a win. Teams can absolutely move their confusion out of the prompt and into a pile of unsigned documents, lossy summaries, or vendor-specific logs that are just as useless under pressure. A sloppy artifact is still sloppy. The standard needs to be higher than "write it down somewhere." These objects need structure, attribution, scope, and a way to survive handoff, interruption, and audit. Otherwise the industry will replace prompt theater with paperwork theater and call it governance.