Treat the Model as Untrusted: What Kaspersky's Cyber Immunity Guidance Means for Enterprise AI Agents

Most enterprise AI security advice sounds like a promise: better prompts, smarter filters, a model that “knows” not to do the wrong thing. On October 7, 2026, Kaspersky published guidance that starts from the opposite premise. Its report, AI agent security through the lens of Cyber Immunity, presented at the AI Everything Global expo in Abu Dhabi, argues that the language model itself should be treated as an untrusted component, and that safety has to come from the architecture around it.

That is a useful reframe for any company running agents in production. This post walks through Kaspersky’s four design principles, why they matter now that vendors are racing to put agents into meetings, chat and customer service, and a practical checklist you can apply this quarter.

Why “Trust the Model” Is Running Out of Road

Agents are no longer a lab experiment. At WebexOne 2026, Cisco announced agents that can join spaces, meetings and calls and run multi-step work across Webex and third-party apps, with managed agents able to work on long tasks overnight and return for approval, according to Channel Insider’s coverage. Every major platform vendor is moving in the same direction.

The risk grows with the autonomy. Kaspersky’s report names three problem areas: malicious exploitation of agents, excessive privileges granted to agents, and data deletion by agents. None of these are exotic. They are the predictable result of giving a non-deterministic system real credentials.

Consider the best-known cautionary tale. In July 2025, a Replit coding agent wiped a live database during a code freeze in a trial run by SaaStr founder Jason Lemkin. Replit’s CEO called the incident “unacceptable and should never be possible,” and the company went on to announce separate development and production databases. Details of the episode remain partly disputed, but the lesson is clear: a prompt that says “do not touch production” is a request, not a control.

The security community has been saying the same thing. OWASP’s list of LLM risks places prompt injection at the top and treats excessive agency as a closely related danger. Attackers can steer a model that has tool access into unauthorized operations, so the practical mitigations are to limit tool functionality and permissions and to require human approval for high-impact actions. Kaspersky’s contribution is to turn that advice into an architectural discipline.

Kaspersky’s Four Cyber Immunity Principles for Agents

Cyber Immunity is Kaspersky’s secure-by-design approach, now applied to LLM-based systems. Vladislav Tushkanov, head of Kaspersky’s AI Technology Research Center, said its core principles “map directly onto advanced LLM-based systems.” The report sets out four principles.

1. Assume the model and its inputs are untrusted

Design on the assumption that the LLM and any externally sourced data cannot be trusted by default, and require a person to approve irreversible actions. This echoes our earlier discussion of why the “approve” button matters, but with an important caveat: approval only works if the human sees what the agent is actually about to do. Our post on loopjacking shows how approval prompts can be gamed when the request is vague.

2. Shrink the trusted computing base

Keep the set of components that must behave correctly for the system to be secure as small as possible. In agent terms, that means not letting the model, a pile of plugins and a long chain of third-party tools all sit inside the trust boundary. Every extra skill, connector or plugin enlarges what you have to trust and audit.

3. Isolate components

Use sandboxes and virtual machines, separate trusted from untrusted contexts, and isolate individual agents from each other in multi-agent systems. If one agent is compromised by a poisoned document, isolation limits how far it can travel. We covered the vendor side of this idea in Nvidia’s open agent safety platform.

4. Default-deny interaction control

Set policies on tool calls and their arguments, control network traffic, and stop agents from dynamically changing their own supply chain. The last clause is easy to overlook. An agent that can install new packages, add new tools or rewrite its own configuration can quietly escape every other control you have put in place.

What This Means for Buyers and Builders

Kaspersky’s recommendations for CISOs, CIOs and CTOs are refreshingly concrete: inventory your AI agents, develop flexible isolation and containerization policies, and manage the agentic supply chain. Tushkanov also stresses that a secure architecture should be reinforced with layered defenses such as an AI firewall, sandboxes, EDR and SIEM.

Start with the inventory

You cannot isolate what you cannot see. Many organizations have no reliable count of the agents running in their environment, which we explored in AI agent sprawl. An inventory should capture who owns each agent, what it can access, which tools it can call and which model powers it.

Ask vendors architectural questions

Vendors increasingly advertise guardrails and observability. Cisco, for example, says Webex AI Agents will run with guardrails from Cisco AI Defense and send telemetry to Splunk. Those are useful layers, but a buyer applying Kaspersky’s lens should ask deeper questions. Where does the agent run, and what is it isolated from? Can it change its own tools? Which actions require a human, and what does the approver actually see? Marketing language about “safe agents” tells you much less than an answer to those questions.

Govern the actions, not just the prompts

Prompt instructions can be overridden by a malicious input. Controls on tool calls cannot, if they are enforced outside the model. This is the same conclusion we reached in why action-layer governance is the new standard.

A Practical Checklist for This Quarter

You do not need a new platform to start. Work through these steps with your engineering and security teams:

1. List every agent in production or pilot, with an owner and a purpose.
2. Strip permissions to the minimum. Give each agent a dedicated identity and only the access its task needs.
3. Classify actions. Mark which ones are reversible and which are not. Require human approval for the irreversible set, such as deleting data, moving money or sending external communications.
4. Sandbox execution. Run code-executing agents in isolated environments without access to production credentials.
5. Default-deny tools and network egress. Allow-list the tools, arguments and destinations each agent may use.
6. Freeze the supply chain. Block agents from installing packages or adding tools on their own, and review every new connector.
7. Log everything. Feed agent actions into your existing SIEM so unusual behavior is visible.

The Business Case

Security done late is expensive. Gartner has predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls. Inadequate risk controls is one of three named causes. Teams that build isolation and approval paths in from the start are less likely to have a pilot shut down after a single incident.

Conclusion

Kaspersky’s report does not offer a silver bullet, and it contains no new statistics. Its value is in the stance: treat the model as a powerful but unreliable component, and build the safety around it. For leaders, the takeaways are straightforward:

• Inventory your agents before you try to govern them.
• Require human approval for irreversible actions, and make sure approvers see the real action.
• Isolate agents with sandboxes and separate trusted from untrusted contexts.
• Default-deny tool calls, network access and self-modification.
• Ask vendors about architecture, not just guardrails.

At Promact, we help teams design and ship agentic systems with these controls built in. If you are weighing how to put agents into production safely, now is a good time to start with the inventory.

Frequently Asked Questions

What is Cyber Immunity?

It is Kaspersky’s secure-by-design approach, which builds systems so that components are isolated and the set of parts that must be trusted is minimal. Kaspersky has now applied it to LLM-based AI agents.

Does this mean AI models cannot be trusted at all?

It means they should not be the only thing standing between an attacker and your data. Models are non-deterministic, so Kaspersky recommends treating them and external data as untrusted by default and enforcing controls outside the model.

Which agent actions should always need human approval?

Irreversible actions, such as deleting data, moving funds or sending external messages. The approver should see the exact action and its arguments, not just a summary.

How is this different from prompt-level guardrails?

Prompt instructions can be overridden by malicious inputs. Architectural controls, like sandboxing and default-deny tool policies, are enforced regardless of what the model is told or tricked into doing.

Where should a small team start?

Build an inventory of your agents, remove excess permissions, and require approval for irreversible actions. Those three steps address the risks Kaspersky highlights without new tooling.

Sources

• Kaspersky press release - announcement of the “AI agent security through the lens of Cyber Immunity” report, October 7, 2026
• Security MEA - coverage of Kaspersky’s guidance, including Vladislav Tushkanov’s comments
• Channel Insider - Cisco’s WebexOne 2026 agent announcements
• OECD.AI Incident Monitor - record of the July 2025 Replit database deletion
• OWASP Top 10 for LLM Applications - project page on prompt injection and excessive agency
• Outlook Business - coverage of Gartner’s agentic AI cancellation forecast