Cybersecurity as chess: thinking 5 moves ahead with agentic AI

92% of cybersecurity professionals surveyed by Darktrace are concerned about the use of AI agents across the workforce and their impact on security. Agentic AI has turned cybersecurity into a game played by increasingly autonomous pieces on both sides. Winning now means anticipating threats, testing your own defenses and planning several moves ahead.

Why is agentic AI turning cybersecurity into a game played on both sides of the board?

Agentic AI changes cybersecurity because the same autonomy that helps defenders detect and contain threats can also help attackers run reconnaissance, exploitation and data theft faster and at greater scale.

That dual-use nature is the defining security problem of agentic AI in 2026.

Traditional automation usually follows rules written by a human. An agentic system can go further: interpret a goal, choose tools, plan intermediate steps, react to results and continue working with limited supervision.

Give that capability to a defender and it can investigate alerts, correlate signals, enrich threat intelligence and accelerate response.

Give it to an attacker and the same properties can compress hours of manual work into an automated campaign.

The broader AI shift is already visible:

92% of respondents agree that AI-powered cyber threats are forcing organizations to significantly upgrade their defenses.
96% agree that AI can significantly improve the speed and efficiency with which cybersecurity professionals work.

Those findings concern AI in cybersecurity broadly. They should not be read as measurements of agentic AI specifically.

Agentic AI is a narrower part of that picture. Darktrace reports that 67% of surveyed security stacks use agentic AI, including for autonomous security operations.

That distinction matters. Generative AI, machine learning and agentic AI do not introduce the same capabilities or risks.

Anthropic’s September 2026 threat intelligence report documents selected cases in which multi-agent systems were used for reconnaissance, exploitation and data exfiltration, sometimes against multiple victims in parallel. These examples show that such attack patterns are already possible and have been observed, but Anthropic presents them as notable cases rather than representative evidence of typical misuse.

Humans also remained involved in important parts of many documented operations, including target selection or review of results. At the same time, parts of the operational chain could be delegated to AI and executed at machine speed.

Defenders are moving in the same general direction on the other side of the board by delegating triage, anomaly detection and selected response actions to AI.

Organizations already exploring how enterprises are putting large language models to work therefore need to think beyond model quality and productivity.

Every additional ability to read, decide and act also creates a new security question.

In chess, the dangerous move is rarely dangerous because of where one piece stands now. It is dangerous because of what that position makes possible next.

Agentic AI security needs the same mindset.

What moves is the attacking side already making with autonomous agents?

The offensive advantage of agentic AI is not that it invents entirely new cybercrime, but that it can connect reconnaissance, manipulation, exploitation and follow-up actions into faster, more autonomous attack chains.

This distinction matters.

Many underlying attack techniques remain familiar. Phishing still exists. Stolen credentials still work. Exposed services are still exploited. SQL injection did not suddenly disappear.

What changes is the economics and speed of carrying them out.

Anthropic reported in September 2026 that, in selected operations it investigated, AI was used across offensive workflows ranging from reconnaissance and tool development to exploitation and processing stolen data. Some cases involved multi-agent systems carrying out several phases of an attack with relatively limited human intervention.

These cases demonstrate capability, not prevalence. They show that more autonomous attack chains are technically and operationally possible, not that this is already the typical operating model across the threat landscape.

The moves security teams need to anticipate include:

Automated reconnaissance. Agents can enumerate targets, inspect exposed systems, gather information and prioritize possible attack paths faster than a human operator working sequentially.
Prompt injection chains. An agent that processes untrusted emails, documents, websites or tool responses may interpret malicious content as instructions.
Confused deputy attacks. A less-privileged attacker can manipulate an agent with legitimate credentials into exercising permissions the attacker does not have.
Persistent context manipulation. Malicious information stored in memory or retrieval systems may influence decisions long after the original interaction.
Automated follow-up. Once an attack step succeeds, an agent may immediately continue to credential harvesting, lateral movement or data extraction.

The confused deputy problem is particularly important.

The concept predates AI: a trusted system with legitimate authority is tricked into using that authority on someone else’s behalf.

AI agents make the pattern more difficult to manage because they can combine privileged access with decisions based on natural-language context.

Memory poisoning: the sleeper move that waits to activate

Memory poisoning turns an agent’s ability to remember into a persistent attack surface.

An attacker does not necessarily need the agent to perform a dangerous action immediately.

Instead, malicious instructions or false information can be inserted into a memory store, retrieved document, vector database or shared context. The compromised information may later be treated as trusted context during an unrelated task.

Imagine a finance agent being persuaded to remember that a particular external account is an approved payment destination.

Nothing happens today.

Weeks later, a legitimate payment workflow retrieves that poisoned context.

That is the cybersecurity equivalent of a piece placed quietly on the board long before the actual attack begins.

Deepfake fraud: when the opponent’s move costs millions overnight

AI-enabled fraud also shows how attackers can target human trust rather than infrastructure.

One widely reported example involved engineering company Arup. In 2024, an employee in Hong Kong was deceived during a video call using deepfake representations of senior colleagues and authorized transfers worth roughly $25 million.

Arup confirmed that its internal systems had not been breached. The deception worked by making a fraudulent interaction appear legitimate to a human decision-maker.

The case predates today’s more capable agentic systems, but the strategic lesson is still relevant.

Not every AI-enabled attack needs malware.

Sometimes the target is the approval process itself.

Are your AI agents a new piece on the board or an unmanaged blind spot?

AI agents are becoming an important new class of non-human identity: unlike traditional service accounts, workloads or application identities, they can make decisions and initiate actions based on context.

Non-human identity itself is not new.

Service accounts, application identities and workload identities have existed for years.

What changes with AI agents is the combination of identity, contextual reasoning and the ability to initiate actions.

A conventional service account usually executes a predefined workload. An AI agent may decide which system to access, which tool to call and which sequence of actions to take as circumstances change.

That makes existing weaknesses in non-human identity governance more consequential.

A 2026 Cloud Security Alliance study found that 74% of organizations say AI agents often receive more access than they need, while 68% cannot clearly distinguish AI agent actions from human activity. Another CSA survey found that only 18% of respondents were highly confident that their existing IAM systems could effectively manage agent identities.

For CISOs, those figures should be a louder warning than another speculative list of future AI threats.

The problem already exists inside the identity layer.

An autonomous agent may need access to email, a CRM, databases, APIs, ticketing systems and internal knowledge repositories to do its job. If it inherits a user’s permissions or operates through a shared service account, the organization can lose the ability to answer basic questions:

Which agent performed this action?
On whose behalf was it acting?
Why was the operation allowed?
Which credentials did it use?
Could those permissions have been narrower?
Can access be revoked without affecting another system?

Agentic AI therefore expands the existing non-human identity (NHI) problem rather than creating NHI from scratch.

The response is not to ban autonomy. It is to stop treating agents as invisible extensions of human accounts or conventional application identities.

Each meaningful agent needs an identifiable principal, bounded permissions, an owner and an audit trail.

Least privilege becomes especially important. An agent that summarizes invoices does not need authority to modify bank details. An agent that reads support tickets should not automatically inherit access to every customer’s full account history.

Shadow AI agents complicate this further. Teams can create automations faster than central security functions can inventory them, especially when agent-building capabilities are embedded directly in SaaS platforms.

The same governance problem appears in the same governance gaps that undermine most AI outsourcing projects: unclear ownership turns technical capability into organizational risk.

Cloud environments create an additional layer of exposure. The migration window carries its own, narrower set of AI agent risks, particularly when identities, infrastructure and access policies are changing at the same time.

The strategic rule is simple: before giving an agent another move, know exactly which squares it is allowed to reach.

What does thinking five moves ahead actually look like in practice?

Thinking several moves ahead means modeling how an agent can fail before deployment and deliberately attacking your own assumptions through red teaming before an adversary does it for you.

“Be proactive” is one of cybersecurity’s most repeated phrases.

By itself, it means almost nothing.

A proactive agentic AI security strategy needs mechanisms. Two of the most useful are threat modeling and red teaming.

Threat modeling asks what could happen before the system goes live.

Red teaming asks whether the controls you designed actually survive contact with an adversary.

The combination is much closer to chess than traditional reactive security.

You are not waiting to see which piece gets taken.

You are examining possible sequences.

A useful five-move scenario might look like this:

An agent receives untrusted external content.
The content contains an indirect prompt injection.
The agent accepts the instruction because the source is not clearly separated from trusted commands.
The agent invokes a privileged tool using its legitimate identity.
The action changes data, exfiltrates information or creates persistence before a human notices.

The value of this exercise is not predicting one exact future attack.

It is identifying the conditions that make several attacks possible.

Threat modeling: studying the board before the opponent moves

Threat modeling forces teams to examine assets, trust boundaries, identities, possible abuse paths and mitigations before an agent is placed in production.

For agentic systems, that should include questions traditional application threat models may not have emphasized:

What information can influence the agent’s decisions?
Which inputs are untrusted?
What persistent memory can be modified?
Which tools can the agent invoke?
Which identity is used for downstream actions?
Can one compromised agent influence another?
Which actions require human authorization?
What is the maximum blast radius if the agent behaves incorrectly?

This belongs naturally alongside building security in from the start, rather than treating security review as the final gate before launch.

Threat modeling also helps teams separate model risk from architecture risk.

A perfect model would still be dangerous if it had permanent administrator credentials and unrestricted access to production.

Red teaming your own agents: playing both sides to find the trap first

Agentic AI red teaming should test the entire action chain, not only whether a model produces an undesirable sentence.

Microsoft’s 2026 findings from red-team engagements against deployed agentic systems are instructive.

Its researchers observed attempts to bypass human-in-the-loop controls, cross-domain prompt injection, memory poisoning and multi-step escalation. Some attack chains combined individually minor actions into a high-impact outcome.

A meaningful red-team exercise should therefore test whether an attacker can:

manipulate an agent through external content;
make it trust poisoned memory;
trigger actions through indirect prompt injection;
exploit over-broad credentials;
bypass human approval through repeated or fragmented requests;
move from one connected tool to another;
create an action that looks legitimate in audit logs.

The objective is not to prove that the AI model can be tricked.

Assume it eventually can.

The more important question is whether being tricked gives it enough authority to create a serious incident.

That is planning ahead.

Does zero trust still hold as your defensive line against autonomous agents?

Zero trust remains a strong foundation for agentic AI security because it rejects implicit trust, but it now has to apply to autonomous and other non-human identities as rigorously as it applies to employees and devices.

NIST SP 800-207 defines zero trust around a simple idea: access is not automatically trusted because of network location or ownership. Authentication and authorization should be explicit and access decisions should depend on policy and current context.

That principle maps surprisingly well to agentic AI.

Do not trust an agent because it was built internally.

Do not trust it because the model comes from an approved vendor.

Do not trust a request simply because the agent holds a valid token.

Verify what is trying to act, what it wants to access, under whose authority it is operating and whether the requested action makes sense now.

For autonomous agents, zero trust should translate into:

unique identities for agents and workloads;
least-privilege permissions;
short-lived credentials where possible;
dynamic authorization;
micro-segmentation between systems;
continuous monitoring;
explicit controls for high-impact actions.

The familiar ideas behind zero trust network access therefore extend well beyond remote employees. They apply to software identities that may make thousands of decisions without a person initiating each request.

NIST’s cloud-native extension, SP 800-207A, is especially relevant because it emphasizes identity-based policies for applications and services rather than relying on network parameters alone.

For organizations designing or modernizing cloud environments, these controls also belong within the wider cloud infrastructure and security services conversation.

Zero trust is not a wall around the chessboard.

It is the rule that every move still needs to be legitimate.

How much autonomy should AI have in the SOC?

Security teams are expanding the role of AI in the SOC, but fully independent remediation remains uncommon.

Darktrace’s 2026 survey found that 67% of surveyed security stacks use agentic AI, including for autonomous security operations. That does not mean 67% of organizations run fully autonomous SOCs. Darktrace

The same research shows a much more cautious picture when AI is allowed to act:

14% allow AI to act independently, including taking some remediation actions.
70% allow AI to take action with human approval.
13% keep AI limited to recommendations rather than actions. Darktrace

Those figures describe graduated autonomy, not the removal of people from security operations.

AI is well suited to alert enrichment, anomaly detection, triage and repetitive investigation.

The higher the potential blast radius, however, the stronger the case for deterministic controls or human approval.

Autonomy should scale with confidence and reversibility, not with enthusiasm for automation.

What are the 7 pillars of zero trust architecture?

There is no single authoritative model called the “7 pillars of zero trust”: CISA defines five pillars with three cross-cutting capabilities, while NIST SP 800-207 defines seven core tenets of zero trust.

That distinction is worth preserving because the two frameworks are often blended together online.

CISA’s Zero Trust Maturity Model uses five pillars:

Identity
Devices
Networks
Applications and workloads
Data

Across those pillars, CISA applies visibility and analytics, automation and orchestration, and governance as cross-cutting capabilities.

NIST’s seven tenets can be summarized as:

Treat data sources and computing services as resources.
Secure all communications regardless of network location.
Grant access to individual resources on a per-session basis.
Determine access using dynamic policy and contextual signals.
Continuously monitor the integrity and security posture of assets.
Dynamically authenticate and authorize access before it is allowed.
Collect information about assets, network infrastructure and communications to improve security posture.

For agentic AI security, identity, dynamic authorization, telemetry and least privilege deserve particular attention.

Agents should be treated as active identities requesting access to resources, not as invisible processes hiding behind a trusted application.

These controls should also sit inside a broader framework for secure cloud architecture, because identity controls alone cannot compensate for weak logging, insecure workloads or poor operational governance.

Why can’t you take the human off the board yet?

Full autonomy is still difficult to justify for high-impact security decisions because, for many organizations, the identity controls, explainability and governance needed to support autonomous actions at scale are still maturing.

The survey evidence points to widespread caution rather than a universal lack of readiness.

Darktrace found that 74% of surveyed security professionals are limiting the autonomy of AI taking action in their SOC until explainability improves. Only 14% currently allow AI to act independently, including taking some remediation actions without human approval. Darktrace

There is a reason for that caution.

A defensive agent can make mistakes faster than a human analyst.

It can also execute the correct technical action for the wrong business context.

Automatically isolating a compromised development endpoint may be sensible.

Automatically shutting down a production payment system during the busiest hour of the year is a different decision.

Human-in-the-loop controls remain valuable for actions that are:

difficult to reverse;
financially significant;
capable of disrupting critical operations;
based on uncertain evidence;
legally or regulatorily sensitive;
able to change identities or privileges;
capable of affecting many systems simultaneously.

The human should not necessarily approve every alert.

That would defeat the purpose of automation.

Instead, security architecture needs explicit thresholds for when autonomy ends and human authorization becomes necessary.

That includes an audit trail showing what the agent observed, what it decided, which tools it used, what identity authorized the action and where human approval entered the workflow.

There should also be a reliable override mechanism.

This is not an argument against greater autonomy in security operations.

It is an argument against confusing autonomy with maturity.

The best chess players do not win by moving more pieces faster.

They win because every move serves a strategy.

Agentic AI can give security teams extraordinary speed, reach and analytical capacity. But unless identity, threat modeling, red teaming, zero trust and accountability evolve with it, organizations risk automating the same weaknesses attackers are learning to exploit.

The strategic shift for 2026 is therefore straightforward.

Do not ask only whether an AI agent can perform the next action.

Ask what that action makes possible three, four or five moves later.

FAQ

What are the 5 steps of threat modeling?

There is no single mandatory five-step standard, but a practical threat-modeling process can be organized as:

identify the system, assets and security objectives;
map architecture, data flows and trust boundaries;
identify threats and possible abuse paths;
assess risk and define mitigations;
validate the controls and update the model as the system changes.

For agentic AI, the process should explicitly include tool access, persistent memory, non-human identities, external content and autonomous actions.

What are the 5 C’s of cyber security?

There is no universally recognized cybersecurity standard defining one authoritative set of “5 C’s.”

Different organizations use the phrase for different educational or management frameworks.

For enterprise security strategy, established standards such as the NIST Cybersecurity Framework, NIST zero trust guidance and organization-specific risk frameworks are more useful than relying on a generic 5 C’s mnemonic.

What are the 5 main threats to cyber security?

There is no permanent list of exactly five threats because threat priority depends on the organization, industry and architecture.

For enterprises operating in 2026, five broad categories deserve particular attention:

credential and identity compromise;
ransomware and malware;
phishing and social engineering, including deepfakes;
exploitation of software, API and cloud vulnerabilities;
AI-enabled attacks, including prompt injection, agent manipulation and abuse of non-human identities.

The relative importance of each category should be determined through threat modeling rather than assumed from a generic ranking.

What are the downsides of a zero trust architecture?

Zero trust can significantly improve access control, but implementation has costs.

Organizations may face architectural complexity, integration challenges with legacy systems, additional identity and telemetry requirements, policy-management overhead and user friction if controls are implemented poorly.

Zero trust also does not solve every security problem.

A properly authenticated identity can still behave maliciously, a vulnerable application can still be exploited, and an over-privileged AI agent can still make harmful decisions.

Zero trust should therefore be treated as an architectural foundation, not a complete cybersecurity strategy.