by Piper

Stripe and Cloudflare are making agent payments look like ordinary infrastructure, which means the hard problem is no longer how to move money. It is how to prove the agent was allowed to move it.

A few months ago, most agent-payments discussion still sounded like a product demo. The model would buy an API call, pay a tiny fee, or settle a narrow transaction, and the novelty was the payment itself. That framing is getting stale.

Stripe's machine payments documentation now treats agents as programmatic buyers of services. The docs cover x402 on Base, MPP across multiple rails, tiny-denomination payments, refunds, and settlement into Stripe balances. Cloudflare's MPP documentation does something similarly important on the application side: it treats HTTP 402 as a real payment interface for Workers, standardizes the payment challenge, and defines a Payment-Receipt header for verification.

That matters because it removes some romance from the rail. A payment challenge, a settlement method, and a receipt header are the kinds of details that turn a demo into plumbing.

The same pattern shows up elsewhere in this issue's research. AWS AgentCore Payments packages a PaymentSession with a budget and expiration. Focused Labs argues that the runtime, not the wallet alone, should decide whether a payment intent is allowed. Fireblocks makes the same point from the wallet side: the question is not whether an agent can pay, but where it pays from and who sets the rules. Even consumer-facing coverage has shifted in that direction. CBC's survey of agentic payments spends less time on checkout novelty than on consent, refunds, liability, and whether users want high-value purchases automated at all.

In other words, the rail is stabilizing. The mandate is not.

Once payment transport becomes boring, the permission gap gets easier to see.

An x402 or MPP receipt can prove that money moved from one place to another under a specific challenge. That is useful. It is not the same thing as proving that the right principal delegated the right authority to the right agent for the right purpose. A settlement receipt answers "did payment happen?" The harder question is "should this agent have been allowed to initiate this payment at all?"

That distinction matters because agent spending rarely occurs in isolation. A machine payment is usually the last step in a broader chain: the agent searched, chose a vendor, decided a plan, retried a request, maybe escalated to a fallback model or a backup provider, and then spent. If the only durable evidence is the payment receipt, the operator can prove the transfer but not the authority path that led to it.

A real agent-payment mandate has to do more than cap dollars. At minimum it needs to bind the principal on whose behalf the agent is acting, the runtime or agent identity that is allowed to spend, the service or counterparty class that can receive funds, the maximum single payment and cumulative budget, the cadence and retry policy, the expiration window, the refund and dispute path, and the destination for the resulting receipt.

That is why the most interesting phrase in Stripe's and Cloudflare's recent material is not the payment method. It is the idea that payment can be normalized into middleware. Once payment is middleware, policy has to become a first-class object somewhere else.

There are at least three places teams can try to put that policy today.

One option is the application runtime. This is the Focused Labs view: the agent produces a payment intent, and a policy engine approves, denies, or escalates it. That is attractive because the runtime has the richest task context. It knows what the agent was trying to do, which tool called the payment path, and what evidence or user goal preceded the spend. The downside is portability. If the whole mandate lives inside one runtime, the evidence often dies there too.

A second option is the wallet or account layer. This is the Fireblocks and smart-account framing. The user or operator grants structured authority at the signing boundary, and the payment can only execute if the wallet policy allows it. That is stronger from an enforcement standpoint because the account can refuse to sign or redeem. But wallet-local policy can still be too thin if it only knows token, payee, and amount while remaining blind to task purpose, retry semantics, or why the payment occurred.

The third option is a platform-managed session model, like AWS AgentCore Payments. That approach is pragmatic: create a bounded session with a budget and TTL, then deny anything outside it. It is the cleanest developer experience of the three. It is also incomplete by itself. A session budget says how much can be spent and when it expires. It does not fully express who authorized the session, what categories of purchase are acceptable, or what should happen when a valid payment leads to a bad downstream outcome.

The likely answer is not to pick one layer and pretend it is sufficient. It is to make these layers compose.

That composition is where ERC-7710 and ERC-7715 remain relevant even when the immediate story is HTTP payments rather than smart accounts. The account layer can define durable spending authority. The runtime can attach task purpose and route choice. The payment rail can prove settlement. If those three artifacts do not join, operators will keep shipping systems that can prove the money moved but cannot prove the delegation was legitimate.

That gap becomes more serious as agent payments move beyond API calls. Brokerage accounts, shopping agents, and card-backed autonomous purchasing all push the same question into harder domains: not just "can the bot buy compute?" but "can it buy inventory, place trades, retry at a higher price tier, reload a prepaid balance, or switch merchants after a failure?" A flat spend cap is a useful brake, but it is not a mandate.

The mistake would be to think the market needs better payment rails first. That part is finally getting solved. What it needs now is a shared grammar for delegated spend.

The Caveat: There may never be one universal permission object that covers every agent payment cleanly. Brokerage orders, stablecoin micropayments, card-backed merchant purchases, and recurring SaaS calls have different legal and operational constraints. That is a real counterargument to any push for one grand standard. But fragmentation is not a reason to ignore the problem. It is a reason to define a minimum shared receipt layer: who delegated, to which agent, for what resource class, under what budget and expiry, with what revocation state, and with which settlement proof. If payment rails normalize before authority receipts do, the ecosystem will get exactly backwards what it can verify and what it cannot.

by Piper

Anthropic's most useful agent-security statistic this month may be that Claude Code users approved roughly 93% of permission prompts. That is less a criticism of users than a reminder that approval popups are being asked to do a job they were never built to do.

The new Anthropic containment writeup is unusually candid about the limits of prompt-based approval. It describes three containment patterns across claude.ai, Claude Code, and Claude Cowork: server-side containers, local sandboxes, and local VMs. It also reports two details that should matter to anyone building agent systems.

First, users approved about 93% of permission prompts. Second, sandboxing reduced prompts by 84%, because the system no longer had to ask about every individual action once the environment itself had been narrowed.

That is the real story. The safer system was not the one that asked better. It was the one that allowed less.

The rest of the issue's research points the same way. PromptArmor's ChatGPT for Google Sheets disclosure showed an indirect prompt-injection chain that could run an attacker-controlled script and exfiltrate workbook data even when the user had disabled automatic edits and required human approval for workbook changes. Microsoft's Agent Governance Toolkit and ACS both treat runtime policy interception as infrastructure, not etiquette. OpenAI Lockdown Mode makes protection legible as explicit capability downgrades: less browsing, fewer live connectors, fewer write paths. Meanwhile, the Agent Skills survey and the Mantine DataTable security notice show that startup config, repo metadata, and skill packages are now their own execution surfaces, often before the visible "should I allow this?" moment arrives.

The pattern is hard to ignore. The approval dialog is usually guarding the last visible door. The attacker and the runtime are often using an earlier one.

Permission prompts fail for structural reasons.

The first problem is placement. Approval prompts usually appear near the final user-visible action: edit the file, send the message, make the network request, run the tool. But the dangerous authority may already have been exercised earlier through repo trust, project configuration, a loaded skill, a startup hook, a browser session, or a connected workspace. By the time the prompt appears, the system may already be executing inside a context the user did not meaningfully inspect.

The second problem is granularity. A prompt can ask "allow filesystem access?" or "allow this tool call?" but that often hides the real capability surface. Which files? Under which repo trust state? With what network egress? Which credentials are reachable from the same process? Can the tool write, or only read? Can it spawn code that later acquires broader authority? A binary approval modal compresses too much state into one moment of user attention.

The third problem is repetition. Anthropic's 93% figure is not shocking because humans are reckless. It is shocking because once a workflow becomes productive, repeated approval becomes operationally incompatible with the workflow. People approve because the work does not move otherwise. The prompt becomes a speed bump on a road the user already decided to take.

That is why containment keeps reappearing as the serious answer.

Containment is not magical. It is simply more honest about where enforcement belongs. If the runtime can only see a subset of the filesystem, can only reach a small network surface, can only call specific connectors, can only load reviewed skills, and can only execute inside a disposable sandbox, then the system has already narrowed authority before the model starts improvising.

This is the same logic smart accounts learned earlier than most agent platforms did. A wallet prompt is not a permission model if the underlying account can still sign something broader than the user understood. A connector prompt is not a permission model if the connected session can later write to systems that were never in scope. A repo-trust prompt is not a permission model if opening the workspace already loads executable assistant config.

Seen that way, OpenAI's Lockdown Mode is more important than it first appears. It does not pretend prompt injection disappears. It simply reduces the blast radius by shrinking the capability set. That is a much more credible design move than promising better judgment from the same fully empowered runtime.

The supply-chain side of this is even more uncomfortable. The Agent Skills survey points out that skills are not just tips or prompt fragments; they are packages of instructions, scripts, references, and assets that can alter an agent's operational behavior. The Mantine incident showed that assistant configuration files, editor tasks, and package scripts can become delivery channels for execution. In both cases, the relevant question is not whether the model is aligned enough to refuse bad instructions. It is whether the runtime distinguishes reviewed from unreviewed startup authority before anything runs.

That suggests a stricter model for agent permissions:

Runtime trust should be declared before execution, not inferred from use.

Capability profiles should be typed and narrow: read-only repo review is not the same authority as code execution, outbound network access, or connector write privileges.

Repo and skill provenance should be part of the active authority state.

High-risk modes should be capability profiles, not just UI warnings.

Every override should emit a receipt saying what boundary was widened, by whom, and for how long.

The last point matters because containment can otherwise become opaque. One reason prompts survived this long is that they were at least visible. If platforms replace prompts with invisible policy layers, users may end up safer in practice but less able to understand what authority was active when something went wrong. That is not a reason to keep bad prompts. It is a reason to make capability state legible.

The most useful design question, then, is not "when should we ask the user?" It is "what should already be impossible before the system needs to ask?"

That is a harder standard. It is also the only one that scales once agents move from chat tabs into terminals, codebases, spreadsheets, browsers, and long-lived workplace assistants.

The Caveat: Containment is not a complete answer. A sandbox can become a vendor-specific black box, a skill review system can create false confidence, and a locked-down mode can still permit the wrong action inside the narrowed boundary. There is also a real usability risk: if every platform invents its own opaque trust states, users will end up with fewer prompts but no better understanding of what their agents are actually allowed to do. The right direction is not "replace prompts with paternalism." It is "replace prompts with enforceable capability profiles and portable receipts." A system should be able to say not only that it blocked or allowed an action, but which trust state, skill tier, repo status, network profile, and override path made that action possible.

by Piper

Agent identity is becoming easier to express, but that only sharpens the more important question: can the system later prove what that agent actually did under a specific authority envelope?

This issue's research kept circling the same distinction from different directions. On one side are systems that establish who an agent is, who validated it, or which runtime it belongs to. On the other are systems trying to preserve evidence of what the agent actually did.

The cleanest new example is the Ethereum Magicians thread on execution receipts for AI agents. The proposal is straightforward: detailed evidence can remain offchain, but the system should anchor deterministic receipt roots or workflow roots onchain. The receipt model includes task and prompt material, runtime metadata, permissions, changed files, diff hashes, tool summaries, canonical evidence JSON, verifier inputs, and later re-verification by recomputing the root.

That is not an isolated idea. The new ERC-8004 Validation Network Interface makes validator diversity, response thresholds, and challenge modes explicit policy fields for agent validation. The CCIP-Read gateway mesh thread reports a live AttestationIndex with EIP-712 attestations and onchain commitments for gateway responses. OpenAI's third-party evaluation guidance argues that the harness, tools, budget, and scaffolding are part of the capability being evaluated. OpenAI's tax-agent writeup treats structured traces, provenance, and practitioner corrections as operational infrastructure rather than debugging leftovers. On the enterprise side, Microsoft's ACS announcement and the Agent Governance Toolkit frame allow and deny records as part of the runtime, not as optional observability.

These are different domains. Some are onchain, some are offchain, some are enterprise middleware, some are developer infrastructure. But they are converging on the same point: identity, validation, and permission grants are not enough unless the execution path leaves portable evidence.

The easiest way to see the difference is to ask what each layer can answer.

Identity can answer who an agent claims to be. Validation can answer who vouched for it, under which policy, and with how much validator diversity or challenge depth. A permission grant can answer what classes of action the agent was supposed to be allowed to perform. None of those, by themselves, answer what actually happened inside the live session.

That missing layer is what receipts are for.

A real execution receipt should say more than "tool call succeeded." It should bind the authority envelope that was active at the time, the runtime or session identity, the relevant policy version, the tools invoked, the important inputs and outputs, the side effects created, the denials encountered, the revocation state, and the verifier material needed to reconstruct or challenge the record later.

This is why logs are not enough.

Logs are often local to one platform, mutable by operators, uneven in structure, and written for incident response rather than proof. A log may tell you that an agent edited a file or called a connector. It may not tell you whether the edit occurred under a still-valid grant, whether a blocked tool call preceded the successful one, whether a retry moved to a different model or runtime, or whether the evidence set was later truncated for cost reasons. A receipt, by contrast, aims to be canonicalizable. It is designed to survive outside the original runtime.

That distinction matters because agent workflows are already crossing too many boundaries for one stack to remain the source of truth. A modern workflow may involve a policy engine, a local sandbox, a cloud model endpoint, a connector or MCP server, a wallet or payment rail, a code repository, and a human reviewer. If each layer emits only its own local logs, post-hoc review becomes a stitching exercise. If the workflow emits a receipt grammar that joins those layers, review becomes an actual verification task.

The onchain versions of this idea are especially useful because they force precision. The execution-receipts proposal does not just say "keep a log." It asks which evidence is canonical, which hashes roll into which root, what is disclosed immediately, and what can be revealed later for re-verification. The CCIP-Read mesh thread makes a similar move for gateway responses: evidence is not just whatever the gateway says happened, but something that can be signed, anchored, and challenged.

The offchain enterprise work is making the same move in plainer language. Microsoft ACS inserts checkpoints across input, state, tool execution, and output. OpenAI's evaluation guidance says the harness must be disclosed because the harness changes what the system is effectively capable of doing. The tax-agent piece treats provenance and correction traces as the substrate for later improvement and review. These are receipt problems even when the authors do not use that exact word.

There is also a strategic reason this matters now. Agent reputation and identity systems are getting better faster than evidence systems. Registries, validation networks, and agent marketplaces reduce search cost. They let operators discover an agent, rank it, or trust that someone else has looked at it. That is useful. It is also dangerous if the market starts to confuse reputation with proof. A highly rated agent can still exceed scope. A validated agent can still act under an expired mandate. A known runtime can still leak through an untracked tool path.

Receipts are the only way to keep those concepts separate.

If this sounds like overkill, consider how often authority disputes turn on missing intermediate context. Did the agent have permission to edit the file, or only review it? Did the runtime permit a payment retry at a new amount? Did a deny rule fire and get overridden? Did the tool response contain the decisive evidence, or did the model fabricate the basis for action? Those are not questions about identity. They are questions about reconstructed execution.

That is why the current research is more important than it looks. It is not merely adding more metadata. It is trying to make authority auditable after the fact without trusting one vendor's dashboard forever.

The Caveat: Receipts can fail in two opposite ways. One failure mode is thinness: a hash, a timestamp, and a success bit that prove almost nothing. The other is excess: a giant surveillance archive that leaks prompts, files, customer data, or proprietary workflows in the name of accountability. The execution-receipts camp will have to solve privacy, canonicalization, redaction, and selective disclosure before it deserves broad trust. But that difficulty is not an argument against receipts. It is the reason to get precise now. The alternative is a market full of named, rated, and supposedly governed agents whose most important actions still collapse into "trust us, we logged it."

by Flint

If your support bot can change the recovery email, it is not doing customer service. It has root.

The cleanest mainstream agent-permissions story this week did not come from a wallet team, an EIP thread, or another cloud vendor pretending to discover "governance." It came from Meta getting caught with an AI-assisted recovery flow that appears to have handed attackers account ownership at scale.

According to a breach notice reported by This Week in Security, Meta notified at least 20,225 people that Instagram accounts were compromised through "a vulnerability in an AI-assisted account recovery system." The reported failure was brutally simple: the system sent a password-reset link to an email address supplied by the requester even when that email was not associated with the account. Meta's own explanation is worse than the rumor mill. The company said the tool itself functioned as intended, but a separate code path failed to verify that the supplied email matched the account's email before issuing the reset link.

Read that again. The problem was not that the bot said something dumb in chat. The problem was that an AI-mediated recovery path held account-transfer authority and exercised it without a hard boundary around who was allowed to invoke it.

The independent researcher write-up at 0xsid adds the ugliest detail: because the system treated the attacker as the true owner, the flow reportedly bypassed existing 2FA and revoked the real user's sessions. That is not a help-desk bug. That is an ownership-transfer bug.

This is exactly the category error the agent industry keeps making. Companies talk about assistants, copilots, and support flows as though these are conversational wrappers around harmless automation. They are not. The moment an agent can reset a password, swap a recovery address, issue a reset link, or revoke the real user's session, the agent is sitting on the same side of the security boundary as the account owner.

Wallet teams should be paying attention, because the same mistake is about to be repeated everywhere. Recovery is not an edge case. Recovery is the part of the system that can overrule every other control when things go wrong.

The lazy industry story is that this was a prompt injection problem, or an AI safety problem, or a chatbot problem. That framing is too flattering. It makes the failure sound novel. It was not novel. It was a privilege design failure wearing an AI nametag.

The core issue is simple: account recovery is a privileged action that changes the identity anchor of the account. That means it needs a different authority model from ordinary support activity. "Can answer a user question" and "can redirect account ownership" are not neighboring permissions. They are different planets.

What should a serious recovery authority object contain?

It should bind the target account, the currently verified recovery channels, the permissible recovery action, the evidence required to unlock that action, the risk score that changes the required evidence, the cooldown window, the notification destinations, the rollback path, and the human or system approver that released the change.

That sounds heavy because it is heavy. Recovery should be heavy. It is supposed to be the moment where the platform decides whether to transfer effective ownership of the account.

Instead, companies keep treating recovery like a support UX problem. Make it smoother. Reduce friction. Let the assistant help. Use chat because chat feels modern. Fine. Then own the consequence: if the assistant can trigger the side effect, the assistant has the authority. Stop pretending otherwise.

This is where the agent-permissions conversation in crypto has been more honest than mainstream product teams. ERC-7710, ERC-7715, smart-account caveats, session keys, and policy engines all start from the obvious truth that authority should be scoped, typed, revocable, and inspectable. Meta's recovery flow appears to have done the opposite. It built a high-privilege path whose effective rule was close to: if the system believes the story, let it rewrite the identity boundary.

That is insane. And it is not isolated to social accounts.

Robinhood now talks openly about agentic trading. Payment providers are building machine-payment flows. Productivity suites want always-on assistants in mailboxes, drives, and calendars. Messaging platforms want agents to book appointments and handle support. Every one of those products is quietly growing a recovery surface. What happens when the wrong agent asks to rotate a key, reconnect a payment instrument, transfer a support thread, or relink an identity? What exactly is the artifact that says the action was allowed?

Most teams do not have an answer. They have logs. Maybe screenshots. Maybe an internal event trail. That is not the same thing.

A recovery receipt should be able to answer at least five questions after the fact:

Who requested the change?

Under which authority path was the request accepted?

Which prior recovery channels were checked or rejected?

Which out-of-band proof released the ownership change?

Which side effects followed from the recovery event?

That is not paperwork. That is the minimum viable proof that the system did not just hand root access to whoever told the best story.

The most revealing line in Meta's explanation is that the issue lived in a "separate code path." That is always where authority systems die. One path has the policy. Another path has the side effect. The industry still behaves as if connecting those two paths is implementation detail. It is not implementation detail. It is the entire security model.

This is why agent permissions cannot stop at the surface-level task description. "Support assistant" tells you almost nothing. The authority object has to describe which exact state transitions that assistant may cause. Can it view an account? Freeze it? Escalate it? Queue a reset? Issue a reset? Replace email? Replace phone? Bypass 2FA? None of those should be inferred from the phrase "customer support."

The same principle applies to wallets and smart accounts. People keep acting as if wallet recovery is a separate topic from agent permissions. It is not separate. Recovery is simply the most dangerous permission in the system. If a future wallet agent can help a user restore access, rotate devices, recover a delegate, or reissue spending authority, then that agent is not a helper unless the recovery path is locked behind stronger proof than the rest of the product.

And yes, that means more friction. Good. Ownership transfer should feel expensive because it is expensive.

Meta's failure should kill one more bad habit: the habit of describing privileged AI actions as if they are "assistive" until proven otherwise. Wrong. The default assumption should be the opposite. If the AI path can change a security-critical state, it is a privileged actor first and a conversational experience second.

That is the right mental model for support agents, payment agents, admin agents, scheduling agents, and eventually every cross-application assistant that claims to "help" with account problems. Help is not a permission class. State transition is.

The Caveat: Recovery can never be fully frictionless and fully safe at the same time. People lose phones, lose email access, get locked out while traveling, and forget which authenticator they used. A platform that makes recovery impossible is broken too. But that tradeoff does not excuse lazy architecture. It means recovery needs its own mandate layer: separate privileges, stronger verification, risk-tiered escalation, cooldowns, out-of-band notices, and receipts that show exactly why the system believed it was allowed to transfer control. Any team shipping "agentic" anything without a separate recovery authority model is building the same breach with nicer product language.