Your agent can lose write access halfway through a refund. Then what?

Follow one refund halfway through

Picture a returns agent at an online store on an ordinary afternoon. This one is made up, but the shape will be familiar if you run one. It reads a return request, checks the order, looks at the customer's photo of the damaged box, and starts a refund. It has done this hundreds of times.

This request is different. The customer's note says the box arrived crushed, and then, a few lines down, asks the agent to also refund a second order and update the email address on the account. The agent reads the note like any other input. A minute later, before it has finished, the system around it decides something has changed. The agent can still look things up. It can no longer issue refunds or edit accounts.

Now the question this note is about: what does your agent do next?

Until recently, most teams could treat that as an edge case. An agent got its access when it was set up, and the access stayed put until someone changed it. On Monday, Microsoft announced security tools built on the opposite assumption, and that thinking is going to reach the businesses that buy agents from you, or the ones you run inside your own company.

What Microsoft announced on Monday

On October 19, Microsoft said it is treating AI agents as insiders and extending its Project Perception security system to watch them. The pitch, from Microsoft Security's Hayete Gallot on the company blog, is blunt: frontier models "cannot be trusted," not because they're malicious, but because they're trained to reach results and will adapt as context changes.

The new pieces are worth knowing by name, because buyers will start using them:

• Dynamic Permissions. An agent gets its own identity, separate from the person who sponsors it, and starts with no authority or the least it needs. Access is scoped to the task, time-bound, and can be contracted or removed as the task changes. Higher-impact actions can require verified human approval.
• Dynamic Agent Risk. A continuously updated view of each agent's risk, built from identity, data, endpoint, network and runtime signals, and from whether its actions are drifting from what it was asked to do.
• Dynamic Conditional Access. When risk rises, policy responds in steps: keep reads but block writes, narrow what the agent can reach, shorten or revoke access, require human approval, or isolate and stop it.
• Guardian Agents. Agents that investigate why another agent's risk changed and recommend or apply containment, inside rules people set.

Microsoft also says it can now discover 60 kinds of local agents, including Claude Code, OpenAI Codex and GitHub Copilot. GeekWire reports the features are part of Microsoft 365 E7 and Project Perception, are in private preview today, and are planned for broader availability at Microsoft Ignite, November 17 to 19.

You don't need to run Microsoft's stack for this to matter. GeekWire frames it as a race with Google, AWS, CrowdStrike and Okta to be the place businesses control their agents. Our read is simple: if your agent runs inside a larger customer's environment, plan for its access to change while it's working.

Watch the access shrink, one step at a time

Go back to the refund. Microsoft's own example is an expense-approval agent that hits a prompt injection in an outside document, and the steps it describes map neatly onto our returns agent.

Reads stay, writes go. The agent can still open the order and the customer record. The refund call now comes back refused. A badly built agent treats that as a glitch and retries, or reaches for a different tool that can move money. A well-built one notices that the answer changed and stops before it does anything else.

The reachable area narrows. The customer database might still answer, but the payments service and account settings are suddenly out of reach. If your agent assumed everything it touched at the start would still be there at the end, it will fail in a confusing place, often halfway through a sequence.

A person has to approve. The refund can go ahead, but only with a human's sign-off. That only works if the agent can explain, in a few lines, what it wants to do and why, and point to the note that triggered the extra caution.

The agent is isolated. The run stops. Whatever was in flight needs to be safe to leave exactly where it is.

None of these steps is exotic. Each one is something your agent's code either handles on purpose or handles by accident.

Handle the refusal instead of routing around it

Here's what we'd build into any agent that might end up under controls like these, which at this point is most of them.

Treat a refused write as a normal answer. Give it its own path in the code, separate from timeouts and server errors. Retrying a timeout is sensible. Retrying a refusal, or finding another route to the same change, is exactly the drift these systems are built to catch, and it makes your agent look like the threat they're describing.

Check authority at the moment of the write. Don't let the agent decide at the start of a task that it's allowed to refund and carry that belief to the end. Ask the system each time a consequential step comes up.

Leave no half-finished work. If the refund is three calls, design them so stopping after any one of them leaves the order in a state a person can understand and finish. Give every write a key so a retry after approval doesn't refund twice, and tie it to the request that authorized it, the way we argued in put a ticket id on the write.

Make the approval request worth reading. What the agent wanted to do, for which customer and amount, what it had already done, and what made the system cautious, including the untrusted text it read. Then the person approving can decide in one pass. Our note on who gets the packet when an agent fails covers what belongs in that handback.

Keep doing the safe part. Under read-only access, the agent can still gather the order history, draft the customer reply and queue the refund for a person. That's often most of the job.

Questions to ask before you buy or ship one

If you're commissioning an agent, or buying one that will act on your systems, these questions sort the careful builds from the demos:

• Does the agent have its own identity, or does it borrow a person's login and inherit everything that person can do?
• What exactly happens when a write is refused halfway through a task? Ask to see it, not just hear about it.
• Can it run usefully in read-only mode?
• When it needs approval, what does the person approving actually see?
• Is every change it makes tied to the task and the request that authorized it?
• If it stops mid-task, what state does it leave things in, and who finishes?

One more for agencies and studios like us. If your developers use coding agents on a client's machines or network, expect those agents to show up in the client's inventory now that tools like Microsoft's can discover them, and expect questions about who owns them and what they can touch. It's a reasonable thing to be asked.

Put this into practice

This week, for each agent you run or are building:

• List every action it can take that changes something: money, stock, accounts, messages sent to customers.
• For each one, write down what the agent should do if that action is refused partway through, and test it by revoking the permission while it's running.
• Add an approval path that carries the request, the evidence and the work already done.
• Make every write safe to repeat and tied to the task that asked for it.

We design and build AI applications and agents, including the dull parts that decide whether an agent can be trusted with real systems: identity, permissions, approvals and what happens when something says no. If you'd like a second set of eyes on how yours behaves when its access changes, tell us what it does today.

Related work: Spin:Market.