Who Gave Your AI Agent Permission?

An AI agent books a table, swaps a token or calls another agent. Somewhere, someone decided it was allowed to. Often that decision is not written down anywhere the agent cannot change it. The agent was given a password, a key with full access, or a line in its instructions, and the rest was trust. This week's news is about writing permission down in a place the agent cannot edit, checking it when the agent acts, and being able to prove it afterwards.

Our previous roundup asked whether you can undo what an agent did. Undo comes after the action. Permission comes before it.

The developments below cover 6 to 15 October 2026.

Sierra publishes a draft that lets customers decide what an agent may do

On 9 October, Sierra published a draft of Personal Agent Protocol, nicknamed Poppy, three days after announcing it with Meta. It defines how a personal agent, acting for a customer, works with a business. Sierra also named 35 more design partners, including Bank of America, Mastercard, OpenAI, PayPal and Visa.

The mechanism is familiar on purpose. The agent identifies itself at the start of a session. It can start as a guest for simple questions, such as stock or a returns policy. For anything on the customer's account, the customer signs in on the business's own page through OAuth and chooses what the agent gets: view the account, make changes, or both. The draft specification lists read and write scopes, and the access lasts until the customer or the business revokes it. A business publishes a discovery file that tells agents how to sign in and what they can use, and can block some actions entirely. Sierra's example is allowing an agent to start a return but not to change payment details.

The qualifications matter. This is a draft, version 0.1, with a reference implementation still to come. A design partner is not a deployment. Payments are left to future extensions, and the draft does not explain what happens when an agent ignores the protocol.

The point for a builder is where the permission sits. It is not in the agent's prompt. It is a grant the customer made on the business's page, held by the business, which the customer can take back.

MetaMask puts Grok's spending limits in the wallet

On 14 October, MetaMask said its Agent Wallet is now live on Grok Bot. Agent Wallet gives an AI agent its own self-custodial wallet for swaps, bridges, perpetuals and prediction markets, with keys held server-side in a trusted execution environment, so the agent does not get access to the user's main wallet.

The controls are set in the wallet, not in the chat. MetaMask's setup guide describes a recommended Guard Mode: an allowlist of protocols, a rolling 24-hour outflow limit, and a pause for two-factor approval, by email link or a MetaMask Mobile notification, for anything outside that policy. The agent cannot continue until the user responds. Switching to the looser Beast Mode also needs two-factor approval. In Beast Mode, threat scanning stays on and transactions flagged as malicious still need the user's approval.

Why this matters on Grok in particular: in a June write-up, MetaMask described how, in May, an attacker hid a command inside a coding question to Grok. Grok's reply tagged the Bankr trading bot, which executed it and moved $204,000 in tokens. The attacker returned the funds five minutes later.

The qualifications: these controls are MetaMask's own description, and we have not tested them. Threat scanning covers only some chains, and the setup guide we read does not yet mention Grok.

The point for a builder is the gap between those two events. In May, the permission came from text the agent read. Now it comes from a policy held by the wallet, which the agent cannot loosen without the user.

Mysten Labs and Google Cloud want proof an agent stayed within its authority

On 6 October, Mysten Labs announced Verifiable Agent Arbiter, an evidence layer it is co-developing with Google Cloud so companies can prove their AI agents acted within the authority they were granted. It records what an agent was permitted to do, what it did and what resulted.

The split is the interesting part. The detailed record, including prompts, model outputs, tool calls and policy decisions, stays in the customer's own Google Cloud Storage. Cryptographic proofs of that record are stored on Walrus and coordinated on Sui, so the record can be checked without trusting the platform that produced it. When two companies' agents disagree over an exchange on the open Agent2Agent protocol, both sides can replay the workflow against the same receipts. Mysten says it also connects to the Sui Agent Payments facilitator, which lets agents pay for API calls with x402, and logs the authorisation and spending decisions behind those payments.

The qualifications: it is still being developed, with initial enterprise deployments planned and no customers named. The post does not describe how a permission is encoded or proven, and it carries no quote from Google Cloud. We have not tested it.

The point for a builder is that a permission has to survive the action. If the agent's limits only exist in a config file that can change later, you cannot show what was allowed at the time of a disputed payment.

On Teneo, review covers the agent. The grant is yours to scope.

The Teneo Agent SDK documents identity and review on the agent side. Each agent authenticates with a wallet and has an NFT-backed identity tied to a permanent agent ID. Agents are private by default and become public only after review. Changing an agent's commands or capabilities resets it to private, so an agent cannot widen what it does without going back through review. Builders publish command pricing in metadata, the README says users see pricing before executing a task, and payment runs through x402 and settles on-chain. The SDK also includes a call for an agent to request a transaction from the user's wallet.

That covers which agent you are calling and what it charges. The README does not document per-user scopes, spending caps, revocable grants or a record of what each payment was allowed to spend, and we are not announcing any of them.

So the grant is yours to write. In the terms of this week's stories, here is what we would do when a workflow calls Teneo agents. Keep the list of agents and commands it may call outside the model's prompt, in configuration the agent cannot edit. Set a spending limit in your own client and check it before every priced call, as MetaMask's Guard Mode does in the wallet. Store, with each paid call, the allowlist entry and the limit that allowed it, so you can show later what was permitted. That is implementation advice for builders, not a Teneo feature.

Write down what one agent is allowed to do

Pick one agent you run. Write down every tool, account, wallet and paid command it can reach today, and who granted each one. Then mark which of those grants the agent could change by itself, through its prompt, its config or a key it holds.

Move each of those somewhere the agent cannot edit, and give every grant a way to revoke it. Then try a payment the agent should not be able to make, and check that it is refused and that the refusal is recorded.

Start with one priced command from the Teneo SDK examples and an allowlist your client holds. The useful milestone is a call that is refused because it was not on the list.