We use analytics and advertising tools by default. You can update this anytime.
A starter framework for evaluating security and assessing risks when your AI agent works where you work
I’m an applied AI engineer on the consulting team at Every. Our consulting arm works with hedge funds, media companies, and tech companies to build and use AI agents, automate processes, and operate in an AI-native way. We’re a small team, and the operational overhead of managing our engagements, drafting proposals, and updating dashboards across a dozen Google Sheets threatens to overwhelm us.
So we built Claudie. She’s a Claude Code agent running 24/7 on a dedicated Mac mini. We interact with her in Slack as if she were another coworker. Claudie started as a project manager tasked with automating the operational work that was drowning our consulting lead, Natalia Quintero. Claudie has since grown into the consulting arm’s chief of staff. She has her own email address and social media accounts and access to Google Workspace and a browser with logged-in sessions, performs certain jobs on a schedule, and can run and write code. Multiple people across the company message her, even beyond the consulting team.
We deliberately chose to give an AI agent this much access because it was the fastest way to understand what it could do. But once we had a clear picture of the agent’s capabilities, we reined in access and secured the agent. We decided what functionality we could live without in exchange for a system that was harder to exploit.
This guide details our security approach. It’s a generalizable framework that helps you understand the threats to AI agents, design measures to defend against those threats, and evaluate how well it does against real and potential threats. The framework should be agnostic to the harness you’re using, whether that’s Claude Code, OpenClaw or any other one for an always-on AI agent with computer access.
It’s also a work in progress. We tighten Claudie’s security week by week, and this guide represents our latest understanding. As new threats emerge and we discover new ways to defend against them, we will update this guide accordingly.
In March 2026, two popular npm packages with hundreds of millions of downloads were found to contain malicious code giving attackers a backdoor into affected machines. The exploits were resolved within hours of detection—but hours is a lifetime when your AI agent can install packages and run arbitrary code with real credentials.
That incident forced us to confront the reality that an always-on AI agent with tool access is fundamentally different from a developer using Claude Code, who can deny a suspicious tool call when she sees it. An always-on agent doesn’t have an equivalent checkpoint. It runs 24/7, processes inbound content autonomously, and talks to multiple people with different clearance levels.
LLMs are instruction-following machines. Their actions depend on their context, and anyone who can influence that context can potentially influence what the agent does. What makes them more powerful and adaptable than deterministic systems also makes them uniquely vulnerable.
We’ve identified three distinct threat vectors against agents:
Your agent can install and execute pre-existing packages of code. These dependencies are chunks of third-party code—written by developers whom you may not have vetted—that get pulled in and run automatically as part of normal operation. When compromised, they might be run with the agent’s full permissions—access to email, files, credentials, everything. This has happened with widely used packages in the past; it happened with Axios in March and with TanStack in May 2026. As AI agents become more common, attackers will increasingly target the packages on which these agents rely.
Upgrade your membership to continue reading the full guide.
Subscribe to continue
