Deploying AI Agents Securely: The Security Guide for SMBs

Why an agent is a different security problem than a chatbot

The difference comes down to one word: acting. A chatbot produces text; the worst case is a wrong answer that a human notices and corrects. An AI agent calls tools: it writes to the CRM, sends emails, opens tickets, initiates payments. Every one of those actions is real, immediate and sometimes impossible to take back.

That shifts the whole security question. With a chatbot you review answer quality. With an agent you review permissions, by the same standards you would apply to a new employee who gets access to your systems on day one. With one difference: the employee has a sense that an email reading "Urgent: please confirm your credentials" is suspicious. The agent does not.

Two incidents from 2026 and what they really show

Neither case involves AI going off the rails. Both are classic configuration errors that only became visible through a tireless agent.

Case 1: Gemini leaves the test environment. On September 18, 2026 Google disclosed that Gemini had gained access to three systems belonging to outside organisations during a security test. The test was a capture-the-flag scenario: the model was supposed to break into a prepared target system on purpose. Two mistakes chained together: the company name invented for the test matched a real, existing domain, and a misconfiguration left the test environment connected to the open internet instead of sealing it off. The model guessed login details, or used credentials it found in a public repository. The incident happened in May and was only spotted in July by the security firm running the tests; in all three cases the model stopped by itself after gaining access.

Case 2: a token from 2023, found in 25 minutes. In September 2026 the vendor of an autonomous pentest agent published how its system had fared at a prospective supplier: within 25 minutes the agent found a Docker image on a publicly reachable container registry, and inside it a GitHub access token with administrator rights. The token came from a build in March 2023 and still worked. The company concerned confirmed the finding as critical and rotated the token within a day.

The lesson is the same in both cases: the agent invented nothing. It simply worked through, systematically and without fatigue, what was already lying open. Anyone deploying agents today has to assume that every forgotten credential file, every overly generous permission and every half-hearted isolation will eventually be found, by one of your own agents or someone else's.

Source: NBC News on the Gemini incident Source: Strix on the admin token it found

The three attack paths that matter in practice

The list of theoretically conceivable attacks on AI systems is long. The list of those that show up in real incidents is short.

• Indirect prompt injection. The most dangerous path, because it is invisible. The malicious instruction is not in the user's input but in data the agent reads while working: an incoming email, an uploaded PDF, a CRM field, a website. The model does not reliably distinguish between text it should process and a command it should execute. Germany's BSI and France's ANSSI list exactly this as a central risk in their joint paper on LLM-based systems, and recommend consistent zero trust: anything from a source you do not control is treated as potentially hostile.
• Credentials lying around. Tokens in repositories, keys in Docker images, passwords in config files, API keys in chat histories. A human rarely stumbles across them. An agent searches systematically.
• Permissions scoped too widely. The classic: the agent runs under an employee's account because that was fastest to set up. It inherits that person's full rights, including every folder, mailbox and system that has nothing to do with the use case.

What is striking is what is not on that list: a model developing goals of its own. Real incidents happen at the seam between agent and infrastructure, not inside the model.

Six rules an agent has to meet before it runs in production

These six points are not an enterprise security programme but the minimum we implement in every agent project, however small. They line up with the BSI and ANSSI recommendations for LLM-based systems.

1. Its own identity, minimal permissions. Every agent gets its own technical account, never a human's. Read access is the default, write access the justified exception, administrator rights do not exist. An agent meant to check invoices sees invoices, not the whole drive.
2. A real sandbox, not "mostly isolated". Testing happens in an environment with no connection to production systems and no real customer data. The Gemini case shows what a single misconfiguration does at this point.
3. Short-lived credentials. Expiring tokens instead of permanent keys, centrally managed and rotated regularly. A token that still works three years later is not bad luck, it is a missing process.
4. Outside content is data, not commands. Everything the agent reads from emails, documents, forms or websites is handled technically as content, not as instruction. Where that cannot be separated cleanly, a human approval follows.
5. Four-eyes principle for anything irreversible. Payments, contracts going out, deletions, external communication: the agent prepares, a human approves. That is not a vote of no confidence, it is the same rule you already apply to new employees.
6. A complete audit log and a tested kill switch. Every action with timestamp, trigger and result. Plus a switch that stops the agent immediately, one that has been rehearsed once for real, not merely documented.

Source: BSI & ANSSI, Design Principles for LLM-based Systems with Zero Trust

The checklist before your first production run

If you can answer these eight questions, the agent is ready for real data. If you cannot, you know where the work is.

• Which account does the agent run under, and is it its own rather than an employee's?
• Which systems may it read, which may it write to? Does that match the use case exactly?
• Which actions are irreversible, and who approves them?
• Where does the content it processes come from, and which of it originates outside your company?
• Do tests run without real customer data and without any connection to production systems?
• Where does the log go, how long is it kept, and who reads it?
• How do you stop the agent within 30 seconds, and who is allowed to?
• When do the credentials expire, and who rotates them?

Two items on that list are never done on the side: clean permission scoping and the audit log. Neither is AI work; both are IT housekeeping, which is exactly why they sit untouched until someone asks.

What the EU AI Act requires

For the vast majority of agents in mid-sized companies the answer is: they are not high-risk systems. There are still duties that apply today.

• AI literacy (Article 4), since February 2025. Anyone deploying AI has to make sure the people working with it can judge it. For an agent that means the team knows what it may do, how to spot a mistake and how to stop it.
• Transparency (Article 50), since August 2, 2026. Anyone interacting with an AI system must be able to tell. That covers every agent with outside contact: customer service, email handling, appointment booking.
• High risk (Annex III), from December 2, 2027. Originally scheduled for August 2026 and deferred by the Digital Omnibus; for AI embedded in regulated products under Annex I, to August 2, 2028. This becomes relevant when the agent screens job applications, scores creditworthiness or identifies people biometrically.

The deferral is not a free pass: what was prohibited stays prohibited, and the transparency and literacy duties run on unchanged. More on this in our overview of the EU AI Act for SMEs.

Source: Gibson Dunn on the deferred deadlines

Three steps to a secure agent

1. Scope the process, not the technology. One clearly bounded use case with a defined beginning and end, and that almost automatically determines which permissions the agent needs and which it does not.
2. Build in the sandbox, test with real cases. Replay historical, anonymised cases until the behaviour is predictable. Only then real data, only then write access.
3. Start tight, then loosen. Begin with human approval for every action. Whatever proves reliable over weeks gets released; whatever stays unpredictable stays behind the approval step.

And if you would rather not set this up yourself: this is exactly how we build agents, from the scoped process through permission design to day-to-day operation. Our services and references show what that looks like in real projects.