AI Agents Are Becoming a Cybersecurity Problem: What Changed in 2026?

The change is not only that models are better

AI chatbots were already a cybersecurity concern. They could help write convincing phishing, summarise technical material and speed up research. That was serious, but the human operator was still usually deciding what happened next.

The part that interests me in 2026 is different. An AI agent can be given an objective, use tools, read data, authenticate to services, observe what happened and continue. That changes the security question from “What can the model say?” to “What is this system allowed to do?”

That is not a reason to panic about every assistant. It is a reason to stop treating agents like ordinary chat windows.

What is an AI agent?

A traditional chatbot is mostly a conversation: a human asks, the model responds, and the human decides whether to act.

An agent has a loop. It can plan a task, call an API, browse a site, search files, read a result, adjust the plan and make another call. Some run on demand. Others run in the background. Some coordinate smaller agents in parallel.

Microsoft describes an agent as an application working toward a goal by understanding context, making decisions and acting through available tools. That definition matters because the tools are where real-world authority lives.

A model with no access can still give bad advice. A model with browser, email, cloud or shell access can create a much larger problem if its access, instructions or data are not controlled well.

Why 2026 feels different

The capability jump is not just better prose. It is persistent workflow and tool use.

Anthropic’s September threat report described operators using agentic workflows across reconnaissance, intrusion attempts, vulnerability research, malware development and intelligence collection. The report said some workstreams ran in parallel and retained campaign context between sessions. That is a useful signal, even if it is one company’s view of activity on its own platform: the workflow is becoming more scalable and less dependent on one person manually stepping through every task.

At the same time, security teams are building agents for defensive work. Microsoft’s September updates focused on discovering and controlling local agents, extending Zero Trust to agent traffic and strengthening security operations for an agentic environment. The capability works both ways.

AI used by attackers versus the agent as an attack surface

These are related, but they are not the same problem.

### AI used by attackers

Attackers can use AI to speed up research, translate and adapt content, analyse stolen data, organise tasks or help write code. That is the offensive side.

The defensive lesson is not to assume every campaign is “fully autonomous.” It is to recognise that automation can reduce time and increase scale. A person still needs access, opportunity and intent. AI can make each step easier to repeat.

### The legitimate agent that becomes risky

The second problem sits inside an organisation. A well-meaning agent may be connected to a mailbox, cloud drive, ticketing system, browser, database, source repository or admin tool. If it has broad permissions, it can become a very attractive route for an attacker.

A useful agent needs enough authority to complete work. An unsafe agent has more authority than it needs, weak boundaries around its tools and no clear record of what it actually did.

Giving an agent your main administrator account is not convenience. It is a design decision with a large blast radius.

Prompt injection is not just a strange chatbot answer

Prompt injection happens when an agent reads content it does not control and that content tries to influence the agent’s behaviour. It might be a webpage, document, email, support ticket or repository file.

If the agent only answers questions, the result may be an incorrect response. If it can call tools, the risk is more serious. The agent may be manipulated into reading data it should not read, taking an unintended action or sending information somewhere it should not go.

This is why external content should be treated as untrusted input. The agent needs clear instructions, narrow tool permissions, sensible confirmation steps and a way to stop when the task starts to look different from the original objective.

OWASP’s guidance on securing agentic applications treats this as a practical design problem, not a science-fiction problem. Memory can also become part of the attack surface when an agent carries untrusted context from one task into another.

Identity is becoming the centre of the conversation

Human accounts, service accounts and agents should not all look the same.

An agent needs its own identity, its own access policy and its own audit trail. Microsoft’s agent identity guidance makes the same point: autonomous agents operate differently from human users, and controls designed for interactive human sign-in do not automatically fit an agent that requests access tokens in the background.

For me, the useful principles are familiar security principles applied more carefully:

• Give each agent a separate identity.
• Give it the minimum data and tool access needed for one job.
• Prefer short-lived, scoped credentials over long-lived shared secrets.
• Require human approval for payments, account changes, destructive actions and sensitive exports.
• Keep audit logs that show which agent acted, what tool it used and under whose authority.
• Make revocation and a kill switch easy.

This is not a product checklist. It is a way to think about accountability before an agent is allowed into systems that matter.

A practical example

Imagine an agent that reads support emails and updates customer records. That can save time. But it should not automatically have permission to reset accounts, export the entire customer list or change payment details just because it can read the inbox.

The safe version separates those jobs. It gives the agent a narrow identity, limits its tools, asks a human to approve higher-risk actions and logs the workflow. It also assumes that an email body is untrusted content, even when it looks convincing.

The same idea applies to self-hosted automation. An agent that can inspect logs is different from an agent that can restart services. One that can suggest a configuration change is different from one that can deploy it. Small permission differences matter a lot once a system can keep trying without a person watching every click.

AI can help defenders too

The point is not that AI agents are bad. Security teams can use them for alert triage, log correlation, investigation support, vulnerability analysis, detection engineering and repetitive incident-response work.

Used carefully, an agent can reduce time spent moving between dashboards and help an analyst find the right evidence faster. The human role does not disappear. It becomes more important at the points where judgement, accountability and risk acceptance are required.

The same technology that helps an attacker scale a workflow can help a defender spot patterns, prioritise noise and respond faster. The difference is the controls around it.

What I would do before giving an agent access

Before connecting an agent to anything important, I would ask:

1. What exact job is this agent allowed to do? 2. Which data does it genuinely need? 3. Which tools can it call, and which actions require approval? 4. Does it have its own identity rather than my personal admin account? 5. Are credentials short-lived, scoped and easy to revoke? 6. Can I see an audit trail after the fact? 7. What happens if it reads a malicious page, email or document? 8. Can I pause or disable it quickly? 9. Have I tested the failure path, not only the happy path?

If those questions do not have clear answers, the agent probably has too much access too soon.

The real security question now

AI agents are useful precisely because we give them the ability to act. That is also why they need to be treated differently from ordinary chatbots.

The conversation is no longer only about model output. It is about identity, permission, tools, data, logs and approval. In other words, it is about security architecture.

That is what changed in 2026. The model is part of the system, but the risk sits in the connection between the model and everything it is allowed to touch.

Sources and further reading

• Anthropic: Countering misuse of AI, September 2026
• Anthropic: alignment assessment of recent cybersecurity incidents
• Microsoft Security: September 2026 updates
• Microsoft Entra: agent identities
• Microsoft Entra: Zero Trust guidance for AI agents
• NIST: identity and authority of software agents
• OWASP: Securing Agentic Applications Guide