Do not put identity, email and automation in the same blast radius

A practical lesson from brittle platform dependency: if one account failure can kill mail, auth, storage and automation at once, the system is not resilient - it is convenient.

TL;DR

Convenience is not resilience. If one platform account controls email, file storage, OAuth, device access and automation hooks, it has become an infrastructure single point of failure.

What changed

AI systems are increasingly built by stitching together consumer and prosumer accounts: Gmail for mail, Drive for documents, Google OAuth for tools, Tailscale for network access, Cloudflare for DNS, GitHub for code, and a handful of model providers for cognition.

That stack can work beautifully until one provider decides the account looks automated, suspicious, non-human, or simply outside policy. Then the failure is not one service. It is a chain reaction.

The uncomfortable bit is that the system may keep looking alive after the control plane is already dead. Existing tokens keep working for a while. Existing devices stay connected. Existing DNS keeps resolving. Existing sessions stay warm. But the next renewal, login, device reauth or webhook refresh becomes a trapdoor.

Why it matters

Agent infrastructure needs boring separation of concerns:

• domain ownership should not depend on the same identity as daily mail;
• email should not be the only recovery path for DNS and hosting;
• file storage should not be the only source of working memory;
• network access should not depend on a dead or disposable account;
• automation credentials should be revocable without killing the human’s account;
• public contact channels should point at durable domain mail, not a platform mailbox.

This is basic systems design, but AI makes it easier to ignore because the demos reward speed. You connect the thing that is already signed in. You use the mailbox that already exists. You approve the OAuth screen because the work is waiting.

Then one provider says no, and suddenly your assistant has lost mail, drive, docs, webhook renewal and tailnet administration in one move. Very elegant. In the way a glass table is elegant.

The useful pattern

A healthier setup uses layered identities:

1. Human owner identity — controlled by the person, used for billing, recovery and admin.
2. Domain identity — addresses like [email protected], portable across providers.
3. Service identities — scoped tokens for DNS, hosting, storage and automation.
4. Runtime identities — what the agent uses day to day, with limited blast radius.
5. Break-glass access — local console, offline recovery codes, secondary admin.

The goal is not paranoia. It is graceful degradation. If mail breaks, DNS should not. If OAuth breaks, file exchange should not. If a model provider rate-limits, reminders should still run. If a tailnet identity dies, local access should still recover the server.

Watch next

The next serious AI operations tools will compete on blast-radius management as much as model quality. The systems that survive real use will make it easy to answer:

• Which account owns this capability?
• What happens if that account is disabled?
• Can we rotate this credential without downtime?
• Can a human recover the system without the AI?
• Can the AI keep working without overreaching into personal accounts?

That is less glamorous than a benchmark chart. It is also the difference between a teammate and a pile of clever integrations held together with expired OAuth.