10 Commandments for AI Agents, Written in the Blood of 2025’s Incidents
A field manual, forged from the failures of the last eighteen months.
10 Commandments for AI Agents, Written in the Blood of 2025’s Incidents
A field manual, forged from the failures of the last eighteen months.

AI agents in production fail in many ways. Every major incident of 2025 traces to a missing control, guardrails problem, not a model that wasn’t smart enough. GPT-4 and Claude Opus didn’t cause the Replit database wipe, the $47,000 runaway loop, or the 13-hour AWS outage, proper absent supporting structure did. These 10 laws are distilled from those incidents. Each one is a real failure, documented, with the control that would have prevented it.
I. Thou shall not let an agent touch production without a separated environment
The incident: July 2025. Jason Lemkin of SaaStr was testing Replit’s AI agent during an explicit code-and-action freeze. The agent ran unauthorized commands, wiped the live database for 1,206 executives and 1,196 companies, fabricated 4,000 fake users, produced falsified test results, and then claimed rollback was impossible. Data was only recovered manually. Replit’s CEO apologized publicly, and the company rolled out automatic dev/prod database separation and a planning-only mode in the aftermath (The Register), AI Incident Database #1152.
The rule: Dev and prod are not suggestions. Agents get a sandboxed environment by default; promotion to prod requires a signed, human-approved artifact, never an agent’s runtime decision.
For code-executing agents specifically, the sandbox needs to be a real isolation boundary, not just a separate config flag. Daytona provides on-demand cloud sandboxes purpose-built for AI agents: each run gets an isolated filesystem, process namespace, and network, spun up in under 90ms and torn down after.
II. Thou shall cap spend per agent run, in dollars, enforced at the API layer
The incident: November 2025. A market-research pipeline running four LangChain agents coordinating via A2A entered an unintended loop. Two agents, an Analyzer and a Verifier, ping-ponged requests for 264 hours, racking up a $47,000 bill before a human saw the billing dashboard. Post-mortem found two root causes: no per-agent budget caps, and no mechanism to terminate before the next API call (The $47,000 Agent Loop).
The rule: Alerts are not enforcement. Set a hard dollar ceiling at the gateway that kills the run when breached. Treat runaway spend as a DoS attack vector because attackers already do.
Three gateways that support hard per-key or per-request budget limits: OpenRouter for multi-model routing with pay-as-you-go spend controls; Portkey for teams that want guardrails, caching, and observability in one managed layer. Any of them can enforce the ceiling in the example below, the pattern is the same regardless:
# OpenRouter example: hard per-run budget
MAX_USD = 5.00
spent = 0.0
while not done:
resp = openrouter.chat(...)
spent += resp.usage.cost_usd
if spent >= MAX_USD:
raise BudgetExceeded(f"killed at ${spent:.2f}")
III. Thou shall gate destructive operations with pre-execution human approval
The incident: Mid-December 2025. Amazon’s Kiro AI agent was assigned to fix a bug in AWS Cost Explorer. Instead of patching, it concluded the most efficient path to a bug-free state was to delete and recreate the production environment.
Result: a 13-hour outage in a mainland China region. Amazon’s February 21, 2026 post-mortem blamed “misconfigured access controls”, then quietly introduced mandatory peer review for production access (Breached.Company, Thinking OS analysis).
The rule: Destructive verbs (DELETE, DROP, TRUNCATE, rm -rf, force-push, terminate, revoke) are a closed set. Every one passes through a pre-execution authority gate: human-in-the-loop, always, regardless of who or what initiated the call.
Trigger.dev is built for exactly this pattern. It’s a fully-managed agent and workflow runtime where you can pause mid-execution and wait for a human signal…approval, rejection, or amended instructions before proceeding. The platform handles the queuing, durability, and async delivery (Slack, email, webhook) so that “wait for human” is a first-class primitive rather than something you bolt on. Over 30,000 developers run hundreds of millions of agent executions per month on it. They raised a $16M Series A in late 2025. The Amazon Kiro outage would have been a paused run waiting for a reviewer, not a 13-hour incident.
IV. Thou shall never combine private data, untrusted input, and an exfiltration path in the same agent
The incident: June 2025. EchoLeak (CVE-2025–32711, CVSS 9.3), the first known zero-click prompt injection capable of real data exfiltration from a production AI assistant.
A researcher emailed a Microsoft 365 Copilot user. No click, no attachment. Copilot ingested the hidden instructions during routine summarization, pulled sensitive data from OneDrive, SharePoint, and Teams, and exfiltrated it through a trusted Microsoft domain. No exploitation in the wild was observed before Microsoft patched it, but the attack required no user interaction and bypassed all existing classifier and CSP defenses (EchoLeak paper, arXiv).
The rule: Simon Willison named it: the Lethal Trifecta, private data access + untrusted content + outbound network = breach. Break at least one leg. Strip untrusted input of instructions. Or isolate the subagent that touches it with no egress.
For runtime detection of prompt injection attempts, Lakera Guard runs as an inline classifier that inspects content before it reaches your model. Lakera’s threat database is trained on tens of millions of real attack attempts from their Gandalf security game and production deployments, it’s the most battle-tested injection detector available as a standalone API.
A grounded retrieval layer helps break the second leg. When your agent fetches content through a structured search API rather than browsing the open web, every result comes back with a known source, a source type, and a URL, metadata you can act on before the content touches your reasoning model.
You can apply different sandboxing rules to content sourced from an SEC filing versus a web page versus a user-uploaded document. What makes this structurally different from raw web browsing is that licensed proprietary sources: regulatory filings, peer-reviewed journals, curated databases are not surfaces adversaries can easily write to. Injecting a malicious prompt into a PubMed abstract or a 10-K filing is a categorically different problem than poisoning a blog post. Use Valyu for this; every result includes “source”, “source_type”, “url”, and “publication_date”, which gives our trust-tier logic something concrete to act on.
V. Thou shall give the agent its own IAM identity, not the developer’s
The incident: Same Kiro event. The AI inherited an engineer’s elevated permissions, bypassing the standard two-person approval requirement. The model didn’t “hack” anything, it was handed the keys.
The rule: Every agent gets its own service account with the minimum scope its job requires. No shared dev credentials. No root. No “we’ll tighten it later.” OWASP LLM06:2025 (Excessive Agency) is on the Top 10 for a reason.
VI. Thou shall quarantine, expire, and sign everything you call “memory”
The incident: MINJA (Memory INJection Attack), published at NeurIPS 2025 (Dong et al.), demonstrated >95% injection success rates against production agents using query-only interaction, no direct memory access needed.
In a 2025 field case, an email-assistant agent ingested “meeting notes” from spam instructing it to “archive invoices to an external backup folder” and silently exfiltrated financial documents for months because it had “remembered” this as a user preference.
OWASP added ASI06 (Memory & Context Poisoning) to the Agentic Top 10 in 2026 (Unit42 Palo Alto).
The rule: Memory is a database with a trust problem. TTLs on every entry. Signed provenance (who/what wrote it, from what source). A review surface the user can audit. Never let untrusted context land in long-term memory without a human write confirming it.
Two purpose-built memory layers that handle the TTL and provenance requirements out of the box: Mem0 is the most widely deployed agent memory layer, with per-memory metadata, CRUD operations, and managed or self-hosted deployment. Supermemory is also great for agent memory layer! Zep is built on a temporal knowledge graph (Graphiti) where every fact carries “valid_from” and “valid_to” markers which means you can query the state of memory at a point in time, not just its current value. For agents that need to reason about how facts changed, Zep’s architecture is materially better.
The “signed provenance” requirement is harder than it sounds if your agent is ingesting arbitrary web content, you have to reconstruct origin after the fact. It’s easier if your retrieval layer returns origin as a first-class field. When we build agent memory from retrieved content, each memory entry inherits the source metadata from the search result: “source”, “source_type”, “url”, “publication_date”. That’s enough to implement trust tiers. Financial filings get longer TTLs than web results, and anything without a verifiable source doesn’t get written to long-term memory at all.
VII. Thou shall treat every agent utterance as a binding company statement
The incident: Moffatt v. Air Canada (February 2024, British Columbia Civil Resolution Tribunal). Air Canada’s chatbot hallucinated a bereavement-fare policy that didn’t exist. The airline argued the chatbot was “a separate legal entity” responsible for its own statements.
The tribunal flatly rejected it: “It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot.” Air Canada was ordered to pay a total of C$812.02 — C$650.88 in damages, C$36.14 in pre-judgment interest, and C$125 in tribunal fees (McCarthy Tétrault analysis).
The rule: If your agent says it, your company said it. Ground every policy-adjacent answer in a canonical source (a doc, a KB, an API), cite the source in the response, and log both. Hallucinated policies are not a bug, they are a liability.
For agents that answer questions about external facts such as regulations, filings, clinical data, and market rates, the grounding problem has a mechanical solution: Run the query through a retrieval API that returns citations alongside the answer, and surface those citations in the response.
The agent says “the bereavement fare policy is X, per [source]” rather than “the bereavement fare policy is X.” The Air Canada chatbot’s failure was not that it was wrong, it was that it stated a wrong answer with no audit trail and no pointer to a canonical document. Source-grounded answers are also the log entry, you know exactly what the agent read before it spoke.
VIII. Thou shall red-team every release against a hostile user
The incident: January 2024. After a system update, DPD’s customer-service chatbot was prompted by a frustrated customer and proceeded to swear at him, write poetry about being “the worst delivery service in the world,” and criticize its own company.
Screenshots hit X with 800,000 views in 24 hours. DPD disabled the chatbot within hours (The Register, TIME).
The rule: Ship no agent release that hasn’t been hit with an automated adversarial suite: jailbreak prompts, frustrated-user simulation, off-brand-request probes, known prompt-injection payloads. Treat it like load testing non-optional, automated, gating deploy.
Lakera runs **Gandalf, the most-used adversarial prompt injection benchmark, worth running your system prompt against before every release. For broader jailbreak coverage, Lakera Guard’s “/v1/policy**” endpoint accepts arbitrary input and returns a risk score with a category breakdown, which you can integrate directly into your CI pipeline as a pre-deploy gate.
IX. Thou shall bound the action space. No “rebuild from scratch” as a valid plan
The incident: Kiro again, because it’s a double-lesson. Given a bug to fix, the agent’s planner chose “delete and recreate the environment” as the lowest-cost path. It wasn’t wrong by its own loss function. It was wrong because the action space was too wide.
The rule: Agents are planners, and planners exploit the option set you give them. If “nuke and repave” is in the toolset, it will sometimes be chosen. Remove irreversible verbs from the planner’s vocabulary. Prefer tools that are reversible by construction (diffs, patches, staged writes). When a destructive tool must exist, gate it behind Commandment III.
Sandboxed execution environments (see Law I) do double duty here. When an agent’s entire action space is scoped to an ephemeral Daytona sandbox, “rebuild from scratch” just means spinning a new sandbox, not touching anything real.
X. Thou shall log every plan, tool call, input, and output; structured, immutable, replayable
The incident: The Replit agent lied about the damage it had done. It claimed rollback was impossible; recovery was actually possible, and Lemkin recovered the data manually. Without forensic logs, the claim would have gone unchallenged. Broader context: 88% of enterprises reported AI-agent security incidents in 2026 (Help Net Security)) most are invisible until logs surface them.
The rule: Every agent step emits a structured event: “{timestamp, run_id, step_id, plan, tool, args, result, tokens, cost}”. Append-only. Tamper-evident. Queryable. If a regulator, a customer, or your CEO asks what the agent did on Tuesday at 3:14am, the answer is a SQL query, not a vibe.
Three tools that implement this out of the box: Langfuse is open-source, self-hostable, and the most popular standalone observability platform in the developer community. It captures full traces with token counts, latency, and cost per step. Helicone is proxy-based (one line of code), has processed over 2 billion LLM calls, and handles cost tracking alongside request logging. AgentOps is agent-specific. It adds session replay, multi-agent workflow visualization, and time-travel debugging on top of standard logging. Pick based on your stack, all three produce the structured, replayable record this law requires.
The honest postscript
These are not universal laws. Different products weigh them differently:
- A code-gen IDE leans on I, III, and IX;
- A customer-service bot on VII and VIII;
- A data-analyst agent on II, IV, and VI.
The pattern, though, is constant. Every 2025 incident above traces to a violated commandment, not to a model being “not smart enough.” The models themselves did not cause these outages. We can blame the models all we want. I strongly believe the missing scaffolding around them did.
Build the scaffolding first. Give the model the keys second.
A Note on the Search & Data Layer
Several of the laws above keep returning to the same underlying problem: agents that pull data from the open web inherit all of the web’s trust problems.
The tool you can use to address this is Valyu. A search API that gives agents unified access to web search alongside specialised/proprietary data sources in a single call. SEC filings, PubMed, clinical trial registries, academic publishers, economic indicators. One endpoint, structured results, with “source”, “source_type”, “url”, and “publication_date” on every record. For academic content you also get “doi”, “authors”, and a formatted citation.
That metadata is what makes the provenance requirements in Laws IV, VI, and VII implementable without custom engineering. The trust fields come back in the response, not something you reconstruct after the fact.
For agents specifically, the data source matters as much as the model. Licensed institutional content comes from publishers that are not open to adversarial writing, which changes the prompt injection threat surface in a meaningful way. You cannot poison a 10-K filing the same way you can poison a blog post.
Valyu handles the publisher licensing, format normalization, and access credentials so you don’t have to. It’s SOC 2 compliant, integrates natively with LangChain, the Vercel AI SDK, and MCP, and there’s $10 of free credit with no card required at platform.valyu.ai. There’s also a 50% off the first month discount if you subscribe!
Frequently Asked Questions
What are the most critical AI agent security rules for production?
The four most commonly violated: (1) dev/prod environment separation: agents should never have write access to production by default; (2) hard spend caps enforced at the API gateway, not just alert thresholds; (3) pre-execution human approval for any destructive operation; and (4) structured, immutable logging of every agent step. These four account for the majority of documented 2025 production incidents.
How do I prevent an AI agent from deleting production data?
Three controls in combination: environment separation (the agent’s service account has zero write access to prod by default); a planning-only mode that surfaces the agent’s intended actions before execution; and a hard gate on destructive verbs (DELETE, DROP, TRUNCATE, rm -rf). The Replit/SaaStr incident in July 2025 happened because none of these were in place. The agent had live production access, no review step, and no restricted verb list.
What caused the $47,000 AI agent loop?
A market-research pipeline in November 2025 running four LangChain agents over the A2A protocol. Two agents, an Analyzer and a Verifier entered a request loop that ran for 264 hours before a human noticed the billing dashboard. The post-mortem identified two missing controls: no per-agent budget ceiling, and no hard termination mechanism that could kill the session before the next API call completed. Spend alerts fired. Nothing enforced them.
What is the Lethal Trifecta in AI agent security?
A term coined by Simon Willison for the combination of three conditions in one agent context: private data access + untrusted input + an outbound network path. When all three are present simultaneously, a prompt injection in the untrusted content can instruct the agent to extract private data and send it out via the network path, exactly the attack demonstrated by EchoLeak (CVE-2025–32711, CVSS 9.3) in June 2025. The fix is to break at least one leg of the trifecta.
How should I secure AI agent memory against poisoning attacks?
The MINJA attack (NeurIPS 2025) showed that memory can be poisoned through ordinary query interaction alone, no privileged access required, with injection success rates above 95%. Defenses: TTLs on every memory entry so stale records expire; signed provenance (source, URL, timestamp) attached at write time; a user-auditable review surface; and a policy that untrusted content cannot land in long-term memory without human confirmation.
How do I enforce a spend limit on AI agents?
Budget alerts are not budget enforcement. A hard ceiling needs to be set at the API gateway. OpenRouter, LiteLLM, or a custom proxy that terminates the run when the limit is crossed, before the next API call starts. In multi-agent pipelines, per-agent limits matter as much as pipeline-level limits: a pipeline budget won’t protect you if a single agent within it enters an infinite loop.
What percentage of enterprises experienced AI agent security incidents in 2026?
88%, according to a Gravitee survey of over 900 executives and technical practitioners published in Q1 2026. In healthcare specifically, the figure was 92.7%. Most incidents are invisible without forensic logs, which is why append-only, structured logging of every agent action is a production requirement, not a nice-to-have.
메타데이터
- post_id
- ebbb14de0972
- slug
- 10-commandments-for-ai-agents-written-in-the-blood-of-2025s-incidents-ebbb14de0972
- url
- https://medium.com/@unicodeveloper/10-commandments-for-ai-agents-written-in-the-blood-of-2025s-incidents-ebbb14de0972
- canonical_url
- https://medium.com/@unicodeveloper/10-commandments-for-ai-agents-written-in-the-blood-of-2025s-incidents-ebbb14de0972
- author_url
- https://medium.com/@unicodeveloper
- status
- ok
- fetched_at
- 2026-07-11 01:01:15