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”.
Let’s be real, local-first tooling is an essential capability when your internet is not stable, in a world where every cloud service out-there is frequently crashing, not to mention speed-privacy-ownership concerns while sending code, prompts, logs, or half-baked ideas to a remote API.
To avoid all these noise and make my workflow more autonomous-quicker-stable-private I made a machine where I can code with an AI assistant Locally and Fully Offline.
I do not think everyone should run a local coding model, this is still a serious tech task. But if you enjoy owning and playing with your stack, and you have the hardware for it, it can be a very satisfying experience.
This is a Debian machine with 64 GB GPU and OpenCode as the coding agent with llama.cpp .
When you get your local llama-server running, OpenCode talks to it like it would talk to any OpenAI-compatible provider.
The difference is that the whole loop stays on my local machine.
Neat!
Running Qwen3.6 27B Q8_0 with 256k context in reasoning mode loads around 50GB of the GPU memory and gives around 64 tokens/s for prompt+generation.
That is quite good for a local model with that much context.
Qwen3.6 27B at 256k context is about three times slower compared to a hosted frontier model.
You have to care about model storage, updates, server flags, GPU memory, and cooling.
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:
While this example only starts a notepad, the same method can be used to distribute ransomware, steal credentials, or maintain persistence.
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 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.
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.
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.
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.
This is a structural challenge in how we build and trust AI.
Here’s how to protect your stack:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
As you probably know GSAP (GreenSock Animation Platform) is a powerful JavaScript library used for creating high-performance animations in web development.
I put my creative touch on this for you, hope you love it!
See the Text Twister on CodePen.
Vibe Coding, a technique aimed at creating an optimal “vibe” or environment to enhance coding flow.
It sounds attractive at first glance, but here is the reality.
Why is that?
The answer lies in the fact that vibe coding requires solid foundational skills and discipline, developed only by independently finishing projects.
This is not about newbies entering the industry from other fields, in those situations, exploration is fundamental.
But for devs that have intention to advance, building the full stack of skills from personal experience first will keep you grounded and make your vibe coding really and profoundly productive.
To mitigate privacy risks it is essential for the organizations to implement broad technical and operational measures.
Grant agents only the minimum permissions necessary to perform specific tasks, preventing the catastrophic consequences of excessive agency.
Implement federated learning to train models without centralizing sensitive data, use differential privacy to add mathematical noise that protects individual privacy, and develop machine unlearning capabilities to address the right to be forgotten.
Encrypt data at rest and in transit, authenticate all requests, and regularly audit third-party services for security and compliance.
Integrate human oversight at critical decision points, especially for high-stakes decisions with financial, legal, or safety implications. This creates verifiable audit trails and restores accountability.
Implement ongoing auditing to detect model drift, track data provenance, and ensure compliance. Maintain tamper-proof, human-verifiable audit trails.
Train employees on privacy risks and set up clear policies for handling sensitive data and autonomous agents.
Autonomous AI Agents engage with data throughout its entire lifecycle and this creates multiple points of vulnerability.
To function effectively, these systems routinely handle terabytes or petabytes of data, including sensitive information like healthcare records, financial data, and biometric information. The sheer volume increases the probability of data exposure.
Information collected for one purpose may be used for completely different, unforeseen purposes without the user’s knowledge. A notable example involved a surgical patient who discovered that medical photos she had consented to for treatment were used in an AI training dataset without her permission.
The persistent memory of autonomous agents and decreasing storage costs mean information can be stored indefinitely, potentially outlasting the person who created it. This is problematic because privacy preferences change over time – consent given in early adulthood may lead to data being used in ways an individual would no longer agree to later in life.
Agents may unknowingly collect information about individuals who weren’t the intended subjects of data collection, such as bystanders who appear in photos or conversations.
The independent nature of autonomous agents fundamentally transforms the security threat landscape through a concept known as “Excessive Agency” – agents having too much functionality, permissions, and autonomy.
Autonomous AI Agents have few built-in hazards due to their operational nature.
As AI models grow more complex, they can develop emergent abilities that were not explicitly programmed. These unintentional results can lead to unexpected and harmful outcomes, such as an agent optimizing server speed by deleting security monitoring software.
Numerous AI models run as “black boxes”, making it hard to understand how they make decisions or use data. This counteracts accountability and makes it difficult to identify biases that could lead to discriminatory outcomes.