An anti-pattern is a recurring solution that looks reasonable but reliably produces bad outcomes — and for which a better alternative is known. This guide names twenty-five such anti-patterns from production AI-agent deployments and pairs each with a remediation grounded in OWASP LLM Top 10, NIST AI RMF, Microsoft SFI, and SLSA. A separate article covers the ReAct engineering discipline that keeps these failure modes out in the first place. Articles are grouped by domain — the same four groups as the folders and the Jump to article menu. Start anywhere.
If you are new to the topic, the whole catalogue rests on four ideas that recur in every group. First, an agent cannot reliably tell instructions apart from data — anything it reads can try to steer it. Second, an agent should hold the least authority that still lets it do its job, so that a compromise is contained rather than total. Third, everything an agent trusts — code, dependencies, container images, retrieved documents — needs verifiable provenance, because trust without evidence is just hope. And fourth, consequential actions need a point of human accountability. Each anti-pattern below is one of those four ideas being violated in a specific, nameable way; the four groups are simply where the violation tends to surface.
Identity & access
-
Wildcard Tool Exposure
Securing AI Agents: Why the Tool Allow-List Is Your Real Security Boundary
The core security boundary for AI agents is the set of tools they are allowed to invoke. Naming the Wildcard Tool Exposure anti-pattern and the layered controls that contain it.
-
Standing Credential
The Standing Credential: Why Long-Lived Tokens Are a Class of Risk to Retire
Long-lived broad-scope credentials in agent runtimes are one of the highest-leverage compromise targets. The replacement pattern — just-in-time minting from workload identities — is well-supported on every major platform.
-
Phishable Flow
The Phishable Flow: When Convenience Becomes a Documented Attack Path
The OAuth device-code flow on devices that have a browser turns an input-constraint workaround into the attacker's preferred channel. The right flow for each device class.
-
Shared Identity Runtime
The Shared Identity Runtime: Why AI Agents Belong in Their Own Sandbox
An agent that runs inside the operator's process can do whatever the operator can do. The three-zone architecture — operator, sandbox, target — applied to agent runtimes.
-
Implicit Agent-to-Agent Trust
Sub-agents trusted like internal functions
In a multi-agent system, one agent accepting another's output or tool calls without authentication or scope checks lets a single compromised agent pivot through the whole orchestration.
-
System Prompt as Secret Store
Credentials and policy hidden in the prompt
Embedding API keys, connection strings, or access rules in the system prompt assumes the prompt is confidential. It is extractable, so anything in it is effectively published.
Prompt injection
-
Unauthenticated Tool Channel
The Unauthenticated Tool Channel: Remote Connectors as Hidden Data Exits
Every remote tool server is a third-party data processor. Treat the next connector the way procurement treats the next SaaS contract.
-
Conflated Context
The Conflated Context: Why AI Agents Can't Tell Data from Instructions
Indirect prompt injection is structural, not a bug to patch. Four composing layers — labelling, sanitisation, capability constraint, human approval — make the defence tractable.
-
Comment-to-Commit Promotion
Comment-to-Commit Promotion: When Anyone Becomes a Committer Through an Agent
A pull-request comment is not authorisation to change code. Restoring the boundary between comment-author and commit-author trust.
-
Poisoned Knowledge Base
RAG and fine-tuning corpora treated as trusted
Documents an agent retrieves or is trained on are an injection surface. A poisoned corpus steers behaviour long after ingestion, with no prompt to inspect at runtime.
-
Persistent Memory Poisoning
Cross-session memory written without validation
An agent that persists "learnings" across sessions can be taught a malicious instruction once and replay it indefinitely. Memory is state, and unvalidated state is an attack surface.
-
Porous Vector Store
Embeddings and retrieval without tenant isolation
A shared vector index that ignores per-user access control leaks one tenant's documents into another's retrieval results; embeddings themselves can be inverted back toward source text.
-
Unsanitised Output Sink
Model output trusted as code, SQL, or markup
Passing raw model output into a shell, a query, or a browser DOM turns the model into an injection vector for the classic web vulnerabilities. Output is untrusted input to the next system.
-
Hallucinated Authority
Overreliance on unverified agent assertions
Acting on a confident but fabricated answer — a non-existent API, a wrong policy, a made-up citation — because the interface presents it with no uncertainty signal or verification step.
Supply chain
-
Live-Fetch Dependency
The Live-Fetch Dependency: Why "@latest" Is a Supply-Chain Decision
Installing dependencies at runtime by floating version tags repeats a well-documented failure mode. Pin, lock, audit, publish an SBOM, attest provenance.
-
Mutable Reference Trust
Mutable Reference Trust: Why "v4" Is Not the Same as a Commit Hash
A pipeline reference that resolves at runtime is a trust delegation. Pin by hash, restrict permissions, observe egress, attest provenance.
Governance
-
Plaintext Journal
The Plaintext Journal: When Telemetry Becomes a Forensic Goldmine
Telemetry is necessary; unredacted plaintext telemetry is a pre-staged exfiltration target. Five controls that make agent telemetry safe.
-
Unsupervised Perimeter
The Unsupervised Perimeter: When Some Agents Are Governed and Others Are Not
A product's security posture is the posture of its weakest invocable agent. Governance that applies to every shipped agent, not just the curated ones.
-
Documented Defence
The Documented Defence That Doesn't Exist: Trust Calibration in Security Products
Documentation that overstates the defences a product implements is a security problem, not a marketing problem. The two-track fix — raise the implementation, rewrite the claim — applied at every release.
-
Internal-to-Product Gap
The Internal-to-Product Gap: New Obligations When You Start Shipping
The moment a tool moves from internal use to a shipped product, its obligations change category. The shippable-to-customers gate and the artefacts it requires.
-
ReAct Discipline
The ReAct Discipline: Designing AI Agents That Are Safe to Ship
A single architectural decision — separating what the model proposes from what the host executes — gives every other AI security control an obvious place to attach. Mapped to OWASP, NIST AI RMF, MITRE ATLAS, and enterprise platform services.
-
Unbounded Consumption
No rate, cost, or loop ceiling (denial of wallet)
An agent with no token budget, recursion limit, or request cap can be driven into runaway loops or adversarial cost amplification — a denial-of-service that bills you instead of crashing.
-
Unattributable Action
No audit trail linking action to identity
When an agent acts under a shared identity with no per-decision log, you cannot answer "who did this and why" after an incident — failing the non-repudiation controls auditors expect.
-
Rubber-Stamp Approval
Human-in-the-loop defeated by approval fatigue
A human-approval gate that fires on every routine action trains the reviewer to click "approve" without reading. The control exists on paper but provides no real oversight.
-
Ungated Model Swap
Model or prompt changed with no evaluation gate
Switching the underlying model or editing the system prompt without a regression-eval gate ships silent behaviour and safety changes straight to production, outside change management.
-
Boundaryless Data Egress
Prompts and data sent across data-residency lines
Routing user data to a model endpoint in another jurisdiction, or to a third-party provider, without a data-residency or processing-location control breaches privacy and sovereignty obligations.
About the series
Each article in this series names an anti-pattern that is well-attested across the industry but rarely discussed by its own name. Naming is not a stylistic choice. A pattern that has a name can be discussed in architecture review, raised in a procurement questionnaire, and recognised across teams. A pattern without a name has to be re-explained every time.
The references in each article point to the same small set of frameworks — OWASP, NIST, Microsoft Secure Future Initiative, SLSA, Zero Trust — chosen because they are the frameworks that procurement, audit, and regulators are most likely to ask about. Articles can be read individually; readers who work through the full set will notice that the controls compose, which is intentional.
More field guides
-
Playbook
Self-Test Playbook
A paste-ready prompt pack you run against your own agent’s code, with twenty-five targeted security checks and a red-team prompt.
-
Field guide
Release Engineering
Eight chapters on shipping an agent to a customer environment: delivery models, signing, the pin file, the bootstrap repo, ephemeral runners, hygiene, cadence and rollback.
-
Field guide
Supply-Chain Trust
Judging third-party code, packages, actions, images and models before you trust them — provenance signals, independent verification, danger-surface review, and safe handling, grounded in OpenSSF, SLSA, NIST, OWASP and MITRE.
-
Field guide
Getting Quantum-Safe
A vendor-neutral post-quantum readiness field guide: what quantum computers break (RSA, ECC, TLS, PKI), the finalised NIST standards (ML-KEM, ML-DSA, SLH-DSA), a five-phase readiness assessment with a CBOM and maturity model, migration on real platforms, and what it all means for AI.