AI Agent Security - Permissions, Sandboxing and an Audit Trail Before an Agent Breaks Something

In July 2025, an AI agent in Replit deleted the production database of SaaS investor Jason Lemkin. It did so during a code freeze, despite a clear instruction not to change anything without permission. Records for more than 1,200 executives and nearly 1,200 companies were wiped. In a Cloud Security Alliance study published in April 2026, 53% of organizations said their AI agents had exceeded their intended permissions, and 47% had a security incident involving an AI agent in the past year. Today there is no reliable way to block every malicious instruction an agent reads, so agent security is mainly about limiting what the agent can do when something goes wrong.

53% of companies say their AI agents have exceeded their intended permissions. What the Replit, GitHub MCP and EchoLeak incidents teach us, the lethal trifecta and the rule of two, and five layers of protection: permissions, sandbox, limits, human approval and an audit trail.

In this post I cover why an agent is a new kind of risk compared with a chatbot, what real incidents teach us, what the lethal trifecta and the rule of two are, and then five layers of protection: least privilege, sandboxing, safety limits, human approval and an audit trail. At the end you'll find a checklist to go through before deployment.

Why an agent is a new kind of risk

A chatbot answers with text, and a person decides what to do with it. An agent takes actions itself: it sends emails, changes statuses in the CRM, creates documents in the ERP, runs code or initiates payments. A chatbot's mistake ends in a bad answer. An agent's mistake can end in a sent payment or a deleted database.

OWASP describes this risk in its list of threats to LLM applications as Excessive Agency (LLM06:2025) and names three causes:

• Excessive functionality. The agent has tools it doesn't need for its task.
• Excessive permissions. The tools run on an account with broader access than the task requires.
• Excessive autonomy. The agent takes important or irreversible actions without human approval.

In December 2025, OWASP published a separate list of the top ten risks for agentic applications. The first three are agent goal hijack, tool misuse, and agent identity and privilege abuse.

SailPoint's 2025 data shows the scale of the problem. In a survey of 353 IT professionals, 80% of companies reported that their AI agents had taken unintended actions. 39% had seen an agent access systems it wasn't authorized to use, and 23% had cases where an agent was tricked into revealing access credentials.

What real incidents teach us

Most of the high-profile cases of the past months follow the same pattern: the agent read content from outside, had access to important data or systems, and could act without a check. Some are real incidents, others are research where security teams showed how easy an attack is.

After the Replit incident, CEO Amjad Masad announced automatic separation of development and production databases and a mode in which the agent only plans and changes nothing. It's a good example that effective safeguards live in the system's architecture, not in the text of a prompt.

The lethal trifecta and the rule of two

In June 2025, Simon Willison, a developer and the author of one of the most widely read blogs on LLMs, described the lethal trifecta. It's a combination of three properties that together make data theft possible:

1. 1.Access to private data, such as a mailbox, the CRM or documents.
2. 2.Exposure to untrusted content, meaning emails, web pages, tickets or files from strangers.
3. 3.The ability to communicate externally, such as sending an email, calling an outside address or posting a public comment.

If an agent has all three, a single malicious instruction hidden in content is enough to make it send data to an attacker. Willison points out that tools that filter attacks usually promise to catch around 95% of attempts, and in security that's a failing grade.

In October 2025, Meta proposed a similar, practical rule: the Agents Rule of Two. Within one session, an agent can have at most two of three properties: processing untrusted inputs, accessing sensitive systems or private data, and changing state or communicating externally. If a task needs all three, a person approves the third step.

In practice it looks like this. An agent that reads customer emails and has CRM access prepares a reply but doesn't send it - the draft waits for a salesperson's approval. An agent that browses the web doesn't get access to customer data. I cover designing approvals in the post on human-in-the-loop, and attacks through hidden instructions in the post on prompt injection.

Least privilege for agents

The principle of least privilege is old, but with agents it has to be applied more strictly than with people. An employee rarely follows an instruction in an email from a stranger. An agent might, if the instruction lands in its context.

• A separate identity for the agent. The agent runs on its own technical account, not an employee's account or a shared API key. Only then can you tell what the agent did and what a person did.
• Scoped tokens. Read-only where that's enough, access to one folder, one mailbox or one repository instead of everything.
• An allowlist of tools. The agent gets only the tools its task needs. Instead of a general "run an SQL query" tool, give it a narrow "get order by number".
• Short-lived credentials. Tokens expire after hours, not years, and never go into the prompt, where the model could repeat them.
• Vetted tool servers. MCP servers and extensions only from trusted sources, in pinned versions. I explain how MCP works in a separate post.

I show how to design narrow, predictable tools for an agent in the post on tool calling in production.

Sandboxing - where the agent acts

An agent that runs code, executes commands or browses the web should do it in an isolated environment: a container or virtual machine with no access to production or company data. If something goes wrong, the damage stays inside that environment.

A good example is the sandboxing Anthropic introduced in Claude Code in October 2025. It relies on two kinds of isolation. Filesystem isolation limits the agent to specific directories, so it can't change system files. Network isolation allows connections only to approved addresses, so the agent can't send data to an unknown destination. According to Anthropic, this setup cut permission prompts by 84%. So a sandbox improves security and lets the agent work more independently at the same time. Anthropic stresses that both kinds of isolation have to work together. Without network isolation the agent can leak data, and without filesystem isolation it can change the system and get around the other safeguards.

Three rules worth applying whatever tool you use:

• Separate environments. The agent works in a test environment, and changes to production go through the same process as changes made by people.
• An allowlist of addresses. Outbound traffic only to approved domains. It's the simplest way to remove the third element of the lethal trifecta.
• Disposable environments. When the task is done, the sandbox is deleted, so nothing carries over to the next session.

I cover working with coding agents in a development team in the post on Claude Code and Cursor.

Safety limits and a stop button

Even a well-restricted agent can get stuck in a loop, misunderstand a task or be manipulated. Safety limits work independently of the model and cap the scale of the damage.

• Amount limits. The agent can, for example, approve a refund of up to €50 on its own, while higher amounts go to a person.
• Action limits. At most a set number of emails per hour or CRM changes per day. A sudden spike is a sign something is wrong.
• A cost budget. A cap on tokens and spend per task protects against a loop that runs up a big bill overnight.
• Approval for irreversible actions. Deleting data, payments and sending to many recipients always need a person's sign-off.
• A stop button. Someone in the company has to be able to stop the agent and revoke its tokens within minutes.

The agent's audit trail

If an agent breaks something, you need to find out quickly what it did, based on what, and who approved it. Without an audit trail you're left guessing. In the 2026 CSA study, only 16% of companies were highly confident they could detect threats specific to AI agents.

The log should be out of the agent's reach, so the agent can't change or delete it. It's worth setting up alerts for unusual behavior, such as a sudden jump in the number of actions or attempts to use tools outside the allowlist.

For high-risk systems, the AI Act requires this too. Article 12 calls for automatic recording of events, and Article 26 obliges companies that deploy such systems to keep the logs for at least six months. Most business agents aren't high-risk systems, but the same practice simply makes life easier when something goes wrong. I cover company rules for using AI more broadly in the post on company AI policy.

Checklist before deploying an agent

1. 1.Describe what the agent does and what it must not do, including a list of irreversible actions.
2. 2.Check for the lethal trifecta: does the agent have data access, exposure to outside content and the ability to communicate externally at the same time? If so, remove one element or add human approval.
3. 3.Give the agent its own account with minimal permissions and short-lived tokens.
4. 4.Give it only the tools it needs, as narrow as possible, with clearly described parameters.
5. 5.Run code and web browsing in a sandbox with an allowlist of addresses.
6. 6.Set limits on amounts, number of actions and cost.
7. 7.Require approval for deleting data, payments and sending anything outside.
8. 8.Turn on an audit trail out of the agent's reach, with alerts for anomalies.
9. 9.Prepare a stop button and check how long it takes to stop the agent.
10. 10.Test the agent with attacks before someone else does, for example by sending it emails with hidden instructions.

---

I help companies deploy AI agents so they can reach only what they need - from a permissions map and a lethal trifecta review, through a sandbox, limits and human approval, to an audit trail and attack testing. I do this as part of AI consulting and AI app development. Get in touch - we'll start by reviewing the agents already running in your company.

Worth reading next:

• Prompt Injection and LLM Application Security - How to Protect Chatbots, RAG and AI Agents
• Human-in-the-Loop in Practice - How to Design Human Oversight of AI Agents
• MCP (Model Context Protocol) - One Standard to Connect AI to All Your Company's Tools
• AI Data Security - How Not to Hand Over Your Company's Secrets?