Anti-Patterns and Failure Modes — How the RA + CMM Go Wrong

Anti-Patterns and Failure Modes

Closes peer-review-readiness §4: “No anti-patterns / failure-modes catalog. Every mature framework documents how it goes wrong: BSIMM has activities-not-undertaken; CMMC has appeals; SAMM has scoring caveats.” This page is the wiki’s catalog of how its own recommendations fail in the field, organized by category, with the failure mode that follows and the recovery / prevention mechanism.

Why anti-patterns matter

A framework that doesn’t document its failure modes is a framework that hasn’t been used. Mature frameworks earn legitimacy by naming where they break. The wiki’s RA + CMM are well-argued as designs; this page is what they look like under operational stress. Each entry is the negation of an L3+ control claim — if your program shows the anti-pattern, the L3+ evidence is theater.

Structure of each entry

Every anti-pattern below follows the same shape:

Field	What it captures
Pattern	What it looks like in production
Why it happens	The pressure or incentive that produces it
Failure mode	The concrete bad outcome
Recovery / prevention	What the wiki recommends
Anchor	The wiki page where the positive control is documented

Category 1 — Architecture

A1. PDP becomes a bottleneck

Pattern	Every agent action waits on the central PDP for an authorization decision; the PDP becomes the critical-path latency floor and the single point of failure
Why	Centralization makes policy evaluation easy to audit; defaults to “external service” without sidecar or in-process options
Failure mode	Agent latency unacceptable for interactive uses; PDP outage → mesh-wide stop
Recovery	RA’s PDP-location trade-off: default to sidecar for separation + acceptable latency; inline (in-process) for highest-frequency low-risk decisions; external service only when policy spans org boundaries. Cache decisions for repeat patterns; document fail-mode (fail-closed for high-risk-tier; fail-open for read-only)
Anchor	RA §Trade-offs (PDP location); Oversight Layer

A2. Sentinel signal flood overwhelms Operative bandwidth

Pattern	Sentinels emit telemetry at agent volume (10–20× human log volume); Operatives can’t keep up; alerts queue or drop
Why	Single-agent observability scales linearly with N agents; pre-aggregation isn’t built in
Failure mode	Real alerts hidden in noise; cascade-detection latency exceeds attack timeline
Recovery	Pre-aggregation at the runtime hook, not in the SIEM. Sample non-anomalous events; compress repeat patterns; rate-limit per signal class. The wiki’s Agent Observability page flags 10–20× log volume as not-optional architecture
Anchor	Agent Observability §Key stat; Multi-Agent Runtime Security §Aggregate invariants

A3. Egress proxy is the chokepoint

Pattern	All agent egress goes through a single AgentGateway / Smokescreen instance; the broker takes down every agent when it fails
Why	Centralized brokers are the design pattern; HA configuration is post-MVP afterthought
Failure mode	Mesh-wide outage from broker fault; no graceful degradation
Recovery	Broker → mesh transition above ~50 agents (per the RA trade-off); active-active broker pairs with sticky-session affinity for stateful tool calls; per-tier fail-mode — high-risk tools fail-closed (deny rather than bypass), read-only tools can fail-open with audit
Anchor	RA §Trade-offs (single broker vs mesh)

A4. Credential proxy bypassed by deep agents

Pattern	Credential proxy intercepts declared tool calls; the agent writes its own code, calls APIs directly, and never hits the proxy
Why	Deep-agent products (Claude Code-style) generate code that runs in their own sandbox; the proxy isn’t on the path
Failure mode	Credentials in agent context; trifecta containment broken at the data plane
Recovery	Per PEP for Non-Tool-Mediated Actions: proxy connections out of agent sandboxes; annotate internal API endpoints; require declared-tool path or block egress entirely; track this as a known coverage hole until CMM D5 / D6 evidence catches up
Anchor	PEP for Non-Tool-Mediated Agent Actions; Credential Proxy Pattern

Category 2 — CMM scoring

B1. Cumulative-floor demoralizes teams (largely resolved 2026-05-04)

Pattern	Org has L4 controls in 6 of 9 domains; one weak domain (typically D9 Operations or D7 Observability) drops the headline rating to L1; team disengages
Why	The prior single-floor rule (CMMC 2.0 import) was unforgiving by design and treated all 9 domains as equally load-bearing for cross-domain failure
Failure mode	CMM gets ignored or gamed; honest self-assessment becomes punishing
Recovery (2026-05-04 revision)	The single-floor rule was replaced with dependency-resolved effective scores (v1 = 3 conservative active rules: D2→D5, D2→D7, D3→D4). Operational lag in D9 no longer drags D2 identity controls down; D7 observability gaps in architectural-containment programs (Stripe-style) no longer drag D3+D5 strength down. Headline is now a three-number summary (typical / weakest / strongest) plus the matrix. The pattern is largely resolved; the residual case is a program with a weakness in an upstream-dependency domain (e.g. D2 at L1 with everything else at L4) — there the cap is substantive and the demoralization is honest signal, not punitive aggregation
Anchor	CMM §Aggregation rule; Dependency Rules; Calibration Stress Test; Counter-Arguments §Thesis 4

B2. Cherry-picking — claiming high level on the strong domains (reframed 2026-05-04)

Pattern	Org reports L4 on D2 Identity (where it has Microsoft Agent 365 deployed) without disclosing L1 on D9 Operations
Why	Self-assessment without disclosure discipline is asymmetric reputation gain
Failure mode	The asymmetric program looks mature when its weakest domain is exploitable; observers cannot tell whether the cited domain is representative or selectively reported
Recovery (2026-05-04 revision)	Disclosure discipline replaces the single-floor rule. Any rating claim MUST publish the full per-domain matrix (raw + effective scores under the active dependency-rule version) and the active rule-set version. Reports that cite a single domain’s score without the matrix are non-compliant with the measurement protocol. The cross-domain attack-path concern that the floor rule was approximating is now captured substantively by the active dependency rules (e.g. D2 weakness genuinely caps D5 effective score because identity gates per-agent egress enforcement) — so an org claiming D5 L4 with D2 L1 will see its D5 effective score capped at L1 and cannot honestly headline as L4 in egress
Anchor	CMM §Aggregation rule; Dependency Rules; Measurement Protocol §Aggregation rule

B3. Evidence theatre

Pattern	Artifacts produced for the audit (Cedar policy repo, AI-BOM document, IR runbook) exist but don’t reflect operational reality; nobody runs the IR runbook in a drill
Why	Auditor evidence requirements are document-shaped; operational use is process-shaped; the two diverge over time
Failure mode	Audit-passing programs that fail under real attack
Recovery	The measurement protocol’s live observation requirement at L3+: assessor MUST observe at least one live action per high-risk-tier agent. Static configs alone do not satisfy L3+; L4 requires live behavioral-drift event + live red-team eval; L5 requires live attestation + closed-loop incident replay
Anchor	Measurement Protocol §Live observation requirements

B4. Stub-as-evidence — claiming AIUC-1 readiness without doing the assessment

Pattern	D1 L4 evidence cites “AIUC-1 readiness assessment complete” but the assessment is a self-checklist, not a Schellman-conducted readiness review
Why	”Readiness” is ambiguous — the difference between “we read the standard” and “Schellman reviewed our gap” is large
Failure mode	L4 evidence collapses on first independent audit
Recovery	The AIUC-1 page documents the two-actor audit model — readiness assessment must be conducted by the accredited auditor (Schellman), not self-attested. CMM D1 L4 evidence requires the readiness report, not the self-checklist
Anchor	AIUC-1 §Caveats; CMM D1 L4

Category 3 — Operations

C1. Metagovernance regresses

Pattern	Guardian agent is operational, but the meta-controls that govern it (sandboxing, immutable audit, dry-run mode for new policies, intervention-frequency tracking) drift over time as the GA is treated as “trusted infrastructure”
Why	The supervisor of supervisors gets less attention than the supervised; metagovernance is not on anyone’s primary KPI
Failure mode	A GA failure or compromise has the same blast radius as a privileged insider, with no oversight
Recovery	The five metagovernance controls (separation of identity / sandboxing / audit / monitoring / dry-run) are on a quarterly review cadence at L3+; GA-on-GA disagreement detection at L4 surfaces drift early. Gartner Note 4 explicitly flags this regression risk
Anchor	Guardian Agent Metagovernance

C2. HITL fatigue → rubber-stamping

Pattern	Approver clicks “approve” on every confirmation request because volume is too high to actually evaluate
Why	Per-call approval at scale; no batching, no risk-based gating; cognitive load mismatch
Failure mode	Per the source triangulation §Claim 7: “confirmation fatigue makes per-call approval security-equivalent to no approval.” All HITL value evaporates
Recovery	Coarse-grained approval (per-session, not per-call); approval-budget rate-limiting; queued/batched/optimistic confirmations + LLM-as-second-reviewer (Stripe pattern); approval-rate-without-comment as an explicit D9 KPI to surface rubber-stamping. Reduce HITL surface to irreversible / novel actions only
Anchor	Bullen-talk §Sensitive-action UX; CMM D9

C3. Behavioral baselines go stale

Pattern	Per-agent baselines established at L4 deployment time; agent population churns; new agents inherit the old baseline; drift detection alerts on legitimate change
Why	Baseline maintenance is a job nobody owns; the team that built the L4 monitoring isn’t the team that adds new agents
Failure mode	Alert volume rises until the team disables the rule; D7 L4 evidence becomes false
Recovery	Baselines are owned by the agent’s product team, not security; baseline-refresh cadence (e.g., 30-day rolling) documented in the agent catalog entry; baseline-staleness as a D7 KPI
Anchor	Agent Observability; Multi-Agent Runtime Security §Aggregate invariants

C4. Eval suite as Goodhart’s target

Pattern	The team optimizes the agent to pass the L4 eval suite; novel attacks not in the suite remain undetected
Why	Eval suites are observable; novel-attack coverage is not; the metric becomes the goal
Failure mode	High eval scores; production exploited by attacks the eval doesn’t cover
Recovery	Independent benchmark anchor (AgentDojo) at D7 L4 — vendor self-eval alone is not L4. Quarterly threat-modeling refresh to update the eval; red-team team distinct from product team; explicit “what would we miss?” exercise on every release
Anchor	CMM D7 L4 (four-quadrant red-team coverage); AgentDojo

C5. Red-team becomes ceremonial

Pattern	Quarterly red-team eval is a checkbox; attackers don’t actually try novel things because the report has to look familiar
Why	Quarterly cadence, vendor-tool-driven coverage, fixed scope — all push toward repeatable rather than adversarial
Failure mode	Red-team report becomes documentation, not signal
Recovery	Distinct attack categories at L4 — orchestration (PyRIT) × probe library (Garak) × CI regression (Promptfoo) × continuous CART (Mindgard) — single-tool coverage is not L4; rotate scope per quarter (one quarter focused on multi-agent, next on supply-chain, etc.); allocate budget for novel-attack research
Anchor	CMM D7 L4

Category 4 — Threat-model

D1. Trifecta-split that isn’t

Pattern	Org reports “we split the trifecta” — research agent has untrusted-content + external-comms; personal-assistant agent has private-data + external-comms — but the agents share state via blackboard, RAG, or memory
Why	The split is documented at the agent-definition level but not at the data-flow level; shared state propagates the trifecta back together
Failure mode	Indirect injection in research-agent input → assistant-agent acts on the contaminated state → exfiltration via assistant’s external comms
Recovery	Trifecta split is a data-flow assertion, not an agent-definition assertion. CMM D6 (Data, Memory & RAG) L3+ evidence must include cross-agent provenance and trust-label propagation. Auditors should walk the data flow, not just read the agent manifest
Anchor	Lethal Trifecta §Containment Strategies; Multi-Agent Runtime Security

D2. Cascade-detection without thresholds

Pattern	Org claims D7 L3+ cascade detection but the rules name categories (rapid fan-out, queue storm) without numeric thresholds; nothing actually fires
Why	OWASP ASI08 / Adversa describe categories; rule SQL/YAML is not public; vendor implementations don’t surface thresholds
Failure mode	Detection rules look complete in the rubric; never produce alerts
Recovery	Per the multi-agent runtime security page: org MUST establish thresholds from a 30-day baseline period (rolling p99 + 3σ); rule-firing rate is a D7 KPI; missing-threshold rules are L2 evidence at best
Anchor	Multi-Agent Runtime Security §Cascade detection; Counter-Arguments §unresolved contests

D3. Single-tool red-team coverage claimed as L4

Pattern	Org runs Garak quarterly, calls it “comprehensive AI red team,” reports D7 L4
Why	Single tool is operationally simple; vendor tool sales push single-vendor coverage
Failure mode	Coverage gaps the wiki documents — Garak is probe library not orchestration; multi-turn attacks (PyRIT territory) and CI regression (Promptfoo territory) and continuous (Mindgard) are uncovered
Recovery	The four-quadrant rule is non-optional at L4. Single-tool coverage is explicitly not L4. Add at minimum one tool from each of the other three quadrants plus an independent benchmark anchor
Anchor	CMM D7 L4; PyRIT · Garak · Promptfoo · Mindgard CART · AgentDojo

D4. Behavioral monitoring deployed but no SOC integration

Pattern	Vectra / Miggo / SecureClaw deployed; alerts go to a dashboard nobody watches; SOC playbook references Splunk only
Why	AI security tooling is procured by the AI platform team; SOC integration is a separate project that gets deferred
Failure mode	Detection works; response doesn’t; cascade extends beyond containment window
Recovery	D7 L4 evidence requires alerts wired to SIEM/SOAR — drift alerts feed the same on-call rotation as other security alerts; agent-aware SIEM playbooks (Falcon AIDR + NeMo Guardrails or Sentinel + Defender for Cloud Apps) at L5
Anchor	CMM D7 L4; Agent Observability

Category 5 — Standards / compliance

E1. AIUC-1 cert frozen

Pattern	Org achieves AIUC-1 certification at quarterly refresh N; doesn’t update at refresh N+1 / N+2; still cites “AIUC-1 certified” months later
Why	Quarterly refresh cadence is unusual; standards-fatigue makes maintaining the cert deprioritized
Failure mode	”Certified” claim becomes false; D1 L5 evidence stale
Recovery	The AIUC-1 page makes the freshness requirement explicit: D1 L5 means “certified against the most recent quarterly refresh.” Auditors must check the refresh date; freshness >2 quarters drops the rating
Anchor	AIUC-1 §Update cadence; CMM D1 L5

E2. Crosswalk-as-decoration

Pattern	The standards crosswalk matrix exists but L4+ findings don’t actually carry the per-standard anchors (Annex IV item, AIUC-1 safeguard, ISO 42001 Annex A control, NIST SP 800-53 ID)
Why	The crosswalk is a one-time deliverable; per-finding tagging is ongoing work
Failure mode	The crosswalk doesn’t help compliance because nothing operationalizes it
Recovery	ID-tagged evidence at L3+ — every finding MUST carry the standards-anchor IDs (CMM §Global evidence rule). Untagged findings are L2 at best. The crosswalk is consumed per-finding, not authored once
Anchor	CMM §Global evidence rule; Crosswalk

E3. Standards shopping

Pattern	Org cites whichever framework supports the current claim — NIST AI RMF for governance, CSA ATF for autonomy gates, AIUC-1 for certification, ISO 42001 for management — but doesn’t reconcile contradictions
Why	Multiple frameworks all in the air; consistent crosswalk is hard
Failure mode	Two parts of the org’s evidence contradict each other; auditors find inconsistency
Recovery	The wiki’s validation page documents per-standard verdict and contradictions; the crosswalk is the unified surface; orgs cite the same framework across related findings rather than rotating
Anchor	Validation: Agentic AI CMM vs Widely Adopted Standards

Category 6 — Identity / credential

F1. Per-agent identity but no rotation

Pattern	D2 L3 evidence (every agent has its own identity) is met; identities are issued at agent creation and never rotated
Why	Rotation breaks running workflows; the team prioritized issuance over lifecycle
Failure mode	Compromised credential is forever-valid; revocation has no fail-safe
Recovery	NHI lifecycle bound to code-deploy pipeline, not HR events (Oasis sharpening at D2 L3); rotation cadence + dependency map at D2 L4. Per-credential rotation is the failure mode the NHI page documents
Anchor	NHI; CMM D2 L3/L4

F2. Identity-credential coupling unaddressed

Pattern	Org claims D2 L4 with credential proxy in use, but production has SAS tokens, storage access keys, PATs, Snowflake API keys — where the credential IS the identity. Proxy can’t help
Why	Credential proxy works for decoupled credentials; coupled credentials require structural migration
Failure mode	”Credential proxy in use” is true at the workflow boundary; some workflows route around it
Recovery	D2 L4 evidence requires a coupled-credential migration plan (Identity-Credential Coupling). Audit reports must call out which credentials remain coupled and what the planned migration is
Anchor	Identity-Credential Coupling; NHI

Category 7 — Multi-agent

G1. All-to-all communication graph

Pattern	Multi-agent mesh has default-allow inter-agent communication; the agent communication graph is fully connected; ACL discipline is theoretical
Why	Convenience during development; tightening the graph is post-MVP
Failure mode	Cascade attacks have unbounded fan-out; pairwise/triadic baselines are useless
Recovery	Default-deny ACL as L2+ evidence (Multi-Agent Runtime Security); pair-by-pair authorization documented in A2A Agent Cards. The graph is sparse on purpose
Anchor	Multi-Agent Runtime Security; A2A Protocol

G2. Recovery doctrine = “restart everything”

Pattern	Mesh-wide quarantine is the only documented recovery; “selective rollback” and “rolling restart” are unimplemented
Why	Mesh-wide is operationally simpler; selective recovery requires per-agent state isolation that wasn’t built
Failure mode	Every multi-agent incident triggers full-mesh outage; cost of false positive is hours of downtime
Recovery	The three recovery shapes (selective rollback / rolling restart / mesh-wide quarantine) require infrastructure; build them in the order of severity. D7 L4+ evidence includes per-agent rollback drill
Anchor	Multi-Agent Runtime Security §Recovery

Category 8 — Procurement / governance

H1. Buying the platform = considering coverage complete

Pattern	Org buys Microsoft Agent 365 (or AWS Bedrock Guardrails, or Google Vertex AI Agent Builder) and treats the hyperscaler-embedded controls as full coverage
Why	Procurement-driven security; cross-cloud / cross-platform / cross-vendor concerns deferred
Failure mode	Cross-cloud agent interactions remain ungoverned (per Gartner’s explicit warning: “vendor safeguards typically stop at their own cloud borders”)
Recovery	Independent oversight layer for cross-vendor coverage; treat hyperscaler-embedded as one tier, not the only tier. The Guardian Agent page documents the cross-vendor argument explicitly
Anchor	Guardian Agent; Gartner Market Guide

H2. Vendor-promise-as-evidence

Pattern	D4 L4 evidence cites vendor self-eval (“LlamaFirewall PromptGuard 2: 97.5% recall”) as the L4 standard
Why	Vendor numbers are what the marketing publishes; finding independent benchmarks takes effort
Failure mode	”L4” claims rest on vendor numbers that don’t replicate on independent benchmarks (per source triangulation §Claim 5: AgentDojo is the cleanest independent comparator)
Recovery	Vendor self-eval is insufficient at L4. Independent benchmark anchor (AgentDojo / InjecAgent / WASP) required at L4. Wiki’s source-triangulation audit is the standing reference for what’s vendor-self-eval vs independent
Anchor	Source Triangulation Audit §Claim 5

H3. Decision rights skipped in favor of access policies

Pattern	D1 L3 evidence has Cedar/OPA policy repo; doesn’t have a decision-rights matrix (action class × decision right × approver × justification × time bound). Access policies cover what’s allowed; decision rights cover who decides
Why	Security thinks in access; governance thinks in authority; D1 L3 demands both
Failure mode	Per Knostic: governance ≠ security. An org with strong access controls and no decision-rights documentation has unresolvable accountability after an incident
Recovery	D1 L3 evidence requires both — access policy AND decision-rights matrix. The two are complements, not alternatives
Anchor	Decision Rights for AI Agents; CMM D1 L3

Category 9 — Talent / org

I1. AI security on data scientists with no security training

Pattern	The team running the AI platform also owns AI security; threat-modeling, IR, and adversarial-thinking gaps
Why	Org chart treats AI as a data-science workload; security as a follow-on
Failure mode	Common-sense security controls missing; eval suite optimized for accuracy not adversarial robustness
Recovery	AI security as a joint capability — security team + AI platform team co-own; D9 L3+ evidence includes named AI security role and training plan
Anchor	CMM D9

I2. AI security on traditional security team with no AI training

Pattern	The reverse anti-pattern — the security team handles AI risk with classical-security primitives only; misses AI-specific threats
Why	Org chart treats AI security as a security workload; AI-specific knowledge as out of scope
Failure mode	Prompt injection treated as input validation; supply-chain treated as SBOM-only; novel agentic threats missed
Recovery	Same as I1 — joint capability. Security team training on agentic-AI-specific threats; AI platform team training on threat-modeling and IR. The wiki itself is one input to that training
Anchor	CMM D9

I3. Bus factor 1

Pattern	Single AI security person owns the program; everything depends on their continuity
Why	New domain; small market for AI security talent; teams form around individuals
Failure mode	Personnel change breaks the program; institutional knowledge lost
Recovery	D9 L3+ evidence includes named deputy plus runbook continuity test (every L3+ runbook executable by the deputy without the primary). Bus factor ≥ 2 is a D9 L3 hard requirement
Anchor	CMM D9

How to use this catalog

1. In self-assessment. Walk this list before claiming L3+ evidence. If your program shows the anti-pattern, the L3+ evidence is theater — downgrade or remediate.
2. In audit. External assessors should ask “what’s your version of these anti-patterns?” — orgs that name 3+ that apply to them are operating in good faith. Orgs that claim none probably aren’t paying attention.
3. In peer review. This catalog is the wiki’s “where it goes wrong” appendix. Mature frameworks have these (BSIMM activities-not-undertaken; CMMC appeals; SAMM scoring caveats); the wiki now does too.
4. In post-incident. Every incident review should ask “which of these patterns were operating?” — if the catalog covers it, the recovery is documented. If not, that’s a new entry.

Mapping to BSIMM / CMMC / SAMM precedents

Mature framework	Equivalent feature	What the wiki imports
BSIMM	Activities-not-undertaken — what good orgs don’t do	Several entries (single-tool red-team, vendor-promise-as-evidence) are wiki’s version
CMMC 2.0	Appeals process for rating disputes	Floor-rule + per-domain matrix gives transparency for disagreements
OWASP SAMM	Scoring caveats — when the score doesn’t fit	Multiple anti-patterns (cumulative-floor demoralizes; cherry-picking; evidence theatre) are scoring-caveat shaped
NIST CSF 2.0	”Implementation Tier” gap framing	This page’s anti-patterns are the Implementation Tier failures the CMM is meant to surface

Open issues

What this catalog doesn't yet cover

1. Cross-org / federated anti-patterns — when two orgs share an agent mesh, whose anti-patterns dominate? Not addressed.
2. Empirical incident anchors — most entries are first-principles + practitioner knowledge. Production-incident anchors would strengthen each. The wiki’s GTG-1002 is the only public agentic incident anchor; more are needed before the catalog is empirically validated.
3. Quantitative thresholds for the recovery mechanisms — when is “approval-rate-without-comment” too high? When is “baseline-staleness” too stale? These need numbers.
4. Anti-patterns of this catalog itself — meta-failure: catalog becomes ceremonial / used as a checklist rather than as ongoing reflection. The bar for adding a new anti-pattern is “we’ve seen it in the field” — not “it’s theoretically possible.”

See Also

• Peer-Review Readiness — origin (§4 closed by this page)
• Wiki Novelty and Counter-Arguments — sister page; per-thesis competing-view callouts
• Validation: Agentic AI CMM vs Widely Adopted Standards — sister page; standards comparison
• Agentic AI Security CMM 2026 — the framework these anti-patterns are failure modes of
• Measurement Protocol — live-observation requirements that prevent evidence theatre
• Multi-Agent Runtime Security — multi-agent-specific anti-patterns anchored here
• Guardian Agent Metagovernance — metagovernance regression anchored here