AI agents are evolving from digital assistants into active components of enterprise IT. They can operate applications, call APIs, modify files, develop software and increasingly perform security-related tasks. This fundamentally changes the risk profile: the critical issue is no longer only whether an AI produces the right answer, but what actions it is allowed to execute. In a new guidance paper, Kaspersky argues for a secure-by-design approach in which large language models and external inputs are treated as untrusted by default and potentially harmful actions are constrained at the architectural level.

The next phase of enterprise AI is likely to be shaped less by conversational interfaces and more by autonomous or semi-autonomous agents. Traditional generative AI primarily produces text, analysis or code. Agentic systems go further by accessing tools, interacting with corporate resources and carrying out multi-step tasks with limited human intervention.

This changes the nature of the security problem. An inaccurate response from a language model may create an information-quality issue. An agent that interprets a situation incorrectly and then deletes data, changes access rights, invokes an external service or executes software can create an operational incident.

Kaspersky addresses this shift in its new guidance paper, AI agent security through the lens of Cyber Immunity. Presented at AI Everything Global in Abu Dhabi, the document examines common agentic use cases, different degrees of autonomy and known incidents involving AI-driven actions. It applies principles from Kaspersky’s “Cyber Immunity” concept, a secure-by-design approach intended to keep critical system functions protected even when individual components fail or become compromised.

From language model to operational system

The security risk of an AI agent does not arise solely from the underlying large language model. It emerges from the combination of the model, the data it consumes, the tools it can invoke and the permissions it has been granted.

An agent may have access to email, files, databases, development environments, ticketing platforms, cloud infrastructure or external APIs. As more of these capabilities are combined, the agent’s operational reach increases accordingly. At the same time, large language models remain probabilistic systems whose behaviour cannot be fully predicted in every situation.

Kaspersky therefore starts from a strict assumption: the language model itself, as well as data received from external sources, should be treated as untrusted by default. External content can be manipulated and may influence the agent’s behaviour in ways that are difficult to anticipate.

This marks an important difference from conventional software development. In traditional business logic, developers can usually define relatively precisely which input triggers which action. In an LLM-based agent, a non-deterministic model first interprets a situation and may then decide which tools to use in order to achieve an objective.

Security controls should therefore not depend on the assumption that the model will always make the correct decision. The surrounding architecture must ensure that an incorrect decision cannot automatically produce irreversible damage.

Human approval where consequences become irreversible

One of the most important principles in the Kaspersky guidance concerns irreversible actions. Operations that cannot easily be undone should require explicit human confirmation. Depending on the environment, this could include deleting business-critical information, transmitting sensitive data, changing production systems or initiating certain financial transactions.

This does not mean that every agent action should require manual approval. Such an approach would eliminate much of the productivity benefit that agentic systems are intended to provide. The challenge is to build a graduated control model in which routine actions within clearly defined boundaries can be automated, while consequential actions require additional authorisation.

For CISOs, this introduces a new governance responsibility. Enterprises must define not only which employee can access which system, but also which decisions an AI agent may make independently and at which point human intervention becomes mandatory.

The classic identity and access management question — “Who is allowed to do what?” — therefore gains an additional dimension: What may a machine do autonomously on behalf of this user?

Permissions become a primary security boundary

The usefulness of an AI agent increases with its ability to access enterprise resources. That same access, however, creates one of the most significant sources of risk.

An agent that can only read information from a knowledge base has a comparatively limited potential impact. An agent capable of sending email, reconfiguring cloud resources, modifying files, installing software and using privileged credentials operates in an entirely different risk category.

Kaspersky therefore identifies excessive permissions as a major concern in agentic systems. Security should not be based on granting broad access and expecting the model to decide responsibly which permissions it actually needs. Instead, privileges should be tied as closely as possible to the defined purpose of the agent.

This principle is familiar from Zero Trust and least-privilege architectures, but agentic AI makes it more important because the system dynamically plans its own actions. The broader the available toolset, the larger the number of potentially harmful action sequences.

An agent should therefore not be able to access a system simply because such access would be convenient. It should have access only where that capability is necessary for its specific role.

Minimise the trusted computing base

A second core principle concerns the trusted computing base, or TCB: the components whose correct operation must be assumed for the security of the overall system.

Kaspersky recommends keeping this trusted core as small as possible. The more components that are implicitly trusted, the larger the surface on which a failure or compromise can undermine the entire security model.

This is especially relevant to AI systems. A modern agent architecture can contain far more than a single model. Prompt orchestration, retrieval systems, databases, APIs, plug-ins, tool servers, identity services and potentially other agents may all be involved in completing a task.

If each of those components is treated as inherently trustworthy, the organisation creates a long chain of dependencies. Compromise of one element may influence the behaviour of the others.

The alternative is to make trust enforceable rather than assumed. Critical security decisions should, wherever possible, be handled by small, auditable and deterministic components whose behaviour is clearly defined.

Isolation becomes a basic requirement

This logic also explains Kaspersky’s emphasis on isolation. Sandboxes and virtual machines should separate execution environments, while trusted and untrusted contexts should remain distinct. In multi-agent environments, individual agents should also be isolated from one another.

The principle resembles network segmentation. If a security incident cannot always be prevented, its ability to spread must at least be limited.

For AI agents, that can mean running code-generation or development tasks inside isolated environments, restricting file-system access to dedicated directories or assigning temporary rather than standing privileges. Sensitive production systems should not be directly reachable from a general-purpose agent context unless there is a clearly justified operational requirement.

Isolation becomes even more important in multi-agent architectures, where one system may delegate work to another. These interactions create additional trust relationships, forcing enterprises to determine which agent may receive which data and which actions one agent is permitted to trigger through another.

A failure should remain local whenever possible. This is the central idea behind the Cyber Immunity approach: individual components do not need to be infallible if the architecture prevents their failure from compromising critical system functions.

Default deny instead of unrestricted tool use

Kaspersky applies the same logic to external interactions and recommends a default-deny model. An agent should not be allowed to access a resource or invoke a function unless that interaction has been explicitly authorised.

Importantly, this control should apply not only to the availability of tools themselves but also to the parameters used when invoking them. An agent might, for example, be allowed to query a database but not delete records, or call a cloud API without being authorised to assign new administrator privileges.

This shifts part of the security decision away from the language model and into deterministic policy enforcement. The model may propose an action, but a separate control layer determines whether the action is permitted.

For highly autonomous systems, this separation may prove essential. Organisations should not have to trust a model to remain voluntarily within organisational boundaries. Those boundaries should be enforced independently of the model.

Network access falls into the same category. Agents should not be able to contact arbitrary external services or install additional software components at their own discretion. Kaspersky specifically warns against allowing agentic systems to modify their own supply chain dynamically.

The new supply chain is broader than software

The supply chain of an AI agent is more complex than that of a conventional application. It may include not only software libraries, but also models, APIs, tools, data sources, extensions and external services.

A compromised component anywhere in that chain can influence the behaviour of the overall system. The risk increases if the agent itself is allowed to select new services or dependencies during execution.

Enterprises therefore need visibility into which agents are deployed, which models they rely on, which APIs they can access and which external data sources influence their decisions. Kaspersky recommends that CISOs, CIOs and CTOs build an inventory of agentic systems and manage their supply chains systematically.

This creates a new asset-management challenge. In the future, organisations may need to know not only which software is installed, but which autonomous agents exist, which identities they use and which decisions they are authorised to make.

Without this visibility, enterprises risk creating a new form of Shadow IT. Business units could deploy agents and connect them to sensitive services without security teams having a complete picture of their permissions, dependencies or external communications.

Cyber Immunity does not replace conventional security

Kaspersky presents Cyber Immunity as a secure-by-design concept in which systems remain resilient even when individual components fail or become compromised. The term itself is proprietary rather than an industry standard, but many of its principles overlap with established security concepts such as least privilege, isolation, Zero Trust and secure-by-design engineering.

The architecture is also not intended to replace conventional security controls. Kaspersky argues that agentic systems should still be protected through layered defences including sandboxing, endpoint detection and response, SIEM and specialised security controls for AI systems.

That distinction matters. Architecture can limit the impact of a failure, but it cannot prevent every attack or every unexpected action.

Security operations therefore still need the ability to detect unusual agent behaviour, such as unexpected resource access, abnormal volumes of data processing or actions that deviate from the agent’s established role. Agent logs and tool-call telemetry will become increasingly important sources for detection engineering, incident response and forensic investigation.

The real issue is not AI itself, but the authority it receives

Much of the current discussion around AI risk focuses on hallucinations, incorrect answers or prompt manipulation. For enterprises, however, another question may become far more important: how much real-world authority is assigned to a system whose behaviour cannot be fully predicted?

A model that produces an inaccurate recommendation creates an information problem. An agent that implements that recommendation autonomously can turn it into a security incident.

Risk assessments should therefore consider far more than model quality. The available tools, permissions, accessible datasets and external interfaces are equally important.

The more autonomous an agent becomes, the more important it is to design the surrounding architecture on the assumption that individual decisions may be wrong. The objective should not be to make a language model perfectly trustworthy. A more realistic goal is to build an environment in which incorrect decisions have limited consequences.

CISOs need an agent governance model

For security leaders, this creates a new organisational requirement. AI agents should not be introduced in the same way as ordinary SaaS applications, with security controls added after deployment.

Before an agent enters production, organisations should define its purpose, the resources it requires and the actions it must never perform. Escalation points requiring human approval should be established in advance rather than improvised after an incident.

Enterprises are therefore likely to need dedicated agent governance covering inventory, identity management, permissions, network rules, logging, isolation, supply-chain controls and emergency procedures.

Machine identity will be particularly important. Agent actions should be attributable to distinct machine identities rather than executed through shared service accounts with broad permissions.

Only if organisations can determine which agent accessed which resource, under whose authority and for what purpose will security teams be able to investigate incidents effectively.

This is also likely to become relevant for compliance and auditability. As AI agents take on more operational responsibilities, regulators and auditors may increasingly ask not only whether a system was authorised, but how its actions were constrained and whether critical decisions can be reconstructed afterwards.

Agentic security will require controls outside the model

One of the broader lessons from the Kaspersky approach is that organisations should resist the temptation to solve every AI-security problem inside the model itself.

More advanced prompting, alignment or model-level safety mechanisms can be useful, but they should not become the sole enforcement mechanism for enterprise policy.

Critical restrictions are more reliable when implemented independently. An external policy engine can reject an unauthorised tool call. A sandbox can prevent an agent from reaching a production system. An identity platform can limit privileges. Network controls can block unauthorised destinations.

This architecture assumes that the model may occasionally misunderstand, be manipulated or make an undesirable choice, but prevents that choice from automatically becoming an operational event.

The principle is well established elsewhere in cybersecurity. Secure systems generally avoid placing all trust in one control. Agentic AI should be no exception.

Security must come before autonomy

Kaspersky’s guidance addresses one of the central issues in the next phase of enterprise AI. Agentic systems promise significant productivity gains precisely because they can move beyond assisting humans and begin carrying out tasks independently. That same capability is what creates their new security relevance.

Organisations should therefore avoid enabling maximum autonomy first and attempting to wrap security around it afterwards. The more sustainable approach is to define the boundaries of safe autonomy before deployment and then allow the agent to operate within those limits.

The most important idea behind the Cyber Immunity approach is therefore less the terminology than the underlying assumption. Enterprises should not design AI infrastructure around the expectation that every model, data source and component will behave correctly at all times. They should assume that errors, manipulation and compromise are possible and build systems in which those failures cannot automatically escalate into severe incidents.

This also changes the role of cybersecurity in the age of agentic AI. Security teams will no longer be concerned only with preventing external attackers from gaining control of systems. They will increasingly be responsible for ensuring that legitimate autonomous systems remain inside clearly defined operational boundaries.

As enterprises delegate more decisions and tasks to AI agents, reviewing their outputs will no longer be enough. The decisive security question will be which actions those outputs are allowed to trigger, under which permissions, and which operations must remain impossible without additional control.