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 thirteen 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 fourteenth article covers the ReAct engineering discipline that keeps these failure modes out in the first place. Start with Article 1 below, or use the Jump to article menu in the top navigation at any time.
Capability and credential boundaries
-
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.
Untrusted content and influence
-
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.
Supply chain and pipelines
-
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.
Observability, governance, and trust calibration
-
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.
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 thirteen 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.