The Trust Gap
If you're following the "ClawVerse" (OpenClaw, MoltBook), you know the promise: an AI agent with unrestricted OS access and a library of automation skills. It's powerful, but from Day 0, the security implications have been glaring. Giving an LLM access to un-sandboxed personal data creates a massive vulnerability surface, ranging from standard prompt injection to unintended data purges.
The current trajectory looks like AI agents will be handling our personal and professional automation. While biking today, I was thinking about the "solution" to this trust gap. Current fixes usually involve isolation—remote VMs, local virtualization, or the dedicated Mac Mini clusters we're seeing pop up.
The problem is Isolation limits utility. If you sandbox the agent away from your data, it can't actually help you. One solution is calling out for more widespread OAuth 2 support. OAuth 2 scopes allow for selective authorization (Read vs. Write), but they aren't being adopted fast enough. If you're developing a service today, supporting granular OAuth scopes isn't just a feature; it's a prerequisite for the agent economy.
Sessions Assume Human Control
OAuth doesn't solve everything. Many agents, like OpenClaw, interact with the browser via Remote CDP (Chrome DevTools Protocol). This is a session-based workflow.
The fundamental flaw in modern web architecture is the assumption that the entity controlling an active session is a human. We assume the user knows exactly what they are doing at every click. In an AI-driven workflow, that assumption vanishes. A session might be driven by a human, an AI, or a "centaur" mix of both.
Imagine your agent has access to your LinkedIn session to monitor job postings. You want it to Read, but you likely don't want it to Write—the risk of an LLM hallucinating a career-ending post to your professional network is too high. Yet, current web sessions are binary: you are either logged in with full permissions, or you aren't.
Design Patterns for Agent-Ready Backends
We need to rethink authorization so that users can enable or disable "Write" access for specific journeys. We need to build services that assume an agent might be at the wheel. Here are three patterns I'm considering:
- User-Gated Session Scopes: Websites could allow users to toggle a "Read-Only" mode for a current session, protected by a password or biometric check that the agent doesn't know. You flip the switch, the AI takes over the browser, and the backend rejects any
POSTorDELETErequests until you manually re-authorize. - The
REQUEST_MADE_BY_AIHeader: Browsers could signal when a request is initiated via CDP or automation APIs. While spoofable and also not foolproof (especially for computer-use agents looking at raw pixels), it provides a signal for backends to trigger extra verification for sensitive actions. - Proof of Human Intent: Certain "Write" actions could require a human-in-the-loop signature—like a biometric check on a phone—to sign a specific transaction generated by the agent.
Conclusion
The takeaway is simple: when building a service in 2026, assume an AI will eventually use it. If we don't build the infrastructure for "selective trust" now, we'll be forced to choose between total isolation or total vulnerability.
P.S. It's worth noting that none of this "solves" prompt injection entirely. An agent with Read-only access can still be tricked into exfiltrating your data to an attacker's server. We're solving for unintended action, but unintended disclosure remains the next great frontier.