AI agents & security

Cyber security in the age of agents: what changes when AI acts on its own

The short answer

AI agents change cyber security because they do not just answer — they act: they read untrusted content, call tools and use credentials. Attackers no longer need to break into a server; redirecting the agent is enough. Three things protect effectively: limited permissions, vetted integrations and human approval for actions that cannot be undone.

What an agent does differently from a chatbot

A chatbot answers questions. An agent pursues a goal: it plans steps, remembers intermediate results, calls tools and acts with the permissions somebody gave it. That combination is exactly what makes it useful — and attackable. The damage of a mistake or attack is no longer limited to a wrong answer; it reaches as far as everything the agent can access and trigger.

The OWASP GenAI Security Project has taken this up. After its list of the ten biggest risks for applications built on language models (2025 edition), it published its first dedicated list for agentic applications on 9 December 2025. It covers systems that plan, use memory, call tools and act on other systems with delegated authority.

The risks, sorted into three questions

The ten-point list is useful but hard to remember. In practice three questions are enough. Each corresponds to a guide in this series.

  • What does the agent read? Every web page, email, document and tool response can contain instructions that the agent takes for genuine tasks. That is prompt injection; it ranks first in the OWASP list for language models (LLM01:2025).
  • What is the agent allowed to do? The more functions, permissions and autonomy a system gets, the greater the damage when it misbehaves (LLM06:2025, “Excessive Agency”). The agent list adds identity and privilege abuse and the exploitation of tools.
  • What is the agent connected to? With agents, tools, plug-ins and interfaces are often loaded only at runtime. The agent list names the supply chain as a risk of its own — for example malicious MCP servers or manipulated templates.

Three principles that apply to every project

The following principles are our recommendation from building and operating AI agents, not quotations from the sources above. They can be applied to any project before an agent goes live.

  • Limited permissions: an agent gets only the tools and access its task needs — read-only where reading is enough, and with its own narrowly scoped credentials instead of shared administrator accounts.
  • Vetted integrations: every interface an agent uses is treated like third-party software: check its origin, pin versions, log access.
  • Human approval for the irreversible: deleting, paying, sending to external parties and changing access require confirmation. The barrier sits in the application, not in the prompt.

A prompt is not a security boundary. What an agent must not do has to be prevented by the environment — not by the instruction “please don’t”.

Where to start

  • Inventory: which agents run in your organisation, with which tools and which credentials? Without that list nothing can be assessed.
  • Tighten permissions: define the minimum for every agent and withdraw everything else.
  • Logs: store every tool action together with its trigger so that you can reconstruct what happened when it matters.
  • Kill switch: there must be a way to stop an agent immediately and revoke its credentials.
  • Have it tested from the outside: where systems are reachable over the internet, a scan shows what attackers see.

What this means for companies with web and plant technology

Agents do not come in isolation: they connect to websites, calendars, CRM systems and sometimes to plant. Anyone who deploys agents widens the attack surface of existing systems. The classic tasks therefore remain — apply updates, secure access, protect remote access — and now apply to the agents themselves as well.

Frequently asked questions

What is an AI agent in security terms?

A system that uses a language model to plan steps, call tools and act on other systems with delegated permissions. What matters is not the model but what the agent can reach and trigger.

Why is a good instruction in the prompt not enough?

Because a prompt is not access control. Untrusted content can contain instructions that the agent follows. What it must not do has to be prevented technically, for example through limited permissions and approvals.

Which list should I use as a basis?

For applications built on language models, the OWASP Top 10 for LLM Applications (2025 edition); for agents additionally the OWASP Top 10 for Agentic Applications for 2026. Both are freely available.

Do I need a large security project to begin with?

No. An inventory of agents, minimal permissions, logs and a kill switch are the most sensible first step and can be set up without a large project.

Sources

This assessment rests on the publications listed. Check the original source before making decisions.

Keep reading

Want to know where you stand?

A Basic Scan shows where your systems can be attacked from the outside — fixed price, with a report. Or get warned about new flaws for free.