The Lobster That Broke the Internet And Maybe Security | Agentic & Distributed Systems, DeFi, and Compute Economics

OpenClaw makes the appeal of AI agents obvious. The harder question is how much access to give them, and who controls what happens next.

AI agents that actually do things are here.

A lobster-themed project called OpenClaw connects models to your messages, files, and tools that can take action. Instead of explaining how to deal with an email, an assistant could read the thread, find the details you need, and prepare a reply for you to check. That's work I would gladly hand off.

Sending it is a different question.

That's where I want to start this blog. I build with these tools. I'm excited about what they make possible. I also want to decide how far into my life they get to reach.

What is OpenClaw?

Remember when Siri and Alexa were supposed to be personal assistants? I wanted more than what we got. Less telling me how to do something. More helping me get it done.

Apparently that promise comes with a lobster now.

OpenClaw is software for running a personal AI assistant, connecting models to tools and the messaging services you use. In his January 29 introduction, creator Peter Steinberger described a project that started as a WhatsApp relay and grew into something much broader.

OpenClaw isn't itself the language model. The model interprets the request and proposes what to do. The surrounding software, or runtime, brings in messages, makes tools available, and carries out the actions the model requests within the permissions you've configured. It's the difference between an answer in a chat window and something happening in your account.

Take that email reply. Say I ask an assistant to read one thread, pull out the questions I still need to answer, and draft a response. With the right connections, it could do the preparation without making me copy everything between windows. I could check the facts, change the wording, and decide whether to send it.

That is already an assistant worth building. It doesn't need to run my whole life to save me some work.

Whether it does the job correctly depends on the model, the integrations, and the task. The models still need to improve. But a smarter model alone doesn't decide which messages it can read or whether it can press send. Those decisions live in the software around it, and they change what a mistake can cost.

The security problem

Now imagine the thread includes a hostile email telling the assistant to fetch a private file and send it somewhere else. The assistant was asked to read a message. The sender is trying to turn that reading access into authority over something else.

That's indirect prompt injection: instructions arriving inside material the agent was supposed to read as data. OWASP's prompt-injection guidance describes the risk, including disclosure of sensitive information and unauthorized use of connected functions.

There are documented failures in this broader category. CVE-2025-32711 records an AI command-injection vulnerability in Microsoft 365 Copilot that allowed an unauthorized attacker to disclose information over a network. That is a specific Microsoft vulnerability, not an OpenClaw flaw or evidence that patched installations remain vulnerable.

An email asking for a private file should not become permission to send it. The person who wrote the email doesn't get to borrow my account just because my assistant is reading their words.

Models can reject malicious instructions. They can also fail. I don't want the safety of my files to depend entirely on the model interpreting every sentence correctly. If the task is to prepare a reply, why give that run a tool that can send unrelated files in the first place?

OpenClaw's launch post acknowledged prompt injection as an unresolved industry problem and described security-hardening work. Particular bugs can be patched while the broader problem still needs layers of protection. And a stolen credential or a badly exposed service doesn't need to persuade a model of anything. Running an agent means taking responsibility for ordinary software security too.

What defense actually looks like

I build AI agent infrastructure. On my platform, that meant persistent agents connected to real services. The security architecture took longer than the feature.

That work didn't earn me the right to call the result safe. It made me care about the decisions hidden inside something as simple as “connect your email.” Which messages? Which tools? Who gets to approve what leaves the account?

For the reply task, I would start with access to the thread and a place to prepare the draft. Not the whole file system. Not every credential on the machine. Sending can wait for me.

The same approach extends beyond email:

Least privilege. Give a tool only the access its job needs. Keep a research task away from credentials and unrelated private files. Don't bundle sending permission into a task that only needs to read.
Treat outside content as untrusted. Mark where it came from and use filters to catch suspicious material. Filters can miss attacks; passing a scan must not grant new authority.
Control outbound actions and data. Enforce destination and data restrictions outside the model. Require human approval before a new recipient, a payment, a destructive change, or another consequential action. An approved address is not permission to send it every private thing the agent can read. Show what will leave, not just where it will go.
Bound the work. Limit tool calls, spending, messages, and file changes. Limits can reduce damage or runaway cost. They won't prevent a single sensitive file from leaking.
Keep a useful audit trail. Record actions and approval decisions somewhere the agent cannot casually rewrite. Protect those logs and minimize the sensitive information in them. I want to know what happened without making another copy of every secret.

OWASP recommends least privilege, human approval for high-risk actions, separating external content, and adversarial testing. These are controls to implement and test, not magic words to put in a system prompt.

So I would test the reply task both ways. Can the assistant prepare a useful response? And if the thread contains hostile instructions, can it reach an unrelated file or send anything I never approved? A good draft doesn't compensate for a failed boundary.

These are the boundaries I'd start with, not a claim that every one is already enforced by OpenClaw or my platform. The work is proving what a particular setup permits, including when the model gets it wrong.

The autonomy tradeoff

I still want the reply prepared. The risk hasn't made the useful part disappear.

That's what gets lost when the choice is framed as a useless chatbot or an agent with the keys to everything. Reading, drafting, and sending are different permissions. Proposing a code change and deploying it are different permissions. An assistant can do a lot of the work without owning the final decision.

An assistant that asks about every harmless step is frustrating. One that quietly takes an irreversible action is worse. I want the routine preparation to happen without a conversation about every tool call, then a clear stop where the consequences change.

For an email, that means letting me review the actual message and recipient before it goes out. If I later choose to automate a narrow class of replies, that should be a deliberate permission change, not something the assistant assumes because I approved yesterday's draft.

More autonomy is not automatically more value. Sometimes the valuable part is doing the preparation well enough that I can make a better decision.

The compute question

There's another question before I hand over that thread: where does it go?

A personal assistant running on my computer does not necessarily mean the AI is running there. The agent software can be local while sending prompts to a cloud model. Email, messaging, and other connected services can still move data off the machine. “Self-hosted” tells me where one part of the system lives, not the whole path my information takes.

If the model and the work stay entirely on hardware I control, I have more control over that processing. I also have to supply the hardware, power, maintenance, and a model that is good enough for the job. I would choose between those arrangements based on the work, rather than assume buying a computer settles it.

But tracing the work to a cloud service also means tracing it to somebody else's community. The convenience reaches me through a screen. The electricity, cooling water, and infrastructure have to come from somewhere.

When a data center is proposed, I want to know who pays for that infrastructure, what demands it places on local resources, and what the surrounding community gets to decide. People living nearby may not be the people using my assistant or collecting revenue from it. They still have a stake in the decision.

I especially don't want communities with less political power treated as places to put costs that wealthier users don't have to see. The benefits and burdens need to be argued in public, project by project. The person who gets a useful email draft isn't the only person whose interests count.

Local AI changes who controls a particular workload and whether it needs to leave the device. It doesn't erase electricity use or the cost of manufacturing hardware. I care about having that option, and I care about who bears the consequences of the option I choose.

What comes next

I think the agent layer will become a major point of competition.

The place where AI connects to your email, your calendar, your files, your money. The place where it stops answering questions and starts doing work.

Whoever controls that layer can shape which models you use, which tools you can connect, and how difficult it is to leave. They can also make broad access the easy default or make narrow permissions understandable. Those product decisions affect how much control a person actually has, not just what a settings page says they have.

An open project is worth paying attention to because it offers another way to organize that relationship. It still has to earn trust through its code and its behavior. I don't know which project will win. I care whether the work, the instructions, and the permissions remain understandable to the person using the system.

Someone should be able to stop at drafting, revoke access, or decide they don't want an agent connected to their accounts at all. Building a more capable assistant doesn't entitle its builder to make that choice for them.

People want AI that operates, not only AI that talks. I do too.

I want the help without giving up the right to decide what it can do.