Treat Your AI Agent Like an Intern, Not a Co-Founder
Published on 13.02.2026
How I Claw - OpenClaw as My Intern
TLDR: OpenClaw is a powerful personal AI agent, but giving it unfettered access to your accounts, SSH keys, and passwords is a security nightmare. The author advocates treating it like a junior developer or intern: give it its own scoped accounts, require code reviews on everything it does, and build an audit trail. This is not about avoiding AI agents, it is about using them responsibly.
Summary:
There is a gold rush happening right now with personal AI agents, and OpenClaw sits right at the center of it. People are buying Mac Minis, spinning up instances, and handing over the keys to their entire digital lives: email, calendars, messaging platforms, SSH keys, passwords, the whole lot. And look, I get the appeal. The productivity gains are real. But so are the security implications, and the conversation around those implications is not happening loudly enough.
The list of documented security concerns is genuinely sobering. ZDNET called OpenClaw "a security nightmare" with five red flags. Cisco documented intentionally malicious skills being successfully executed. CrowdStrike flagged prompt injection as a significant concern given the agent's expansive access. The Hacker News reported a bug enabling one-click remote code execution, and SecurityWeek documented vulnerabilities that let attackers hijack the assistant entirely. Forbes summed it up well: while OpenClaw enables significant power with agents that can do your bidding, it also opens significant security and privacy concerns. This is not hypothetical risk. These are documented, real-world vulnerabilities.
The author's approach is refreshingly pragmatic. Rather than abandoning OpenClaw, they restructured how they use it. The AI agent operates under its own identity, a bot account called ScuttleBot, with separate accounts on GitHub, GitLab, and Telegram. It opens merge requests, comments on code, proposes changes, and manages tasks, all under its own identity. Every action traces back to the bot, not to the human. The workflow mirrors exactly what you would set up for a junior developer: feature branch, commit, merge request, CI pipeline runs tests and security scans, human reviews inline, the bot addresses feedback, and the human merges when satisfied. Most of the repositories the bot contributes to are not even code; they are things like blog content and configuration, treating everything as code so there is never ambiguity about whether a human or the AI made a change.
The structural insight here is worth sitting with for a moment. The problem is not any single vulnerability in OpenClaw. The problem is non-deterministic large language models with standing access to everything you care about. Product designer Tommaso Nervegna found roughly a sixty percent success rate on complex tasks and bluntly advised: you will be babysitting more than delegating. That is not a criticism of the technology; it is a realistic assessment of where we are right now. And if you are babysitting anyway, you absolutely want a review step between the agent's actions and your production environment, where "production" in this context means your personal relationships, finances, and digital life.
The practical setup does not require exotic tooling. Create AI-specific accounts in your identity provider, configure single sign-on with appropriate group mappings, set branch protection rules requiring review for AI-opened pull requests, use AI-specific accounts for automation instead of personal credentials, and document the workflow. It is mostly configuration and discipline, which is exactly the kind of work that pays dividends when something eventually goes wrong.
Key takeaways:
- Personal AI agents like OpenClaw create a single point of compromise for your entire digital life when given full account access
- Multiple major security organizations including ZDNET, Cisco, CrowdStrike, and SecurityWeek have documented real vulnerabilities in OpenClaw deployments
- The recommended approach is to treat AI agents like interns: scoped accounts, required reviews, audit trails, and room to make mistakes that get caught before production
- Running the agent under its own bot identity (separate GitHub, GitLab, messaging accounts) provides both security isolation and clear attribution
- The standard development workflow of branch, commit, merge request, CI, review, and merge works just as well for AI contributors as it does for human ones
- The setup requires no exotic tooling, just configuration discipline around identity providers, SSO, branch protection rules, and documentation
Tradeoffs:
There is an inherent tension between convenience and security with personal AI agents. The more access you grant, the more useful the agent becomes, but the larger your blast radius if something goes wrong. Running the agent under its own scoped identity adds friction to every interaction: you have to review merge requests, manage separate accounts, and maintain branch protection rules. For someone who just wants their inbox cleaned up, that overhead might not be worth it. But for anyone whose agent touches code, credentials, or communications, the review step is the difference between a caught mistake and a compounding disaster. The author also acknowledges that isolating the agent to a VPS rather than running it on a personal machine adds infrastructure cost and complexity, but reduces the blast radius significantly.