Kaspersky published guidelines on securing AI agents on October 7, presented at AI Everything Global in Abu Dhabi, alongside a report called “AI agent security through the lens of Cyber Immunity.” I’ve only read the press release, not the report. It is a vendor publication that also promotes Kaspersky products, and it contains no incident statistics, so I’m treating it as a framework worth borrowing, not evidence.

The three risks it names

  1. Malicious exploitation of agents
  2. Excessive privileges granted to agents
  3. Data deletion by agents

Those map closely onto real stories I’ve covered, from Anthropic’s evaluation incidents to the permission fixes in Claude Code.

The four design principles

  1. Set security assumptions at design time. Treat the language model, and any externally sourced data, as untrusted by default. Require explicit human confirmation for irreversible actions.
  2. Minimize the trusted computing base. Keep the set of components that must be trusted as small as possible.
  3. Isolate components. Use sandboxes and virtual machines, separate trusted from untrusted contexts, and isolate individual agents in multi-agent systems.
  4. Control interactions, default-deny. Apply policies to tool calls and their arguments, control network traffic, and stop agents from dynamically modifying their own supply chain.

Kaspersky’s Vladislav Tushkanov adds that a secure architecture should be reinforced with layers (the company names an AI firewall, sandboxes, EDR and SIEM) and that models should be treated as “fundamentally non-deterministic and untrusted.”

For leaders: three actions

  • Inventory your agents. You can’t govern what you haven’t listed.
  • Write flexible isolation and containerization policies.
  • Manage the agentic supply chain, meaning what an agent installs, fetches and connects to.

Turning it into a checklist for a coding agent

This is my translation, not Kaspersky’s:

  • Untrusted model: assume a prompt injection in a README or issue can steer your agent. Don’t let it hold secrets it doesn’t need.
  • Small trusted base: run the agent in a container or VM, or at least a separate user, with only the repository it needs mounted.
  • Isolation: one agent, one workspace. Worktrees help; see the Codex worktrees post.
  • Default-deny: allowlist commands and network destinations. Hooks that block on failure are a practical way to do that.
  • Human confirmation for the irreversible: deletes, force-pushes, deploys, payments.
  • Supply chain: pin dependencies, review what an agent installs, and remember the Malfex npm campaign.

Why now

The security stories keep stacking up: the LiteLLM MCP bypass, two MCP flaws, and a reported campaign that used open-source agents against 27 companies. Different problems, same shape: something trusted a thing it shouldn’t, or had more access than the job needed.

A vendor checklist isn’t proof of anything, but “assume the model is untrusted” is a good default regardless of who says it.

Source: Kaspersky press release.