Security is a product decision, not a checklist.

AI agents are moving from demos to production: calling APIs, accessing databases, executing code and making decisions.

I've been building Oktsec because of what I keep finding when I review how those agents are wired up: the security gap is real, and it is growing faster than the tooling that would close it.

Patterns in MCP servers and configs

Reviewing MCP servers and agent configurations, the same patterns keep showing up.

Tool poisoning is a documented attack technique. MCP servers can inject instructions into tool descriptions that override agent behavior, even when the server’s executable code has not changed. Authentication is optional by design: the MCP authorization specification marks authorization as OPTIONAL and defines it only for HTTP transports, so a server exposed with no authentication is a configuration the protocol permits, and, without application-level access controls, reachable tools may be callable by an unauthenticated requester. Agents that connect to multiple MCP servers create implicit trust chains, and a compromised server may try to steer calls to other connected servers, subject to host and server controls. On top of that, check whether sensitive data can pass between tools without filtering or an enforced destination policy.

CVE-2025-49596, published in June 2025, is the concrete version of the second pattern: MCP Inspector shipped without authentication between its client and its proxy, so unauthenticated requests could launch MCP commands over stdio, which is remote code execution (CVSS 9.4, fixed in 0.14.1).

Where agent security differs

AI agent security is different from traditional AppSec because its attack surface is dynamic, its trust boundaries are implicit and its supply chain is barely reviewed. 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. A client that exposes every advertised tool without review can grant more access than the workflow needs. Granular permissions and least privilege are possible, but the host and server must implement and enforce them.

The supply chain needs a review process. 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. Vulnerability tracking exists: CVE-2025-49596 (MCP Inspector, June 2025) and CVE-2025-6514 (mcp-remote, July 2025, OS command injection from a crafted authorization_endpoint URL, CVSS 9.6, affecting versions 0.0.5 through 0.1.15) were both published before this article. What is uneven is adoption. A registry page or pasted configuration is not evidence that the selected version has been checked against current advisories. Verify that check in the actual installation path.

What should a team refuse to ship?

Security is decided by what you leave out of the release. Two examples of features I would not ship before authorization exists. First, an agent with write access to a production system (a database, a deployment pipeline, a customer messaging channel) and no per action policy in front of it. Read access also needs limits before use: disclosed data cannot be recalled. Writes additionally require controls for integrity and recovery. Until each write is evaluated against identity, tool, arguments and destination, ship the agent read only or do not ship it. Second, an MCP server reachable over the network without authentication. CVE-2025-49596 illustrates the risk of an unauthenticated management interface. Internal reachability should be constrained and tested; it does not replace authentication for sensitive tools.

Building security alongside agents

There's a narrow window where we can establish security patterns for this ecosystem before it calcifies. Web security got its safe defaults eventually, but it got them after the attack classes were well understood and widely exploited. If we don't build the security infrastructure for agents now, we'll be retrofitting it onto a broken foundation for years.

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 two layers: Oktsec Cloud as the managed control plane and Oktsec Control at the execution boundary, where the tool call is about to run.

New MCP servers appear daily, existing ones get updated and novel attack patterns emerge, so the review has to repeat rather than happen once.

Security tooling for a new ecosystem needs inspectable controls, clear evidence and operating guarantees that security teams can trust. That is the bar for production adoption.

Before deployment, test one permitted action, one action outside scope and the record each leaves behind.