Before you give an agent your inbox: permissions, identities and what researchers found in OpenClaw

Why identity is the first decision, not the last

An agent that runs while you sleep is acting as someone. The question every vendor has to answer, and most of them answered this year, is: as whom? If the answer is you, then every mistake it makes is yours, every permission you have is its, and the day your password rotates it dies silently. If the answer is a separate identity, you can give it exactly what it needs and nothing else, you can see its actions in a log under its own name, and you can revoke it without locking yourself out.

My jobs run under a service account that can write to one storage bucket, read one secret and purge one cache. It cannot read my email, it cannot see the billing console, and it cannot renew itself into anything bigger. Every call it makes names that account explicitly, because the day I relied on the default identity was the day the default identity expired. That is the whole first rule: never my own login.

What the vendors do about it

I read the launches in the headlines post with this one question, and they split cleanly.

Microsoft: an identity per agent

Scout, now Autopilot, is the clearest answer. Microsoft's own words are that every agent operates under its own governed Entra identity, not a shared, anonymous service account, so its actions are attributable to a known identity in your directory, and credentials are scoped to each task. Access in the preview also needs Intune policy configuration and an opt-in attestation, which is a vendor saying out loud that the permission step is the step. I have no inside view of what the identity includes by default, and I will not guess.

Anthropic: the agent never sees the key

Managed Agents added vaults in June: you register a key with a variable name and the domains it may reach, the sandbox holds only a placeholder, and the real key is attached at the network boundary for approved domains only. Anthropic's line is that the agent never sees your key because the sandbox only holds a placeholder. That is the design I would copy if I were building a platform, because it makes the most common leak, an agent pasting a secret into a log or a prompt, impossible rather than discouraged.

OpenAI: a separate computer, and a map

Each dot gets its own cloud computer and browser; your local machine is off limits unless you connect it through the desktop app, and background research is limited to read-only tools. The regional map tells its own story: Pro access excludes the European Economic Area, Switzerland and the UK at launch, and the Enterprise, Edu and Healthcare beta is off until an admin turns it on. I read a default-off beta as the right instinct.

Meta: everything on one machine

Muse is the opposite bet, and I say that without hostility. It runs on what Meta calls a dedicated, secure computer with its own browser, and Meta says it cannot see your passwords or payment methods and keeps conversations away from the ads systems. It also asks, one app at a time, for email, calendars, payments through Link by Stripe, health and fitness apps, smart home, dining and shopping, and where a service has no API it uses the browser. Two weeks after launch, Amazon blocked it from its retail site, saying the agent had not identified itself and appeared to capture and store customer credentials, a claim that contradicts Meta's and that I cannot adjudicate. What I can say is that one VM holding email, payments and health is a single place for everything to go wrong, and TechCrunch's framing on launch day, that users will have to trust Meta with more personal information than ever before, is the right one.

What researchers found in OpenClaw

OpenClaw is the most-starred repository on GitHub this year and its tagline is that it really does things. It needs broad access to files, accounts and messaging apps to work, and security researchers have documented exposed installations and malicious third-party skills. After a 2026 hardening update, skills without proper permission declarations now fail closed. A separate agent social network, Moltbook, suffered a database breach in late January 2026 that exposed 1.5 million API tokens; it is not OpenClaw itself, but it is the same ecosystem and the same class of mistake. Every guide I trust says the same thing: run it on a dedicated machine, not the one with your banking and your passwords. I have seen larger figures quoted for a formal audit of the project; I could not verify them on the day I wrote this, so they are not here.

The four rules I will not break

1. No uncapped spend. Every hosted model my jobs could call has a hard monthly limit set before the first run. An agent with an open budget and a loop is an open tab, which is most of what the pricing post is about.
2. Never my own login. A service identity with the narrowest grant that works, named on every call. The default identity expires; the agent must not be able to borrow mine.
3. Nothing irreversible without a human. My agents publish, because I can unpublish. They draft, because a draft is not sent. Deleting pages, sending money and emailing a list get a person and a confirmation. The watchdog that runs every morning is not allowed to delete anything at all.
4. Nothing silent. Every run writes a log. Failures email me. The absence of an email means a check passed, and I only trust that because the job is built to fail loudly.

The operational safeguards, which are the boring part

Rules are cheap. These are the mechanisms behind them, and each one exists because something went wrong once.

• A shared lock between jobs. Two daily jobs edit the same two files, the sitemap and the blog index. They share a lock file, and a lock older than thirty minutes is treated as a crash and cleared, so two runs can never interleave a read-modify-write on the same file.
• A kill switch that is a file. Creating one file pauses both jobs. No login, no dashboard, nothing that could itself be down at 3am.
• Backups before every edit. Each edited file is copied to a dated folder first. Nothing uploads unless the sitemap parses as XML and the index parses as JSON with the counts I expect.
• Idempotent and catch-up. The publisher checks whether an action already happened before doing it, and acts on everything due on or before today, so a missed morning heals itself.
• Retry only on the right failure. On 17 October the watchdog sent me a false alarm because a single read of the newsletter provider's API timed out. It now retries on timeouts and 5xx responses, and treats only a 4xx as final on first sight.

A checklist before you connect an agent to anything

1. Create an identity for it. Name it after the job, not after you.
2. Grant it the smallest set of permissions that lets one run succeed, then try to run it with less.
3. Put a hard cap on every model and every card it can reach.
4. List what it is allowed to change, and check each item can be undone.
5. Decide where its log goes and who reads it when a run fails.
6. Put it on a machine that holds nothing you would mind losing.
7. Write down how to turn it off, then turn it off once to prove the switch works.

That checklist is the spine of every setup guide in this series, on every system, and the guides begin tomorrow with the cloud. The whole series is on one page; the definition is in the first post, the reasons I keep models out of most jobs are in yesterday's, and the one agent I do let decide things is here.

Sources

1. Microsoft 365 Blog, Introducing Microsoft Scout: your always-on personal agent (accessed October 20, 2026)
2. Anthropic, New in Claude Managed Agents: run agents on a schedule and store environment variables in vaults (accessed October 20, 2026)
3. DataCamp, OpenAI dots: always-on agents in ChatGPT, explained (accessed October 20, 2026)
4. Szymon Paluch, OpenAI dots: ChatGPT's always-on agents, and who can use them (accessed October 20, 2026)
5. TechCrunch, Meta debuts its Muse AI agent. Will consumers trust it? (accessed October 20, 2026)
6. Wikipedia, Muse (AI agent) (accessed October 20, 2026)
7. Emergent, What is OpenClaw? I tested it in 96 minutes (accessed October 20, 2026)
8. AI Tool Briefing, OpenClaw review 2026 (accessed October 20, 2026)
9. GitHub, openclaw/openclaw (accessed October 20, 2026)

Written by Lera Leonteva. The vendor security claims are quoted from the linked pages as read on the access date; I have tested none of the commercial products, and the operational safeguards describe my own jobs only.