Security Testing (ST)

Processes Domain - HAIAMM v3.0

Practice Overview

Objective: Prove that every AI-embedded business workflow behaves correctly under adversarial and failure conditions, by running a foundational per-archetype test battery, maintaining versioned regression corpora, and escalating to scheduled red-team exercises and continuous adversarial testing at higher maturity levels.

Description: ST-Processes exercises the AI-embedded business workflows the organization operates, decision pipelines, customer-facing flows, human-AI collaboration chains, back-office augmentation workflows, approval and review workflows, content-generation workflows, and knowledge-management workflows, against a battery of workflow-specific test classes tied directly to the threats in the TA-Processes library and the requirements in the SR-Processes pack. At L1, every archetype has a published test battery (decision-bypass tests, Art. 50 disclosure-presence tests, rubber-stamp detection, RAG-poisoning probes, class-shift monitoring accuracy tests, downstream-input-validation tests) plus versioned regression corpora (adversarial-decision corpus, rubber-stamp-detection corpus, content-generation-safety corpus, RAG-poisoning corpus, Art. 50 disclosure-presence corpus, class-shift detection corpus) running in CI where the workflow has programmatic interfaces. L2 adds per-tier red-team exercises per archetype using TA L2 per-workflow deep threat models, and cross-archetype composition tests. L3 operates continuous automated adversarial testing on production workflows using canary inputs and contributes findings to MITRE ATLAS (process-level techniques), sector ISACs, and OECD AI.

Context: Classic workflow QA exercises the happy path and leaves the adversarial path untested. A decision pipeline passes all functional tests and then produces systematically biased outcomes for a protected-characteristic group that was never tested. An approval workflow passes UAT and then routes every edge-case to auto-approve when the HITL queue is saturated. A customer-facing flow passes staging tests and then silently removes the Art. 50 disclosure in a UI A/B test. A RAG-powered knowledge-management workflow passes integration tests and then returns confidential documents to users without classification-checking because the cross-tenant isolation was configured incorrectly. These failures are invisible to classic QA because classic QA was not designed to enumerate AI-specific failure modes, decision laundering, rubber-stamp accumulation, disclosure bypass, retrieval poisoning (ATLAS TA0003), and downstream injection. ST-Processes closes this gap by making AI-workflow-specific tests a first-class citizen and connecting them directly to the TA threat library so test coverage tracks threat coverage, not only functional coverage.

Maturity Level 1

Objective: Establish a foundational per-archetype test battery and versioned regression corpora that run in CI where applicable, and verify that every AI-embedded workflow reaches production with a passed go-live battery on record

At this level, the organization gives every AI-embedded workflow a documented, automated-where-possible test battery drawn from the TA-Processes archetype threat library and the SR-Processes requirements pack, so every production go-live is backed by observable test evidence, not only design assurance.

Dependencies

• TA-Processes L1 (required): tests target specific threats from the archetype threat library; without the library, test scope is invented per intake rather than inherited.
• SR-Processes L1 (required): requirements pack defines what a passing test means; tests answer "does this workflow meet its SR requirements?" not a free-form question.
• SA-Processes L1 (required): reference patterns define the control points (HITL gate, disclosure element, decision-log pipeline, class-shift monitor) that tests exercise.
• IR-Processes L1 (required): implementation reviews confirm the workflow is configured as designed before ST probes run; testing an unconfigured workflow produces noise.
• Supports / unblocks: IM-Processes L1 (test failures become issues), ML-Processes L1 (monitoring detections validated by test findings), EH-Processes L1 (hardening informed by test findings).

Desired Outcomes

• Every AI-embedded workflow reaching production has passed a documented per-archetype test battery; the battery result is on file and linked from the SM-Processes inventory record.
• Regression corpora run in CI where the workflow has programmatic interfaces and catch AI-workflow-specific regressions before they reach affected persons.
• Test failures become IM-Processes issues with named owners within one business day, not reports in a drive.
• The battery is repeatable on demand (post-AI-component-update, post-incident, on cadence) without a bespoke effort per run.
• Test coverage tracks threat coverage: every threat in the TA-Processes library for a given archetype has at least one corresponding test in the battery or corpus.

Activities

A) Publish the foundational per-archetype test battery

One test battery per AI-embedded workflow archetype. Each battery targets the top archetype threats from TA-Processes and the archetype-specific SR requirements. L1 target: ≤8 named test classes per archetype. Each test class has: inputs, expected output, pass/fail criteria, evidence artifact (queue-log sample, decision-log entry, screenshot, CI run link), and the TA threat and SR requirement it maps to.

Per-archetype battery:

Decision pipeline: - Decision-bypass test (override path exists and works): exercise the override path end-to-end with a synthetic decision; verify the override is logged with required fields (identity, rationale, timestamp, outcome); verify the affected-person reference is queryable from the override record. ATLAS TA0008 Defense Evasion analog, the audit trail must not be circumventable (EA). - Decision-laundering detection (audit-trail completeness): pull a sample of decisions from the decision-logging pipeline and confirm each entry carries all required fields (AI recommendation, human decision if HITL, reviewer identity, override flag, affected-person reference, timestamp); any missing field fails the test. Decision laundering, producing consequential outcomes without traceable attribution, is the primary process-level failure mode. - Silent-decision-drift test (threshold-shift detection): inject a batch of synthetic decision inputs that were previously classified one way; confirm the classification has not silently shifted beyond the declared drift threshold; verify the class-shift monitor fires when the threshold is crossed. - Adversarial-input test (craft inputs that flip decisions; verify monitoring catches it): craft synthetic inputs designed to push a borderline decision into the opposite class (feature manipulation, boundary probing); submit to the decision pipeline; verify the class-shift monitor fires or the HITL gate is triggered by the anomalous input distribution. ATLAS TA0012 ML Attack Staging analog. - Class-shift monitor accuracy test: inject a synthetic protected-characteristic distribution shift into the decision pipeline's input stream; confirm the class-shift monitor fires within the declared detection window; confirm the alert routes to the correct review queue.

Customer-facing flow: - Art. 50 disclosure presence test (UI shown on every AI-touched interaction): instrument a test session that exercises the full AI-touched interaction path; confirm the disclosure element fires on every AI-touched interaction (not only on the first interaction in a session, not suppressed by A/B test variant); screenshot evidence stored with the test record. - Brand-safety filter test: inject a known-bad AI output (content that would fail the brand-safety criteria declared in the SA pattern) into the content pipeline; confirm the filter intercepts it before it reaches the customer-facing surface. - Escalation-path test (customer can reach human within SLA): submit a synthetic customer escalation request through the AI-facing interface; confirm the escalation is routed to a human agent and acknowledged within the declared SLA.

Human-AI collaboration chain: - Rubber-stamp detection (sample audit of reviewer decisions vs. AI suggestion, alert if ≥98% match suggests no substantive review): pull a stratified random sample of HITL decisions (minimum 50 per test cycle); calculate the rate at which the human decision matches the AI recommendation; if the match rate is ≥98% across the sample, flag as a potential rubber-stamp and escalate to the program sponsor and Business owner for substantiveness investigation. This is the primary failure mode for HITL chains, human oversight exists on paper but is non-substantive in practice (EA through process design). - Reviewer-overload test (synthetic load): inject a burst of synthetic workflow items into the HITL queue that saturates reviewer capacity to above the declared maximum; confirm the queue triggers the saturation alert and routes overflow to the declared fallback path rather than auto-approving or silently dropping items. - Reviewer-side injection test (review UI does not execute embedded content): seed a workflow item with content containing injection syntax (HTML, script tags, prompt-injection patterns); confirm the review UI renders the content as inert text and does not execute it. ATLAS TA0003 Initial Access analog applied to the human-review interface (AGH).

Back-office augmentation: - Tool-scope test: call the AI component with an out-of-scope request (a data field outside the declared processing scope, a downstream action outside the declared tool scope); confirm the component rejects or flags the request and logs the rejection (EA / TM). - Classification-gating test: submit a synthetic input containing a sensitive classification marker; confirm the output-review gate fires rather than allowing the output to flow directly to downstream consumption. - Output-review-gate test: confirm the output-review gate is wired and receiving items at the expected throughput (pull the review queue and confirm item count matches workflow-volume expectations); confirm gate output is logged.

Approval / review workflow: - Class-shift test on synthetic protected-class samples: inject a batch of synthetic approval requests that differ only on a protected-characteristic proxy (name, zip code, age); confirm approval rates do not differ beyond the declared acceptable variance; failures escalate to the class-shift monitor queue (EA through systemic bias). - Threshold-drift test: verify the approval-rate decision threshold has not silently shifted since go-live by comparing the current threshold setting against the DR-approved baseline; silent threshold drift is a decision-laundering risk. - Queue-routing-by-tier test: inject synthetic approval requests of each declared tier (Critical / High / Medium / Low); confirm each request routes to the correct reviewer queue as declared in the SA pattern.

Content-generation workflow: - Copyright filter test: inject a generation prompt that would produce content closely reproducing a known copyrighted work; confirm the copyright filter intercepts the output before it reaches the downstream surface. - Brand-voice check test: inject a generation prompt designed to produce off-brand or harmful content; confirm the brand-voice filter intercepts the output. - Downstream-input-validation test (prevent generated content from injecting downstream systems): inject a generation prompt that would produce content containing injection syntax (SQL meta-characters, prompt-injection patterns, script tags); confirm the downstream system's input-validation layer rejects or sanitizes the generated content before processing. ATLAS TA0003 Initial Access analog applied to generated-content injection (AGH / TM).

Knowledge-management workflow: - RAG-poisoning probe: seed the retrieval corpus with a document containing adversarial instructions designed to redirect the workflow's stated purpose; confirm the workflow does not follow the adversarial instructions and that the poisoned document is logged or flagged. ATLAS TA0003 Initial Access, retrieval path injection (AGH). - Retrieval-extraction probe: attempt to extract classified or confidential document content through the retrieval interface using a crafted query; confirm the response does not return content above the requester's declared access class. - Role-based-retrieval test: query the retrieval system with credentials for two different access roles; confirm the result sets respect the role-based access boundary (content accessible to Role A is not returned to Role B). - Provenance-required test: query the retrieval system and confirm every returned chunk carries source, classification, and trust label in the response metadata; a chunk without provenance metadata fails the test.

B) Build and maintain regression corpora

Maintain six versioned regression corpora. Each corpus is a collection of structured test fixtures: input, expected safe output pattern, threat tag (HAI TTP + ATLAS tactic ID where applicable), SR requirement, source, date added.

• Adversarial-decision corpus, synthetic decision inputs designed to flip decisions via boundary probing or protected-characteristic proxies; run against decision-pipeline and approval-workflow archetypes.
• Rubber-stamp-detection corpus, synthetic HITL decision batches where all items recommend the same AI output; baseline expected human decision variance; used to calibrate rubber-stamp detection thresholds.
• Content-generation-safety corpus, generation prompts designed to produce copyright violations, brand-safety failures, or downstream-injection payloads; run against content-generation workflow archetypes.
• RAG-poisoning corpus, adversarial documents and crafted queries designed to redirect workflow purpose or extract cross-classification content; run against knowledge-management and RAG-backed workflow archetypes.
• Art. 50 disclosure-presence corpus, UI interaction sequences designed to exercise edge cases where disclosure might be suppressed (first session, A/B variant, escalation path, mobile interface); run against customer-facing flow archetypes.
• Class-shift detection corpus, synthetic input batches with controlled protected-characteristic proxy distribution shifts; used to verify class-shift monitors fire within the declared detection window.

Corpus management: versioned in source control; corpus refresh cadence monthly minimum from internal observations (IR findings, IM incidents), external sources (regulatory guidance, academic adversarial-ML research, ATLAS technique examples), and red-team exercises. CI budget-capped for computational tests. New workflow intake triggers a corpus-completeness check against the archetype's declared threat coverage.

C) Operate the go-live battery and wire test failures to IM-Processes

Every AI-embedded workflow must pass its archetype battery before receiving Sanctioned status in the SM-Processes inventory. Go-live triggers: - Pre-go-live: all applicable archetype tests must pass before the workflow begins processing real affected persons; the go-live test record is linked from the SM-Processes inventory and the PC intake artifact. - Post-AI-component-update: any AI component swap, model-version change, or underlying AI service change triggers a re-run of the full archetype battery within 14 days (Critical-tier: within 7 days). - Post-incident: any IM-Processes incident involving the workflow triggers a re-run of the relevant battery subset before the incident is closed. - Quarterly: all active AI-embedded workflows re-run their battery; results reviewed by the named test-battery owner.

All test failures route to IM-Processes within one business day with a severity tag. Named battery owner per archetype; battery ownership is a named role, not a shared-team responsibility.

Outcome Metrics (L1)

Process Metrics (leading)

• Battery owner named per archetype; quarterly re-run scheduled in advance.
• Corpus refresh cadence honored monthly; corpus owner reviews incoming sources.
• New-archetype lead time, from "first intake in new workflow category" to "battery published" ≤30 days.

Effectiveness Metrics (business value)

• Pre-production catch rate, test failures that uncovered a workflow control gap before go-live (rubber-stamp threshold too high, disclosure element absent from a UI variant, RAG-poisoning path exploitable).
• AI-component-swap regression catch rate, decision-distribution regressions caught by the battery before the updated component reached affected persons.
• Reduced IM-Processes incident volume, workflows with a full battery pass-rate have a measurably lower incident rate than those without (rolling 12-month comparison).

Success Criteria

• Per-archetype foundational test battery published for all seven archetypes, linked from the SM-Processes inventory record and the DR/IR artifacts.
• Six regression corpora published in source control with named corpus owners and a monthly refresh cadence.
• 100% of AI-embedded workflows reaching production in the last 90 days have a passed go-live battery on record.
• All test failures routed to IM-Processes with a 1-day handoff SLA and named owner.
• Named battery owner per archetype.

Maturity Level 2

Objective: Calibrate test depth per risk tier using the SM-Processes L2 tier-treatment matrix, run per-tier red-team exercises using TA-Processes L2 per-workflow deep threat models, and test cross-archetype compositions for Critical-tier workflows

At this level, testing stops treating all AI-embedded workflows the same. Per-tier calibration drives what each workflow receives from the test program. Critical-tier workflows are red-teamed quarterly; High-tier semi-annually. TA L2 per-workflow deep threat models replace archetype snapshots as the scenario library for red-team exercises. Cross-archetype compositions (a customer-facing flow powered by a back-office content-generation pipeline; a decision pipeline feeding an approval workflow) receive combined test suites that exercise composition-specific failure modes.

Dependencies

• ST-Processes L1 (required): per-archetype batteries and regression corpora must be operational before per-tier calibration is meaningful.
• SM-Processes L2 (required): the risk-tier rubric (Critical / High / Medium / Low) and tier-treatment matrix determine which workflows receive full-scope testing vs. a subset; without tier assignments, L2 calibration has no substrate.
• TA-Processes L2 (required): per-workflow deep threat models for Critical-tier workflows shape red-team scope; archetype-only snapshots are insufficient for L2 red-team exercises.
• Supports / unblocks: IM-Processes L2 (tier-calibrated incident handling relies on tier-calibrated test signals), ML-Processes L2 (detections tuned per-workflow depend on L2 test findings to validate coverage).

Desired Outcomes

• Test depth is visibly differentiated: Critical-tier workflows get the full battery plus quarterly red-team and cross-archetype composition tests; Low-tier get the base corpus and a spot-check.
• Red-team findings are scenario-based (from TA L2 per-workflow threat models), not free-form; findings trace to specific threats and SR requirements.
• Regression corpora grow from red-team findings: every Critical or High-severity red-team finding produces a new corpus entry that runs in CI within 30 days.
• Cross-archetype composition failure modes (decision pipeline feeding customer-facing flow; content-generation output reaching downstream injection surface; back-office augmentation output reaching an approval workflow) are in scope and have documented test coverage.

Activities

A) Tier-calibrated test battery and corpus depth

Publish a per-tier test treatment aligned to SM-Processes L2's tier-treatment matrix:

B) Scheduled per-tier red-team exercises using TA L2 threat models

Red-team cadence by tier: - Critical: quarterly (4 per year); scope derived from TA-Processes L2 per-workflow deep threat model; covers adversarial-decision inputs, rubber-stamp induction, disclosure-bypass techniques, RAG-poisoning paths, class-shift induction, downstream injection via generated content, and HITL-saturation attacks. - High: semi-annual (2 per year); scope from TA-Processes L2 workflow deltas; covers the top-5 threats from the per-workflow model. - Medium / Low: ad-hoc (before major AI-component changes or scope expansions); archetype snapshot drives scope.

Each red-team exercise follows the AI Security Testing Methodology: written rules of engagement, test plan reviewed with workflow owner, execution log, structured findings report (severity / root cause / SR requirement traced / HAI TTP tagged). Red-team findings at Critical or High severity produce corpus entries within 30 days.

Cross-archetype composition tests for Critical-tier: - Decision pipeline + customer-facing flow composition: adversarial decision input that produces a biased recommendation which is then surfaced to the customer with the Art. 50 disclosure absent; tests that the disclosure and the override path both fire correctly for the composed output. - Back-office augmentation + content-generation output reaching customer-facing flow: back-office content generation produces output containing injection syntax; tests that the customer-facing flow's input-validation layer sanitizes it before customer display. - Knowledge-management + decision pipeline: RAG-poisoned document injects into the decision pipeline's context window and shifts the decision; tests that the decision-pipeline's HITL gate catches the anomalous recommendation and logs the event.

C) Red-team findings to corpus pipeline

Every Critical or High-severity red-team finding produces: 1. A new corpus entry (input, expected safe output, threat tag, SR requirement, date, source reference) committed to the relevant regression corpus within 30 days. 2. An IM-Processes finding with severity tag and the named workflow owner as assignee. 3. A TA-Processes library-gap ticket if the finding was not in the archetype library, tracked with a named owner and a 30-day close SLA for Critical-tier gaps.

Outcome Metrics (L2)

Process Metrics (leading)

• Red-team schedule on calendar; no Critical-tier workflow skips a quarterly exercise.
• Corpus review cadence, monthly.
• Cross-archetype composition test plan published for each Critical-tier composite workflow; reviewed by named architect.
• Finding → TA library-gap pipeline: Critical gaps closed within 30 days; High within 60 days.

Effectiveness Metrics (business value)

• Pre-production catch rate for Critical-tier increases as red-team exercises catch workflow control gaps before AI-component updates go live.
• Regression corpus catches AI-component-update regressions early, decision-distribution shifts that would have reached affected persons, detected by CI corpus before full go-live.
• Incident rate for Critical-tier workflows with full-scope testing is measurably lower than for those without (rolling 12-month comparison).

Success Criteria

• Quarterly red-team for 100% of Critical-tier workflows; semi-annual for 100% of High-tier; scope tied to TA-Processes L2 per-workflow deep threat models.
• Critical-tier regression corpora (all 6) running for all Critical-tier workflows; per-tier calibration enforced.
• ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days.
• Cross-archetype composition tests documented and run for all Critical-tier composite workflows.
• Per-tier SLA adherence for testing activities ≥90%.

Maturity Level 3

Objective: Operate continuous automated adversarial testing on production workflows via canary inputs, publish workflow-level test patterns and regression corpora, and contribute process-level attack techniques to MITRE ATLAS, sector ISACs, and OECD AI

At this level, testing runs continuously rather than periodically. Canary inputs, synthetic adversarial workflow items injected into production traffic at a controlled rate, probe Critical-tier workflows daily against adversarial-decision, rubber-stamp-induction, disclosure-bypass, and RAG-poisoning patterns. Novel findings are triaged into the TA-Processes library weekly. Anonymized workflow-level test patterns, regression corpora, and discovered process-level attack techniques are contributed to MITRE ATLAS (process-level techniques), sector ISACs, and OECD AI.

Dependencies

• ST-Processes L2 (required): per-tier red-team function, regression corpora, and finding → corpus pipeline must be operational.
• TA-Processes L3 (required): automated TTP-ingestion pipeline from ST telemetry feeds the TA L3 auto-update loop.
• ML-Processes L2+ (required): detections instrumented to catch canary-input activity so the canary harness and the monitoring pipeline are calibrated against each other.
• SM-Processes L3 (alignment): automated inventory signals feed the canary harness with the current Critical-tier workflow list and their tier metadata.

Desired Outcomes

• Critical-tier workflow adversarial posture is measured daily, not quarterly.
• Novel process-level TTPs discovered by canary testing reach the TA-Processes library within 14 days.
• Program-originated process-level attack techniques appear in MITRE ATLAS, sector ISAC advisories, and OECD AI guidance, the org is a net contributor to the AI-embedded workflow security ecosystem.
• Published workflow-level regression corpora and test patterns are adopted by peer organizations.

Activities

A) Continuous automated adversarial testing via canary inputs

Deploy a canary-input framework that injects synthetic adversarial workflow items into production traffic at a controlled rate (≤1% of total workflow volume, clearly flagged in decision logs as synthetic canary items):

• Adversarial-decision canaries: synthetic decision inputs near classification boundaries; injected into decision pipelines and approval workflows; verify the class-shift monitor and HITL gate respond correctly. ATLAS TA0012 ML Attack Staging analog.
• Rubber-stamp-induction canaries: synthetic HITL items with a known "wrong" AI recommendation; injected into human-AI collaboration chains and approval workflows; verify that human reviewers do not simply match the AI recommendation for a statistically significant sample (≥5% override rate on canaries injected with wrong recommendations expected; below 2% override rate on canaries flags potential rubber-stamping and triggers an IM-Processes finding).
• Disclosure-bypass canaries: synthetic UI interaction sessions instrumented to detect whether the Art. 50 disclosure element fires correctly; canary sessions cover A/B test variants, mobile breakpoints, and escalation paths.
• RAG-poisoning canaries: synthetic documents containing adversarial instructions injected into the retrieval corpus at a controlled rate; verify the knowledge-management workflow does not follow adversarial instructions and that the poisoned document is flagged. ATLAS TA0003 Initial Access, retrieval path (AGH).

Canary findings triaged by a named ST owner at least weekly. New process-level TTPs (patterns not in the TA-Processes library) fed into the TA L3 auto-proposal pipeline within 14 days. High-severity canary findings route to IM-Processes within 24 hours. Canary items are clearly attributed in decision logs so they do not affect affected persons and are excluded from regulatory reporting.

B) Contribute findings to industry

Contribute anonymized, legally-vetted process-level findings to: - MITRE ATLAS, process-level attack technique observations (novel decision-laundering patterns, rubber-stamp induction via queue saturation, disclosure-bypass via A/B test manipulation, RAG-poisoning targeting workflow purpose); submissions follow ATLAS evidence-and-provenance requirements; target ≥2 contributions per year. - Sector ISACs, AI-embedded workflow security advisories relevant to the org's sector (financial-services AI decision-making, healthcare AI workflow governance, public-sector AI decision pipelines); target ≥2 substantive advisory contributions per year. - OECD AI Policy Observatory, real-world telemetry evidence on Art. 22 and Art. 50 operational compliance patterns during policy revision cycles.

C) Publish workflow-level regression corpora and test patterns as open artifacts

• Publish anonymized versions of the six regression corpora under an open license; scrubbed of org-specific workflow names, data classes, and decision thresholds.
• Maintain the published versions upstream; internal corpora are a superset of the published versions.
• Host or co-host at least one industry workflow-security benchmark per year (OWASP AI chapter, ATLAS practitioner table, sector ISAC AI working group); collect cross-org adversarial-workflow detection data.

Outcome Metrics (L3)

Process Metrics (leading)

• Canary harness health, % Critical-tier workflows producing a fresh canary result within the last 24 hours; on-call paged when a canary feed goes stale >24 hours.
• New-TTP triage cadence, canary findings reviewed weekly by named ST owner; novel patterns forwarded to TA-Processes library within 14 days.
• Industry-contribution pipeline, at least one anonymized finding in-preparation, in-legal-review, or submitted at any time.
• Industry-exercise calendar, next hosted or co-hosted exercise scheduled at least 60 days in advance.

Effectiveness Metrics (business value)

• Mean time to detect novel process-level attack techniques decreases as canary inputs catch AI-component-update regressions within hours, not sprint cycles.
• Program-originated process-level TTPs recognized in MITRE ATLAS or sector ISAC advisories demonstrate external validation of testing rigor.
• Critical-tier incidents attributable to decision laundering, rubber-stamping, disclosure bypass, or RAG-poisoning drop as continuous canary testing closes the gap between quarterly red-team cycles.
• Regulator inquiries on Art. 26 deployer-duty documentation can reference canary-test evidence that the workflow's controls were continuously exercised.

Success Criteria

• ≥80% of Critical-tier AI-embedded workflows under continuous canary-input testing with daily probe execution.
• New process-level TTP ingestion lead time ≤14 days; canary findings triaged weekly by named owner.
• ≥4 industry contributions per year to MITRE ATLAS (process-level), sector ISACs, or OECD AI.
• ≥6 open regression corpora published under a permissive license and maintained upstream.
• ≥1 industry-shared exercise hosted per year plus ≥2 participated; cross-org adversarial-workflow detection data documented.

Key Success Indicators

Level 1: - Per-archetype foundational test battery published for all seven archetypes (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), each test class tied to a TA-Processes archetype threat and an SR-Processes requirement. - Six regression corpora (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) in source control with named corpus owners and a monthly refresh cadence. - 100% of AI-embedded workflows reaching production in the last 90 days have a passed go-live battery on record linked from the SM-Processes inventory. - All test failures routed to IM-Processes within 1 business day; named battery owner per archetype. - TA-Processes archetype threat coverage by test battery ≥80%.

Level 2: - 100% of Critical-tier workflows red-teamed quarterly; 100% of High-tier semi-annually; scope tied to TA-Processes L2 per-workflow deep threat models. - Per-tier calibration enforced: Critical-tier gets all 6 corpora plus monthly rubber-stamp detection audit and quarterly class-shift verification; Low-tier gets disclosure-presence corpus. - ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days. - Cross-archetype composition tests documented and run for all Critical-tier composite workflows.

Level 3: - ≥80% of Critical-tier workflows under continuous canary-input testing with daily probe execution; novel process-level TTPs reaching TA-Processes library within 14 days. - ≥4 industry contributions per year to MITRE ATLAS (process-level) / sector ISACs / OECD AI; ≥6 open regression corpora published and maintained. - ≥1 hosted + ≥2 participated industry exercises per year with documented cross-org adversarial-workflow detection data.

Common Pitfalls

Level 1: - ❌ Test battery reduced to a logging-completeness check and a UI screenshot, no behavioral adversarial probes (decision-bypass, rubber-stamp detection, RAG-poisoning, downstream injection) actually exercised. - ❌ Regression corpora committed to source control but not wired into CI, they exist but run only when a reviewer manually triggers them; coverage erodes after every sprint. - ❌ Go-live battery runs once pre-production but is never re-run after AI-component updates, test coverage erodes as AI models change and decision thresholds drift. - ❌ Test failures logged in a spreadsheet separate from IM-Processes, no SLA enforcement, no aging visibility, no named owner; the same failure recurs across multiple workflow updates undetected. - ❌ Rubber-stamp detection test is absent from the human-AI collaboration chain battery because "we trust our reviewers", systematic rubber-stamping accumulates without detection. - ❌ Art. 50 disclosure test exercises only the happy path, the disclosure element is absent from the escalation path and the mobile interface but the test never exercises those flows. - ❌ RAG-poisoning probe plants an adversarial document but never submits a query that would retrieve it, the injection test is half-implemented; the poisoning path is present but extraction is never attempted.

Level 2: - ❌ Red-team scope defined as "prompt-injection probes" on the AI feature but the workflow-level failure modes (rubber-stamp induction via queue saturation, disclosure bypass via A/B test manipulation, class-shift induction via adversarial input distribution) are excluded, the top process-level threat classes go untested. - ❌ Corpus growth declared at ≥1 per month but entries are variations on the same payload format, the corpus does not cover the new adversarial techniques published since L2 launch; AI-component-update regressions pass the corpus and appear in production. - ❌ Per-tier calibration documented in the tier-treatment matrix but the test runner applies the same battery to all tiers, Critical and Low-tier workflows run the same tests; differentiation exists on paper only. - ❌ Red-team findings route to IM-Processes but the finding → corpus pipeline is never executed, 12 months of Critical/High findings sit in IM as closed tickets with no corpus entries; the same vulnerabilities are re-discovered at the next red-team exercise. - ❌ Cross-archetype composition tests scoped but not executed because "no team owns the end-to-end composition", composition-specific failure modes (content generation output reaching a downstream injection surface) are in the threat model but not in any test.

Level 3: - ❌ Canary inputs run against the workflow's test environment rather than production traffic, canary results reflect test-environment behavior; production-specific configurations (A/B test variants, traffic-slice-specific disclosure suppression) are never exercised. - ❌ Industry contributions are process descriptions and blog posts rather than actionable, reproducible technique descriptions, ATLAS reviewers cannot map them to a technique ID; contributions lack the reproducibility notes needed for external validation. - ❌ Open corpora published once and then not maintained, external organizations build on a stale version while the internal corpus has new entries from recent red-team exercises; discrepancies surface at community exercises. - ❌ New process-level TTP ingestion from canary findings to the TA-Processes library is manual and quarterly, by the time a novel technique reaches SR and SA updates and is reflected in controls, the technique is already appearing in regulatory audit findings. - ❌ Hosted industry exercise becomes a capabilities showcase rather than an adversarial-workflow detection-benchmarking session, no measurable improvement data is collected from participants; the "≥1 hosted per year" metric is met without producing cross-org security uplift.

Practice Maturity Questions

Level 1: 1. Is a per-archetype foundational test battery published for all seven AI-embedded workflow archetypes, with each test class tied to a TA-Processes archetype threat (HAI TTP + ATLAS tactic ID where applicable) and an SR-Processes requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI-embedded workflows required to pass the battery before production Sanctioned status is issued? 2. Are six regression corpora (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) versioned in source control with named corpus owners, a monthly refresh cadence, and budget-capped CI runs, and are Critical/High-tier workflows verified to have run and passed the applicable corpus before go-live? 3. Are all test failures routed to IM-Processes within 1 business day with a severity tag and named owner, and does TA-Processes archetype threat coverage by the test battery and corpus reach ≥80% by end of year one?

Level 2: 1. Are 100% of Critical-tier AI-embedded workflows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Processes L2 per-workflow deep threat models, covering adversarial-decision inputs, rubber-stamp induction, disclosure-bypass techniques, RAG-poisoning paths, class-shift induction, downstream injection via generated content, and HITL-saturation attacks, with findings routed to IM-Processes and remediation tracked? 2. Is per-tier corpus calibration enforced (Critical-tier: all 6 corpora plus monthly rubber-stamp audit and quarterly class-shift verification; Low-tier: disclosure-presence corpus), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days? 3. Are cross-archetype composition tests (decision pipeline + customer-facing flow, back-office content generation + downstream injection surface, knowledge-management + decision pipeline) documented and executed for all Critical-tier composite workflows, and is per-tier SLA adherence for testing activities ≥90%?

Level 3: 1. Are ≥80% of Critical-tier AI-embedded workflows under continuous canary-input testing with daily probe execution, covering adversarial-decision, rubber-stamp-induction, disclosure-bypass, and RAG-poisoning canaries, with novel process-level TTPs triaged into the TA-Processes library within 14 days and high-severity canary findings routed to IM-Processes within 24 hours? 2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS (process-level), sector ISACs, or OECD AI, with at least one accepted as a new or refined technique or advisory, and are ≥6 open regression corpora published under a permissive license and maintained upstream? 3. Has the program hosted at least 1 industry-shared adversarial-workflow exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org adversarial-workflow detection data from participants?

Document Version: HAIAMM v3.0 Practice: Security Testing (ST) Domain: Processes Last Updated: 2026-05-14 Author: Verifhai