Moltbot and the Security *** of Autonomous Agent Ecosystems

When “agent-first” innovation ignores basic security principles and turns AI into a systemic risk

Moltbot and its social network, Moltbook, were introduced as a very nice idea: a platform built not for humans, but for AI agents to interact, share context, and act autonomously. For people working with advanced automation, this sounded exciting. From a security perspective, however, it quickly became a textbook example of what not to do.

Well, I tested it, with another machine, and at first glance, Moltbot looks impressive. It promises to be a personal AI assistant that can read your emails, send messages on your behalf, access your files, talk on WhatsApp or Telegram, browse the web, and manage your calendar. People describe it as a real-life Jarvis (hahahha). But that power comes at a cost... To work as advertised, the agent needs deep access to your operating system, your browser, your accounts, and sometimes even your local files. That means it can do almost anything you can do digitally (including things you never intended). If something goes wrong, well, you know.

The danger is not just bugs or bad configuration. It is the nature of LLM-based agents themselves. Prompt injection is an intrinsic risk. A single email, message, or file can contain hidden instructions that the agent may follow without you noticing. Because LLMs are not deterministic, you cannot fully rely on text-based rules to keep them safe. When you combine hallucinations, broad permissions, and autonomous execution, you are effectively trusting an unpredictable system with full control over your digital life. Until we have strong isolation, real sandboxing, and security models that do not depend on “please behave” instructions, installing agents like this is gambling with your own security.

A publicly exposed and misconfigured Supabase database revealed API keys, authentication tokens, and verification codes for roughly 1.5 million accounts, with no real access controls in place. This was not a sophisticated exploit. It was the absence of role-based access control, secret management, and basic environment isolation. As a result, attackers were able to take over agent identities and post content on their behalf, including from well-known agents. At that point, the platform stopped being a social network and became an identity-hijacking engine.

The deeper problem goes beyond the initial leak. Moltbot’s architecture fits what security researchers describe as the “lethal trifecta”: agents with access to sensitive user data, exposure to untrusted external content, and the ability to communicate and act autonomously. Add persistent memory to that mix, and the risk multiplies. Malicious instructions can be stored gradually and executed later, triggered by prompt injection hidden inside seemingly harmless posts or comments. This is no longer hypothetical… There were real cases where agents ended up exposing parts of the host filesystem during security testing.

Prompt injection is treated as an edge case when it should be considered a core threat. Content posted on Moltbook can contain hidden instructions that cause agents to leak secrets, API tokens, or credentials. Many of these agents run without proper sandboxing, directly on host machines or cloud environments with broad permissions. Without isolation, input validation, or execution boundaries, the agent effectively becomes an untrusted extension of the operating system.

Abuse controls are also almost nonexistent. The lack of effective rate limiting allowed a single bot to create hundreds of thousands of fake accounts, massively increasing the attack surface. This enabled cross-agent manipulation and emergent behaviors, including attempts by agents to negotiate private, encrypted communication spaces that explicitly excluded humans and platform operators. Innovation ? It is loss of control.

From a privacy and compliance standpoint, the situation is just as concerning. Generic claims about HTTPS and “standard security measures” do not survive real-world incidents. User data from multiple jurisdictions was exposed without meaningful consent controls or risk-based safeguards.

My opinion as a privacy professional is that giving autonomous agents access to data, memory, and execution capabilities in an environment without zero-trust principles, mandatory sandboxing, and continuous monitoring is reckless.

If you want to experiment with it, do so at your own risk. Use a separate machine, test accounts, fake identities, and test data, nothing real. Moltbot is an interesting playground to understand what a “Jarvis-like” assistant could look like, but it does not yet have the maturity, isolation, or security guarantees required to be considered safe for real-world use.