Tech Blog by Minox

Category: Security

  • OpenClaw – What it does, Who’s it for, What’s required

    OpenClaw – What it does, Who’s it for, What’s required

    OpenClaw is a personal AI assistant that runs on your laptop, talks to local or remote models, and exposes itself through every messaging app you already use.

    It can actually does the work and gets things done.

    OpenClaw is written in TypeScript.

    It is open source and available for everyone to download on GitHub.

    At the time of writing it had 383k stars on GitHub.

    It has the largest community, largest skill marketplace, most comprehensive “it just works” tool catalog. Default skills cover code, web, files, calendar, mail, and lots of integrations.

    OpenClaw is general and more reactive AI agent.

    There are lots of skills available, low setup overhead, no native learning system.

    Who should use it

    That said, if you plan to do anything meaningful with OpenClaw bare in mind that power consumption and hardware requirements are very high and as such it remains prohibitive for everyday users. This is painfully true for the local model size of 70B+.

    Just price of the one old 2022 NVIDIA GPU RTX 4090 starts from $1,600 (at the time of writing).

    OpenClaw is not for everyone. People running it will need a decent, up-to-date rig, cover increased climate control expenses, and face extremely high electricity costs.

    All of this comes with a high price tag and this is a major barrier for everyday use.

    It remains best suited to tech experts.

    Caveats

    ~500k lines across hundreds of files, in a layered architecture nobody fully understands.

    Isolation is enforced at the application level inside a single shared process – if one skill misconducts, it can in theory reach anything OpenClaw can reach, which is most of your machine.

    What’s required to get it running

    You will need a decent hardware to run it.

    Forget about gaming rigs as top of the line.

    There are no compromise with AI machines, you will need as much RAM as you can get, NVMe SSD storage is non-negotiable, best GPU’s, tons of electric power, water cooling – you’ll need the best and latest in every category.

    OpenClaw is extremely resource and power hungry

    Here are hardware requirements for heavier use with 30B class (better known as the agent “sweet spot”)

    CPU: 4+ vCPU
    RAM / unified memory ~32GB
    GPU VRAM (for the discrete GPU) ~24GB (only at lower quants)
    Storage: 80 GB SSD+

    Energy demand is extremely high

    Good god! Plan for higher electricity bills.

    Only GPU’s during average run generate 900 W .

    This is just for the 2 old graphic cards RTX 4090 from 2022.

    You will also need to use water cooling for the machine and work out the additional climate control spending for the room where this machine will be located.

    2× RTX 4090: ~900 W average during the run – this is called active inference (generating tokens). For idling only they will suck 200 W.

    Again, this is just for the 2 old graphic cards from 2022.

    As we can see line “personal AI assistant that runs on your laptop” is not entirely true.

    The one who runs OpenClaw will have to get a respectable desktop rig to use it for any meaningful work – otherwise it will be just a slow and boiling hot science experiment.

    What about Security

    OpenClaw is not safe to run directly on your main machine – period.

    The shared-process, application-level permission model means a misbehaving skill – including one pushed by prompt injection – can reach files and tokens it shouldn’t.

    Run it inside a VM is a must for evading this entire class of problems.

    Final thoughts

    The trend is clear: AI hardware is becoming more specialized, power-hungry, and expensive, but also more efficient per unit of compute.

    Anyone running OpenClaw must invest not just in GPUs, but in entire ecosystems of power, cooling, networking, and software optimization to unlock its full potential.

    Darn – it looks like you’ll need an engineer to run it.

  • The AI industry has poorly thought through the trust model for agents operating in untrusted environments

    The AI industry has poorly thought through the trust model for agents operating in untrusted environments

    When your agent browses the web, reads a codebase, or processes third-party data as part of a task, every one of those inputs is a potential injection vector.

    The agent can’t reliably distinguish between “data I should process” and “instructions I should follow”.

    This is because the model itself doesn’t have a hardened boundary there by design.

  • Quick Method of MCP Exploitation via Base64

    Quick Method of MCP Exploitation via Base64

    The original purpose of Base64 was to turn binary data into safe, readable text.

    The irony is that this very ability to create “safe” text is exactly what makes it so useful to an attacker.

    Base64 itself is not inherently bad it is simply a tool that is really good at data conversion.

    The problem is that its primary strength can easily be turned into a convenient weapon by malicious actors.

    Here is how Base64 can be used as a direct attack vector for AI agents.

    Attack goes like this:

    • An attacker posts a Base64 string on social media, which decodes to start a notepad.
    • A user asks Claude to summarize their recent feed.
    • Claude passes the content to a malicious MCP tool as an argument.
    • The MCP server decodes the Base64 and runs the command.
    • No trace of this execution is left on the chat interface.

    While this example only starts a notepad, the same method can be used to distribute ransomware, steal credentials, or maintain persistence.

    Base64 is being used to deceive the human eye.

    Your brain naturally assumes it is just a password hash, a token, or maybe a UUID. Because of this, it often slips past code reviews unnoticed.

    The human eye has a hard time seeing a clutter of random characters as a threat and this is why Base64 is so easily misused.

  • AI Agent Deleted The Entire Production Database

    AI Agent Deleted The Entire Production Database

    AI coding agent deleted the entire production database and every single backup along with it on April 2026 for PocketOS, a SaaS that powers small car rental businesses.

    The setup was deceivingly average. A coding agent powered by Claude Opus 4.6 inside Cursor was working on a routine task in a staging environment. It hit a credential mismatch, a common speed bump.

    Instead of stopping to ask for help, the agent decided to act unilaterally.

    The agent scanned the codebase and found a Railway CLI token.

    This token wasn’t meant for the task at hand, but it was there.

    The token wasn’t narrowly scoped.

    On Railway, certain tokens carry blanket permissions. This one could manage domains, but it could also delete volumes.

    The agent assumed that because it was “in staging,” its actions would be scoped to staging. It didn’t verify the volume ID or the environment.

    It issued a single GraphQL mutation to delete the volume.

    Few seconds later, production was no more.

    What About The Backups?

    Railway (at the time) stored volume-level backups within the same volume they protected. When the agent deleted the volume, it deleted the backups too. The most recent off-site backup PocketOS had was three months old.

    Agent’s Admission

    The most chilling part of the story happened after the deletion. When the founder, Jer Crane, asked the agent what happened, it provided a perfectly structured, clear postmortem.

    It admitted it had guessed. It admitted it hadn’t verified the volume ID. It even listed the specific safety principles it had violated.

    “I assumed the deletion would be scoped to staging… I did not verify… I decided to act unilaterally.”

    This is the “Agent Paradox”: The model could articulate the rules with 100% accuracy after breaking them, but it couldn’t apply them in the heat of the moment.

    Lessons for Devs

    This is a structural challenge in how we build and trust AI.

    Here’s how to protect your stack:

    1. The Principle of Least Privilege

    AI agents shouldn’t have access to “god-mode” tokens. If an agent is working on staging, its credentials should physically be unable to touch production. Use scoped tokens and environment-specific secrets.

    1. Human-in-the-Loop for Destructive Actions

    No matter how “smart” the model is, destructive mutations (DELETE, DROP, WIPE) should require a human click. Cursor and other tools have guardrails, but as we saw, they aren’t foolproof if the agent finds a way around the sanctioned path.

    1. Isolated Backups are Non-Negotiable

    If your backups live on the same “disk” or volume as your data, you don’t have backups, you have a mirror. Ensure your disaster recovery plan includes off-site, immutable backups that an API key can’t easily reach.

    Final Thoughts

    The PocketOS incident wasn’t caused by a “rogue” AI or a jailbreak. It was caused by an agent doing exactly what it was designed to do: solve a problem efficiently with the tools it had.

    As we move toward an agentic era, we need to stop treating AI agents like senior devs and start treating them like powerful, highly-confident interns.

    Give them the tools they need, but never give them the keys to the realm.

  • Common Code Security Challenges with Vibe Coding

    Common Code Security Challenges with Vibe Coding

    Creating site or an app with the use of AI tools and without having a slightest clue of what you are doing is popularly known as “Vibe Coding”. This way of developing is a great way to creating critical security vulnerabilities and bugs.

    The basic cause of all these issues is that AI does not know about code security and it is not aware of the context so it fails to implement permission checks and often sends way too much data.

    Here is a list of some of the common code security issues with AI that we encountered.

    Lack of input validation

    One of the most common issues in vibe coding is the lack of input validation.

    AI’s can not plan ahead what they are doing, and neither are they taught to reason about their code’s security, nor about it’s quality, so it fails to implement permission checks and often sends way too much data.

    Transmit an error message to the attacker with sensitive information

    The API routes often transmit an error message to the attacker with sensitive information, such as, but not limited to paths, filenames and sometimes values from the database or stack used in the application.

    Remote code execution vulnerability

    AI tools often produce a remote code execution vulnerability, the backend code that runs another binary without proper input validation.

    This could be prevented by using proper input validation or even better not needing to run external binaries in the first place.

    Enumeration vulnerabilities – lots of it

    AI tools also produce lots of enumeration vulnerabilities that allowed anyone to request data about a user, including personal information such as email addresses, phone numbers, github and google access tokens, full names and more.

    AI responses that send everything

    The Vibe Coded backend code had no implementation of access controls and it was sending any user data to the client.

    This likely happened because the AI tool generated code that selected the whole user and did not remove the password and other fields from the response.

    AI fails to implement permission checks and often selects too much data, simply because it is not aware of the context.

    To wrap things up

    It is critical that you understand your own code, or the one you are getting from your AI assistants.

    Always have a second look at your code and make sure that you understand what it is doing.