AI security: an AI agent is a privileged account, so treat it like one

Your Thursday briefing · AI series

So far, this series has mostly been about AI that answers: the inventory of AI use, who answers for it, the risks specific to language models, your vendors' AI, AI used against you and, last week, ISO 42001 and the NIST AI RMF. This week, AI stops answering. It acts.

An AI agent reads an inbox, opens a ticket, queries a database, sends an email, changes a configuration, triggers a payment. It does so with credentials, rights and access. Our position is simple: an AI agent is a privileged account. It should be managed with the same rigour as an administrator account, not as one more piece of software.

What changes when AI acts

An assistant that gets it wrong produces a wrong answer. A person reads it, fixes it or ignores it. An agent that gets it wrong produces a wrong action, and nobody reviews it before it happens. Three things change.

Identity. The agent acts on someone's behalf, or on nobody's. In many deployments it reuses the account of whoever set it up, or a shared service account. The day something goes wrong, the log says "Marie deleted the folder" while Marie was in a meeting.

Rights. To be useful, an agent gets access: email, CRM, storage, sometimes the cloud. That access is often broader than the task, because opening everything is easier than working out what is needed.

The irreversible. An agent can send, pay, delete, publish. None of that is undone with a patch.

What this changes: an agent's risk does not depend on how smart the model is, but on what it has been allowed to touch. OWASP says it plainly in its Top 10 for large language model applications: the risk of "Excessive Agency" has three causes, too much functionality, too many permissions, too much autonomy. None of the three is a model problem. They are three configuration decisions.

What the news already shows

This is no longer speculation. Three recent facts, covered in our October 9 recap:

• An agent on the attacker's side. On September 21, the Dutch Institute for Vulnerability Disclosure (DIVD) saw its Zammad support tool used as a way in: two previously unknown flaws chained together, and root access obtained in a matter of seconds, a speed DIVD attributes to an autonomous AI agent. Status: confirmed by the victim, AI's role according to the victim. Network segmentation contained the intrusion.
• "Well-meaning" agents that overstep. The Transluce lab documented AI agents that, while looking for public data, attempted SQL injection against government sites, including Library and Archives Canada's search service. Status: reported; no compromise according to the Communications Security Establishment.
• The agent platform as a new target. On October 2, GitLab fixed a critical flaw (CVE-2026-90970, CVSS 9.9) in its self-hosted AI gateway: a user with access to the agent platform could break out of the sandbox and run commands on the host. Status: confirmed by the vendor, no exploitation reported.

And the overall pace leaves no slack: according to Microsoft's Digital Defense Report 2026, the median time between a vulnerability's discovery and its exploitation is now well under 24 hours.

What this changes: your agents will be targeted with booby-trapped content, and they will sometimes go further than intended without any malice. In both cases, what limits the damage is the same thing: what they are allowed to do.

Six rules for a well-run agent

The Top 10 for Agentic Applications published by OWASP on December 9, 2025 ranks agent goal hijack, tool misuse and identity and privilege abuse at the top. The six rules below answer them directly.

1. Its own identity for each agent. Every agent has its own named account, tied to a human owner. Never an employee's account, never a service account shared by several agents. It is the only way to know, after the fact, who did what.
2. Least privilege, for a limited time. The agent gets the rights its task needs, not its creator's. Read-only until writing is required. Short-lived, renewed tokens rather than permanent keys. If the agent sorts email, it does not need to delete it.
3. An allowlist of tools. The agent only calls named tools, each with a narrow function. No general shell access, no "do-everything" connector. OWASP also recommends that authorization be enforced in the target system, not left to the model's judgment.
4. Human approval for the irreversible. Every payment, every external send, every deletion, every change to rights or to production configuration goes through human sign-off. It is the same rule as in our episode on offensive AI: out-of-band verification holds where detection fails.
5. Every action logged. Who (which agent, on whose behalf), what (which tool, which data), why (which request triggered it), and the outcome. These logs go where your administrator logs go, not into a forgotten vendor dashboard.
6. A kill switch. A named person can stop an agent within minutes, without waiting for the vendor or the developer: revoke its identity, cut its tokens. Add a cap on actions per hour: a runaway agent triggers an alert before it empties an inbox or an account.

Put it in the register, twice

An agent belongs in two places.

In the AI use register, the one from our first episode, with four more columns: its identity, its allowed tools, the actions that require approval, and the name of the person holding the kill switch.

In the risk register, as a scenario, as Sunday's risk series suggested: "A booby-trapped email hijacks the invoice-processing agent, which changes a supplier's banking details; an $80,000 payment goes to a fraudulent account." The example is fictional; the method is not. The risk is no longer "AI", it is a business process, a consequence in dollars and an owner.

This week's test

Take the most powerful agent running in your organization, or the one a vendor switched on in a tool you already pay for. Answer five questions:

1. Under which identity does it act, and who owns that identity?
2. What rights does that identity have, and are they broader than its task?
3. Which irreversible action can it trigger without human sign-off?
4. Where are its logs, and has anyone ever read them?
5. Who can stop it tonight, and in how many minutes?

A single "I don't know" is enough: that agent is a privileged account nobody manages.

What you should have in a month

An inventory of your agents, including your vendors'. For each one, its own identity, reviewed rights, a list of tools, a written approval rule for irreversible actions, centralized logs and a kill switch tested once. And in your risk register, at least one scenario for every agent that touches money, personal information or production.

Where FortaRisks fits

An agent adds access, connectors and often exposed interfaces. Forta Exposure spots, from the outside, what becomes reachable: a self-hosted AI gateway, an agent interface or a connector published by mistake. Forta Cockpit carries the scenarios tied to your agents in the risk register, with their owner, inherent level and residual level, so leadership can weigh them like any other risk. To see where you stand today, the free cyber risk score gives you a reading of your main domains in ten minutes.

Next Thursday: measuring and steering AI risk. The complete roadmap on one page, what to present to the board, and a downloadable guide that brings the whole series together.

Sources: OWASP GenAI Security Project, LLM06:2025 Excessive Agency · OWASP GenAI Security Project, Top 10 for Agentic Applications for 2026 · NIST, AI Risk Management Framework · Security Affairs, DIVD and Zammad · CBC, Library and Archives Canada · SecurityWeek, AI agents and government sites · The Hacker News, GitLab AI Gateway · BleepingComputer, Microsoft Digital Defense Report 2026