{"version":"1.0","name":"MERIDIAN","functions":[{"code":"GV","name":"Govern","ordinal":1,"description":"Establish accountability, policy, and risk ownership for AI systems."},{"code":"DS","name":"Discover","ordinal":2,"description":"Know what AI you have, what data feeds it, and where it is exposed."},{"code":"SC","name":"Secure","ordinal":3,"description":"Protect data, models, pipelines, and interactions from compromise."},{"code":"DT","name":"Detect","ordinal":4,"description":"See attacks against and through AI systems in time to act."},{"code":"RS","name":"Respond","ordinal":5,"description":"Contain, recover, and learn when AI systems are attacked or misbehave."},{"code":"AS","name":"Assure","ordinal":6,"description":"Prove security continuously through testing, evaluation, and audit."}],"families":[{"id":"AS.1","function_code":"AS","name":"Pre-Deployment Assurance","ordinal":1,"description":null,"maturity":[{"level":1,"descriptor":"Models ship without security evaluation."},{"level":2,"descriptor":"Evaluation requirements and red-team triggers are defined."},{"level":3,"descriptor":"Evals and gates block all releases below threshold, and high-impact systems are red-teamed."},{"level":4,"descriptor":"Gate efficacy and eval coverage are measured against ATLAS techniques."},{"level":5,"descriptor":"Assurance depth scales automatically with measured system risk."}]},{"id":"AS.2","function_code":"AS","name":"Continuous Validation","ordinal":2,"description":null,"maturity":[{"level":1,"descriptor":"Security posture is assumed static after launch."},{"level":2,"descriptor":"Recurring evaluation and re-test cadences are defined."},{"level":3,"descriptor":"Production evals and periodic red-teaming run on schedule."},{"level":4,"descriptor":"Regression detection is measured and drives release decisions."},{"level":5,"descriptor":"Validation is continuous, autonomous, and anticipates model change."}]},{"id":"AS.3","function_code":"AS","name":"Audit & Conformance","ordinal":3,"description":null,"maturity":[{"level":1,"descriptor":"No evidence trail supports AI control claims."},{"level":2,"descriptor":"Evidence requirements per control are defined."},{"level":3,"descriptor":"Evidence is collected per system, mapped to MERIDIAN IDs, and retrievable."},{"level":4,"descriptor":"Conformance is independently assessed and OSCAL artifacts validate against NIST schemas."},{"level":5,"descriptor":"Attestation is machine-generated and continuously current."}]},{"id":"DS.1","function_code":"DS","name":"AI Asset Inventory","ordinal":1,"description":null,"maturity":[{"level":1,"descriptor":"No reliable record of AI systems in use exists."},{"level":2,"descriptor":"An AI inventory exists with owners and impact tiers."},{"level":3,"descriptor":"The inventory is complete and current, validated by discovery spot checks."},{"level":4,"descriptor":"Shadow AI detection runs continuously and reconciles to inventory with coverage metrics."},{"level":5,"descriptor":"The inventory is self-maintaining through automated discovery and registration."}]},{"id":"DS.2","function_code":"DS","name":"Data Provenance & Classification","ordinal":2,"description":null,"maturity":[{"level":1,"descriptor":"Data enters AI systems without classification or lineage."},{"level":2,"descriptor":"AI-eligibility classification rules and a dataset inventory exist."},{"level":3,"descriptor":"All training and retrieval data carries classification and lineage before ingestion."},{"level":4,"descriptor":"Provenance attestation is required and verified for third-party data, with metrics."},{"level":5,"descriptor":"Lineage is captured automatically end to end and is provably complete."}]},{"id":"DS.3","function_code":"DS","name":"Exposure Mapping","ordinal":3,"description":null,"maturity":[{"level":1,"descriptor":"The AI attack surface is unknown."},{"level":2,"descriptor":"AI interfaces and dependencies are documented per system."},{"level":3,"descriptor":"Attack-surface and AI-BOM maps are current and threat-modeled against ATLAS."},{"level":4,"descriptor":"Exposure changes trigger re-modeling, and coverage drift is measured."},{"level":5,"descriptor":"Exposure mapping is continuous and feeds detection and red-team scoping automatically."}]},{"id":"DT.1","function_code":"DT","name":"Telemetry & Logging","ordinal":1,"description":null,"maturity":[{"level":1,"descriptor":"AI interactions are not logged."},{"level":2,"descriptor":"A logging standard defines required AI telemetry."},{"level":3,"descriptor":"All AI systems emit standard telemetry to the SIEM with protected storage."},{"level":4,"descriptor":"Telemetry coverage and completeness are measured, and gaps alert."},{"level":5,"descriptor":"Telemetry adapts automatically to new AI components and attack surfaces."}]},{"id":"DT.2","function_code":"DT","name":"Threat Detection","ordinal":2,"description":null,"maturity":[{"level":1,"descriptor":"AI attacks would be invisible."},{"level":2,"descriptor":"Detection requirements for injection, abuse, and agent anomalies are defined."},{"level":3,"descriptor":"Detections operate across interaction telemetry with a triage workflow."},{"level":4,"descriptor":"Detection efficacy is measured by purple-team detonation and tuned."},{"level":5,"descriptor":"Detections are generated and tuned continuously from emerging TTPs."}]},{"id":"DT.3","function_code":"DT","name":"Model & Pipeline Monitoring","ordinal":3,"description":null,"maturity":[{"level":1,"descriptor":"Model behavior changes go unnoticed."},{"level":2,"descriptor":"Drift and pipeline integrity monitoring requirements are defined."},{"level":3,"descriptor":"Drift thresholds and pipeline change detection run on all production systems."},{"level":4,"descriptor":"Monitoring sensitivity is tuned against measured baselines and incident history."},{"level":5,"descriptor":"Monitoring predicts degradation and compromise before impact."}]},{"id":"GV.1","function_code":"GV","name":"Accountability & Policy","ordinal":1,"description":null,"maturity":[{"level":1,"descriptor":"AI use occurs without policy; decisions are individual judgment calls."},{"level":2,"descriptor":"An approved AI security policy and a named accountable risk owner exist."},{"level":3,"descriptor":"Policy is enforced through review gates, and exceptions are tracked to closure."},{"level":4,"descriptor":"Policy effectiveness is measured through exception and violation metrics reviewed on cadence."},{"level":5,"descriptor":"Policy adapts ahead of need, updated from incident, threat, and regulatory foresight."}]},{"id":"GV.2","function_code":"GV","name":"Risk Management","ordinal":2,"description":null,"maturity":[{"level":1,"descriptor":"AI risks are considered informally, if at all."},{"level":2,"descriptor":"A documented AI risk assessment process and impact tiers exist."},{"level":3,"descriptor":"Every AI system carries a current assessment and a tier that drives control depth."},{"level":4,"descriptor":"Risk decisions are quantified and tracked against tolerance with trend metrics."},{"level":5,"descriptor":"Risk models are continuously recalibrated from incidents, evals, and threat intelligence."}]},{"id":"GV.3","function_code":"GV","name":"Third-Party & Supply Chain Governance","ordinal":3,"description":null,"maturity":[{"level":1,"descriptor":"AI vendors are procured without security review."},{"level":2,"descriptor":"Vendor AI assessments and contractual security clauses are defined and required."},{"level":3,"descriptor":"All AI procurements pass assessment, and embedded-AI disclosure is enforced."},{"level":4,"descriptor":"Vendor AI risk is re-evaluated on model-change notifications against measured SLAs."},{"level":5,"descriptor":"Continuous vendor monitoring feeds procurement and exit decisions automatically."}]},{"id":"GV.4","function_code":"GV","name":"Workforce & Culture","ordinal":4,"description":null,"maturity":[{"level":1,"descriptor":"AI security knowledge is individual and uneven."},{"level":2,"descriptor":"Role-based AI security training and a secure development standard exist."},{"level":3,"descriptor":"Training completion is enforced and the standard is applied in every project."},{"level":4,"descriptor":"Workforce capability is measured through assessments and exercise performance, with gaps closed."},{"level":5,"descriptor":"The culture is self-correcting: practitioners surface AI risks before controls require it."}]},{"id":"RS.1","function_code":"RS","name":"AI Incident Response","ordinal":1,"description":null,"maturity":[{"level":1,"descriptor":"AI incidents are handled by improvisation."},{"level":2,"descriptor":"AI-specific playbooks and severity criteria exist."},{"level":3,"descriptor":"Playbooks are exercised and integrated with enterprise incident response."},{"level":4,"descriptor":"Response performance is measured, including detection and recovery times for AI scenarios."},{"level":5,"descriptor":"Response improves continuously from exercised and real incidents."}]},{"id":"RS.2","function_code":"RS","name":"Containment & Recovery","ordinal":2,"description":null,"maturity":[{"level":1,"descriptor":"There is no way to quickly stop or roll back a misbehaving model."},{"level":2,"descriptor":"Kill-switch, rollback, and remediation procedures are documented."},{"level":3,"descriptor":"Containment and recovery are tested within defined objectives."},{"level":4,"descriptor":"Recovery objectives are measured under realistic exercise conditions."},{"level":5,"descriptor":"Containment is automated with graduated, reversible degradation modes."}]},{"id":"RS.3","function_code":"RS","name":"Disclosure & Learning","ordinal":3,"description":null,"maturity":[{"level":1,"descriptor":"Incidents end without reporting or learning."},{"level":2,"descriptor":"Reporting obligations and feedback procedures are documented."},{"level":3,"descriptor":"Disclosures meet obligations, and findings feed evals and detections."},{"level":4,"descriptor":"Feedback-loop SLAs are measured and closure is verified."},{"level":5,"descriptor":"Lessons propagate automatically into controls, evals, and training."}]},{"id":"SC.1","function_code":"SC","name":"Data Security","ordinal":1,"description":null,"maturity":[{"level":1,"descriptor":"Training and retrieval data has no protection beyond general IT controls."},{"level":2,"descriptor":"Data minimization and integrity requirements are documented."},{"level":3,"descriptor":"Poisoning screens, minimization, and RAG ACL enforcement operate on all corpora."},{"level":4,"descriptor":"Data controls are tested adversarially and their effectiveness is measured."},{"level":5,"descriptor":"Data defenses adapt automatically to new poisoning and leakage techniques."}]},{"id":"SC.2","function_code":"SC","name":"Model Protection","ordinal":2,"description":null,"maturity":[{"level":1,"descriptor":"Models are stored and served without dedicated protection."},{"level":2,"descriptor":"Weight protection and endpoint access-control requirements are defined."},{"level":3,"descriptor":"Encryption, least-privilege access, and audit logging cover all models."},{"level":4,"descriptor":"Extraction resistance is tested and access anomalies are measured."},{"level":5,"descriptor":"Model protection is continuously validated and tuned against live attack telemetry."}]},{"id":"SC.3","function_code":"SC","name":"Supply Chain Security","ordinal":3,"description":null,"maturity":[{"level":1,"descriptor":"Models and packages are pulled from public sources unchecked."},{"level":2,"descriptor":"Provenance verification and scanning requirements are defined."},{"level":3,"descriptor":"All acquired models are verified, scanned, and loaded via safe formats."},{"level":4,"descriptor":"Supply chain controls are tested with seeded malicious artifacts and measured."},{"level":5,"descriptor":"Supply chain trust is cryptographically attested end to end."}]},{"id":"SC.4","function_code":"SC","name":"Input & Interaction Hardening","ordinal":4,"description":null,"maturity":[{"level":1,"descriptor":"Prompts reach models without validation."},{"level":2,"descriptor":"Injection defenses and input validation are documented and partially deployed."},{"level":3,"descriptor":"Layered injection defenses cover all interfaces, including indirect paths."},{"level":4,"descriptor":"Defense effectiveness is measured against an adversarial test corpus on cadence."},{"level":5,"descriptor":"Defenses retune automatically from observed attack patterns."}]},{"id":"SC.5","function_code":"SC","name":"Output & Action Safety","ordinal":5,"description":null,"maturity":[{"level":1,"descriptor":"Model output is trusted and rendered or acted on directly."},{"level":2,"descriptor":"Output handling and guardrail requirements are defined."},{"level":3,"descriptor":"Encoding, validation, and guardrails are enforced on every output path."},{"level":4,"descriptor":"Guardrail bypass rates are measured through scheduled adversarial testing."},{"level":5,"descriptor":"Output safety adapts in-line to novel bypass patterns with measured drift."}]},{"id":"SC.6","function_code":"SC","name":"Infrastructure & Pipeline","ordinal":6,"description":null,"maturity":[{"level":1,"descriptor":"AI runs on general-purpose infrastructure with no specific hardening."},{"level":2,"descriptor":"Hardening baselines, secrets rules, and decommissioning procedures exist."},{"level":3,"descriptor":"Baselines, vaulted secrets, and decommissioning are enforced across environments."},{"level":4,"descriptor":"Configuration drift and secrets exposure are continuously measured and remediated."},{"level":5,"descriptor":"Infrastructure is immutable or self-healing with provable configuration state."}]},{"id":"SC.7","function_code":"SC","name":"Agentic AI Security","ordinal":7,"description":null,"maturity":[{"level":1,"descriptor":"Agents run with inherited human credentials and unrestricted tools."},{"level":2,"descriptor":"Agent permission, identity, and sandbox requirements are defined."},{"level":3,"descriptor":"Least-privilege manifests, non-human identities, and sandboxing are enforced for all agents."},{"level":4,"descriptor":"Agent containment is tested adversarially and blast radius is quantified."},{"level":5,"descriptor":"Agent authority adjusts dynamically from measured behavior and risk."}]}],"frameworks":[{"code":"aicm","name":"CSA AI Controls Matrix (AICM)","version":null,"url":"https://cloudsecurityalliance.org"},{"code":"atlas","name":"MITRE ATLAS","version":"5.6.0","url":"https://atlas.mitre.org"},{"code":"iso_42001","name":"ISO/IEC 42001","version":"2023","url":"https://www.iso.org/standard/42001"},{"code":"nist_800_53","name":"NIST SP 800-53","version":"Rev 5","url":"https://csrc.nist.gov/pubs/sp/800/53/r5/final"},{"code":"nist_ai_rmf","name":"NIST AI Risk Management Framework","version":"1.0","url":"https://www.nist.gov/itl/ai-risk-management-framework"},{"code":"omb","name":"OMB Memoranda (Federal AI)","version":"M-24-10","url":null},{"code":"oscal","name":"NIST OSCAL","version":null,"url":"https://pages.nist.gov/OSCAL"},{"code":"owasp_llm","name":"OWASP Top 10 for LLM Applications","version":"2025","url":"https://genai.owasp.org"},{"code":"saif","name":"Google Secure AI Framework (SAIF)","version":null,"url":"https://saif.google"},{"code":"sans_aismm","name":"SANS AI Security Maturity Model","version":null,"url":"https://www.sans.org"}],"tags":[{"code":"agentic","name":"Agentic AI"}],"controls":[{"id":"AS-01","family_id":"AS.1","name":"Pre-Deployment Security Evaluation","statement":"Models pass defined security evals (injection resistance, leakage, harmful output) before production.","evidence":"Evaluation reports covering injection resistance, leakage, and harmful output, with pass thresholds, predate production release for sampled models.","tier":"M-1","ordinal":1,"impl_notes":"Define what \"evaluated\" means before anyone asks to ship: a written checklist of safety, leakage, and injection tests with pass thresholds, run against the release candidate, results attached to the deployment ticket. Start with open suites (garak, PyRIT, promptfoo) and add cases from your own threat model. Trap to avoid: treating a passing eval as a safety certificate; it is one sample of a distribution, which is why continuous validation exists.","applicability":["build","acquire"],"lifecycle":["deploy"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.6.2.4","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MEASURE 2.x","note":"eval subcategories","verified":true},{"framework":"saif","reference":"Detection & validation","note":null,"verified":true}]},{"id":"AS-02","family_id":"AS.1","name":"AI Red Teaming","statement":"Adversarial testing against ATLAS-mapped TTPs is performed before release of high-impact systems and periodically thereafter.","evidence":"Red-team reports referencing ATLAS techniques exist for high-impact systems before release and on the defined cadence.","tier":"M-2","ordinal":2,"impl_notes":"Start with structured self-attack before buying anything: one engineer, a week, the OWASP LLM Top 10 as the script, findings written up like any pentest. Graduate to scheduled exercises with rotating objectives (extraction, injection chains, tool abuse) and track which findings recur. Trap to avoid: red teaming only the model; the application layer, retrieval pipeline, and tool integrations are where most real findings live.","applicability":["build","acquire"],"lifecycle":["deploy","operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"Full matrix","note":"red team scenario source","verified":true},{"framework":"nist_800_53","reference":"CA-8","note":null,"verified":true},{"framework":"sans_aismm","reference":"L3-L4","note":"maturity-level calibration","verified":true}]},{"id":"AS-03","family_id":"AS.1","name":"Security Gates in AI CI/CD","statement":"Pipeline gates block promotion of models failing security thresholds (scans, evals, provenance checks).","evidence":"CI/CD configurations show blocking gates, and pipeline history shows promotions blocked on threshold failures.","tier":"M-2","ordinal":3,"impl_notes":"Wire the checks you already trust into the pipeline that ships models: secret scanning on prompt files, dependency audit on ML packages, serialization checks on model artifacts, and a blocking eval-regression suite. One failing gate stops the deploy, same as unit tests. Trap to avoid: advisory-only gates; a warning nobody must act on is a log line, not a control.","applicability":["build"],"lifecycle":["deploy"],"tags":[],"mappings":[{"framework":"aicm","reference":"AIS","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"SA-11","note":null,"verified":true},{"framework":"saif","reference":"Secure development","note":null,"verified":true}]},{"id":"AS-04","family_id":"AS.2","name":"Eval Regression in Production","statement":"Security evals run continuously or regularly against production systems; regressions trigger response.","evidence":"Scheduled production eval runs exist, with regression alerts and corresponding response records.","tier":"M-3","ordinal":4,"impl_notes":null,"applicability":["build","acquire"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_ai_rmf","reference":"MEASURE 2.7","note":null,"verified":true},{"framework":"sans_aismm","reference":"L4-L5","note":"maturity-level calibration","verified":true}]},{"id":"AS-05","family_id":"AS.2","name":"Periodic Adversarial Re-Testing","statement":"Red-team exercises recur on a defined cadence and after material model or guardrail changes.","evidence":"The red-team schedule and reports show cadence adherence and re-tests after material model or guardrail changes.","tier":"M-3","ordinal":5,"impl_notes":null,"applicability":["build","acquire"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"CA-8(2)","note":null,"verified":true},{"framework":"sans_aismm","reference":"L4","note":"maturity-level calibration","verified":true}]},{"id":"AS-06","family_id":"AS.3","name":"AI Control Audit Trail","statement":"Control implementation evidence is collected and auditable per system, mapped to MERIDIAN IDs.","evidence":"An evidence repository maps artifacts to MERIDIAN control IDs per system, and sampled items are retrievable on request.","tier":"M-2","ordinal":6,"impl_notes":"Decide which AI decisions need to be reconstructable later (deployment approvals, guardrail changes, eval sign-offs, access grants) and log who, what, when for each in a system that survives personnel changes. A ticket queue with mandatory fields beats a bespoke tool. Trap to avoid: auditing model outputs but not configuration changes; the question after an incident is \"who changed the system prompt and when.\"","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"9.2","note":null,"verified":true},{"framework":"nist_800_53","reference":"CA-2","note":null,"verified":true}]},{"id":"AS-07","family_id":"AS.3","name":"Machine-Readable Attestation (OSCAL)","statement":"Control catalog, profiles, and system assessments are maintained in OSCAL for federal interoperability.","evidence":"Current OSCAL catalog, profile, and assessment artifacts exist and validate against published NIST OSCAL schemas.","tier":"M-3","ordinal":7,"impl_notes":null,"applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"CA-2","note":null,"verified":true},{"framework":"nist_800_53","reference":"PM-31","note":null,"verified":true},{"framework":"oscal","reference":"Catalog / Profile / SAR","note":null,"verified":true}]},{"id":"AS-08","family_id":"AS.3","name":"Independent Assessment","statement":"High-impact AI systems undergo independent (internal audit or third-party) security assessment.","evidence":"Independent assessment reports exist for high-impact systems, with findings tracked to closure.","tier":"M-3","ordinal":8,"impl_notes":null,"applicability":["build","acquire"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"9.2","note":null,"verified":true},{"framework":"nist_800_53","reference":"CA-2(1)","note":null,"verified":true}]},{"id":"DS-01","family_id":"DS.1","name":"AI System Inventory","statement":"All AI systems (built, acquired, embedded, SaaS) are inventoried with owner, purpose, and impact tier.","evidence":"The AI inventory lists sampled known systems with owner, purpose, and impact tier, and spot checks find no unlisted production AI.","tier":"M-1","ordinal":1,"impl_notes":"Start with a spreadsheet, not a platform: system name, owner, vendor or model, data it touches, who uses it, impact tier. Capture sanctioned tools first, then sweep expense reports, SSO logs, and browser extensions for the rest. Review quarterly. Trap to avoid: waiting for perfect tooling; an 80% complete spreadsheet today beats a CMDB integration next year.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"CM-8","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MAP 1.1","note":null,"verified":true},{"framework":"omb","reference":"M-24-10","note":"federal AI use-case inventory","verified":true}]},{"id":"DS-02","family_id":"DS.1","name":"Model Registry & Model Cards","statement":"Deployed models are registered with versioned model cards documenting intended use, data, and limitations.","evidence":"Registry entries with versioned model cards exist for sampled deployed models, documenting intended use, data, and limitations.","tier":"M-2","ordinal":2,"impl_notes":"Stand up a registry the day you have a second model: every production model gets an entry with owner, version, training data reference, intended use, and known limitations. MLflow or even a disciplined wiki works at first; the discipline is the control. Trap to avoid: model cards written once at launch and never updated; a card that does not match the deployed version is worse than no card.","applicability":["build","acquire"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.6","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MAP 2.1","note":null,"verified":true},{"framework":"saif","reference":"Model documentation","note":null,"verified":true}]},{"id":"DS-03","family_id":"DS.1","name":"Shadow AI Detection","statement":"Unsanctioned AI use (browser tools, plugins, embedded features) is detected via network, SaaS, and endpoint telemetry.","evidence":"Network, SaaS, or endpoint telemetry demonstrably flags unsanctioned AI use, and sampled alerts show triage and disposition.","tier":"M-2","ordinal":3,"impl_notes":"Look where AI actually leaks in: SSO and CASB logs for AI domains, expense reports for AI subscriptions, browser extensions, and the AI features quietly switched on inside approved SaaS. Run the sweep quarterly and feed every find into the inventory (DS-01) rather than a shame list. Trap to avoid: treating discovery as enforcement; if the sanctioned path is worse than the shadow one, you have found a product problem, not just a policy violation.","applicability":["use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"aicm","reference":"GRC","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"CM-8(3)","note":null,"verified":true},{"framework":"sans_aismm","reference":"L2","note":"maturity-level calibration","verified":true}]},{"id":"DS-04","family_id":"DS.2","name":"Training Data Inventory & Lineage","statement":"Datasets used for training, fine-tuning, and RAG are inventoried with source, lineage, and transformation history.","evidence":"The dataset inventory records source, lineage, and transformation history for sampled training, fine-tuning, and RAG corpora.","tier":"M-2","ordinal":4,"impl_notes":"For every training or fine-tuning run, record what data went in, where it came from, and what license or consent covers it, captured at ingestion when the answer is cheap. A manifest file per dataset version is enough to start. Trap to avoid: reconstructing lineage after the fact; six months later nobody remembers which scrape produced which shard, and by then it is a legal question.","applicability":["build"],"lifecycle":["data"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.7","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MAP 2.2","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM04","note":"data & model poisoning","verified":true}]},{"id":"DS-05","family_id":"DS.2","name":"Data Classification for AI Use","statement":"Data is classified for AI eligibility (trainable, retrievable, prohibited) before ingestion.","evidence":"Classification labels (trainable, retrievable, prohibited) exist on sampled datasets with dates preceding their ingestion records.","tier":"M-1","ordinal":5,"impl_notes":"You do not need a new classification scheme, just an AI eligibility column on the one you have: may this class be sent to external AI, internal AI only, or neither. Three buckets are enough. Wire the answer into the AUP and any DLP rules you run. Trap to avoid: classifying documents but not data flows; the spreadsheet pasted into a chat window is the leak, not the file share.","applicability":["build","use"],"lifecycle":["data"],"tags":[],"mappings":[{"framework":"aicm","reference":"DSP","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"RA-2","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM02","note":"sensitive information disclosure","verified":true}]},{"id":"DS-06","family_id":"DS.2","name":"Dataset Provenance Attestation","statement":"Third-party datasets and pretrained corpora carry license and provenance attestation.","evidence":"License and provenance attestations are on file for sampled third-party datasets and pretrained corpora.","tier":"M-3","ordinal":6,"impl_notes":null,"applicability":["build","acquire"],"lifecycle":["data"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0010","note":"AI Supply Chain Compromise","verified":true},{"framework":"nist_800_53","reference":"SR-4","note":null,"verified":true},{"framework":"saif","reference":"Supply chain","note":null,"verified":true}]},{"id":"DS-07","family_id":"DS.3","name":"AI Attack Surface Mapping","statement":"Externally and internally reachable AI interfaces (chat, API, agent, plugin) are enumerated and threat-modeled against ATLAS.","evidence":"A current attack-surface register enumerates AI interfaces, with threat model artifacts referencing ATLAS techniques.","tier":"M-2","ordinal":7,"impl_notes":"Map every way into your AI systems the way an attacker would: endpoints, upload paths, retrieval sources, plugins, agent tool calls, and the admin planes behind them. Diagram it, then walk each edge asking what untrusted input can reach it. Refresh on architecture change, not on a calendar. Trap to avoid: mapping only the chat interface; the retrieval pipeline and tool integrations are attack surface too.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"atlas","reference":"Reconnaissance / Initial Access","note":"tactic-level mapping","verified":true},{"framework":"nist_800_53","reference":"RA-3","note":null,"verified":true},{"framework":"sans_aismm","reference":"L3","note":"maturity-level calibration","verified":true}]},{"id":"DS-08","family_id":"DS.3","name":"AI Dependency Mapping (AI-BOM)","statement":"Models, embeddings, vector stores, packages, and upstream APIs per system are mapped as a dependency graph.","evidence":"AI-BOM or dependency graphs exist for sampled systems covering models, embeddings, vector stores, packages, and upstream APIs.","tier":"M-3","ordinal":8,"impl_notes":null,"applicability":["build","acquire"],"lifecycle":["model","deploy"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"SR-3","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM03","note":"supply chain","verified":true},{"framework":"saif","reference":"Supply chain","note":null,"verified":true}]},{"id":"DT-01","family_id":"DT.1","name":"AI Interaction Logging Standard","statement":"Prompts, outputs, tool calls, retrievals, and model versions are logged to the SIEM per a defined standard.","evidence":"The SIEM contains prompts, outputs, tool calls, retrievals, and model versions for sampled AI systems, conforming to the logging standard.","tier":"M-1","ordinal":1,"impl_notes":"Decide what you log before an incident decides for you: prompts and responses for high-impact systems, metadata at minimum everywhere (who, when, which model, which data source). Send it where your SOC already looks. Mind privacy: prompts can contain personal data, so set retention deliberately. Trap to avoid: logging nothing because full prompt capture feels heavy; metadata alone answers most incident questions.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"aicm","reference":"LOG","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"AU-2","note":null,"verified":true},{"framework":"nist_800_53","reference":"AU-3","note":null,"verified":true},{"framework":"sans_aismm","reference":"L2","note":"maturity-level calibration","verified":true}]},{"id":"DT-02","family_id":"DT.1","name":"AI Log Protection & Privacy","statement":"AI logs are integrity-protected, access-controlled, and retention-managed given their sensitive content.","evidence":"AI log stores show integrity protection, restricted access, and retention configuration matching policy.","tier":"M-2","ordinal":2,"impl_notes":"AI logs are now a sensitive data store: prompts contain customer data, secrets, and personal information. Encrypt them, restrict who can query them, set retention deliberately, and mask known-sensitive patterns at write time. Trap to avoid: solving incident response by logging everything forever; the log store becomes your largest unclassified data lake and a breach target in its own right.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.7","note":null,"verified":true},{"framework":"nist_800_53","reference":"AU-9","note":null,"verified":true}]},{"id":"DT-03","family_id":"DT.2","name":"Injection & Jailbreak Detection","statement":"Detections identify prompt injection, jailbreak attempts, and adversarial inputs in interaction telemetry.","evidence":"Deployed detections for injection and jailbreak exist, and sampled alerts or test detonations show fires with triage records.","tier":"M-2","ordinal":3,"impl_notes":"Detect at two layers: pattern and heuristic checks on inputs (known payload families, encoding tricks, instruction-like content in retrieved documents) and behavioral checks on outputs (refusal collapse, system-prompt echoes, unexpected tool calls). Route hits to the SOC like any other alert source. Trap to avoid: silent blocking with no telemetry; if you drop attacks without recording them, you cannot see campaigns building.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0051","note":null,"verified":true},{"framework":"atlas","reference":"AML.T0054","note":"LLM Jailbreak","verified":true},{"framework":"owasp_llm","reference":"LLM01","note":null,"verified":true},{"framework":"sans_aismm","reference":"L3","note":"maturity-level calibration","verified":true}]},{"id":"DT-04","family_id":"DT.2","name":"Abuse & Extraction Detection","statement":"Anomalous query patterns indicating extraction, inversion, or systematic abuse are detected and rate-responded.","evidence":"Extraction and abuse detections exist, and simulated anomalous query patterns trigger alerts and rate response in test records.","tier":"M-3","ordinal":4,"impl_notes":null,"applicability":["build"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0024","note":"Exfiltration via AI Inference API","verified":true},{"framework":"nist_800_53","reference":"SI-4","note":null,"verified":true}]},{"id":"DT-05","family_id":"DT.2","name":"Anomalous Agent Behavior Detection","statement":"Agent actions are baselined; deviations (unexpected tools, scope, volume) generate alerts.","evidence":"Agent behavior baselines exist, and deviation test cases (unexpected tools, scope, volume) generate alerts in sampled systems.","tier":"M-3","ordinal":5,"impl_notes":null,"applicability":["build","use"],"lifecycle":["operate"],"tags":["agentic"],"mappings":[{"framework":"atlas","reference":"AML.T0053","note":"AI Agent Tool Invocation — detected via agent behavior baseline","verified":true},{"framework":"atlas","reference":"AML.T0086","note":"Exfiltration via AI Agent Tool Invocation — anomalous write-tool usage","verified":true},{"framework":"atlas","reference":"AML.T0034.002","note":"Agentic Resource Consumption — coerced expensive tool-call patterns","verified":true},{"framework":"nist_800_53","reference":"SI-4(13)","note":null,"verified":true},{"framework":"saif","reference":"Agents","note":null,"verified":true}]},{"id":"DT-06","family_id":"DT.3","name":"Model Drift & Behavior Monitoring","statement":"Production model behavior is monitored for drift and degradation that may indicate compromise or decay.","evidence":"Drift metrics and thresholds are monitored, with alert history or dashboards present for sampled production models.","tier":"M-2","ordinal":6,"impl_notes":"Baseline normal before you can see abnormal: refusal rates, output length distributions, tool-call frequency, topic mix. Alert on deviation, and re-baseline after every provider update or model swap, because the update is often the drift. Trap to avoid: monitoring only accuracy metrics; a model can stay accurate while its safety behavior quietly degrades.","applicability":["build","acquire"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.6.2.6","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MEASURE 2.4","note":null,"verified":true}]},{"id":"DT-07","family_id":"DT.3","name":"Pipeline Integrity Monitoring","statement":"Training and data pipelines are monitored for unauthorized modification to data, code, or configuration.","evidence":"Pipeline integrity monitoring covers data, code, and configuration changes, with alert evidence for unauthorized modification tests.","tier":"M-2","ordinal":7,"impl_notes":"Treat the ML pipeline like the production system it is: alert on training-data modifications outside ingestion windows, unexpected model artifact changes, new packages appearing in the environment, and permission changes on pipeline service accounts. Hash artifacts at each stage and verify before promotion. Trap to avoid: watching the model endpoint while the pipeline that produces the model goes unmonitored; upstream is where poisoning happens.","applicability":["build"],"lifecycle":["data","model"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0020","note":null,"verified":true},{"framework":"nist_800_53","reference":"SI-7(7)","note":null,"verified":true}]},{"id":"GV-01","family_id":"GV.1","name":"AI Security Policy","statement":"The organization maintains an approved AI security policy covering development, acquisition, and use of AI systems.","evidence":"An approved, dated AI security policy exists, covers build, acquire, and use scope, and shows review within the last 12 months.","tier":"M-1","ordinal":1,"impl_notes":"Start from your existing security policy, not a blank page: add an AI section covering approved uses, prohibited data, and who approves new AI tools. One to two pages is enough at first. Route it through your normal policy approval path so it carries the same weight as everything else. Trap to avoid: a standalone 30-page AI policy nobody reads; short and enforced beats long and ignored.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"5.2","note":null,"verified":true},{"framework":"nist_800_53","reference":"PM-1","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"GOVERN 1.1","note":null,"verified":true}]},{"id":"GV-02","family_id":"GV.1","name":"Named AI Risk Ownership","statement":"A named senior role is accountable for AI security risk, with documented decision authority.","evidence":"An org chart or charter names the accountable AI risk role, and meeting minutes or risk decisions demonstrate that authority being exercised.","tier":"M-1","ordinal":2,"impl_notes":"Name one person, in writing, with the authority to say no. Usually the CISO or a deputy; the title matters less than documented decision rights over AI adoption, exceptions, and incidents. Record it in the policy and the org chart. Trap to avoid: a committee instead of a name; committees diffuse accountability and stall decisions.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"5.3","note":null,"verified":true},{"framework":"nist_800_53","reference":"PM-2","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"GOVERN 2.1","note":null,"verified":true}]},{"id":"GV-03","family_id":"GV.1","name":"AI Acceptable Use Policy","statement":"An AUP defines permitted and prohibited AI uses, including data that may not be submitted to AI systems.","evidence":"A published AUP enumerates permitted and prohibited AI uses and prohibited data classes, with distribution or attestation records for the workforce.","tier":"M-1","ordinal":3,"impl_notes":"Write the AUP as answers to the questions employees actually ask: which tools are approved, what data can never be pasted into them, and what happens to violations. Publish the approved-tool list somewhere people can find it. Update it when tools are added, not on an annual cycle. Trap to avoid: banning everything; if the sanctioned path is unusable, shadow AI becomes your real policy.","applicability":["use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"aicm","reference":"GRC","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"PL-4","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"GOVERN 4.1","note":null,"verified":true}]},{"id":"GV-04","family_id":"GV.2","name":"AI Risk Assessment Process","statement":"AI systems undergo documented security risk assessment before deployment and on material change.","evidence":"Completed risk assessment artifacts exist for sampled AI systems, dated before deployment and re-run after material changes.","tier":"M-1","ordinal":4,"impl_notes":"Reuse your existing risk assessment template and add AI-specific questions: what data reaches the model, who can see outputs, what actions can it take, what happens if it is wrong or compromised. Run it before deployment and again on material change (new model version, new data source, new permissions). Trap to avoid: assessing the vendor once and never the use case; the same model is low risk in one workflow and high risk in another.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"6.1","note":null,"verified":true},{"framework":"nist_800_53","reference":"RA-3","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MAP / MEASURE","note":"process-level mapping","verified":true}]},{"id":"GV-05","family_id":"GV.2","name":"Impact Thresholds & Risk Tolerance","statement":"Defined impact tiers (e.g., rights-impacting, safety-impacting) determine required control depth per system.","evidence":"Documented impact-tier criteria exist, and sampled systems carry assigned tiers with control depth matching their tier.","tier":"M-2","ordinal":5,"impl_notes":"Write down the thresholds that change the rules: what makes a system high-impact (data sensitivity, user count, autonomy of action, irreversibility), and what extra controls trigger at each threshold. One page, approved by the risk owner. Every new AI use case gets scored against it at intake. Trap to avoid: deciding impact tier per project by negotiation; thresholds exist so the answer is the same no matter who asks.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"RA-2","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"GOVERN 1.3","note":null,"verified":true},{"framework":"omb","reference":"M-24-10","note":"rights/safety-impacting AI definitions","verified":true}]},{"id":"GV-06","family_id":"GV.2","name":"Regulatory & Obligation Mapping","statement":"Applicable AI legal and regulatory obligations are identified and mapped to controls.","evidence":"A maintained obligations register maps applicable AI laws and regulations to MERIDIAN controls, with review dates current.","tier":"M-2","ordinal":6,"impl_notes":"Build a living table: each regulation or framework you answer to (sector rules, privacy law, the EU AI Act if it applies, contractual AI clauses), the obligations it creates, and which MERIDIAN controls satisfy each. The crosswalk does the second half for you. Review when laws change, not annually. Trap to avoid: assuming AI is unregulated because no law says \"AI\"; existing privacy, sector, and consumer-protection law already applies to AI behavior.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"4.2","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"GOVERN 1.1","note":null,"verified":true}]},{"id":"GV-07","family_id":"GV.3","name":"Vendor AI Risk Assessment","statement":"Third-party AI services and embedded-AI products are risk-assessed before procurement.","evidence":"Vendor AI risk assessments exist for sampled procurements and are dated before contract signature.","tier":"M-1","ordinal":7,"impl_notes":"Add AI questions to the vendor review you already run: where is our data processed, is it used for training, how are model changes communicated, what is the incident notification commitment. For embedded AI, ask vendors to disclose it; most contracts predate the feature. Trap to avoid: treating an AI feature inside an approved SaaS product as already assessed; the AI changes the data flow.","applicability":["acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"aicm","reference":"STA","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"SR-6","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"GOVERN 6.1","note":null,"verified":true}]},{"id":"GV-08","family_id":"GV.3","name":"Contractual AI Security Requirements","statement":"Contracts with AI vendors include security, data handling, incident notification, and model-change clauses.","evidence":"Sampled AI vendor contracts contain security, data handling, incident notification, and model-change notification clauses.","tier":"M-2","ordinal":8,"impl_notes":"Put AI terms in the contract before signature, when you have leverage: no training on your data, breach and incident notification clocks, model-change notice, data residency, deletion on exit, and audit or attestation rights. Keep a clause library so procurement can paste rather than negotiate from scratch. Trap to avoid: accepting the vendor's AI addendum unread; the default version usually grants them training rights you just prohibited in your own policy.","applicability":["acquire"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.10","note":null,"verified":true},{"framework":"nist_800_53","reference":"SR-5","note":null,"verified":true},{"framework":"nist_800_53","reference":"SA-4","note":null,"verified":true}]},{"id":"GV-09","family_id":"GV.3","name":"Embedded-AI Disclosure","statement":"Vendors must disclose AI/ML components embedded in delivered products and services.","evidence":"Procurement records include vendor disclosure statements identifying embedded AI/ML components for sampled products.","tier":"M-2","ordinal":9,"impl_notes":"Add one question to vendor intake and renewal: \"Does this product use AI, on what data, and can we turn it off?\" Track answers in the inventory and require notice when AI features are added mid-contract, because that is how most embedded AI arrives. Trap to avoid: assuming a no from 2024 still holds; vendors ship AI features in routine updates without ceremony, and your data flow changes with them.","applicability":["acquire"],"lifecycle":[],"tags":[],"mappings":[{"framework":"nist_ai_rmf","reference":"GOVERN 6.1","note":null,"verified":true},{"framework":"saif","reference":"Supply chain","note":null,"verified":true}]},{"id":"GV-10","family_id":"GV.4","name":"AI Security Awareness & Training","statement":"Role-based training covers AI threats (prompt injection, data leakage, shadow AI) for builders, defenders, and users.","evidence":"Training records show role-based AI security training completion for builders, defenders, and users within the defined cycle.","tier":"M-1","ordinal":10,"impl_notes":"Train for the threats your people will actually meet: prompt injection in plain terms, what data must never enter a chat box, how to spot AI-generated phishing, and how to report something odd. Fifteen focused minutes beats an hour of generic content. Put builders, defenders, and general staff on different tracks. Trap to avoid: one-time onboarding training; the tools and the threats change too fast.","applicability":["build","acquire","use"],"lifecycle":[],"tags":[],"mappings":[{"framework":"iso_42001","reference":"7.3","note":null,"verified":true},{"framework":"nist_800_53","reference":"AT-2","note":null,"verified":true},{"framework":"nist_800_53","reference":"AT-3","note":null,"verified":true},{"framework":"sans_aismm","reference":"L1-L2","note":"maturity-level calibration","verified":true}]},{"id":"GV-11","family_id":"GV.4","name":"Secure AI Development Standard","statement":"Engineering teams follow a documented secure AI/ML development standard.","evidence":"A published secure AI development standard exists, and sampled projects show conformance artifacts such as design reviews or checklists.","tier":"M-2","ordinal":11,"impl_notes":"Extend your secure development standard rather than writing a parallel one: add AI-specific requirements (prompt handling, output encoding, eval gates, model provenance) to the SDLC checkpoints engineers already pass through. Keep it to requirements a reviewer can check, not aspirations. Trap to avoid: a beautiful standalone AI SDL nobody follows because it lives outside the real development workflow.","applicability":["build"],"lifecycle":[],"tags":[],"mappings":[{"framework":"aicm","reference":"AIS","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"SA-3","note":null,"verified":true},{"framework":"nist_800_53","reference":"SA-8","note":null,"verified":true},{"framework":"saif","reference":"Secure development","note":null,"verified":true}]},{"id":"RS-01","family_id":"RS.1","name":"AI Incident Response Playbooks","statement":"IR playbooks cover AI-specific scenarios: injection compromise, poisoning, model theft, harmful-output events.","evidence":"AI-specific playbooks exist for injection compromise, poisoning, model theft, and harmful-output scenarios, with exercise records within 12 months.","tier":"M-1","ordinal":1,"impl_notes":"Take your closest existing playbook (data leak or account compromise) and write the AI variant: how to disable the integration, who calls the vendor, how to preserve prompts and outputs as evidence, who decides on user notification. One page per scenario. Tabletop it once. Trap to avoid: writing playbooks for exotic model-theft scenarios before covering the common one, an employee pasting sensitive data into an unapproved tool.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"IR-8","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MANAGE 4.1","note":null,"verified":true},{"framework":"sans_aismm","reference":"L2","note":"maturity-level calibration","verified":true}]},{"id":"RS-02","family_id":"RS.1","name":"AI Incident Classification","statement":"AI incidents have defined severity criteria, including rights and safety impact, integrated into existing IR taxonomy.","evidence":"The IR taxonomy includes AI severity criteria covering rights and safety impact, and sampled incidents show classification applied.","tier":"M-2","ordinal":2,"impl_notes":"Define severity levels for AI incidents before the first one: what counts as low (guardrail bypass, no data exposure), high (sensitive data in outputs, agent took unauthorized action), and critical (ongoing exfiltration, safety harm). Map each level to response times and escalation paths in your existing IR plan. Trap to avoid: classifying by how novel the attack is instead of by impact; a boring leak is still a leak.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"IR-4","note":null,"verified":true},{"framework":"nist_ai_rmf","reference":"MANAGE 4.1","note":null,"verified":true}]},{"id":"RS-03","family_id":"RS.2","name":"Model Kill Switch & Isolation","statement":"High-impact AI systems can be rapidly disabled, isolated, or degraded to safe mode.","evidence":"Kill-switch and isolation procedures exist, with a test or actual activation record within the defined cycle.","tier":"M-1","ordinal":3,"impl_notes":"Build the off switch before you need it: a documented, tested way to disable each AI integration in minutes — feature flag, API key revocation, route removal — executable by on-call without vendor help. Test it in business hours once a quarter. Trap to avoid: a kill switch that has never been pulled; the first execution should not be during the incident.","applicability":["build","acquire"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.6.2.5","note":null,"verified":true},{"framework":"nist_800_53","reference":"IR-4(2)","note":null,"verified":true},{"framework":"saif","reference":"Operations","note":null,"verified":true}]},{"id":"RS-04","family_id":"RS.2","name":"Model Rollback & Version Recovery","statement":"Prior known-good model versions can be restored within defined recovery objectives.","evidence":"Recovery tests demonstrate restoration of a known-good model version within defined recovery objectives.","tier":"M-2","ordinal":4,"impl_notes":"Keep the last known-good model deployable at all times: versioned artifacts, pinned dependencies, and a rehearsed rollback that takes minutes, not a retraining cycle. Pair every model promotion with a rollback test, the way database migrations pair with down-migrations. Trap to avoid: rollback plans that assume the registry is intact; if the pipeline was compromised, you need an artifact stored outside it.","applicability":["build","acquire"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"aicm","reference":"BCR","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"CP-10","note":null,"verified":true}]},{"id":"RS-05","family_id":"RS.2","name":"Poisoning Remediation","statement":"Procedures exist to identify, remove, and retrain away poisoned data influence.","evidence":"A documented poisoning remediation procedure exists, with tabletop or actual execution evidence on file.","tier":"M-3","ordinal":5,"impl_notes":null,"applicability":["build"],"lifecycle":["data","model"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0020","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM04","note":null,"verified":true}]},{"id":"RS-06","family_id":"RS.3","name":"AI Incident Reporting & Disclosure","statement":"AI incidents are reported per regulatory, contractual, and federal obligations.","evidence":"Reporting obligations are documented with destinations and timelines, and sampled incidents show on-time reports.","tier":"M-2","ordinal":6,"impl_notes":"Decide now who gets told what when an AI incident happens: which events trigger customer notification, regulator notice, or vendor escalation, on what clock, approved by whom. Pre-draft the templates. Your existing breach-notification process covers most of it; add the AI-specific triggers. Trap to avoid: discovering during an incident that nobody knows whether a prompt leak is a reportable breach; decide in daylight.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.8.4","note":null,"verified":true},{"framework":"nist_800_53","reference":"IR-6","note":null,"verified":true}]},{"id":"RS-07","family_id":"RS.3","name":"Post-Incident Eval Feedback","statement":"Incident findings feed red-team scenarios, detections, and eval suites within a defined SLA.","evidence":"Post-incident findings trace to corresponding red-team scenarios, detections, or eval additions within the defined SLA.","tier":"M-3","ordinal":7,"impl_notes":null,"applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_ai_rmf","reference":"MANAGE 4.3","note":null,"verified":true},{"framework":"sans_aismm","reference":"L4","note":"maturity-level calibration","verified":true}]},{"id":"SC-01","family_id":"SC.1","name":"Training Data Integrity","statement":"Training and fine-tuning data is integrity-protected and screened for poisoning before use.","evidence":"Integrity verification records (hashes or signatures) and poisoning-screen results exist for sampled training datasets prior to use.","tier":"M-2","ordinal":1,"impl_notes":"Protect the data that shapes the model: lock down write access to training corpora, hash and verify datasets before each run, and record exactly which version trained which model. Validate sources on ingestion, especially anything scraped or user-contributed. Trap to avoid: assuming poisoning requires a sophisticated adversary; a single compromised upstream feed or disgruntled labeler is the realistic case.","applicability":["build"],"lifecycle":["data"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0020","note":"poison training data","verified":true},{"framework":"nist_800_53","reference":"SI-7","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM04","note":null,"verified":true}]},{"id":"SC-02","family_id":"SC.1","name":"Sensitive Data Minimization","statement":"PII and regulated data is minimized, masked, or excluded from training and retrieval corpora.","evidence":"Sampled corpora show masking or exclusion of regulated data, and scan or DLP reports confirm minimization.","tier":"M-1","ordinal":2,"impl_notes":"Minimize before the data reaches the model: strip or mask identifiers in retrieval sources, block regulated data classes at ingestion, and default chat history and training opt-outs to off in vendor settings. The vendor configuration page is your first control surface. Trap to avoid: relying on the model to not repeat what it was given; if the data went in, assume it can come out.","applicability":["build","use"],"lifecycle":["data"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.7","note":null,"verified":true},{"framework":"nist_800_53","reference":"SI-12","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM02","note":null,"verified":true}]},{"id":"SC-03","family_id":"SC.1","name":"RAG & Knowledge-Base Access Control","statement":"Retrieval sources enforce document-level authorization so model responses respect source ACLs.","evidence":"Access tests with differently privileged users confirm retrieval results respect source document ACLs.","tier":"M-2","ordinal":3,"impl_notes":"The retrieval layer inherits none of your document permissions unless you make it: enforce the querying user's ACLs at retrieval time, not just at index build. Segment indexes by sensitivity so a marketing chatbot physically cannot retrieve HR documents. Trap to avoid: indexing everything into one store and trusting the model to not surface what the user should not see; retrieval is access, full stop.","applicability":["build","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"aicm","reference":"IAM","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"AC-3","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM08","note":"vector & embedding weaknesses","verified":true}]},{"id":"SC-04","family_id":"SC.2","name":"Model Weight Protection","statement":"Model weights and checkpoints are encrypted, access-controlled, and stored in hardened locations.","evidence":"Weight stores show encryption at rest, restrictive ACLs, and access logging for sampled models and checkpoints.","tier":"M-2","ordinal":4,"impl_notes":"Treat weights like the crown-jewel credential they are: encrypted at rest, access-logged, served from infrastructure where exfiltrating a multi-gigabyte file trips alarms. Restrict download paths to the few humans and systems that genuinely need them. Trap to avoid: protecting the production copy while training checkpoints sit world-readable in a bucket; every checkpoint is the model.","applicability":["build","acquire"],"lifecycle":["model"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0025","note":"Exfiltration via Cyber Means — weight/checkpoint theft (corrected from AML.T0048 External Harms)","verified":true},{"framework":"atlas","reference":"AML.T0044","note":"Full AI Model Access","verified":true},{"framework":"nist_800_53","reference":"SC-28","note":null,"verified":true},{"framework":"saif","reference":"Model protection","note":null,"verified":true}]},{"id":"SC-05","family_id":"SC.2","name":"Model Access Control","statement":"Model endpoints require authenticated, least-privilege, auditable access.","evidence":"Endpoint configurations require authentication, and access reviews plus audit logs exist for sampled model endpoints.","tier":"M-1","ordinal":5,"impl_notes":"Put AI endpoints behind the same front door as everything else: SSO, MFA, and least-privilege roles for who can query, who can configure, and who can see logs. Disable shared accounts and anonymous API keys first; they are the common gap. Trap to avoid: securing the chat UI but leaving the underlying API key in a wiki page.","applicability":["build","acquire","use"],"lifecycle":["deploy","operate"],"tags":[],"mappings":[{"framework":"aicm","reference":"IAM","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"AC-3","note":null,"verified":true},{"framework":"nist_800_53","reference":"IA-2","note":null,"verified":true}]},{"id":"SC-06","family_id":"SC.2","name":"Extraction & Theft Resistance","statement":"Rate limiting, query monitoring, and output controls resist model extraction and inversion.","evidence":"Rate limits and query monitoring are configured, and simulated extraction traffic triggers the controls in test records.","tier":"M-3","ordinal":6,"impl_notes":null,"applicability":["build"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0024","note":"Exfiltration via AI Inference API","verified":true},{"framework":"nist_800_53","reference":"SC-5","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM10","note":"Unbounded Consumption (2025); absorbs 2023 LLM10 Model Theft","verified":true}]},{"id":"SC-07","family_id":"SC.3","name":"Model Provenance Verification","statement":"Acquired models and weights are verified via signing, hashes, or attestation before use.","evidence":"Signature, hash, or attestation verification records predate first use for sampled acquired models.","tier":"M-2","ordinal":7,"impl_notes":"Before any third-party model enters your environment, verify it is what it claims: pull from the official publisher namespace, check hashes or signatures where offered, and record source, version, and checksum in the model registry. Prefer hubs and registries that support signing. Trap to avoid: trusting a model because the repo name looks right; lookalike namespaces on public hubs are the typosquatting of the ML era.","applicability":["acquire"],"lifecycle":["model"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"SR-4(4)","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM03","note":null,"verified":true},{"framework":"saif","reference":"Supply chain","note":null,"verified":true}]},{"id":"SC-08","family_id":"SC.3","name":"Third-Party Model Scanning","statement":"Downloaded models are scanned for embedded malicious payloads before loading.","evidence":"Malware and payload scan results exist for sampled downloaded models, with documented allow or block outcomes.","tier":"M-2","ordinal":8,"impl_notes":"Scan third-party models like the executables they are: check serialization format for embedded code, run a malware and backdoor scan (open tools like ModelScan or your platform's built-in scanner), and do a quick behavioral smoke test in isolation before production. Gate the registry on a passing scan. Trap to avoid: scanning once at first import and never on update; a model version bump is new code from the internet, every time.","applicability":["acquire"],"lifecycle":["model"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0010.003","note":"AI Supply Chain Compromise: Model","verified":true},{"framework":"owasp_llm","reference":"LLM03","note":null,"verified":true}]},{"id":"SC-09","family_id":"SC.3","name":"ML Package & Dependency Security","statement":"ML frameworks and packages are vulnerability-managed and sourced from controlled registries.","evidence":"ML dependencies resolve from controlled registries, and vulnerability scan plus remediation records meet defined SLAs.","tier":"M-1","ordinal":9,"impl_notes":"Apply your dependency hygiene to the ML stack: pin versions, scan for known-bad packages, and watch for typosquats of common ML libraries, which are a favored vector. Pull models and packages through an internal proxy or registry rather than straight from public hubs. Trap to avoid: vetting pip packages but pulling models from Hugging Face unverified; a model file is executable supply chain too.","applicability":["build"],"lifecycle":["model","deploy"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"SI-2","note":null,"verified":true},{"framework":"nist_800_53","reference":"SR-3","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM03","note":null,"verified":true}]},{"id":"SC-10","family_id":"SC.3","name":"Safe Model Serialization","statement":"Unsafe serialization formats (e.g., pickle) are prohibited or sandbox-loaded; safetensors preferred.","evidence":"Policy prohibits unsafe serialization formats, and repository or CI checks reject pickle artifacts or enforce sandbox loading in sampled pipelines.","tier":"M-2","ordinal":10,"impl_notes":"Ban unsafe serialization formats outright: no pickle for anything that crosses a trust boundary; use safetensors or equivalent for model artifacts. Scan inbound model files for embedded code before they touch a runtime. Make the safe format the default in your templates so compliance is automatic. Trap to avoid: trusting a model file because it came from a known hub; the format executes on load, and the hub did not review it for you.","applicability":["build","acquire"],"lifecycle":["model"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0010","note":"AI Supply Chain Compromise","verified":true},{"framework":"saif","reference":"Supply chain","note":null,"verified":true}]},{"id":"SC-11","family_id":"SC.4","name":"Prompt Injection Defense","statement":"Layered defenses (input filtering, instruction hierarchy, context isolation) mitigate direct and indirect prompt injection.","evidence":"Layered injection defenses are documented, and adversarial test results demonstrate mitigation of direct and indirect injection for sampled systems.","tier":"M-1","ordinal":11,"impl_notes":"Assume injection will sometimes succeed and build for containment: separate system instructions from user content, treat retrieved documents and web content as untrusted input, and strip or neutralize instructions found inside them. Test with known payloads before launch. Trap to avoid: buying a prompt firewall and declaring victory; filtering is the outer layer, least privilege is the one that holds.","applicability":["build","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0051","note":"LLM prompt injection","verified":true},{"framework":"owasp_llm","reference":"LLM01","note":"prompt injection","verified":true},{"framework":"saif","reference":"Input validation","note":null,"verified":true}]},{"id":"SC-12","family_id":"SC.4","name":"Input Validation & Filtering","statement":"Untrusted inputs (user, retrieved, inter-agent) are validated and sanitized before reaching the model.","evidence":"Input validation rules exist in code or configuration, and test cases show sanitization across user, retrieved, and inter-agent input paths.","tier":"M-1","ordinal":12,"impl_notes":"Validate at the boundary: enforce input length limits, file-type allowlists for uploads, and schema checks on anything structured before it reaches the model. Log what you reject; rejected inputs are early attack telemetry. Trap to avoid: validating only the chat box while file uploads, URLs, and API fields go straight through.","applicability":["build","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0099","note":"AI Agent Tool Data Poisoning — malicious content staged for tool retrieval","verified":true},{"framework":"nist_800_53","reference":"SI-10","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM01","note":null,"verified":true}]},{"id":"SC-13","family_id":"SC.4","name":"System Prompt Protection","statement":"System prompts contain no secrets and are protected against disclosure; disclosure is treated as expected, not catastrophic.","evidence":"System prompts pass secret scans, and disclosure test results show no privilege or data-access change from prompt exposure.","tier":"M-1","ordinal":13,"impl_notes":"Write system prompts as if they will be read by an attacker, because eventually they will be: no credentials, no internal hostnames, no customer names, nothing whose disclosure costs you. Run a secret scanner over prompt files in CI like any other code. Then test: try to extract your own prompt, and confirm nothing breaks when you succeed. Trap to avoid: treating the system prompt as an access control; it is a suggestion, not a boundary.","applicability":["build","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0051.000","note":"Direct Prompt Injection — system prompt extraction vector","verified":true},{"framework":"atlas","reference":"AML.T0084","note":"Discover AI Agent Configuration — embedded knowledge, tool definitions, call chains","verified":true},{"framework":"owasp_llm","reference":"LLM07","note":"system prompt leakage","verified":true}]},{"id":"SC-14","family_id":"SC.5","name":"Output Handling & Encoding","statement":"Model outputs are treated as untrusted: encoded, validated, and never executed or rendered directly.","evidence":"Code review or configuration shows output encoding and validation, and no sampled flow executes or renders model output directly.","tier":"M-1","ordinal":14,"impl_notes":"Treat model output as untrusted user input, because that is what it is: encode it before rendering to prevent injected HTML or script, and require explicit confirmation before any output triggers an action (sending, deleting, executing, purchasing). Trap to avoid: piping model output directly into a downstream system because the demo worked; the demo did not include an adversary.","applicability":["build","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"nist_800_53","reference":"SI-10","note":null,"verified":true},{"framework":"nist_800_53","reference":"SI-15","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM05","note":"improper output handling","verified":true}]},{"id":"SC-15","family_id":"SC.5","name":"Guardrails & Content Controls","statement":"Policy-enforcing guardrails filter harmful, off-policy, or data-leaking outputs.","evidence":"Guardrail policies are configured, and blocked-output logs plus bypass test results demonstrate operation.","tier":"M-2","ordinal":15,"impl_notes":"Layer guardrails by cost: cheap input filters first, model-level system instructions second, output classifiers third, with each layer assuming the previous one missed. Version guardrail configurations and test them like code, with a bypass-rate metric tracked over time. Trap to avoid: tuning guardrails until the product is useless; the goal is containing the harmful tail, not sanding off every edge, and least privilege does the heavy lifting anyway.","applicability":["build","acquire","use"],"lifecycle":["operate"],"tags":[],"mappings":[{"framework":"aicm","reference":"MDL","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"owasp_llm","reference":"LLM02","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM09","note":"misinformation","verified":true}]},{"id":"SC-16","family_id":"SC.6","name":"AI Infrastructure Hardening","statement":"Training and inference infrastructure (GPU clusters, notebooks, MLOps platforms) is hardened and segmented.","evidence":"Hardening baselines and segmentation evidence (configurations, scan results) exist for training and inference infrastructure.","tier":"M-2","ordinal":16,"impl_notes":"AI infrastructure is infrastructure: patch the serving stack, isolate GPU workloads by tenant and sensitivity, lock down the experiment trackers and notebooks that quietly hold credentials and data, and put the inference API behind the same WAF and rate limits as any production API. Trap to avoid: treating the ML platform as a research sandbox exempt from hardening; it usually holds more sensitive data than production.","applicability":["build"],"lifecycle":["deploy"],"tags":[],"mappings":[{"framework":"aicm","reference":"IVS","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"nist_800_53","reference":"CM-6","note":null,"verified":true},{"framework":"nist_800_53","reference":"SC-7","note":null,"verified":true}]},{"id":"SC-17","family_id":"SC.6","name":"Secrets Hygiene in AI Pipelines","statement":"Credentials are never embedded in prompts, training data, or model artifacts; pipeline secrets are vaulted.","evidence":"Secret scans of prompts, datasets, and model artifacts return clean, and pipeline secrets resolve from a vault in sampled configurations.","tier":"M-1","ordinal":17,"impl_notes":"Sweep prompts, agent configurations, notebooks, and pipeline code for embedded credentials; AI projects accumulate keys fast and informally. Move them to the secrets manager you already run, scoped per integration so one leaked key burns one thing. Add AI repos to your existing secret scanning. Trap to avoid: one master API key shared across every AI experiment in the company.","applicability":["build","use"],"lifecycle":["data","model","deploy"],"tags":[],"mappings":[{"framework":"atlas","reference":"AML.T0082","note":"RAG Credential Harvesting — secrets must not be retrievable from corpora","verified":true},{"framework":"nist_800_53","reference":"IA-5","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM02","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM07","note":null,"verified":true}]},{"id":"SC-24","family_id":"SC.6","name":"Secure AI Decommissioning","statement":"Retired AI systems follow a documented decommissioning procedure covering model weight destruction or archival, training and retrieval data disposition, credential revocation, and inventory closure.","evidence":"Decommissioning records for sampled retired systems show weight disposition, data disposal or archival per retention policy, credential revocation, and inventory status closure.","tier":"M-2","ordinal":24,"impl_notes":"Plan the funeral when you deploy: decommissioning an AI system means revoking its credentials and API keys, deleting or archiving its weights and indexes per retention policy, removing its tool grants, and updating the inventory, all on a checklist with an owner. Trap to avoid: turning off the front end while the model endpoint, vector store, and service account live on; abandoned AI infrastructure is unwatched attack surface.","applicability":["build","acquire","use"],"lifecycle":["retire"],"tags":[],"mappings":[{"framework":"iso_42001","reference":"A.6","note":"AI system lifecycle — domain-level mapping","verified":true},{"framework":"nist_800_53","reference":"MP-6","note":"media sanitization — weights, datasets, embeddings","verified":true},{"framework":"nist_800_53","reference":"SR-12","note":"component disposal","verified":true}]},{"id":"SC-18","family_id":"SC.7","name":"Agency Limitation","statement":"Agent and tool permissions follow least privilege with human approval gates for high-impact actions.","evidence":"Agent permission manifests show least privilege, and high-impact actions show human approval records.","tier":"M-2","ordinal":18,"impl_notes":"Give each agent the narrowest charter that does the job: enumerate allowed tools per agent, scope credentials per task, cap loop counts and spend, and require human approval for actions you could not easily undo. Write the limits in configuration, not in the prompt. Trap to avoid: granting an agent broad permissions because the demo needed three of them; agency expands one exception at a time.","applicability":["build","use"],"lifecycle":["operate"],"tags":["agentic"],"mappings":[{"framework":"atlas","reference":"AML.T0086","note":"Exfiltration via AI Agent Tool Invocation — countered by least privilege and approval gates","verified":true},{"framework":"atlas","reference":"AML.T0101","note":"Data Destruction via AI Agent Tool Invocation — countered by mutative-action approval gates","verified":true},{"framework":"nist_800_53","reference":"AC-6","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM06","note":"excessive agency","verified":true},{"framework":"saif","reference":"Agents","note":null,"verified":true}]},{"id":"SC-19","family_id":"SC.7","name":"Plugin, Tool & MCP Server Security","statement":"Third-party plugins, tools, and MCP servers are reviewed, permission-scoped, and inventoried before agent access.","evidence":"A plugin, tool, and MCP server inventory exists with review records and permission scopes dated before agent access.","tier":"M-2","ordinal":19,"impl_notes":"Vet tools and MCP servers like third-party code, because that is what they are: review what each one can read and do, pin versions, and re-review on update, since rug pulls arrive as version bumps. Maintain an allowlist; agents get tools from it and nowhere else. Trap to avoid: letting an agent discover and attach tools dynamically; tool acquisition is a privilege grant and deserves a human in the loop.","applicability":["build","use"],"lifecycle":["deploy","operate"],"tags":["agentic"],"mappings":[{"framework":"atlas","reference":"AML.T0053","note":"AI Agent Tool Invocation (renamed from LLM Plugin Compromise) — agency limits constrain abusive invocation","verified":true},{"framework":"atlas","reference":"AML.T0010.005","note":"AI Supply Chain Compromise: AI Agent Tool","verified":true},{"framework":"atlas","reference":"AML.T0110","note":"AI Agent Tool Poisoning — persistence via poisoned built-in or MCP tools","verified":true},{"framework":"atlas","reference":"AML.T0104","note":"Publish Poisoned AI Agent Tool — countered by review before agent access","verified":true},{"framework":"atlas","reference":"AML.T0109","note":"AI Supply Chain Rug Pull — countered by re-review on tool updates","verified":true},{"framework":"nist_800_53","reference":"SA-9","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM03","note":"Supply Chain (2025); supersedes 2023 LLM07 Insecure Plugin Design","verified":true},{"framework":"saif","reference":"Agents","note":null,"verified":true}]},{"id":"SC-20","family_id":"SC.7","name":"Agent Execution Sandboxing","statement":"Agent code execution and tool calls run in isolated, resource-limited sandboxes.","evidence":"Sandbox configurations show isolation and resource limits, with escape-test results or platform attestations on file.","tier":"M-3","ordinal":20,"impl_notes":null,"applicability":["build"],"lifecycle":["operate"],"tags":["agentic"],"mappings":[{"framework":"atlas","reference":"AML.T0053","note":"AI Agent Tool Invocation — contained by execution sandboxing","verified":true},{"framework":"atlas","reference":"AML.T0105","note":"Escape to Host — sandbox escape from agent execution environment","verified":true},{"framework":"atlas","reference":"AML.T0112.000","note":"Machine Compromise: Local AI Agent","verified":true},{"framework":"nist_800_53","reference":"SC-39","note":null,"verified":true},{"framework":"saif","reference":"Agents","note":null,"verified":true}]},{"id":"SC-21","family_id":"SC.7","name":"Agent Identity & Credentialing","statement":"Agents operate under distinct non-human identities with scoped, short-lived credentials, never shared human accounts.","evidence":"Sampled agents authenticate with unique non-human identities, and credential lifetimes and scopes meet policy.","tier":"M-2","ordinal":21,"impl_notes":"Every agent gets its own identity: dedicated service accounts, short-lived scoped credentials, and logs that attribute each action to the specific agent run that took it. Never let agents share a credential or borrow a human's. Trap to avoid: one service account for the whole agent platform; when something goes wrong you will not know which agent did it, and revoking access means turning everything off.","applicability":["build","use"],"lifecycle":["deploy","operate"],"tags":["agentic"],"mappings":[{"framework":"aicm","reference":"IAM","note":"domain-level mapping (AICM builds on CCM v4 domains)","verified":true},{"framework":"atlas","reference":"AML.T0083","note":"Credentials from AI Agent Configuration — countered by vaulted, scoped, short-lived credentials","verified":true},{"framework":"atlas","reference":"AML.T0098","note":"AI Agent Tool Credential Harvesting","verified":true},{"framework":"nist_800_53","reference":"IA-9","note":null,"verified":true},{"framework":"nist_800_53","reference":"AC-6","note":null,"verified":true},{"framework":"saif","reference":"Agents","note":null,"verified":true}]},{"id":"SC-22","family_id":"SC.7","name":"Inter-Agent Communication Security","statement":"Agent-to-agent and agent-to-orchestrator messages are authenticated, integrity-protected, and treated as untrusted input.","evidence":"Inter-agent channels show authentication and integrity protection, and received messages route through untrusted-input handling.","tier":"M-3","ordinal":22,"impl_notes":null,"applicability":["build"],"lifecycle":["operate"],"tags":["agentic"],"mappings":[{"framework":"atlas","reference":"AML.T0051.001","note":"Indirect Prompt Injection via inter-agent messages","verified":true},{"framework":"atlas","reference":"AML.T0094","note":"Delay Execution of LLM Instructions — deferred instructions across turns and agents","verified":true},{"framework":"atlas","reference":"AML.T0051.002","note":"Triggered Prompt Injection — event-conditioned activation in agent workflows","verified":true},{"framework":"nist_800_53","reference":"SC-8","note":null,"verified":true},{"framework":"saif","reference":"Agents","note":null,"verified":true}]},{"id":"SC-23","family_id":"SC.7","name":"Agent Memory & State Protection","statement":"Persistent agent memory and state are access-controlled, validated on write, and purgeable to counter memory poisoning.","evidence":"Agent memory stores show ACLs and write validation, and a purge procedure exists with test evidence.","tier":"M-3","ordinal":23,"impl_notes":null,"applicability":["build","use"],"lifecycle":["operate"],"tags":["agentic"],"mappings":[{"framework":"atlas","reference":"AML.T0080","note":"AI Agent Context Poisoning (Memory .000 / Thread .001) — supersedes the AML.T0020 analog mapping","verified":true},{"framework":"atlas","reference":"AML.T0081","note":"Modify AI Agent Configuration — persistence via agent config tamper","verified":true},{"framework":"nist_800_53","reference":"SC-28","note":null,"verified":true},{"framework":"owasp_llm","reference":"LLM08","note":null,"verified":true}]}],"counts":{"controls":65,"families":23,"functions":6,"mappings":201}}