Date: 2026-01-29 Status: Research & Design Phase Author: Philippe (with Claude Code assistance)
This report proposes a fundamental inversion of the trust model for autonomous AI agents. Instead of granting agents access to user systems and services, agents operate on their own infrastructure with their own identities, granting users access to their work when appropriate.
The Core Principle:
The agent gives access to the user when asked, but the user never gives any access to its services to the agent.
This eliminates entire classes of security vulnerabilities by ensuring the agent has zero access to user accounts, credentials, or data.
- Problem Statement
- The Inverted Model
- Market Research
- Architecture Design
- Implementation Patterns
- Challenges & Open Questions
- Next Steps
- References
Most autonomous AI agents today operate by gaining access to user systems:
User ──grants access──► Agent
(OAuth, API keys, credentials)
The risks are severe:
| Risk | Description |
|---|---|
| Credential Exposure | Agent stores user credentials (often in plaintext) |
| Privilege Escalation | Compromised agent gains access to everything user granted |
| Audit Opacity | Agent actions indistinguishable from user actions |
| Blast Radius | Single breach exposes user's entire digital life |
| Irrevocability | Revoking access requires rotating all credentials |
- Moltbot/Clawdbot: Stores credentials in plaintext
~/.clawdbot/, no default sandboxing - MCP Servers: 2,000 instances found exposed without authentication (Knostic, July 2025)
- Enterprise Visibility: Only 21% of enterprises have full visibility into agent actions (Akto, 2025)
- Security Expert Warnings: Google's VP of Security publicly warned against installing Moltbot
No one would give a stranger (or even a new employee):
- Their email password
- Full access to their bank accounts
- Push access to their code repositories
- Keys to their house
Yet this is exactly what current AI agent architectures demand.
Instead of users granting agents access, agents grant users access:
Agent ──grants access──► User
(collaborator invites, shared docs, CC'd emails)
The user never gives the agent access to anything.
TRADITIONAL MODEL:
┌─────────────────────────────────┐
│ USER'S DOMAIN │
│ Gmail, GitHub, Calendar, etc. │
│ │
│ Agent operates HERE │
│ (with user's credentials) │
└─────────────────────────────────┘
↑
│ User grants access (RISK)
│
┌──┴──────────────────────────────┐
│ AGENT │
└─────────────────────────────────┘
INVERTED MODEL:
┌─────────────────────────────────┐
│ USER'S DOMAIN │
│ Gmail, GitHub, Calendar, etc. │
│ │
│ Agent has NO access here │
└─────────────────────────────────┘
User pulls what they want ↓
┌─────────────────────────────────┐
│ AGENT'S DOMAIN │
│ Agent's email, GitHub, Drive │
│ │
│ Agent grants USER access │
│ (collaborator, viewer, CC) │
└─────────────────────────────────┘
| Property | Traditional | Inverted |
|---|---|---|
| User data exposure | High (agent has access) | Zero (agent has no access) |
| Credential storage | User credentials at risk | Only agent's credentials |
| Privilege escalation | Possible | Impossible |
| Audit trail | Mixed (agent as user) | Clear (agent as itself) |
| Blast radius | User's entire digital life | Agent's workspace only |
| Revocation | Complex (rotate all creds) | Simple (remove from repos/channels) |
The industry is moving toward sandboxed agent execution, but hasn't fully embraced the inverted identity model.
| Platform | Isolation Method | Cold Start | Notes |
|---|---|---|---|
| E2B | Firecracker microVMs | ~seconds | Open-source, AI-focused |
| Daytona | Kata Containers/Sysbox | <90ms | Fastest cold starts |
| GKE Agent Sandbox | gVisor | Sub-second (with pools) | Kubernetes-native |
| Microsandbox | libkrun microVMs | <200ms | Max security focus |
| Solution | Approach | Status |
|---|---|---|
| Microsoft Entra Agent ID | Directory identity for agents | Production (2025) |
| GitHub Machine Accounts | Human-responsible bot accounts | Available |
| OpenID Agent-ID Tokens | OAuth extensions for agents | Proposed (whitepaper) |
| BAID Framework | Verifiable credentials | Research |
| Agent | Isolation | Identity Model |
|---|---|---|
| Devin | Sandboxed compute | Service accounts |
| OpenHands | Containerized workspace | Per-session |
| Factory Droids | Custom runtime | Enterprise-managed |
| SWE-agent | Docker containers | Ephemeral |
Key Insight: These solutions isolate compute but still often operate within user accounts for GitHub, email, etc. The inverted model goes further by giving the agent its own accounts entirely.
| Service | Bot/Machine Account Policy |
|---|---|
| GitHub | Machine accounts permitted; human must accept ToS and be responsible |
| Google Workspace | Service accounts available; terms vary by product |
| Slack | Bot accounts permitted; rate limits apply |
| Microsoft 365 | Service principals and managed identities supported |
Legal Note: A human must always accept responsibility for the agent's actions. The agent cannot be a legal entity in its own right (yet).
┌─────────────────────────────────────────────────────────────────┐
│ AGENT'S DOMAIN │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────────┐ │
│ │ Compute │ │ Storage │ │ Agent's Accounts │ │
│ │ │ │ │ │ │ │
│ │ VM/Container│ │ Workspace │ │ - GitHub (machine) │ │
│ │ (E2B/Daytona│ │ Files │ │ - Email (dedicated) │ │
│ │ /Docker) │ │ State │ │ - Calendar │ │
│ │ │ │ Memory │ │ - Drive/Storage │ │
│ └──────────────┘ └──────────────┘ │ - Slack (bot) │ │
│ └────────────────────────┘ │
│ │
│ FULL AUTONOMY IN THIS DOMAIN │
│ │
└───────────────────────────────┬─────────────────────────────────┘
│
│ Agent shares work with user:
│ - Adds user as collaborator
│ - CCs user on emails
│ - Shares doc links
│ - Opens PRs to user's repos
│
▼
┌───────────────────────────────────────────────────────────────────┐
│ USER'S DOMAIN │
│ │
│ User's Gmail User's GitHub User's Calendar User's Slack│
│ │
│ AGENT HAS ZERO ACCESS HERE │
│ │
│ User reviews agent's work and pulls what they want │
└───────────────────────────────────────────────────────────────────┘
Requirements:
- Isolated execution (VM or container)
- Persistent state across sessions
- Network access to agent's services only
- No access to user's local machine
Options:
| Tier | Solution | Cost | Use Case |
|---|---|---|---|
| Development | Docker on local VM | $0-5/mo | Prototyping |
| Production | E2B / Daytona | $20-100/mo | Reliable isolation |
| Enterprise | Dedicated cloud VM | $50-500/mo | Full control |
| Service | Agent's Account | Purpose |
|---|---|---|
| agent@[domain].com | Communication, notifications | |
| GitHub | @agent-[name] | Code, PRs, issues |
| Calendar | agent.calendar | Scheduling, proposals |
| Storage | Dedicated Drive/S3 | Files, artifacts |
| Messaging | Slack/Discord bot | Real-time collaboration |
Cost Estimate:
- Email (Fastmail/Proton): $3-5/mo
- GitHub (free tier): $0
- Storage (S3/B2): $1-10/mo
- Total identity cost: ~$5-15/mo
How the agent shares work with the user:
| Artifact | Sharing Method |
|---|---|
| Code changes | PR to user's repo (agent forks, works, proposes) |
| Documents | Share link from agent's Drive |
| Emails | Send from agent address, CC user |
| Meeting proposals | Calendar invite from agent's calendar |
| Chat messages | Send as agent identity in shared channels |
| Files | Upload to shared folder or send link |
USER'S REPO AGENT'S FORK
──────────── ────────────
│ │
│ 1. User shares repo │
│ (adds agent as collaborator │
│ OR agent forks public repo) │
│ ─────────────────────────────────► │
│ │
│ │ 2. Agent works
│ │ (commits, tests)
│ │
│ 3. Agent opens PR │
│ ◄───────────────────────────────── │
│ │
│ 4. User reviews, merges │
│ (or requests changes) │
▼ ▼
Key Point: Agent never has push access to user's main branch. All contributions go through PR review.
AGENT'S EMAIL USER'S EMAIL
───────────── ────────────
│ │
│ 1. Agent composes email │
│ │
│ 2. Agent sends FROM own address │
│ TO: recipient@external.com │
│ CC: user@personal.com │
│ ─────────────────────────────────► │
│ │
│ 3. User sees CC, can follow up │
│ │
│ 4. Replies go to agent's inbox │
│ (agent forwards relevant ones) │
│ ◄───────────────────────────────── │
▼ ▼
Key Point: Agent never accesses user's inbox. User is kept informed via CC.
AGENT'S STORAGE USER'S STORAGE
─────────────── ──────────────
│ │
│ 1. Agent creates document │
│ in own Drive/Notion │
│ │
│ 2. Agent shares link with user │
│ (viewer or editor access) │
│ ─────────────────────────────────► │
│ │
│ │ 3. User reviews
│ │
│ 4. User copies to own storage │
│ if they want to keep it │
│ │
▼ ▼
Key Point: Agent's workspace is the source of truth during work. User pulls final artifacts.
When user wants agent to work on something:
USER AGENT
──── ─────
│ │
│ 1. User describes task │
│ (chat, issue, email) │
│ ─────────────────────────────────► │
│ │
│ 2. If agent needs context: │
│ Agent requests specific files │
│ ◄───────────────────────────────── │
│ │
│ 3. User shares specific files │
│ to agent's workspace │
│ ─────────────────────────────────► │
│ │
│ │ 4. Agent works
│ │
│ 5. Agent delivers results │
│ (PR, shared doc, email) │
│ ◄───────────────────────────────── │
▼ ▼
Key Point: User consciously decides what context to share. No blanket access.
| Challenge | Notes | Potential Solutions |
|---|---|---|
| Context sharing friction | User must manually share files/context | Build easy sharing workflows; clipboard integration |
| Real-time collaboration | Agent can't see user typing | Shared workspace for active projects |
| Smart home control | Physical devices tied to user accounts | Device-level sharing, or agent as guest |
| Existing workflow integration | Users have established patterns | Migration tools, compatibility layers |
| Challenge | Notes |
|---|---|
| More steps for simple tasks | "Summarize my emails" becomes "forward emails to agent" |
| Learning curve | Users accustomed to "give access and forget" |
| Perceived slowness | Indirect access feels less immediate |
Counter-argument: The friction is a feature. Every piece of data the agent sees is consciously shared.
-
Hybrid scenarios: When (if ever) should the agent have limited read-only access to user services? Is there a safe middle ground?
-
Agent persistence: How long should the agent's identity/workspace persist? Forever? Per-project? Per-task?
-
Multi-agent collaboration: If multiple agents exist, how do they interact? Through their own identities?
-
Cost model: Who pays for the agent's accounts and compute? User subscription? Usage-based?
-
Legal liability: If the agent (with its own identity) causes harm, who is liable? The user who directed it? The platform?
-
Identity verification: How do third parties know they're interacting with a legitimate agent vs. a spoofed one?
- Set up isolated compute environment (Docker on VPS)
- Create agent identity stack:
- GitHub machine account
- Dedicated email (Fastmail or similar)
- Storage bucket (S3/B2)
- Implement basic collaboration patterns:
- Agent forks repo, creates PR
- Agent sends email, CCs user
- Agent shares document link
- Build simple chat interface for task requests
- Implement context sharing workflow (user → agent)
- Build audit logging system
- Add calendar integration (agent proposes, user accepts)
- Create Slack/Discord bot identity
- Develop file sharing interface
- Security audit of isolation boundaries
- Implement credential encryption for agent's secrets
- Add rate limiting and anomaly detection
- Build revocation workflows
- Create admin dashboard for agent oversight
- Reduce friction in common workflows
- Build browser extension for easy sharing
- Create mobile app for approvals/reviews
- Develop templates for common task types
- OpenID Foundation. "Identity Management for Agentic AI." October 2025. arXiv:2510.25819
- "Know Your Agent: Governing AI Identity on the Agentic Web." ResearchGate, 2025.
- "Binding Agent ID (BAID) Framework." arXiv:2512.17538
- Cloud Security Alliance. "Digital Identity Rights Framework (DIRF)." August 2025.
- G2. "Enterprise AI Agents Report." August 2025.
- Akto. "State of Agentic AI Security." 2025.
- Google Open Source Blog. "Agent Sandbox for Kubernetes." November 2025.
- Microsoft Security Blog. "Zero Trust for Agentic Workforce." May 2025.
- E2B - Sandboxed cloud runtimes for AI
- Daytona - AI agent sandboxing
- OpenHands - Open-source coding agent
- Model Context Protocol - Anthropic's agent communication standard
- GitHub Terms of Service - Machine account policy
- Slack API Terms - Bot account requirements
| Solution | Compute Isolation | Identity Model | User Access Model |
|---|---|---|---|
| Moltbot | None (user's machine) | User's accounts | Agent accesses user |
| Devin | Sandboxed | Service accounts | Mixed (agent works in isolation but may access user repos) |
| OpenHands | Containerized | Per-session | Agent accesses user repos |
| Proposed Model | Fully isolated | Agent's own accounts | User accesses agent's work |
This document represents the initial research and design phase. Implementation details will evolve as the project progresses.