Secure Architecture (SA)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Publish the reference architectures for safely building each AI/HAI software archetype the organization ships, so teams have a vetted "green path" that already implements SR-Software requirements and contains the threats identified by TA-Software.

Description: SA-Software ships a catalog of reference patterns, one per AI/HAI software archetype, showing how to place the data boundary, enforce identity, route traffic, log activity, isolate tenants, and contain agentic behavior for software the org builds. Each pattern covers scope, data boundary, identity and auth, traffic path, logging, controls mapped to SR requirements, and threats mitigated (tagged to HAI TTPs and MITRE ATLAS). The catalog is accompanied by an anti-pattern list derived from real incidents in the wild and from first-party post-incident reviews. Teams use the reference pattern as the starting point; deviations require design review. At L2, patterns are encoded as IaC and cover multi-region, multi-tenant, and agent-platform complexity calibrated to SM L2's tier-treatment matrix. At L3, patterns are published as open artifacts adopted by the industry.

Context: Without reference patterns, every engineering team inventing an LLM-integrated feature, a tool-using agent, or a RAG pipeline makes the same architectural missteps: LLM provider API keys embedded in client code, agents granted tool scopes broader than any human permission set, RAG pipelines over unclassified corpora, fine-tunes on regulated data without privacy sign-off, customer-facing inference with no output filter or abuse-detection. The downstream cost is threat models that discover problems too late, design reviews that repeat the same finding set, and incidents that replay avoidable anti-patterns. SA-Software makes the secure path the default path, not by blocking engineering, but by publishing a pre-vetted architecture for each archetype so teams reach for the pattern first.

Maturity Level 1

Objective: Publish reference architectures per AI/HAI software archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Software requirements and TA-Software threats

At this level, architecture becomes prescriptive rather than advisory. Reference patterns are named, versioned, and the first thing a team reaches for when building an LLM-integrated app, an agent, a RAG pipeline, a fine-tuning or training workload, an eval harness, a model-serving service, or a classical ML model. The anti-pattern catalog names the mistakes that reliably produce incidents so teams recognize the hazard before they ship.

Dependencies

• SR-Software L1 (required): patterns implement the base + archetype requirement packs; without the pack, pattern controls are stylistic choices rather than requirement-backed decisions.
• TA-Software L1 (required): threat library drives which controls appear in each pattern and which threats each pattern claims to mitigate.
• PC-Software L1 (required): patterns operationalize AI Acceptable Use and Data-Handling policy constraints.
• SM-Software L1 (required): inventory shows which archetypes the org actually builds; patterns are authored for that archetype list, not a theoretical one.
• Supports / unblocks: DR-Software L1 (design reviews use the pattern as the baseline), IR-Software L1 (implementation reviews check pattern adherence), EH-Software L1 (hardening targets the pattern's surface areas), ST-Software L1 (security tests target the pattern's controls).

Desired Outcomes

• Every team building an AI/HAI software artifact finds a documented reference pattern within one click of the SM inventory record.
• Each pattern is concrete enough to implement: named components, data-flow diagram, auth model, logging points, controls with SR traceability, and named threats mitigated.
• Known anti-patterns, the architectural mistakes that have produced real incidents across the industry and inside the org, are named, explained, and linked to the reference pattern that replaces them.
• Deviations from reference patterns are visible and reviewed, not accidental or silent.
• Architecture decisions carry explicit traceability to SR requirements and TA threats so any reviewer can ask "why is the output filter here?" and get a principled answer.

Activities

A) Publish reference architectures per AI/HAI software archetype

Publish one pattern per archetype the org actually ships. Each pattern is concise (≤3 pages), includes a labeled data-flow diagram, and covers the same structural elements so teams know what to expect.

Pattern skeleton (every archetype): - Scope, what the pattern covers and what it explicitly does not. - Data boundary, where org data meets LLM/model calls; what crosses, what is blocked; DLP inspection points; per-tenant context isolation. - Identity and auth, secrets-vault-backed credentials for LLM provider APIs; no hardcoded keys; service-principal model for internal service-to-service calls; per-user vs. per-service token lifecycle. - Traffic path, egress through monitored network; allowlist of LLM provider domains; API-gateway placement; rate-limit / abuse-detection layer. - Logging, prompt + completion log events; tool-call events with full args and return; admin-audit events; retention and exportability meeting the longest applicable regulation. - Controls mapped to SR requirements, explicit row-by-row mapping; gaps acknowledged. - Threats mitigated, which TA-Software archetype threats the pattern addresses, which remain residual; HAI TTP tags (EA / AGH / TM / RA); MITRE ATLAS mitigation IDs where applicable.

Archetype reference patterns:

• LLM-integrated app reference pattern. API-gateway-fronted; prompt-template versioning in source control; output filter / output-integrity guardrail before response leaves the service boundary; per-customer context isolation (no cross-tenant prompt leakage); secrets-vault-backed API keys to LLM providers; egress allowlist for LLM provider domains only; prompt + completion logging with customer-identifier; rate-limit and abuse-detection; degraded-mode fallback when the LLM provider is unreachable. Threats mitigated: prompt injection at input boundary (AGH), training-data leakage via inference (output filter + context isolation), cross-tenant data leakage (context isolation). ATLAS: TA0008 Defense Evasion mitigated by output filter; TA0006 Persistence mitigated by prompt-template versioning.

• AI agent reference pattern. Explicit tool allowlist, no tool is available unless declared; per-tool argument schema validation before invocation; per-tool scope minimization (read-only where possible; single-resource scope where possible); human-in-the-loop gate required for destructive actions, external communications, and customer-affecting tool calls; process-level kill-switch on the agent process; multi-turn memory bounded by session and by token budget; tool-call logging with full args and return value; observable goal vs. action delta (what the agent intended vs. what it actually invoked). Threats mitigated: EA via tool-scope minimization and allowlist; TM via argument schema validation; AGH via session memory bounds and HITL gate; RA via session bounds, kill-switch, and goal-action observability. ATLAS: TA0007 Privilege Escalation mitigated by tool-scope minimization and allowlist; TA0008 Defense Evasion mitigated by tool-call logging and kill-switch; TA0006 Persistence mitigated by session memory bounds.

• RAG pipeline reference pattern. Retrieval-source provenance tracked per retrieved chunk; per-source classification labels attached at index time (public, internal, confidential, regulated); injection-defense over retrieved content (retrieved content treated as untrusted; prompt structure separates instruction from retrieved material); per-tenant retrieval isolation (tenant A cannot receive chunks indexed for tenant B); embedding-store access control; retrieval-result logging with source identifiers. Threats mitigated: retrieval poisoning (source provenance + classification), AGH via retrieved-content injection (content treated as untrusted + structural separation), training-data leakage via embedding inversion (embedding-store access control). ATLAS: TA0006 Persistence mitigated by source provenance; TA0008 Defense Evasion mitigated by injection defense and untrusted-content treatment.

• Fine-tuning / training workload reference pattern. Training-data provenance recorded (source, version, consent basis, license); data-classification pre-flight check, no regulated PII, PHI, or customer confidential data flows into training without explicit Privacy/Legal sign-off and documented legal basis; training-job isolation (training environment has no production network access); model-card auto-populated from the job run (training data sources, hyperparameters, eval results); eval-suite gating before model promotion, a model does not land in the model registry until it passes the eval harness; lineage tracked from training data through model artifact into the model registry. Threats mitigated: training-data leakage (data classification + provenance), training-data poisoning (provenance + source access control), output-integrity regression on model promotion (eval gating). ATLAS: TA0006 Persistence mitigated by lineage tracking; TA0008 Defense Evasion mitigated by model-card auto-population.

• Eval harness reference pattern. Isolated data flows, eval data does not flow to training pipelines; no training data leaks back through eval results; reproducible eval runs with pinned data versions and pinned model versions; regression corpora for jailbreaks, prompt injections, and output-integrity failures maintained in source control; eval-result attestation signed and stored in the model registry as a prerequisite for model promotion; eval results feed ST-Software. Threats mitigated: eval-data contamination of training (isolated data flows), output-integrity regression on promotion (regression corpora + attestation). ATLAS: TA0008 Defense Evasion mitigated by attestation and regression corpora.

• Model-serving service reference pattern. Versioned model deployment behind a stable API interface; canary deployment for new model versions before full rollout; per-model-version logging (which version handled which request); rollback playbook tested at least quarterly; abuse-detection and rate-limit at the serving layer; per-tenant isolation for multi-tenant serving; model-version pinning so a caller cannot be silently moved to a different model family. Threats mitigated: silent-model-swap compatibility failure (version pinning + canary + rollback), output-integrity regression (per-version logging + rollback playbook), abuse (rate-limit + abuse-detection). ATLAS: TA0006 Persistence mitigated by version pinning and canary deployment.

• Classical ML model reference pattern. Model provenance (training data, feature set, version) tracked; model artifact stored in a registry with access control; inference-endpoint access control (no unauthenticated inference); per-request logging; model-drift monitoring baseline established; rollback to previous version tested.

B) Publish the anti-pattern catalog

Name, describe, and prohibit the AI/HAI software architectural patterns that reliably produce incidents. Each anti-pattern entry includes: description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it.

L1 anti-pattern set:

• Prompt-injection-trusting agent, agent receives retrieved content or user input and passes it to the model without structural separation; attacker-crafted content in a document or tool response redirects the agent's goal. Replaced by: agent reference pattern injection-defense + content-as-untrusted treatment.
• Over-broad tool scope, agent declared with tool access far wider than any single task requires; one compromised call can reach any connected system. Replaced by: agent reference pattern per-tool scope minimization + allowlist.
• System-prompt-leaking persona, LLM-integrated app's system prompt contains credentials, customer PII, or business logic that the output filter does not prevent leaking via extraction prompts. Replaced by: LLM-integrated app reference pattern context isolation + output filter.
• Long-session agent without memory bounds, agent accumulates multi-turn context across sessions with no token budget or session boundary; rogue behavior compounds across turns with no reset point. Replaced by: agent reference pattern session memory bounds + kill-switch.
• Fine-tune on user data without opt-out, training workload ingests production user data without recording legal basis, consent check, or providing a deletion pathway; triggers GDPR Art. 17 and Art. 22 obligations. Replaced by: fine-tuning reference pattern data-classification pre-flight + legal-basis documentation.
• Silent model-family swap with no eval gate, a new model version or model family replaces the previous one in a customer-facing service without running the eval harness or canary; output-integrity regressions land in production undetected. Replaced by: model-serving reference pattern canary + eval gating + rollback.
• RAG over unclassified corpus, retrieval pipeline indexes the full internal knowledge base, including confidential and regulated documents, without per-source classification or per-tenant isolation; queries leak across classification boundaries. Replaced by: RAG reference pattern per-source classification + per-tenant isolation.
• LLM API key embedded in client code, LLM provider API key stored in a mobile app bundle, a browser script, or a public repository; any end user or attacker can extract it and consume the org's API quota or access the org's fine-tuned model. Replaced by: LLM-integrated app reference pattern secrets-vault-backed API keys + server-side proxy.
• Secrets in prompts, system prompt or prompt template carries database credentials, internal endpoint URLs, or API tokens to "help" the model; every output-extraction attack becomes a credential-extraction attack. Replaced by: LLM-integrated app reference pattern secrets-vault pattern + prompt-template review.
• Output-integrity-critical decisions with no human gate, agent or LLM-integrated app makes consequential decisions (account deletions, financial transfers, medical recommendations, access grants) based on model output alone, with no human confirmation step. Replaced by: agent reference pattern HITL gate for destructive and customer-affecting actions.

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path

Reference patterns are only useful if teams encounter them at the right moment, when they are proposing or building an AI/HAI software artifact.

• SM inventory records link to the applicable reference pattern(s) at intake.
• Teams choosing an archetype see the reference pattern and declare: "using pattern" or "deviating from pattern."
• Deviations require a lightweight design review (DR-Software L1) with a named architect reviewer and a documented rationale stored with the artifact's inventory record.
• Patterns are reviewed and change-logged quarterly; repeat deviations in the same direction are a signal to update the pattern, not to keep approving exceptions.
• New archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1)

Process Metrics (leading)

• Pattern review cadence, quarterly refresh with change-log maintained.
• New-archetype lead time, new pattern published within 30 days of the first intake in a new archetype category.
• Deviation-review SLA, ≤5 business days from deviation request to decision.
• Anti-pattern catalog linked from the AI Acceptable Use Policy and the SM intake gate.

Effectiveness Metrics (business value)

• Build lead time, time-to-production for a team building a new AI/HAI software artifact via the reference pattern (should decrease after patterns land and the green path is clear).
• Avoided-incident stories, documented cases where the pattern (e.g., HITL gate, output filter, scope minimization) blocked or contained a real risk before it reached production.
• Pattern reuse rate, % of new artifacts using the pattern unchanged vs. deviating; rising reuse indicates the pattern is fit for purpose and the program scales.

Success Criteria

• Seven reference patterns published, each with: labeled data-flow diagram, scope declaration, data-boundary definition, identity and auth model, traffic path, logging spec, and row-by-row mapping to SR-Software requirements and TA-Software threats with HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs.
• Anti-pattern catalog published (minimum 10 entries), linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Software training.
• Deviation-review path operational with a named architect-reviewer population and ≤5 BD SLA.
• ≥85% of active AI/HAI software artifacts in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations.
• 100% of LLM-integrated app and agent artifacts with LLM provider credentials flowing through a secrets vault, no hardcoded keys in code, config, or prompt templates.

Maturity Level 2

Objective: Extend reference patterns to multi-region, multi-tenant, and agent-platform complexity calibrated to SM L2's tier-treatment matrix; encode patterns as IaC with conformance test suites; update the anti-pattern catalog from IM-Software incidents

At this level, architecture moves from "single-path reference" to "production-scale reference set." Tier-conditional patterns apply: Critical-tier artifacts receive the full pattern with per-tenant isolation, data-residency variants, and kill-switch IaC; High-tier artifacts receive monitoring and logging IaC modules; patterns are encoded as Terraform / Pulumi / similar IaC so teams fork rather than handcraft; multi-region, multi-tenant, and agent-platform complexity are all covered. The anti-pattern catalog evolves from real IM-Software findings, not only from industry patterns.

Dependencies

• SA-Software L1 (required): base reference patterns and anti-pattern catalog are the substrate L2 extends.
• SR-Software L2 (required): quantitative and tier-calibrated requirements drive the L2 pattern controls.
• TA-Software L2 (required): per-artifact and per-tier deep threat models surface the controls each L2 pattern must cover.
• SM-Software L2 (required): risk-tier rubric determines which tier-conditional pattern variant applies to each artifact; per §9.3 of the v3.0 framing, this is the prerequisite for all Software-domain L2 practice calibration.
• IM-Software L1+ (required): incidents feed anti-pattern additions and drive pattern evolution.

Desired Outcomes

• Teams building Critical or High-tier AI/HAI software artifacts have a production-grade pattern to fork rather than a napkin sketch to interpret.
• Tier-conditional pattern variants are explicit: Critical gets per-tenant isolation IaC, EU/US/sector data-residency variants, and kill-switch infrastructure; High gets monitoring and logging IaC modules; Medium and Low follow the base pattern.
• Anti-pattern catalog reflects real incidents from IM-Software, not only theoretical harms.
• Pattern drift is detectable: IaC-encoded patterns enable conformance testing; artifacts using old or hand-modified patterns are flagged.
• Architecture evidence for Critical-tier artifacts is sufficient to support EU AI Act Art. 9 risk management, Art. 15 accuracy/robustness/cybersecurity, and ISO/IEC 42001 AIMS documentation obligations.

Activities

A) Tier-conditional pattern extensions

Publish extended pattern variants calibrated to SM L2's tier-treatment matrix. The base L1 patterns remain; L2 adds tier-specific overlays and variants:

• Critical-tier overlay (applies to any archetype at Critical tier): per-tenant isolation enforced at the data boundary and at the retrieval store; EU / US / sector data-residency variant (pattern shows residency enforcement, cross-region data-flow legal basis under GDPR Art. 44–49, sector-specific constraints); kill-switch IaC (infrastructure-level process termination for the agent or inference endpoint, tested quarterly); EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern; a technical-documentation artifact template auto-populated from the IaC module to support Art. 11 documentation duties.
• High-tier overlay: monitoring and logging IaC modules included in the fork (pre-wired prompt/completion log pipeline, tool-call log pipeline, admin-audit log pipeline, alert routing to the SIEM); standard detections from ML-Software L2 pre-wired.
• Multi-region pattern: residency enforcement for global products (region pinning at the API gateway, cross-region failover with residency preservation, GDPR international-transfer mechanism selection step included as a required decision gate in the IaC module).
• Multi-tenant pattern for SaaS: per-tenant namespace isolation at the prompt and context layer; per-tenant embedding-store partitioning; per-tenant API key scoping; tenant-isolation conformance test wired into CI.
• Agent-platform pattern for multi-agent systems: orchestrator-control-plane design with explicit inter-agent trust model; tool-scope inheritance rules (a sub-agent cannot inherit broader scope than its parent); agent-to-agent authentication (no unauthenticated inter-agent calls); orchestrator kill-switch propagates to all child agents; multi-agent session logging consolidated.

B) Patterns-as-IaC with conformance test suites

• All Critical and High-tier pattern variants encoded as forkable IaC modules (Terraform / Pulumi / CloudFormation or equivalent); teams fork rather than handcraft; deviations surface at plan or apply time.
• Each IaC module ships with a conformance test suite: automated checks that the deployed artifact matches the pattern's controls (secrets in vault, egress allowlist applied, logging pipeline wired, HITL gate present for agent archetypes, per-tenant isolation enforced for multi-tenant patterns).
• IaC modules version-pinned; module updates trigger a drift-detection pass against all deployed instances.
• Module change log maintained; teams consuming a module are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh

• Every IM-Software incident classified to an anti-pattern (existing or new); classification recorded in the IM finding.
• Catalog refreshed monthly from IM-Software findings; new anti-patterns surfaced to teams at intake time, not stored in a reference document nobody reads until after the next incident.
• Quarterly review: if three or more artifacts have deviated from a pattern in the same direction, the pattern is queued for update rather than continued exception approval.
• Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2)

Process Metrics (leading)

• Pattern refresh cadence, at least one substantive pattern change per quarter, change-logged.
• Anti-pattern review cadence, monthly from IM-Software findings.
• IaC pipeline health monitored, module-update notification and drift-detection pass tracked.
• Tier-treatment matrix adherence check, quarterly reconciliation of Critical/High artifact list against IaC-encoded pattern adoption.

Effectiveness Metrics (business value)

• Integration time-to-production drops for teams building Critical/High-tier artifacts that fork IaC modules rather than handcraft architecture.
• Incident rate on IaC-encoded deployments lower than on hand-crafted deployments, tracked as a rolling 12-month comparison.
• Conformance test failures caught in CI before production, not in DR or IR.

Success Criteria

• Five tier-conditional extended patterns published (Critical overlay, High overlay, multi-region, multi-tenant, agent-platform), each encoded as a forkable IaC module with a conformance test suite.
• ≥80% of Critical and High-tier AI/HAI software artifacts running on IaC-encoded patterns with plan-time deviation flagging.
• Anti-pattern catalog updated from ≥3 real IM-Software incidents in the last 12 months; new entries surfaced at intake time.
• Conformance test coverage at 100% of IaC-encoded artifact deployments.
• 100% of Critical-tier artifacts with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern documentation.

Maturity Level 3

Objective: Publish reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage regulators and standards bodies on architecture norms for AI/HAI software

At this level, the reference patterns are open artifacts that the industry adopts, forks, and builds on. The org contributes pattern-derived mitigations to MITRE ATLAS (AML.M00xx), to OWASP SAMM AI and Agentic Top 10, to OpenSSF AI, and to the CSA AI Safety Initiative. Pattern adoption telemetry is operational. Regulatory engagement on EU AI Act implementing acts and sector architecture guidance is active. Internal practice is aligned to the published external versions so the two do not diverge.

Dependencies

• SA-Software L2 (required): IaC-encoded patterns and conformance test suites are the substrate L3 publishes and maintains externally.
• SM-Software L3 (alignment): automation and benchmarking substrate supports the telemetry and benchmarking activities at L3.
• IM-Software L2+ (required): incident-to-pattern feedback loop must be operational before incident data drives external contributions.

Desired Outcomes

• At least two SA-Software reference patterns are cited or forked by recognized industry bodies (OWASP, OpenSSF AI, CSA, MITRE ATLAS, sector equivalents).
• MITRE ATLAS mitigation library carries at least two AML.M00xx entries attributable to SA-Software patterns (tool-scope minimization, output-filter placement, session memory bounds, or equivalent).
• Internal practice is aligned to the published external version, not an aspirational document the org once published and no longer follows.
• Regulatory bodies and sector organizations reference SA-Software patterns in architecture guidance or implementing-act consultations.
• Pattern adoption telemetry provides evidence of industry uptake for board and regulator audiences.

Activities

A) Publish reference patterns as open artifacts

• Patterns published under Apache 2.0 or equivalent open license via OWASP SAMM AI, OpenSSF AI, CSA AI Safety Initiative, or equivalent; sector-specific variants via relevant sector bodies (FS-ISAC, H-ISAC, sector AI working groups).
• Maintained upstream in the public repository; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks.
• Pattern adoption telemetry tracked: GitHub forks, citations in published work, documented adopters.
• New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to MITRE ATLAS mitigation library

• For each control in the reference patterns that corresponds to a threat technique in the ATLAS taxonomy, propose or validate a mitigation entry in the ATLAS mitigation library (AML.M00xx).
• Priority contributions aligned to SA's primary ATLAS tactics: TA0006 Persistence (model-version pinning, prompt-template versioning, lineage tracking), TA0007 Privilege Escalation (tool-scope minimization, allowlist enforcement, per-tenant isolation), TA0008 Defense Evasion (output filter, injection defense, model-card transparency, conformance testing).
• Target: at least two AML.M00xx entries proposed or validated per year; contributions traceable to specific SA-Software pattern controls.
• Participate in the ATLAS practitioner community to align SA-Software control vocabulary with ATLAS technique taxonomy.

C) Engage regulators and standards bodies on architecture norms

• Active participation in EU AI Act implementing-act consultations where architecture standards for high-risk AI systems (Annex III use cases) are under discussion; submit the SA-Software patterns as evidence of "state of the art" architectural practice under Art. 9.
• Contribute to ISO/IEC 42001 AIMS community guidance on architecture documentation for AI Management Systems.
• Engage NIST AI RMF Playbook successor editions with SA-Software pattern mappings to GOVERN / MAP / MEASURE / MANAGE.
• Sector-specific: engage sector regulators (FINRA/SEC model risk, HHS/FDA AI-enabled device guidance, NYDFS Part 500) with sector-relevant pattern variants; seek inclusion in sector architecture guidance documents.

Outcome Metrics (L3)

Process Metrics (leading)

• External contribution pipeline, ≥2 pattern items in-flight (draft, in-review, or in-publication) at all times.
• Internal-external alignment audit, quarterly diff between internal pattern versions and published external versions; unexplained divergence queued for resolution.
• ATLAS contribution cadence, at least one contribution or validation per 6 months.
• Regulatory engagement calendar maintained with active items and target timelines.

Effectiveness Metrics (business value)

• Industry recognition, invitations to working groups, citations in published standards, peer adoption of SA-Software patterns.
• Regulatory benefit, SA-Software patterns referenced in implementing-act or guidance documents reduce compliance uncertainty for the org and the industry.
• Talent, external publication and standards participation attracts experienced security architects with AI-specific expertise.
• Faster sanctioned engineering, industry adoption of patterns means external teams the org integrates with arrive already familiar with the architecture norms; integration friction decreases.

Success Criteria

• ≥5 reference patterns published as open artifacts under a recognized open license via at least one industry body (OWASP, OpenSSF AI, CSA, or equivalent).
• ≥2 patterns externally cited or forked by recognized industry or sector bodies.
• ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Software pattern controls, aligned to TA0006 / TA0007 / TA0008.
• Internal practice 100% aligned to the published external version, no unexplained internal deviations; all deviations proposed as upstream contributions.
• At least one documented regulatory or standards-body reference to SA-Software patterns in implementing-act, guidance, or standards text.

Key Success Indicators

Level 1: - Seven reference patterns published, one per archetype (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML), each with a labeled data-flow diagram, scope, data boundary, identity model, traffic path, logging spec, and row-by-row mapping to SR-Software requirements and TA-Software threats; HAI TTP tags (EA / AGH / TM / RA) and MITRE ATLAS mitigation IDs present where applicable. - Anti-pattern catalog published (minimum 10 entries), each linked to a reference pattern element that replaces it; linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Software training. - ≥85% of active AI/HAI software artifacts in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations. - 100% of LLM-integrated app and agent artifacts with LLM provider credentials routed through a secrets vault; no hardcoded API keys in code, config, or prompt templates confirmed by secrets-scanning in CI. - Deviation-review path operational with a named architect-reviewer population, ≤5 BD SLA, and a repeat-deviation signal that queues pattern updates.

Level 2: - Five tier-conditional extended patterns published (Critical overlay, High overlay, multi-region, multi-tenant, agent-platform), each encoded as a forkable IaC module with a conformance test suite; ≥80% of Critical and High-tier artifacts running on IaC-encoded patterns. - Anti-pattern catalog updated from ≥3 real IM-Software incidents in the last 12 months; new entries surfaced at intake time. - Conformance test coverage at 100% of IaC-encoded artifact deployments; plan-time deviation flagging operational. - 100% of Critical-tier artifacts with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern documentation.

Level 3: - ≥5 reference patterns published as open artifacts under a recognized open license; ≥2 cited or forked by recognized industry or sector bodies. - ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Software pattern controls aligned to TA0006 / TA0007 / TA0008. - Internal practice 100% aligned to published external versions; all deviations proposed as upstream contributions, none silently forked. - At least one documented reference to SA-Software patterns in a regulatory implementing-act, sector guidance document, or standards text.

Common Pitfalls

Level 1: - ❌ Patterns are written but not linked from the SM inventory record or the intake gate, teams skip them because they are hard to find, not because they disagree with them. - ❌ The agent reference pattern omits the HITL gate for destructive and customer-affecting tool calls, the most consequential control is the most commonly omitted. - ❌ Anti-patterns remain theoretical; they are not tied to real incidents or to the specific pattern element that replaces them, so developers do not recognize the hazard when they encounter it. - ❌ Deviations are approved individually but the repeat-deviation signal is never wired, patterns never update because nobody aggregates the pattern-update trigger. - ❌ LLM provider API keys are in the pattern diagram but not in a secrets vault in practice, the pattern describes vault-backed keys and the CI secrets-scanner has not been configured, so hardcoded keys persist. - ❌ RAG reference pattern covers retrieval isolation but omits per-source classification at index time, queries bleed across classification boundaries because the corpus was never labeled. - ❌ Pattern controls are mapped to SR requirements in the document but the mapping is never validated against an actual deployed artifact, the traceability is aspirational.

Level 2: - ❌ IaC patterns are forked once and then hand-edited at each deployment, drift is immediate and the IaC substrate provides no baseline enforcement; conformance tests are skipped. - ❌ Tier-conditional patterns exist in documents but the IaC modules do not enforce the tier-specific controls, the Critical overlay exists on paper; deployed Critical-tier artifacts lack per-tenant isolation or kill-switch IaC. - ❌ Anti-pattern catalog grows from incidents but is only accessible as a reference document; teams encounter the anti-pattern again before they encounter the catalog entry. - ❌ Multi-region pattern covers residency in the diagram but does not include the GDPR international-transfer mechanism selection step, teams deploy cross-region data flows without a legal basis. - ❌ Agent-platform pattern for multi-agent systems includes orchestrator kill-switch propagation in the diagram but the IaC module does not wire it, child agents run indefinitely after the orchestrator is stopped. - ❌ Pattern-drift detection fires on low-signal configuration noise; the team ignores it within a month because alert volume overwhelms bandwidth; meaningful drift goes undetected.

Level 3: - ❌ Externally contributed patterns diverge from internal practice, what is published reflects what the org once did; external adopters discover the discrepancy during implementation; trust erodes. - ❌ ATLAS contribution targets are treated as a compliance checkbox, entries are proposed but never followed through to publication because internal legal or security review creates indefinite delay. - ❌ Regulatory engagement is declaratory ("we participated in the consultation") rather than substantive ("our pattern text was incorporated into the guidance"), the program cannot demonstrate that engagement produced outcomes. - ❌ Industry contributions are conference presentations and blog posts; no technical artifacts actually land in MITRE / OWASP / NIST / OpenSSF, external recognition is aspirational. - ❌ Pattern adoption telemetry is not tracked, the org claims patterns are "widely adopted" but has no evidence; external benchmarking is not possible.

Practice Maturity Questions

Level 1: 1. Are seven reference patterns published, one per archetype (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML), each with a labeled data-flow diagram, data-boundary definition, identity and auth model, logging spec, and explicit row-by-row mapping to SR-Software requirements and TA-Software threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs, accessible within one click of the SM inventory record? 2. Are 100% of LLM-integrated app and agent artifacts verified (via CI secrets-scanning, not only policy declaration) to route LLM provider credentials through a secrets vault, and is the anti-pattern catalog linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Software training, with each entry tied to the real incident that generated it? 3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are ≥85% of active AI/HAI software artifacts in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?

Level 2: 1. Are the five tier-conditional extended patterns (Critical overlay, High overlay, multi-region, multi-tenant, agent-platform) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI software artifacts running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries? 2. Has the anti-pattern catalog been updated from ≥3 real IM-Software incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance testing covering 100% of IaC-encoded artifact deployments with findings tracked to resolution? 3. Are 100% of Critical-tier artifacts carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and is the tier-treatment matrix from SM L2 reflected in the pattern variants, Critical artifacts get the Critical overlay, High artifacts get the High overlay, Medium/Low follow the base pattern?

Level 3: 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body, and have ≥2 of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? 2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Software pattern controls aligned to ATLAS primary tactics TA0006 Persistence, TA0007 Privilege Escalation, and TA0008 Defense Evasion, and is there an active ATLAS practitioner engagement cadence? 3. Is there at least one documented reference to SA-Software patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation?

Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Software Last Updated: 2026-05-13 Author: Verifhai