Agentic AI and Security: the Trade Off
The AI Trade Off
Utilizing an AI agent requires you to strike a balance between the agent’s access and effectiveness. If you give the agent too much access, the limits to their power and potential damage from an attack or malfunction are greatly increased. Alternatively, if you constrict an agent’s permissions and movement you dampen its effectiveness, making it – in many cases – the wrong tool for the job. Among my engineering friends we have a saying that encapsulates this issue with generative AI broadly: “AI ideas go through InfoSec first.” We don’t say this out of laziness, rather, to help an enterprise understand the primary trade off you make when AI is introduced in a production environment: Security and predictability. You see, when these ideas are first pitched by an executive or director, it’s better to let InfoSec kill dreams or at least present the trade offs before any engineering work occurs. Many people – from no wrong doing of their own – buy into new tech before an organization is ready to absorb the costs of implementing new tech. Companies must be strategic about what new technologies are appropriate or risk the cost and time waste from a rogue project that becomes larger than the problem they originally set out to fix.
A new AI agent called Clawdbot (renamed Moltbot) exemplifies this trade off as well as any example I can think of. It’s marketed as “You’re own AI assistant”, with the compelling promise to manage your digital life hands free. You give the agent instructions and it will carry out lengthy tasks that require recall and critical thinking on your behalf. From a technical perspective, the capabilities and integrations offered by Clawdbot are both impressive and terrifying. Clawdbot can comb through your email to connect messages with outside contexts, push code to github and orchestrate a workflow that utilizes multiple pieces of software.
Admittedly, I was on board right away, as I have the resources and time to waste automating tasks for vanity. However, as I read through the documentation, I realized that Clawdbot would have user level access to execute commands. As someone with a homelab, this was discouraging news as I value the security of services running on my home network. I could create a separate VLAN blastwalled from the rest of my LAN and run it in a container, but that would halve the potential use cases. Whatever – that’s fine I’ll just use it to automate some email tasks and organization. Before I could start I had another thought: “What if I receive an email with a prompt injection?” The possibilities for a malicious attacker are exponential. “What if the readme from a github repository contains an html or json file with a prompt injection payload?” I’d be forfeiting any of the information needed by the agent to a threat actor targeting this type of autonomous execution. In an instant, the potential risks and the work required to lock this agent down immediately outweighed any productivity I would gain.
This is the trade off we face as we move into the AI era. The power we give these tools can have an inverse relationship with our security and can compound an attack surface when you integrate software or services. My use case was superficial, but the use cases for AI agents promoted by tech companies are much more technical and sensitive. Increasing the functionality of these agents in a production environment would require extensive safeproofing especially if sensitive information is involved. One might also think about how these new technologies will affect standards set by NIST and ISO. The challenge of establishing an auditable standard for these tools is not lost on me. As I familiarize myself with cutting edge AI tech, the concerns about infrastructure and cost become less pronounced, while the challenges that come with securing and utilizing these tools remain top of mind. The leverage AI can unlock belongs to those who can strike this balance between efficacy and security.