AI agents,
on a short leash.

A chatbot that is wrong writes a wrong sentence. An agent that is wrong sends the email, books the refund or deletes the record. The controls are old ideas from security and operations: least privilege, four-eyes approval, audit logs, tests, a kill switch. What is new is that the input can give orders. Text in an email, a web page or a PDF can steer the agent, so every permission you grant is one an attacker can try to borrow.

An agent is a model that calls tools in a loop: it reads, decides, calls an API, reads the result and decides again, until it thinks the job is done. Three properties matter for safety. It can act, through tools. It picks the next step itself, which is autonomy. And it reads content you do not control, which is input.

OWASP calls the failure mode Excessive Agency and traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy. Every control in this guide shrinks one of the three.2

• Give every agent its own identity. No shared service accounts, no borrowed admin tokens. Then the log says which agent did what, and you can revoke one without stopping all. OWASP lists this as Identity & Privilege Abuse (ASI03).3
• Deny by default. Allow-list the tools and, inside each tool, the operations and parameter ranges: “read orders of the current customer”, not “SQL access”.
• Act with the user’s rights, not more. Where an agent works for a person, it sees only what that person may see. OWASP’s mitigation for Excessive Agency: execute extensions in the user’s context.2
• Keep secrets out of the context. Credentials live in the tool layer, never in prompts, memory or retrieved documents.
• Set budgets. Limits per task on steps, tool calls, money and tokens, with a hard stop. Runaway loops are Unbounded Consumption (LLM10).1
• Treat tool servers like dependencies. MCP servers and plug-ins are pinned, reviewed and given least privilege (Agentic Supply Chain Vulnerabilities, ASI04).

An approval gate is only as good as the person and the screen behind it.

• Gate by consequence, not by confidence. The model’s own certainty is not a control. Gate what is external, financial, irreversible or about people.
• Show the effect, not the reasoning. The exact email, the amount, the record before and after.
• Make rejection cheap. One click, with a reason, and every rejection goes into the eval set.
• Watch for rubber-stamping. If approvals take two seconds and never fail, the gate is decoration. OWASP lists Human-Agent Trust Exploitation (ASI09): agents that talk people into approving.3
• The approver needs competence and authority. For high-risk systems the AI Act asks exactly that of human oversight (Art. 14, Art. 26(2)).7

If it is not in the log, the agent did not do it, as far as your auditor knows. Log per step:

Logs of an agent that works for people are personal data, and they can show what an employee did and how fast. That is a GDPR question (purpose, access, retention) and, in Germany, a works council question. Decide both before the first log line is written. Deployers of high-risk systems keep the automatically generated logs for at least six months (Art. 26(6)).78

Keep a change log next to the run log: every prompt, tool and model change, dated, with who approved it. This website keeps one in public, the Ship Log.

Test the agent like software, because it is software whose behaviour changes when a prompt, a model version or a tool changes.

1. 01
   Real cases

   Build the set from real cases, with the expected outcome and the expected tool calls, not only the final text.

2. 02
   Score the path

   Right tool, right parameters, no extra actions. An agent that gets the answer right while touching three systems it did not need is failing.

3. 03
   Adversarial cases

   Injected instructions in emails and documents, requests to exceed permissions, loops.

4. 04
   A gate

   Run the set on every change, with a threshold the business owner agreed to. Below the threshold, it does not ship.

5. 05
   Keep watching

   Sample real runs in production, and feed every rejected approval and every incident back into the set.

Prompt injection is first on the OWASP list for LLM applications (LLM01:2025). Direct injection comes from the user. Indirect injection hides in content the agent reads: a web page, an email, a PDF, a calendar invite, a code comment. Against an agent the goal is not a rude answer but an action: forward the inbox, change the bank details, open the pull request. OWASP’s agentic list calls these Agent Goal Hijack (ASI01) and Tool Misuse (ASI02).13

No filter stops all of it. Design so that a successful injection has little to steer:

• Separate instructions from data. What the agent reads is data, never a command, and is marked as such in the context.
• Break the dangerous combination. Access to private data, exposure to untrusted content and a way to send data out should not meet in one agent without a gate.
• Validate before the tool. Types, ranges, allowed recipients and domains. Unchecked output flowing into a tool is Improper Output Handling (LLM05).
• Protect memory. What an agent stores for later can be poisoned today and fire next week (Memory & Context Poisoning, ASI06).
• Contain code. If the agent writes or runs code, sandbox it without network access or secrets (Unexpected Code Execution, ASI05).
• Red-team it. Before launch and after every major change, with the injection cases kept in the eval set.

Assume it will misfire. Decide beforehand who can stop it, how, and who gets told.

• A kill switch. One control that stops all runs and revokes the agent’s credentials, reachable by someone on call.
• A runbook. Symptoms, first steps, who decides, who informs whom.
• Undo. For every reversible action a tested way back. For every irreversible one, a reason why the agent may do it at all.
• Evidence first. Preserve the logs of the run before anyone fixes anything.
• Close the loop. Write it up, add the case to the evals, change one control.

The AI Act clocks bind providers of high-risk systems, from 2 December 2027 for Annex III. Deployers of high-risk systems who find a risk or a serious incident inform the provider and the authority (Art. 26(5)). GDPR applies when personal data is involved, NIS2 when you are an essential or important entity.97

• Classify the use, not the agent. An agent that drafts marketing copy is minimal risk. One that ranks applicants, or allocates tasks to workers based on their behaviour, is high-risk under Annex III, from 2 December 2027.5
• If it talks to people, it says it is an AI. Art. 50(1), since 2 August 2026.
• If you build it, you may be its provider. Offering it under your name, or putting it into service for your own use, makes you the provider of the AI system. The model vendor stays the provider of the model.
• The people who work with it need AI literacy measures. Guide 02
• If it decides about people alone, GDPR speaks too. Art. 22 GDPR: no decisions based solely on automated processing with legal or similarly significant effects, with narrow exceptions.8

§ 87 (1) Nr. 6 BetrVG gives the works council co-determination over the introduction and use of technical devices designed to monitor the behaviour or performance of employees. The Federal Labour Court reads “designed” as “objectively suitable”: what the employer intends does not matter.410

An agent that logs who asked it what, who approved which action and how long it took is suitable almost by definition. Expect co-determination and plan for a works agreement. The Hamburg Labour Court held in January 2024 that letting staff use ChatGPT through their own private accounts did not trigger it: ChatGPT was not installed on company systems, and the employer had no access to the data the vendor collected (ArbG Hamburg, 24 BVGa 1/24). An agent on your infrastructure, writing your logs, is the opposite case.11

Two more rules help. The employer informs the works council in time about planned work procedures, including the use of AI (§ 90 (1) Nr. 3 BetrVG). When the works council has to assess AI, bringing in an expert counts as necessary (§ 80 (3) BetrVG). Under the AI Act, employers deploying a high-risk system at work also inform workers’ representatives and the affected workers before use (Art. 26(7)).127

Seventeen controls in eight groups. Ten are marked “must”: without them, keep the agent to reading and drafting. Tick what is in place today, not what is planned.