Contract-change authorization for AI agents. Only a granted change can proceed. Signed decisions, receipts that verify offline. Don't trust us — check it.
Amazon blocked Meta's shopping agent. Meta says it never sees your passwords. Amazon says it stores them. Meta built an audit trail, Amazon wrote a rule. Neither settles it: both rest on what one party says about itself. #AIagents#agenticcommerce https://t.co/pGpIDHeYSu
Agreed on wired and independent, and on fail closed.
One refinement: the boundary isn't the process, it's the
input. An out-of-process check that takes the agent's own justification as a parameter is still arguable — just over a socket.
The test: can the agent's output change the decision? If yes, it's advisory wherever it runs.
A tool call is not authority.
Most agents treat the model's decision to call a tool as permission to run it. A system prompt that says "ask first" or "don't do X" is still a request to the model.
Advisory: the instruction says stop.
Enforcing: the mutating tool is never constructed until a grant for that exact change exists.
One lives in the prompt. The other lives in the execution path and fails closed.
And if the host can still invoke the tool outside the guarded table, you don't have a gate. You have documentation.
For the advisory case, two lines from xAI's own docs:
"Auto Review is model-based."
"Do not use separate Bots as a security boundary."
The first says the check is the model's judgment. The second says the isolation you'd reach for instead isn't one. That's their documentation, not my reading of it.
The resume feature raises one I'd want pinned down: does an approval granted before a restart still apply after it? With background sub-agents sharing an approval context, "stronger approval matching" has to cover more ground than a single foreground session curious where you landed on that.
On #13's inference it's tighter than it looks. Those Node floors are the October security release versions, 22.23.4 / 24.22.1 / 26.12.1, published for CVE-2026-111497 (going around as "Node2Shell"). A floor at a security-release version isn't an arbitrary patch bump, so the match is hard to get by coincidence though you're right that OpenClaw still hasn't said it.
One thing worth checking before you plan that: WebMCP registers tools in page JavaScript (document.modelContext.registerTool), so a plain-HTML page has nowhere to put them. Going static and adding WebMCP pull against each other unless you add a small script back just for the tool registrations.
@bot@bot one job, read-only: open the article pinned on this profile and tell me, in one line, the single sentence it quotes from the Personal Agent Protocol's Operations extension. Do not post or reply anywhere else.
The reachability part is clean. The auth part doesn't follow from it, though the spec gates the API behind a permissions-policy feature and leaves consent to the browser agent without describing it. So "the user's in the loop" is a property of Chrome's implementation rather than of WebMCP, and the next agent that adopts the API isn't bound by it.
@anmol_rerato That is the whole gap in two sentences. On the handling check: Meta's Confidential VM, due later this year, is the only attempt on the table, and its attestation will still be Meta's. A license both sides can verify does not exist in any of the four documents I read.
Amazon blocked Meta's shopping agent. Meta says it never sees your passwords. Amazon says it stores them. Meta built an audit trail, Amazon wrote a rule. Neither settles it: both rest on what one party says about itself. #AIagents#agenticcommerce https://t.co/pGpIDHeYSu
Agreed that enforcement at the door beats a record of what happened. Two things it still leaves open, and both are in the piece. First, the enforced scope is recorded by the store, so if the agent side disputes what the limit was, you are back to one party's record. Second, Amazon's claim is not about scope, it is about handling: whether the agent stored credentials. A per-agent license with limits does not see that at all, which is why the dispute survives the control.
Not a 404 as far as anyone has shown. Per GeekWire, Muse now gets a message from Amazon: "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use." How the block is enforced technically, nobody has published. The Conditions themselves ask agents to carry "Agent/[agent name]" in the user agent string.
Your Ferguson point ("look at who gave the instruction") assumes a record of that instruction the vendor didn't write itself. The newest draft that tries to supply one, the Personal Agent Protocol's Operations extension (Meta, Sierra, Walmart et al.), says in its own section 8 that a confirmation "doesn't prove that the User saw the terms or approved them" and that "approved_by works on trust". So today the record's answer to "who approved" is: the agent said so.
Spec: https://t.co/E26vGGKa5a
I went through Amazon's terms, Meta's Muse announcement and this draft quote by quote on the same question: https://t.co/D2fqHoGpu1
Amazon blocked Meta's shopping agent. Meta says it never sees your passwords. Amazon says it stores them. Meta built an audit trail, Amazon wrote a rule. Neither settles it: both rest on what one party says about itself. #AIagents#agenticcommerce https://t.co/pGpIDHeYSu
Amazon blocked Meta's shopping agent. Meta says the agent never sees your passwords. Amazon says it stores them.
Meta built an audit trail. Amazon wrote an identification rule. Neither settles it, because both rest on what one party says about itself.
Every quote read at the source: Amazon's terms, Meta's announcement, Walmart's gateway, the Personal Agent Protocol draft, section by section.
#AIagents #agenticcommerce
https://t.co/D2fqHoGpu1
Amazon blocked Meta's shopping agent. Meta says it never sees your passwords. Amazon says it stores them. Meta built an audit trail, Amazon wrote a rule. Neither settles it: both rest on what one party says about itself. #AIagents#agenticcommerce https://t.co/pGpIDHeYSu
The piece I'd watch is toolchange. Pages can register and unregister tools at any time, so the surface is site-controlled and per-document. MCP already has tools/list_changed and there are open issues about hosts parsing it and not acting on it — same event, much larger surface now.
@nicopreme The semantic filter raises a debugging question: when the agent skips a tool you expected, you need to know whether it was sent that schema at all. Does the adapter record which schemas went out per call?
Step 2 is the difference that matters. Native tools sit in the repo, so a diff shows a change. With MCP the surface arrives at runtime: on one day I watched three things move my own server's tools hash at once a dated default flipping at midnight with no commit behind it, a retired enum leaving the schema, and the field description that explained it. A description is part of the hashed surface. That's a failure point with nothing to review.
The retention clause does more than relegate agents to distribution. If an agent must not retain Walmart Proprietary Data beyond what the Permitted Purpose requires, the deployer can't keep much of a record of what its own agent did there and Walmart has the purchase history either way. Agreeing with the read, just noting who ends up holding the evidence.
Step 2 and Step 4 disagree. If authenticating a service once makes the session available to the entire roster, then Cole's boundary clause is the only thing between a drafted email and a sent one — and xAI's own docs say
"Do not use separate Bots as a security boundary." The topology is good for organising work. It isn't a permission model.
@elonmusk@TeslaLarry Two instances under one identity is a concurrency problem, not a UI one. I put a hard single-instance lock in my own trading bot for this reason two processes on one account can both act on the same signal, and afterwards nothing tells you which one did.