The Dark Side of AI Agents: What Nobody Talks About

I’ve watched AI enthusiasm outpace security awareness for a year. Here’s what keeps me up at night.

Not long ago, I came across OWASP’s State of Agentic AI Security and Governance — a dense, jargon-heavy report that nonetheless crystallized something I had been observing for months. AI initiatives are proliferating everywhere: corporate, grassroots, government, consumer. But behind the excitement, a serious problem is quietly taking root. Most people building with AI agents have little understanding of the security risks they’re taking on.

I’ll be candid: to this day, I don’t let any AI agent touch my photo albums, messages, or send emails on my behalf. Not because I distrust AI in principle — but because I’ve seen enough to know the attack surface is real, and the industry’s security hygiene hasn’t kept pace with adoption.

Here’s what I mean.

1. Sandboxing: The Illusion of Simplicity

When Openclaw surged in popularity in early 2026, it brought with it a wave of first-time self-hosters. The promise was irresistible — a personal AI assistant that does it all, running on your own machine. Early adopters (myself included) watched with some mix of admiration and unease as users who had never run a Linux command stood up their own instances by following a few lines of documentation.

That accessibility is genuinely impressive. But it papers over something important.

The users who came before — the ones running Arch Linux or Gentoo, or wrestling with ARM64 VM migrations from x86 on their new M-series Macs — earned their setup through friction. That friction taught them sandboxing, OS hardening, least-privilege access, and real-time monitoring. The new wave of Openclaw users skips all of that.

The result: a personal data vault with almost no safeguards. A casual nmap scan of a home network can surface an exposed Openclaw instance, and from there, your contacts, credentials, and OTPs become someone else’s problem. A recent Kaspersky report found zero-authentication deployments and API keys left in plaintext — easy pickings for automated scanners trawling the internet (source).

Enthusiasm without operational knowledge is a liability, not just for individuals but for teams.

2. Skills Poisoning: The Supply Chain Problem Nobody’s Talking About

Every major agentic platform — Claude Code, Openclaw, Hermes — shares one structural vulnerability: a community skill registry with insufficient vetting.

Think of skills as plugins. Anyone can publish one. On Clawhub, there is no equivalent of the seasoned community volunteers in traditional Linux package ecosystems who inspect compiled binaries, verify checksums, and flag suspicious behaviour before a package reaches users. Instead, Clawhub relies primarily on behavioural analysis — understanding what a skill would do when an agent executes it.

That gap is exactly what attackers exploit. The technique is called skills poisoning: a malicious actor publishes a skill with plausible-sounding documentation, embeds social engineering in the README or help text, and delivers an obfuscated payload to anyone who installs it. The attack works because users extend implicit trust to the registry, and because the stakes — agentic systems increasingly touching payment flows and sensitive APIs — are rising every month.

I’ll be watching closely as agentic payment systems mature. The combination of implicit trust, weak supply chain controls, and real financial access is exactly the kind of asymmetry that produces serious incidents.

3. MCP Servers: Better Accountability, but Not Zero Risk

Since Anthropic introduced the Model Context Protocol (MCP), it has become the de facto integration layer for AI tools — a standardised way for agents to execute REST commands against external services. Tools like mcporter in Openclaw or Hermes's built-in mcp add commands make adoption straightforward.

MCP does a few things right. It requires authentication (API keys or OAuth2), and it restricts the set of arguments an agent can pass to a tool. Here’s a typical configuration for a Notion MCP server:

json

{ "mcpServers": { "notion": { "command": "npx", "args": ["-y", "@notionhq/notion-mcp-server"], "env": { "NOTION_TOKEN": "$NOTION_TOKEN" } } } }

The structure enforces scope. That’s good. But implicit trust in any MCP server is still misplaced if that server carries unpatched vulnerabilities.

Case in point: CVE-2026–34742, which targets Go’s standard encoding/json library, affects all MCP servers written in Go. Responsible disclosure processes — where vendors receive a private heads-up, patch within a defined window, and only then allow public disclosure — help, but they require users to stay on top of updates. The moment you treat your MCP server as "set and forget," you're one unpatched dependency away from exposure.

For personal projects and critical corporate workflows, building and owning your MCP server is often the safer path. You control the patch cadence.

4. Integration Platforms: Convenience Versus Resilience

For teams managing long lists of APIs, integration platforms like n8n, Zapier, and Composio have become essential. Done well, they offer fine-grained OAuth scoping, prompt injection protection, and sensible permission boundaries. The efficiency gains are real.

But centralised integration platforms introduce a structural risk that often goes unacknowledged: single point of failure.

In May 2026, Composio experienced an outage lasting over 16 hours with a slow recovery. For teams running critical automation on top of it, that wasn’t an inconvenience — it was a full stop. When I’ve run personal projects through GCP integrations and third-party connectors, I’ve felt the fragility firsthand: when a connector fails, everything downstream fails with it.

The practical takeaway: for workflows that matter — anything touching finances, communications, or time-sensitive decisions — consider whether building directly against the REST endpoint gives you resilience that no managed integration platform can guarantee.

Where This Is Heading

AI security isn’t a niche concern for the technically paranoid. As agentic systems gain more real-world authority — scheduling, purchasing, communicating, making decisions — the security posture of every component in the stack becomes a business risk.

Add to that the looming threat to classical cryptography, and the picture sharpens further. AI security will occupy a central place in the technology conversation for at least the next five years.

The good news is that most of this is addressable. Proper sandboxing, supply chain scrutiny, vulnerability management for MCP dependencies, and resilient integration architecture aren’t exotic practices — they’re table stakes for anyone serious about building with agents.

The bad news is that the current wave of adoption is largely skipping them.

Inspired by OWASP’s State of Agentic AI Security and Governance report. The observations here are my own, drawn from a year of watching the agentic AI ecosystem evolve.