What did Workday, Walmart and Coinbase actually ship?

Workday, Walmart and Coinbase opened their products to outside AI agents over MCP within ten days in October 2026, each with its own rules for what an outside agent may do.

On 13 October Workday made its Trusted Agent Platform headless. Its Agent-Ready Tools are now MCP tools that any MCP agent can call, and every agent, whoever built it, works "under the same Workday permissions, approvals, and audit trails." Each request carries who is asking, what they may see and do, which approvals apply and how the action is recorded.

On 21 October Walmart opened Agent Gateway, an MCP server for approved agents, as an invite-only beta. Shoppers approve each purchase or set a spending limit in advance. Agent Profiles, rolling out in November, will give each agent its own profile in the customer's account. Walmart's terms set what an agent may do, and agents that break them are blocked.

On 22 October Coinbase opened accounts to agents. As 24/7 Wall St. reported, the user chooses which portfolios an agent may reach, can preview an order before it executes and can disconnect at any time, and Coinbase advises a separate portfolio for AI trading.

Walmart and Coinbase sell to consumers; each pattern below is translated into a vertical SaaS write.

• 16%

  Share of Workday's MCP tools that write or delete data: 54 of 329, our arithmetic.

  Source: The New Stack, 13 Oct 2026
• 2

  Agent System Users Workday allows per agent: one delegated, one ambient, each with its own OAuth client.

  Source: The New Stack, citing Workday's documentation, 13 Oct 2026
• 3

  Ways to approve an agent's write shipped in two days: every action, a spending limit, a preview.

  Source: TechCrunch, 21 Oct 2026; 24/7 Wall St., 23 Oct 2026

Why split the tool list into reads, writes and deletes first?

Workday's MCP server has 275 tools that read and 54 that write or delete, the split Gabe Monroy, Workday's CTO, gave The New Stack on 13 October 2026.

Five in six of Workday's agent tools only read

Tools on Workday's MCP server, by what they do to data, count

• ReadBounded by what the user sees
  275
• Write or deleteEach one changes a record
  54
• 0100200300

The split is the first page of your spec. A read is bounded by what the user can already see on screen. A write changes a customer's record, and each one needs four more decisions: whose permission it checks, how it is approved, what scope the user grants and what the audit row says.

So draft reads, writes and deletes as three separate lists before anyone argues about OAuth flows. Name each write as a verb on a record: update the reserve on a claim, release a shipment, change a contract field. Deletes are the last tools you expose, and a first release can ship with none.

Whose permissions should each MCP tool call run under?

Each MCP tool call should run under the person's own permissions. In Workday's design, users sign in to an agent with their own Workday credentials, and the agent cannot reach data the user's own account cannot. The agent acts for that person, inside that person's role and approvals.

For your product, the MCP tools should wrap your service layer: the same code path the UI calls, with the same permission and approval checks. A tool that queries the database directly, or runs under a service account with broad read access, hands every connected agent the widest access in the tenant and skips the rules your UI enforces.

Monroy showed the difference with Workday's own demo, not an independent test. An agent on a custom MCP server returned job requisitions the user should not have seen and moved an employee between teams without approval. Pointed at a Snowflake copy of the data, it produced the CTO's salary. Through Workday's MCP server it returned only the requisitions the user was allowed to see. His summary: "You can export your data, but you can't export the rules that govern the data."

Whether an agent should have an identity of its own at all is the question we took up in should SaaS block AI agents; here that decision is made: the agent carries its own name in the record and acts within its user's permissions.

How should an AI agent's write be approved?

An agent's write can be approved in one of three ways, the three modes Walmart and Coinbase shipped on 21 and 22 October 2026.

• Ask every time. Walmart's shopper can approve each purchase.
• Run under a limit. Walmart's other option is a spending limit set in advance. eesel's summary of the launch gives $50, $100 and $200 as examples; TechCrunch names no amounts. In eesel's reading of the terms, an order over the limit pauses and asks the shopper.
• Preview, then confirm. Coinbase shows the user an order before it executes.

Give each write in your product one of these modes, chosen by what the write does. In a claims administration product, a reserve change previews the old and new values and waits for the adjuster to confirm. A payment below a threshold the customer's admin sets runs on that limit, and a payment above it asks. Closing a claim asks every time.

Write the mode into the tool's definition, beside its input schema, so the server enforces it whichever agent makes the call. The figure follows one write through every decision in this post.

One write, from the agent's call to the audit row

What does the user choose when they connect an agent?

The user chooses which records and which writes the agent may touch, so the blast radius gets set on the consent screen. Coinbase's approval screen lets the user pick which portfolios an agent may reach, and Coinbase tells users to give AI trading a separate portfolio.

In a vertical SaaS product the consent screen names records. An adjuster connecting an agent picks the clients it may act for; a logistics planner picks sites; a legal operations lead picks matters; a finance admin picks cost centres. The same screen shows which writes are switched on for this agent, each with its approval mode, so a user can allow claim notes and leave payments off. Disconnect sits on the same screen: one click, no support ticket.

Default the consent screen to fewer clients and fewer writes; widen it once the audit rows show what the agent did.

How does the audit log tell an agent from the user?

Walmart's answer, announced on 21 October 2026 and rolling out in November, files each agent under its own profile in the customer's account, with its purchases shown separately and deletable at any time. Workday's documentation, as The New Stack reports it, allows up to two Agent System Users per agent, one delegated and one ambient, each with its own OAuth client.

Both give the agent a name of its own in the record. Picture a customer's admin opening the audit log because a reserve on a claim rose by $6,500 overnight. The row has to say which agent made the change, for whom, under which consent and with which approval mode. Write those four fields into the audit row of every write from the first release, and show agent actions in the claim's history with the agent's name beside the user's.

What should your MCP developer terms say?

Walmart's terms say an agent acts within the shopper's intent, never sees payment information and takes only the data the task needs, and that agents which do not comply are blocked.

Your developer terms are part of the surface you ship. Write the equivalents for your domain, such as an agent reading only the claims its user has open, and give them an enforcement path your team can run: revoke one agent, in one customer's account or across all of them, without locking out the customer or their other agents.

What does a filled-in MCP tool table look like?

Here is the method as one table, for an illustrative claims administration product. Each write carries its permission check, its approval mode, the scope the user grants and the fields its audit row records. Copy the columns for your own product and fill in the rows before the first sprint.

The tool table, filled in for a claims administration product

Illustrative. One row per tool; copy the columns.

Illustrative. Approval modes follow patterns Walmart (21 Oct 2026) and Coinbase (22 Oct 2026) shipped; permission model follows Workday (13 Oct 2026).

Ship the reads and the two or three writes your customers ask for most. Add the others one at a time, each with its row filled in first.

Where SynOS fits

SynOS installs in your cloud and runs white-labelled inside your product. Agents your customers build, or bring through any harness, run in the SynOS Agent Runtime, each with an agent identity that acts as a named user in a named role and that the customer can revoke. Every run is traced, with its writes recorded rather than executed. So the first two fields of every audit row, the agent and the person it acted for, are there from your first release. Start with the write your customers ask for, and we will begin there.

Questions