We're in the middle of the biggest infrastructure shift since cloud computing. AI agents are moving from demos to production, calling APIs, accessing databases, executing code, making decisions. Most of them are running with zero security checks.
I've been building Oktsec precisely because of what I keep finding: the AI agent ecosystem has a massive security gap, and it's growing faster than anyone is addressing it.
What am I seeing across MCP servers and agent configs?
After scanning thousands of MCP servers and agent configurations, the patterns are consistent and alarming.
Tool poisoning is everywhere. MCP servers can inject instructions into tool descriptions that override agent behavior. Most developers don't even know this attack vector exists. The majority of MCP servers have zero authentication, so anyone who can reach the endpoint can invoke any tool. Agents that connect to multiple MCP servers create implicit trust chains, and a compromised server can use the agent's access to reach every other server it's connected to. On top of that, agents routinely pass sensitive data between tools without any filtering or boundary enforcement.
These aren't theoretical risks. They're in production systems right now.
Why is AI agent security different from traditional AppSec?
AI agent security is fundamentally different from traditional AppSec because its attack surface is dynamic, its trust boundaries are implicit, and its supply chain is unaudited. Traditional application security has decades of tooling, frameworks, and best practices. SQL injection, XSS, CSRF: we have scanners, WAFs, and established patterns to prevent them.
The attack surface is dynamic. An agent's behavior depends on its prompt, the tools available, and the runtime context. The same agent can behave safely in one configuration and be completely vulnerable in another.
Trust boundaries are implicit. When an agent connects to an MCP server, it implicitly trusts every tool that server exposes. There's no granular permission model, no capability-based security, no principle of least privilege applied at the tool level.
The supply chain is unaudited. Developers are adding MCP servers to their agents the way they used to add npm packages: by searching a registry and installing whatever looks useful. Except there's no equivalent of npm audit, no vulnerability database, no CVE tracking.
That's exactly why the ecosystem needs continuous monitoring, tracking what's published across the major registries and flagging threats before they reach production.
Why is now the moment to build agent security?
There's a narrow window where we can establish security patterns for this ecosystem before it calcifies. The same thing happened with web security: it took a decade of painful breaches before OWASP, CSP headers, and security-by-default frameworks became standard.
We don't have a decade. Agent adoption is moving at AI speed. If we don't build the security infrastructure now, we'll be retrofitting it onto a broken foundation for years.
That's what I'm focused on. Not AI security as a feature. AI agent security as infrastructure.
What needs to happen to secure AI agents?
Every MCP server and agent configuration should be scanned for known vulnerability patterns before going live, the same way you would audit any other dependency.
Static scanning isn't enough on its own. Agents need runtime security policies that prevent unauthorized actions as they happen. Oktsec handles this at the MCP gateway layer.
New MCP servers appear daily, existing ones get updated, and novel attack patterns emerge. Continuous monitoring isn't optional. It's the baseline.
Security tooling for a new ecosystem can't be locked behind vendor gates. The community needs to be able to inspect, contribute to, and build on these tools. Everything we build is open-source for that reason.
If you're deploying AI agents in production, the time to think about security is not after the first incident. It's now.