# E. Accountability Source: https://standard.aiuc-1.com/accountability ## Requirements AI failure plan for security breaches E001 · Mandatory Document AI failure plan for AI privacy and security breaches assigning accountable owners and establishing notification and remediation with third-party support as needed (e.g. legal, PR, insurers). Keywords Incident Response Security Privacy Regulatory Deadlines Capabilities Universal [Open](/accountability/ai-failure-plan-for-security-breaches) AI failure plan for harmful outputs E002 · Mandatory Document AI failure plan for harmful AI outputs that cause significant customer harm assigning accountable owners and establishing remediation with third-party support as needed (e.g. legal, PR, insurers). Keywords Incident Response Emergency Response Harmful Outputs Hallucinations Vendors Capabilities External-facing [Open](/accountability/ai-failure-plan-for-harmful-outputs) AI failure plan for hallucinations E003 · Mandatory Document AI failure plan for hallucinated AI outputs that cause substantial customer financial loss assigning accountable owners and establishing remediation with third-party support as needed (e.g. legal, PR, insurers). Keywords Hallucinations Incident Response Customer Loss Capabilities External-facing [Open](/accountability/ai-failure-plan-for-hallucinations) Assign accountability E004 · Mandatory Document which AI system changes across the development & deployment lifecycle require formal review or approval, assign a lead accountable for each, and document their approval with supporting evidence. Keywords Decision Owners Deployment Capabilities Universal [Open](/accountability/assign-accountability) Document data storage security E005 · Mandatory Document data storage security practices considering data sensitivity, regulatory requirements, security controls, and operational needs. Keywords Deployment Cloud Security On-Premise Security Data Residency Capabilities Universal [Open](/accountability/assess-cloud-vs-on-prem-processing) Conduct vendor and model due diligence E006 · Mandatory Establish due diligence processes for foundation and upstream model providers covering data handling, PII controls, security and compliance. Keywords Vendor Due Diligence Open-Source Foundation Models Upstream Models Capabilities Universal [Open](/accountability/conduct-vendor-due-diligence) \[Retired] Document system change approvals E007 · Optional Merged with E004 - see changelog (Q1 2026 update). Keywords Approvals Workflows [Open](/accountability/document-system-change-approvals) Review internal processes E008 · Mandatory Establish regular internal reviews of key processes and document review records and approvals. Keywords Internal Reviews Documentation Capabilities Universal [Open](/accountability/review-internal-processes) Monitor third-party access E009 · Mandatory Implement systems to monitor and log third-party API connections, sessions, and data access. Keywords Access Logins Capabilities Universal [Open](/accountability/monitor-3rd-party-access) Establish AI acceptable use policy E010 · Mandatory Establish and implement an AI acceptable use policy. Keywords Acceptable Use Breach Capabilities Universal [Open](/accountability/establish-ai-acceptable-use-policy) Record processing locations E011 · Mandatory Document AI data processing locations. Keywords Data Processing Storage Location Data Protections Capabilities Universal [Open](/accountability/record-processing-locations) Document regulatory compliance E012 · Mandatory Document applicable AI laws and standards, required data protections, and strategies for compliance. Keywords Regulatory EU NY NIST ISO GDPR Capabilities Universal [Open](/accountability/document-regulatory-compliance) Implement quality management system E013 · Optional Establish a quality management system for AI systems proportionate to the size of the organization. Keywords EU Quality management Regulatory Capabilities Universal [Open](/accountability/implement-quality-management-system) \[Retired] Share transparency reports E014 · Optional Merged with E017 - see changelog (Q1 2026 update). Keywords Transparency [Open](/accountability/share-transparency-reports) Log AI system activity E015 · Mandatory Maintain logs of AI system processes, actions, and agent outputs where permitted to support incident investigation, auditing, and explanation of AI system behavior. Keywords Explainability Logs Capabilities Universal [Open](/accountability/log-model-activity) Implement AI disclosure mechanisms E016 · Mandatory Implement clear disclosure mechanisms to inform users when they are interacting with AI systems rather than humans. Keywords Labelling Transparency Capabilities Universal [Open](/accountability/implement-ai-disclosure-mechanisms) Document system transparency policy E017 · Optional Establish a system transparency policy and maintain a repository of model cards, datasheets, and interpretability reports for major systems. Keywords Transparency System Cards Capabilities Universal [Open](/accountability/document-system-transparency-policy) Third-party testing for accountability risk E018 · Mandatory Appoint expert third-parties to evaluate system robustness to accountability risk as defined in the AIUC-1 risk taxonomy at least every 3 months Capabilities Universal [Open](/accountability/3rd-party-testing-for-accountability-risk) 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E018: Third-party testing for accountability risk Source: https://standard.aiuc-1.com/accountability/3rd-party-testing-for-accountability-risk Appoint expert third-parties to evaluate system robustness to accountability risk as defined in the AIUC-1 risk taxonomy at least every 3 months Application Mandatory Frequency Every 3 months Capabilities Universal ## Control activities ## Typical evidence Should include ? **Appointing qualified third-party assessors.** Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence. **Conducting regular testing.** Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter. **Maintaining documentation.** Including testing scope and results. E018.1 Evals: Third-party evaluation report assessing accountability riskThird-party evaluation report showing testing for agent accountability risk - including risks tested (e.g., bypassing AI disclosure), testing methodology and findings Category [Third-party Evals](/evidence/third-party-evals) Typical location Third-party evaluation report Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E003: AI failure plan for hallucinations Source: https://standard.aiuc-1.com/accountability/ai-failure-plan-for-hallucinations Document AI failure plan for hallucinated AI outputs that cause substantial customer financial loss assigning accountable owners and establishing remediation with third-party support as needed (e.g. legal, PR, insurers). Keywords Hallucinations Incident Response Customer Loss Application Mandatory Frequency Every 12 months Type Preventative Capabilities External-facing Crosswalks EU AI Act ? [Article 20: Corrective Actions and Duty of Information](/crosswalks/eu-ai-act) [Article 73: Reporting of Serious Incidents](/crosswalks/eu-ai-act) ISO 42001 ? [A.8.4: Communication of incidents](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 1.3: Risk response planning](/crosswalks/nist-ai-rmf) [MANAGE 4.3: Incident communication](/crosswalks/nist-ai-rmf) CSA AICM ? [BCR-09: Disaster Response Plan](/crosswalks/csa-aicm) [BCR-10: Response Plan Exercise](/crosswalks/csa-aicm) [SEF-09: Incident Response](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 9: Agentic AI - Function calling hallucination](/crosswalks/ibm-ai-risk-atlas) [IBM 71: Output - Hallucination](/crosswalks/ibm-ai-risk-atlas) [IBM 89: Non-Technical - Legal accountability](/crosswalks/ibm-ai-risk-atlas) OWASP Agentic Top 10 ? [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC4.2: Evaluate and communicate deficiencies](/crosswalks/soc-2) [CC7.4: Incident response](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing customer communication protocols.** For example, disclosure procedures, explanation of corrective actions, and follow-up commitments with executive approval for significant incidents. **Establishing immediate mitigation steps with designated staff responsibilities.** For example, system freeze capabilities, model adjustments, output validation improvements, customer notification, and enhanced monitoring. E003.1 Documentation: AI failure plan for hallucinationsCan be standalone document or integrated in existing incident response procedures/policies Category [Operational Practices](/evidence/operational-practices) Typical location AI failure plan Capabilities External-facing May include ? **Defining hallucination incident types.** **Coordinating potential external support.** For example, legal consultation for significant claims, financial review when needed, and insurance coverage activation. E003.2 Documentation: Additional hallucination failure proceduresMay include hallucination incident categories (e.g. factual errors, incorrect recommendations), external support contact list (legal counsel, financial reviewers, insurance providers), support engagement procedures, or escalation criteria for involving external parties. Category [Operational Practices](/evidence/operational-practices) Typical location AI failure plan Capabilities External-facing Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E002: AI failure plan for harmful outputs Source: https://standard.aiuc-1.com/accountability/ai-failure-plan-for-harmful-outputs Document AI failure plan for harmful AI outputs that cause significant customer harm assigning accountable owners and establishing remediation with third-party support as needed (e.g. legal, PR, insurers). Keywords Incident Response Emergency Response Harmful Outputs Hallucinations Vendors Application Mandatory Frequency Every 12 months Type Preventative Capabilities External-facing Crosswalks EU AI Act ? [Article 20: Corrective Actions and Duty of Information](/crosswalks/eu-ai-act) [Article 73: Reporting of Serious Incidents](/crosswalks/eu-ai-act) ISO 42001 ? [A.8.4: Communication of incidents](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 1.3: Risk response planning](/crosswalks/nist-ai-rmf) [MANAGE 4.3: Incident communication](/crosswalks/nist-ai-rmf) CSA AICM ? [BCR-09: Disaster Response Plan](/crosswalks/csa-aicm) [BCR-10: Response Plan Exercise](/crosswalks/csa-aicm) [SEF-09: Incident Response](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 12: Agentic AI - Mitigation and maintenance](/crosswalks/ibm-ai-risk-atlas) [IBM 60: Output - Harmful output](/crosswalks/ibm-ai-risk-atlas) [IBM 89: Non-Technical - Legal accountability](/crosswalks/ibm-ai-risk-atlas) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) CA SB 53 ? [22757.13: Critical Safety Incident Reporting](/crosswalks/ca-sb-53) OWASP Agentic Top 10 ? [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC4.2: Evaluate and communicate deficiencies](/crosswalks/soc-2) [CC7.4: Incident response](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing customer communication protocols.** For example, disclosure procedures, explanation of corrective actions, and follow-up commitments with executive approval for significant incidents. **Establishing immediate mitigation steps with designated staff responsibilities.** For example, system freeze capabilities, output suppression, customer notification, and system adjustments. E002.1 Documentation: AI failure plan for harmful outputsCan be standalone document or integrated in existing incident response procedures/policies Category [Operational Practices](/evidence/operational-practices) Typical location AI failure plan Capabilities External-facing May include ? **Defining harmful output categories with reference to risk taxonomy.** For example, discriminatory content, offensive material, inappropriate recommendations, ideally with concrete examples. **Coordinating external support engagement.** For example, legal counsel consultation, PR support, and insurance claim procedures. E002.2 Documentation: Additional harmful output failure proceduresMay include harmful output category definitions referenced to risk taxonomy, external support contact list (legal counsel, PR firms, insurance providers), support engagement procedures or runbooks, or escalation criteria for involving external parties. Category [Operational Practices](/evidence/operational-practices) Typical location AI failure plan Capabilities External-facing Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E001: AI failure plan for security breaches Source: https://standard.aiuc-1.com/accountability/ai-failure-plan-for-security-breaches Document AI failure plan for AI privacy and security breaches assigning accountable owners and establishing notification and remediation with third-party support as needed (e.g. legal, PR, insurers). Keywords Incident Response Security Privacy Regulatory Deadlines Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 20: Corrective Actions and Duty of Information](/crosswalks/eu-ai-act) [Article 73: Reporting of Serious Incidents](/crosswalks/eu-ai-act) ISO 42001 ? [A.8.4: Communication of incidents](/crosswalks/iso-42001) [A.8.5: Information for interested parties](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 1.3: Risk response planning](/crosswalks/nist-ai-rmf) [MANAGE 4.3: Incident communication](/crosswalks/nist-ai-rmf) CSA AICM ? [BCR-09: Disaster Response Plan](/crosswalks/csa-aicm) [BCR-10: Response Plan Exercise](/crosswalks/csa-aicm) [SEF-01: Security Incident Management Policy and Procedures](/crosswalks/csa-aicm) [SEF-02: Service Management Policy and Procedures](/crosswalks/csa-aicm) [SEF-03: Incident Response Plans](/crosswalks/csa-aicm) [SEF-04: Incident Response Testing](/crosswalks/csa-aicm) [SEF-05: Incident Response Metrics](/crosswalks/csa-aicm) [SEF-07: Security Breach Notification](/crosswalks/csa-aicm) [SEF-08: Points of Contact Maintenance](/crosswalks/csa-aicm) [SEF-09: Incident Response](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 12: Agentic AI - Mitigation and maintenance](/crosswalks/ibm-ai-risk-atlas) [IBM 89: Non-Technical - Legal accountability](/crosswalks/ibm-ai-risk-atlas) OWASP Agentic Top 10 ? [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) [ASI10 - Rogue Agents](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC4.2: Evaluate and communicate deficiencies](/crosswalks/soc-2) [CC7.3: Security event evaluation](/crosswalks/soc-2) [CC7.4: Incident response](/crosswalks/soc-2) [CC7.5: Recovery from incidents](/crosswalks/soc-2) [P6.3: Record of unauthorized disclosures](/crosswalks/soc-2) [P6.5: Vendor breach notification commitments](/crosswalks/soc-2) [P6.6: Breach notification obligations](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Assigning a breach response lead from existing staff.** For example, IT manager, security officer, or designated executive with authority to engage external counsel and specialists as needed. **Defining breach notification procedures.** For example, customer communications, regulatory reporting requirements, and vendor notifications based on applicable privacy laws. **Implementing security remediation measures.** For example, system freeze capabilities, vulnerability fixes, access control updates, and coordination with external security consultants when internal expertise is insufficient. **Establishing evidence collection requirements with guidance on preserving evidence for potential legal review.** For example, system logs, user activity records, and basic documentation. E001.1 Documentation: AI failure plan for security breachesCan be standalone document or integrated in existing incident response procedures/policies Category [Operational Practices](/evidence/operational-practices) Typical location AI failure plan Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E005: Document data storage security Source: https://standard.aiuc-1.com/accountability/assess-cloud-vs-on-prem-processing Document data storage security practices considering data sensitivity, regulatory requirements, security controls, and operational needs. Keywords Deployment Cloud Security On-Premise Security Data Residency Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0017: AI Model Distribution Methods](/crosswalks/mitre-atlas) NIST AI RMF ? [MAP 4.2: Internal risk controls](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM03:25 - Supply Chain](/crosswalks/owasp-top-10) CSA AICM ? [AIS-05: Application Security Testing](/crosswalks/csa-aicm) [DCS-01: Off-Site Equipment Disposal Policy and Procedures](/crosswalks/csa-aicm) [DCS-02: Off-Site Transfer Authorization Policy and Procedures](/crosswalks/csa-aicm) [DCS-03: Secure Area Policy and Procedures](/crosswalks/csa-aicm) [DCS-04: Secure Media Transportation Policy and Procedures](/crosswalks/csa-aicm) [DCS-05: Assets Classification](/crosswalks/csa-aicm) [DCS-06: Assets Cataloguing and Tracking](/crosswalks/csa-aicm) [DCS-07: Controlled Physical Access Points](/crosswalks/csa-aicm) [DCS-08: Equipment Identification](/crosswalks/csa-aicm) [DCS-09: Secure Area Authorization](/crosswalks/csa-aicm) [DCS-10: Surveillance System](/crosswalks/csa-aicm) [DCS-11: Adverse Event Response Training](/crosswalks/csa-aicm) [DCS-12: Cabling Security](/crosswalks/csa-aicm) [DCS-13: Environmental Systems](/crosswalks/csa-aicm) [DCS-14: Secure Utilities](/crosswalks/csa-aicm) [DCS-15: Equipment Location](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Supply Chain and Dependency Risk](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 36: Training Data - Data usage restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 37: Training Data - Data transfer restrictions](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-14.1: Unauthorized Access](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [C1.1: Identify and maintain confidential information](/crosswalks/soc-2) [CC6.1: Logical access security](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Documenting data storage security.** For example, assessments around cloud vs. on-premises processing. E005.1 Documentation: Data storage security practicesDocumenting data storage security practices against data sensitivity, regulatory requirements, and operational needs - may include security trust center documentation, deployment decision memos such as cloud vs. on-prem evaluations, risk assessment reports, and records of periodic reviews when requirements changed. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E004: Assign accountability Source: https://standard.aiuc-1.com/accountability/assign-accountability Document which AI system changes across the development & deployment lifecycle require formal review or approval, assign a lead accountable for each, and document their approval with supporting evidence. Keywords Decision Owners Deployment Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0013: Code Signing](/crosswalks/mitre-atlas) EU AI Act ? [Article 17: Quality Management System](/crosswalks/eu-ai-act) [Article 18: Documentation Keeping](/crosswalks/eu-ai-act) ISO 42001 ? [A.3.2: AI roles and responsibilities](/crosswalks/iso-42001) [A.4.6: Human resources](/crosswalks/iso-42001) [A.6.2.2: AI system requirements and specification](/crosswalks/iso-42001) [A.10.2: Allocating responsibilities](/crosswalks/iso-42001) [5.1: Leadership and commitment](/crosswalks/iso-42001) [5.3: Roles, responsibilities and authorities](/crosswalks/iso-42001) [7.2: Competence](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 2.1: Roles and responsibilities](/crosswalks/nist-ai-rmf) [GOVERN 2.3: Executive accountability](/crosswalks/nist-ai-rmf) [MAP 3.5: Human oversight](/crosswalks/nist-ai-rmf) [MEASURE 2.8: Transparency and accountability](/crosswalks/nist-ai-rmf) CSA AICM ? [AIS-01: Application and Interface Security Policy and Procedures](/crosswalks/csa-aicm) [AIS-04: Secure Application Development Lifecycle](/crosswalks/csa-aicm) [CCC-05: Change Agreements](/crosswalks/csa-aicm) [CCC-03: Change Management Technology](/crosswalks/csa-aicm) [CEK-02: CEK Roles and Responsibilities](/crosswalks/csa-aicm) [GRC-06: Governance Responsibility Model](/crosswalks/csa-aicm) [CCC-01: Change Management Policy and Procedures](/crosswalks/csa-aicm) [MDS-09: Model Signing/Ownership Verification](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 15: Agentic AI - Accountability of AI agent actions](/crosswalks/ibm-ai-risk-atlas) [IBM 89: Non-Technical - Legal accountability](/crosswalks/ibm-ai-risk-atlas) SOC 2 ? [CC1.3: Structures, authorities, and responsibilities](/crosswalks/soc-2) [CC1.5: Accountability for internal control](/crosswalks/soc-2) [CC5.3: Deploy controls through policies](/crosswalks/soc-2) [CC8.1: Change management](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining AI system changes requiring approval including model selection, material changes to the meta prompt, adding / removing guardrails, changes to end-user workflow, other changes that drive material.** For example, +/-10% performance on evals. **Assigning an accountable lead as approver for each of these changes.** Can follow a RACI structure to formalize roles of those consulted and informed. E004.1 Documentation: Change approval policy and recordsDocumentation or policy defining which AI system changes require approval with assigned accountable leads, and approval records showing sign-offs with supporting evidence. Can be a change management policy, overview table in e.g. Notion, approval logs from Jira/Linear/GitHub, or deployment gate documentation. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal May include ? **Implementing code signing and verification processes for AI models, libraries, and deployment artefacts to ensure only digitally signed components are approved for production use.** E004.2 Config: Code signing implementationCode signing configuration, CI/CD pipeline requiring signed artifacts, or verification process for AI components - may include model signing process, signature verification in deployment pipeline, artifact registry showing signed models/libraries, or policy enforcement blocking unsigned components from production. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Engineering Practice Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E006: Conduct vendor and model due diligence Source: https://standard.aiuc-1.com/accountability/conduct-vendor-due-diligence Establish due diligence processes for foundation and upstream model providers covering data handling, PII controls, security and compliance. Keywords Vendor Due Diligence Open-Source Foundation Models Upstream Models Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 23: Obligations of Importers](/crosswalks/eu-ai-act) [Article 24: Obligations of Distributors](/crosswalks/eu-ai-act) ISO 42001 ? [A.10.3: Suppliers](/crosswalks/iso-42001) NIST AI RMF ? [MAP 4.2: Internal risk controls](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM03:25 - Supply Chain](/crosswalks/owasp-top-10) CSA AICM ? [STA-01: Supply Chain Risk Management Policies and Procedures](/crosswalks/csa-aicm) [STA-08: Supply Chain Inventory](/crosswalks/csa-aicm) [STA-09: Supply Chain Risk Management](/crosswalks/csa-aicm) [STA-10: Primary Service and Contractual Agreement](/crosswalks/csa-aicm) [STA-11: Supply Chain Agreement Review](/crosswalks/csa-aicm) [STA-12: Supply Chain Compliance Assessment](/crosswalks/csa-aicm) [STA-13: Supply Chain Service Agreement Compliance](/crosswalks/csa-aicm) [STA-14: Supply Chain Governance Review](/crosswalks/csa-aicm) [STA-15: Supply Chain Data Security Assessment](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Supply Chain and Dependency Risk](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 16: Agentic AI - AI agent compliance](/crosswalks/ibm-ai-risk-atlas) [IBM 34: Training Data - Uncertain data provenance](/crosswalks/ibm-ai-risk-atlas) [IBM 39: Training Data - Data usage rights restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 88: Non-Technical - Model usage rights restrictions](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-4.1: Agent Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.3: Dependency / Plugin Compromise](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI04 - Agentic Supply Chain Vulnerabilities](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC9.2: Vendor and partner risk](/crosswalks/soc-2) [P6.4: Vendor privacy commitments](/crosswalks/soc-2) [P6.5: Vendor breach notification commitments](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining assessment criteria for foundational or upstream AI models.** For example, data handling and ownership practices, PII controls, security measures, compliance status, open-source. **Conducting documented assessments.** For example, scoring results, verification activities such as certifications reviewed and references contacted, and approval decisions. **Maintaining assessment records with sufficient detail for audit purposes and retaining due diligence evidence before vendor approval.** E006.1 Documentation: Vendor due diligenceVendor assessment records showing evaluation criteria, scoring results, verification activities, approval decisions with accountable leads, and retained evidence supporting the assessment. May include vendor questionnaires, security reviews, compliance documentation, or due diligence reports. Category [Operational Practices](/evidence/operational-practices) Typical location Vendor Contracts Internal processes Capabilities Universal May include ? **Verifying the source, integrity and licence of the open-weight model before use.** For example, obtaining weights from the publisher's own repository or a vetted registry, verifying published checksums or signatures, checking for known issues with the model version, confirming the licence permits the intended use and identifying the base model for fine-tuned derivatives. E006.2 Documentation: Open-weight model source, integrity and licence verificationAssessment records showing the source, integrity and license checks performed on the open-weight model - may include a model intake checklist identifying publisher, repository or registry, model version and base model for fine-tuned derivatives, checksum or signature verification output, and licence and known-issue review notes. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E012: Document regulatory compliance Source: https://standard.aiuc-1.com/accountability/document-regulatory-compliance Document applicable AI laws and standards, required data protections, and strategies for compliance. Keywords Regulatory EU NY NIST ISO GDPR Application Mandatory Frequency Every 6 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 16: Obligations of Providers of High-Risk AI Systems](/crosswalks/eu-ai-act) [Article 18: Documentation Keeping](/crosswalks/eu-ai-act) [Article 21: Cooperation with Competent Authorities](/crosswalks/eu-ai-act) [Article 22: Authorised Representatives of Providers of High-Risk AI Systems](/crosswalks/eu-ai-act) [Article 25: Responsibilities Along the AI Value Chain](/crosswalks/eu-ai-act) [Article 26: Obligations of Deployers of High-Risk AI Systems](/crosswalks/eu-ai-act) [Article 43: Conformity Assessment](/crosswalks/eu-ai-act) [Article 44: Certificates](/crosswalks/eu-ai-act) [Article 47: EU Declaration of Conformity](/crosswalks/eu-ai-act) [Article 48: CE Marking](/crosswalks/eu-ai-act) [Article 49: Registration](/crosswalks/eu-ai-act) ISO 42001 ? [A.2.3: Alignment with other organizational policies](/crosswalks/iso-42001) [A.8.5: Information for interested parties](/crosswalks/iso-42001) [10.2: Nonconformity and corrective action](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.1: Legal and regulatory compliance](/crosswalks/nist-ai-rmf) [GOVERN 1.7: AI system decommissioning](/crosswalks/nist-ai-rmf) [MAP 1.1: Context understanding](/crosswalks/nist-ai-rmf) [MAP 4.1: Legal risk mapping](/crosswalks/nist-ai-rmf) CSA AICM ? [A\&A-04: Requirements Compliance](/crosswalks/csa-aicm) [DSP-10: Sensitive Data Transfer](/crosswalks/csa-aicm) [DSP-18: Disclosure Notification](/crosswalks/csa-aicm) [GRC-07: Information System Regulatory Mapping](/crosswalks/csa-aicm) [HRS-10: Non-Disclosure Agreements](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 16: Agentic AI - AI agent compliance](/crosswalks/ibm-ai-risk-atlas) [IBM 32: Training Data - Data privacy rights alignment](/crosswalks/ibm-ai-risk-atlas) [IBM 36: Training Data - Data usage restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 89: Non-Technical - Legal accountability](/crosswalks/ibm-ai-risk-atlas) CO AI Act ? [6-1-1706 & 6-1-1707: Enforcement & AG, Rulemaking Authority](/crosswalks/co-ai-act) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC3.1: Clear objectives for risk assessment](/crosswalks/soc-2) [P6.6: Breach notification obligations](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Identifying relevant regulations.** For example, data protection laws. For example, GDPR, CCPA, sector-specific requirements, emerging AI standards. For example, EU AI Act. **Documenting compliance procedures and strategies appropriate for company size and operations.** **Reviewing the repository every 6 months and when additional requirements may be triggered.** For example, regulations change or business operations expand into new jurisdictions. E012.1 Documentation: Regulatory compliance reviewsCompliance register, assessment memo or review tickets (e.g. in Notion), or policy listing applicable regulations with compliance strategies - should include review dates or version history showing periodic updates. Category [Legal Policies](/evidence/legal-policies) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E007: [Retired] Document system change approvals Source: https://standard.aiuc-1.com/accountability/document-system-change-approvals Merged with E004 - see changelog (Q1 2026 update). Keywords Approvals Workflows Application Optional Type Detective Crosswalks EU AI Act ? [Article 17: Quality Management System](/crosswalks/eu-ai-act) [Article 18: Documentation Keeping](/crosswalks/eu-ai-act) NIST AI RMF ? [GOVERN 2.1: Roles and responsibilities](/crosswalks/nist-ai-rmf) [GOVERN 2.3: Executive accountability](/crosswalks/nist-ai-rmf) [MANAGE 1.1: Purpose achievement](/crosswalks/nist-ai-rmf) [MAP 3.5: Human oversight](/crosswalks/nist-ai-rmf) [MEASURE 2.8: Transparency and accountability](/crosswalks/nist-ai-rmf) [MEASURE 4.3: Performance tracking](/crosswalks/nist-ai-rmf) CSA AICM ? [CCC-01: Change Management Policy and Procedures](/crosswalks/csa-aicm) [CCC-03: Change Management Technology](/crosswalks/csa-aicm) [CCC-04: Change Authorization](/crosswalks/csa-aicm) [CCC-05: Change Agreements](/crosswalks/csa-aicm) [CCC-06: Change Management Baseline](/crosswalks/csa-aicm) [AIS-01: Application and Interface Security Policy and Procedures](/crosswalks/csa-aicm) ISO 42001 ? [A.6.2.2: AI system requirements and specification](/crosswalks/iso-42001) [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) [6.3: Planning of changes](/crosswalks/iso-42001) ## Control activities ## Typical evidence Should include ? **This requirement was merged into E004 at the Q1, 2026 standard update.** See aiuc-1.com/changelog for more information E007.1 RetiredRetired Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E017: Document system transparency policy Source: https://standard.aiuc-1.com/accountability/document-system-transparency-policy Establish a system transparency policy and maintain a repository of model cards, datasheets, and interpretability reports for major systems. Keywords Transparency System Cards Application Optional Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0023: AI Bill of Materials](/crosswalks/mitre-atlas) [AML-M0025: Maintain AI Dataset Provenance](/crosswalks/mitre-atlas) EU AI Act ? [Article 11: Technical Documentation](/crosswalks/eu-ai-act) ISO 42001 ? [A.4.2: Resource documentation](/crosswalks/iso-42001) [A.4.3: Data resources](/crosswalks/iso-42001) [A.4.4: Tooling resources](/crosswalks/iso-42001) [A.4.5: System and computing resources](/crosswalks/iso-42001) [A.6.2.3: Documentation of AI system design and development](/crosswalks/iso-42001) [A.2.2: AI policy](/crosswalks/iso-42001) [A.2.4: Review of the AI policy](/crosswalks/iso-42001) [4.3: Determining the scope of the AI management system](/crosswalks/iso-42001) [5.2: AI policy](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.2: Trustworthy AI policies](/crosswalks/nist-ai-rmf) [GOVERN 1.6: AI system inventory](/crosswalks/nist-ai-rmf) [MAP 1.6: System requirements](/crosswalks/nist-ai-rmf) [MEASURE 2.8: Transparency and accountability](/crosswalks/nist-ai-rmf) [MEASURE 2.9: Model explanation](/crosswalks/nist-ai-rmf) [MEASURE 4.3: Performance tracking](/crosswalks/nist-ai-rmf) CSA AICM ? [GRC-13: Explainability Requirement](/crosswalks/csa-aicm) [GRC-14: Explainability Evaluation](/crosswalks/csa-aicm) [MDS-03: Model Documentation](/crosswalks/csa-aicm) [MDS-04: Model Documentation Requirements](/crosswalks/csa-aicm) [MDS-05: Model Documentation Validation](/crosswalks/csa-aicm) [STA-16: Service Bill of Material (BOM)](/crosswalks/csa-aicm) [DSP-20: Data Provenance and Transparency](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 13: Agentic AI - Lack of AI agent transparency](/crosswalks/ibm-ai-risk-atlas) [IBM 79: Non-Technical - Lack of data transparency](/crosswalks/ibm-ai-risk-atlas) [IBM 80: Non-Technical - Lack of model transparency](/crosswalks/ibm-ai-risk-atlas) [IBM 81: Non-Technical - Lack of system transparency](/crosswalks/ibm-ai-risk-atlas) NYC LL 144 ? [5-303: Publish Audit Results](/crosswalks/nyc-ll-144) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC6.1: Logical access security](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Creating transparency documentation for major AI systems.** For example, documenting system characteristics, data provenance, and model behavior for systems meeting documentation criteria. E017.1 Documentation: AI system transparency documentationTransparency documentation artifacts such as a model card, datasheet, or AI bill of materials - for example, records of the system name and version, training or fine-tuning data sources and characteristics, dated records of fine-tuning or adaptation changes and records of AI-specific components beyond the model including frameworks, orchestration layers, tool connectors. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal May include ? **Defining policies for sharing transparency documentation with external stakeholders.** For example, establishing when reports are shared, specifying recipient categories, determining what information is disclosed to each stakeholder type. **Documenting sharing procedures including approval workflows, version control, and distribution tracking.** For example, establishing approval requirements before external sharing, maintaining version control of shared documents, tracking which stakeholders received which versions. E017.2 Documentation: Transparency report sharing policyPolicy document defining transparency sharing practices - may include sharing triggers, recipient categories with disclosure levels (regulators, customers, affected parties, public), or matrix mapping stakeholder types to shared documentation (model cards, datasheets, performance reports, incident summaries). Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Internal policies Capabilities Universal **Documenting platform-level and deployer-level security responsibilities for AI systems.** For example, delineating which security obligations are managed by the platform versus the deploying organization. E017.3 Documentation: Platform and deployer security responsibilitiesDocumentation delineating platform and deployer security responsibilities - may include shared responsibility documentation defining platform-level and deployer-level security obligations. Category [Legal Policies](/evidence/legal-policies) Typical location Terms of Service Internal policies Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E010: Establish AI acceptable use policy Source: https://standard.aiuc-1.com/accountability/establish-ai-acceptable-use-policy Establish and implement an AI acceptable use policy. Keywords Acceptable Use Breach Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks ISO 42001 ? [A.2.2: AI policy](/crosswalks/iso-42001) [A.9.2: Processes for responsible use of AI systems](/crosswalks/iso-42001) [A.9.4: Intended use of the AI system](/crosswalks/iso-42001) [A.2.4: Review of the AI policy](/crosswalks/iso-42001) [A.9.3: Objectives for responsible use of AI system](/crosswalks/iso-42001) [4.1: Understanding the organization and its context](/crosswalks/iso-42001) [4.3: Determining the scope of the AI management system](/crosswalks/iso-42001) [5.2: AI policy](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.2: Trustworthy AI policies](/crosswalks/nist-ai-rmf) [MAP 1.6: System requirements](/crosswalks/nist-ai-rmf) [MAP 3.3: Application scope](/crosswalks/nist-ai-rmf) [MAP 3.4: Operator proficiency](/crosswalks/nist-ai-rmf) [MEASURE 2.4: Production monitoring](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [GRC-09: Acceptable Use of the AI Service](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Orchestration and Multi-Agent Exploitation](/crosswalks/owasp-aivss) Cisco AI Security Framework ? [AITech-13.1: Disruption of Availability](/crosswalks/cisco-ai-security-safety-framework) [AITech-18.1: Fraudulent Use](/crosswalks/cisco-ai-security-safety-framework) [AITech-18.2: Malicious Workflows](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC1.1: Commitment to integrity and ethical values](/crosswalks/soc-2) [CC5.3: Deploy controls through policies](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining prohibited AI usage for end-users.** For example, jailbreak attempts, malicious prompt injection, unauthorized data extraction, generation of harmful content, and misuse of customer data. E010.1 Documentation: AI acceptable use policyPolicy document defining acceptable and/or prohibited AI usage - can be standalone document or parts of, e.g., terms of service Category [Legal Policies](/evidence/legal-policies) Typical location Acceptable Use Policy Capabilities Universal **Implementing detection and monitoring tools.** For example, prompt analysis, output filtering, usage pattern anomalies, and suspicious access attempts. E010.2 Config: AUP violation detectionCode, configuration, or monitoring system detecting acceptable use policy violations - may include prompt analysis logic, output filtering rules, anomaly detection for usage patterns, or alerting on suspicious access attempts. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Implementing user feedback when policy is breached.** For example, showing alerts or error messages when inputs violate acceptable use. E010.3 Demonstration: User notification for AUP breachesUser-facing alerts or error messages displayed when acceptable use policy is violated - may include in-product warning messages, blocked request notifications, or error screens explaining policy violations. Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Universal May include ? **Real-time monitoring, blocking, or alerting capabilities.** **Maintaining logging and tracking systems.** For example, incident creation, violation tracking with case assignment and resolution documentation. **Conducting regular effectiveness reviews.** For example, quarterly analysis of violation trends, tool performance assessment, policy updates based on emerging threats, and user training adjustments. E010.4 Documentation: Guardrails enforcing acceptable useDocumentation or screenshots showing additional AUP enforcement mechanisms - may include real-time blocking/alerting systems, violation tracking logs with incident management, effectiveness review reports analyzing violation trends and policy updates, or training materials addressing emerging misuse patterns. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E016: Implement AI disclosure mechanisms Source: https://standard.aiuc-1.com/accountability/implement-ai-disclosure-mechanisms Implement clear disclosure mechanisms to inform users when they are interacting with AI systems rather than humans. Keywords Labelling Transparency Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 13: Transparency and Provision of Information to Deployers](/crosswalks/eu-ai-act) [Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems](/crosswalks/eu-ai-act) ISO 42001 ? [A.8.2: System documentation and information for users](/crosswalks/iso-42001) NIST AI RMF ? [MAP 2.2: Knowledge limits](/crosswalks/nist-ai-rmf) [MAP 3.4: Operator proficiency](/crosswalks/nist-ai-rmf) [MEASURE 2.8: Transparency and accountability](/crosswalks/nist-ai-rmf) CSA AICM ? [GRC-15: Human supervision](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Identity Impersonation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 70: Output - Non-disclosure](/crosswalks/ibm-ai-risk-atlas) NYC LL 144 ? [5-304: Provide Notice](/crosswalks/nyc-ll-144) CO AI Act ? [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) OWASP Agentic Top 10 ? [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC2.2: Internal communication of controls](/crosswalks/soc-2) [CC2.3: External communication of controls](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing AI disclosure for text-based interactions.** For example, displaying clear notices when users interact with AI chatbots, virtual assistants, or automated messaging systems. **Implementing AI disclosure for voice-based interactions.** For example, providing audio notifications at the beginning of voice calls or interactions. **Labelling AI-generated media and documents in a machine-readable and detectable format.** For example, marking AI-generated images, videos, audio, or documents with metadata, watermarks, or labels indicating artificial generation. **Disclosing when autonomous AI agents or systems are performing actions.** For example, notifying users when AI systems are making decisions, processing requests, or executing tasks without human oversight. **Establishing reactive disclosure capabilities when users ask if they are interacting with AI.** E016.1 Demonstration: AI disclosureAI disclosures across applicable modalities. May include disclosures for text (“You’re chatting with AI” notice in chat or on automated email/SMS), voice (recording or transcript of a spoken disclosure), automated actions (“Powered by AI” labels or “Completed by AI agent” notifications), AI-generated content (C2PA metadata or watermarks), and responses to “Are you AI?” (chatbot or voice agent transcript). Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E013: Implement quality management system Source: https://standard.aiuc-1.com/accountability/implement-quality-management-system Establish a quality management system for AI systems proportionate to the size of the organization. Keywords EU Quality management Regulatory Application Optional Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 9: Risk Management System](/crosswalks/eu-ai-act) [Article 10: Data and Data Governance](/crosswalks/eu-ai-act) [Article 11: Technical Documentation](/crosswalks/eu-ai-act) [Article 12: Record-Keeping](/crosswalks/eu-ai-act) [Article 16: Obligations of Providers of High-Risk AI Systems](/crosswalks/eu-ai-act) [Article 17: Quality Management System](/crosswalks/eu-ai-act) [Article 18: Documentation Keeping](/crosswalks/eu-ai-act) [Article 19: Automatically Generated Logs](/crosswalks/eu-ai-act) [Article 26: Obligations of Deployers of High-Risk AI Systems](/crosswalks/eu-ai-act) [Article 43: Conformity Assessment](/crosswalks/eu-ai-act) [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) [Article 73: Reporting of Serious Incidents](/crosswalks/eu-ai-act) NIST AI RMF ? [GOVERN 1.4: Risk management governance](/crosswalks/nist-ai-rmf) [GOVERN 1.3: Risk management processes](/crosswalks/nist-ai-rmf) ISO 42001 ? [A.5.2: AI system impact assessment process](/crosswalks/iso-42001) [A.6.2.7: AI system technical documentation](/crosswalks/iso-42001) [A.5.3: Documentation of AI system impact assessments](/crosswalks/iso-42001) [A.5.4: Assessing AI system impact on individuals or groups of individuals](/crosswalks/iso-42001) [A.4.2: Resource documentation](/crosswalks/iso-42001) [4.4: AI management system](/crosswalks/iso-42001) [6.1.4: AI system impact assessment](/crosswalks/iso-42001) [7.1: Resources](/crosswalks/iso-42001) [7.5.1: Documented information — General](/crosswalks/iso-42001) [8.1: Operational planning and control](/crosswalks/iso-42001) [8.4: AI system impact assessment](/crosswalks/iso-42001) [A.6.2.3: Documentation of AI system design and development](/crosswalks/iso-42001) [9.1: Monitoring, measurement, analysis and evaluation](/crosswalks/iso-42001) [10.1: Continual improvement](/crosswalks/iso-42001) [10.2: Nonconformity and corrective action](/crosswalks/iso-42001) CSA AICM ? [AIS-01: Application and Interface Security Policy and Procedures](/crosswalks/csa-aicm) [AIS-03: Application Security Metrics](/crosswalks/csa-aicm) [BCR-02: Risk Assessment and Impact Analysis](/crosswalks/csa-aicm) [DSP-09: Data Protection Impact Assessment](/crosswalks/csa-aicm) [GRC-02: Risk Management Program](/crosswalks/csa-aicm) [GRC-10: AI Impact Assessment](/crosswalks/csa-aicm) [MDS-02: Model Artifact Scanning](/crosswalks/csa-aicm) [A\&A-05: Audit Management Process](/crosswalks/csa-aicm) [I\&S-02: Capacity and Resource Planning](/crosswalks/csa-aicm) [CCC-02: Quality Testing](/crosswalks/csa-aicm) [TVM-01: Threat and Vulnerability Management Policy and Procedures](/crosswalks/csa-aicm) [TVM-02: Malware and Malicious Instructions Protection Policy and Procedure](/crosswalks/csa-aicm) [SEF-01: Security Incident Management Policy and Procedures](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Supply Chain and Dependency Risk](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 12: Agentic AI - Mitigation and maintenance](/crosswalks/ibm-ai-risk-atlas) [IBM 85: Non-Technical - Incorrect risk testing](/crosswalks/ibm-ai-risk-atlas) CO AI Act ? [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC1.3: Structures, authorities, and responsibilities](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) [CC5.3: Deploy controls through policies](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining quality objectives, metrics, and risk management approach for AI systems.** For example, establishing performance targets, safety thresholds, risk assessment methodologies, and measurement processes appropriate to system risk level. E013.1 Documentation: Quality objectives and risk managementDocumentation showing quality objectives, metrics, and risk management approach - may include quality metrics dashboard or reports, risk assessment documentation for AI systems, performance targets and safety thresholds, or measurement methodologies defining how quality is evaluated. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal **Establishing change management, approval processes, and documentation standards.** For example, defining review and approval requirements for AI system changes, assigning accountability for quality decisions, documenting design and development procedures. E013.2 Documentation: Change management proceduresDocumentation showing change management and approval processes - may include change approval workflows or procedures, RACI matrix assigning accountability for quality decisions, design and development procedure documents, or documentation standards and templates for AI systems. May be fulfilled by evidence submitted to E004: Assign accountability. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal **Implementing defect tracking, continuous improvement, and post-market monitoring.** For example, maintaining issue tracking systems, conducting root cause analysis, documenting corrective actions, establishing post-market monitoring processes. E013.3 Config: Issue tracking and monitoringIssue tracking system or monitoring records - may include issue tracker (Jira, Linear, GitHub) with defects and corrective actions, root cause analysis reports, post-market monitoring logs or dashboards, or continuous improvement documentation showing lessons learned. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal May include ? **Establishing data management and record-keeping systems.** For example, documenting data governance procedures, maintaining technical documentation, implementing record retention policies for model training data and system outputs. E013.4 Documentation: Data management proceduresDocumentation showing data management and record-keeping practices - may include data governance policies, technical documentation standards, record retention procedures, or data lineage tracking systems for training data and system outputs. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal **Documenting communication procedures with regulatory authorities and stakeholders.** For example, establishing protocols for regulatory reporting, stakeholder notifications for incidents, and procedures for authority interactions. E013.5 Documentation: Stakeholder communication proceduresProcedures document or communication protocols - may include incident reporting templates or protocols to regulatory authorities, stakeholder notification procedures for serious incidents, guidelines for interacting with competent authorities or notified bodies, or escalation procedures for regulatory communications. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E015: Log AI system activity Source: https://standard.aiuc-1.com/accountability/log-model-activity Maintain logs of AI system processes, actions, and agent outputs where permitted to support incident investigation, auditing, and explanation of AI system behavior. Keywords Explainability Logs Application Mandatory Frequency Every 12 months Type Detective Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0024: AI Telemetry Logging](/crosswalks/mitre-atlas) EU AI Act ? [Article 12: Record-Keeping](/crosswalks/eu-ai-act) [Article 19: Automatically Generated Logs](/crosswalks/eu-ai-act) ISO 42001 ? [A.6.2.8: AI system recording of event logs](/crosswalks/iso-42001) NIST AI RMF ? [MEASURE 2.4: Production monitoring](/crosswalks/nist-ai-rmf) [MEASURE 2.8: Transparency and accountability](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [LOG-01: Logging and Monitoring Policy and Procedures](/crosswalks/csa-aicm) [LOG-03: Security Monitoring and Alerting](/crosswalks/csa-aicm) [LOG-07: Logging Scope](/crosswalks/csa-aicm) [LOG-08: Log Records](/crosswalks/csa-aicm) [LOG-09: Log Protection](/crosswalks/csa-aicm) [LOG-10: Encryption Monitoring and Reporting](/crosswalks/csa-aicm) [LOG-11: Transaction / Activity Logging](/crosswalks/csa-aicm) [LOG-13: Failures and Anomalies Reporting](/crosswalks/csa-aicm) [LOG-14: Input Monitoring](/crosswalks/csa-aicm) [LOG-15: Output Monitoring](/crosswalks/csa-aicm) [MDS-10: Model Continuous Monitoring](/crosswalks/csa-aicm) [LOG-04: Audit Logs Access and Accountability](/crosswalks/csa-aicm) [LOG-05: Audit Logs Monitoring and Response](/crosswalks/csa-aicm) [LOG-06: Clock Synchronization](/crosswalks/csa-aicm) [LOG-12: Access Control Logs](/crosswalks/csa-aicm) [SEF-05: Incident Response Metrics](/crosswalks/csa-aicm) [SEF-07: Security Breach Notification](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Untraceability](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 1: Agentic AI - Unexplainable and untraceable actions](/crosswalks/ibm-ai-risk-atlas) [IBM 13: Agentic AI - Lack of AI agent transparency](/crosswalks/ibm-ai-risk-atlas) [IBM 14: Agentic AI - Reproducibility](/crosswalks/ibm-ai-risk-atlas) [IBM 15: Agentic AI - Accountability of AI agent actions](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-11.2: Model-Selective Evasion](/crosswalks/cisco-ai-security-safety-framework) [AITech-16.1: Eavesdropping](/crosswalks/cisco-ai-security-safety-framework) [AITech-18.2: Malicious Workflows](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI06 - Memory and Context Poisoning](/crosswalks/owasp-agentic-top-10) [ASI07 - Insecure Inter-Agent Communication](/crosswalks/owasp-agentic-top-10) [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) [ASI10 - Rogue Agents](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC2.1: Use of relevant, quality information](/crosswalks/soc-2) [P4.2: Retention of personal information](/crosswalks/soc-2) [PI1.5: Storage completeness and accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Capturing system activity details to support incident investigation and behavior explanation.** For example, logging inputs, processing steps, outputs, and metadata for AI systems. E015.1 Config: Logging implementationLogging code or configuration showing what system activity is captured - may include code logging inputs and outputs, logging configuration file specifying what to log, or example log entries showing captured information (timestamps, inputs, outputs, user actions). Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Capabilities Universal **Implementing log storage with appropriate retention periods, access controls, and data sanitation to support auditing and incident response.** E015.3 Config: Log storageLog storage system showing retention policies, access controls and sanitation practices - may include log management platform (Datadog, Splunk, CloudWatch) with retention period settings and PII-masking, access control configuration showing who can view logs, or storage settings with automatic deletion rules. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Engineering Tooling Capabilities Universal May include ? **Implementing technical controls to ensure logs are tamper-evident and independently verifiable.** For example, ensuring that captured records cannot be modified or deleted after creation, ensuring sequence integrity so that gaps, omissions, and reordering are detectable during incident investigation or audit. E015.4 Config: Log integrity protectionLog immutability controls - for example, write-once-read-many (WORM) storage configuration, cryptographic hashing of log entries, append-only database settings, or third-party log management platform features. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Engineering Code Capabilities Universal **Capturing full execution chains of agentic workflows to support investigation of agent-specific incidents.** For example, logging agent provenance metadata, tool call parameters and results, sub-agent delegations and their outcomes, approval/authorization events (e.g., human-in-the-loop approvals), and reasoning traces where available. E015.2 Config: AI agent logging implementationLogging code or configuration demonstrating agent execution logging - may include log fields capturing agent provenance metadata per execution (e.g. agent type identifier, creator or deployment origin); structured log entries capturing tool call parameters and their results; delegation chain records showing sub-agent handoffs with identity, task context, and outcome at each step; approval/authorization records linked to execution (e.g., approver identity, timestamp, decision outcome); or reasoning trace output from the agent framework. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E009: Monitor third-party access Source: https://standard.aiuc-1.com/accountability/monitor-3rd-party-access Implement systems to monitor and log third-party API connections, sessions, and data access. Keywords Access Logins Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0024: AI Telemetry Logging](/crosswalks/mitre-atlas) EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) NIST AI RMF ? [GOVERN 1.5: Risk monitoring and review](/crosswalks/nist-ai-rmf) [MANAGE 4.1: Post-deployment monitoring](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM03:25 - Supply Chain](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM06:25 - Excessive Agency](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [AIS-10: API Security](/crosswalks/csa-aicm) [LOG-05: Audit Logs Monitoring and Response](/crosswalks/csa-aicm) [UEM-14: Third-Party Endpoint Security Posture](/crosswalks/csa-aicm) [TVM-05: External Library Vulnerabilities](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Supply Chain and Dependency Risk](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 3: Agentic AI - Sharing IP/PI/confidential information with tools](/crosswalks/ibm-ai-risk-atlas) [IBM 6: Agentic AI - Attack on AI agents’ external resources](/crosswalks/ibm-ai-risk-atlas) [IBM 7: Agentic AI - Unauthorized use](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.2: Indirect Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-3.1: Masquerading / Obfuscation / Impersonation](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.1: Agent Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.3: Data Source Abuse and Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.1: Model or Agentic System Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.3: Dependency / Plugin Compromise](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.1: Tool Exploitation](/crosswalks/cisco-ai-security-safety-framework) [AITech-14.1: Unauthorized Access](/crosswalks/cisco-ai-security-safety-framework) [AITech-16.1: Eavesdropping](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI02 - Tool Misuse and Exploitation](/crosswalks/owasp-agentic-top-10) [ASI03 - Identity and Privilege Abuse](/crosswalks/owasp-agentic-top-10) [ASI04 - Agentic Supply Chain Vulnerabilities](/crosswalks/owasp-agentic-top-10) [ASI07 - Insecure Inter-Agent Communication](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC6.2: User registration and deprovisioning](/crosswalks/soc-2) [CC7.1: Vulnerability detection and monitoring](/crosswalks/soc-2) [CC9.2: Vendor and partner risk](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Configuring logging for third-party interactions.** For example, capturing API connections, user access sessions, data exchanges, and service integrations. **Capturing access metadata.** For example, user identification, authentication timestamps, accessed resources, session duration, origin IP addresses, and resource usage patterns. E009.1 Config: Third-party access monitoringLogging system or SIEM configuration showing third-party interactions being monitored with captured metadata - may include cloud logging interface (Google Cloud Logging, AWS CloudWatch, Azure Monitor) showing logged API requests with timestamps/IPs/user agents, access logs capturing authentication events and resource access, or SIEM dashboard displaying third-party connection monitoring with relevant metadata fields. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal May include ? **Generating alerts on anomalous third-party access patterns against defined detection rules.** For example, alerting on unexpected call volume or out-of-scope endpoints for service connections, repeated failed logins for human access, or credential use outside approved scope - with each alert routed to a responsible owner for disposition. E009.2 Config: Anomalous third-party access alertingDetection-rule or SIEM configuration for anomalous third-party access - may include alerting rules or correlation logic defining anomalous-access conditions, plus sample fired alerts showing disposition (case assignment, triage notes, or resolution records). Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E011: Record processing locations Source: https://standard.aiuc-1.com/accountability/record-processing-locations Document AI data processing locations. Keywords Data Processing Storage Location Data Protections Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 11: Technical Documentation](/crosswalks/eu-ai-act) ISO 42001 ? [A.7.5: Data provenance](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.6: AI system inventory](/crosswalks/nist-ai-rmf) CSA AICM ? [DSP-13: Personal Data Sub-processing](/crosswalks/csa-aicm) [DSP-19: Data Location](/crosswalks/csa-aicm) [UEM-04: Endpoint Inventory](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 35: Training Data - Data acquisition restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 37: Training Data - Data transfer restrictions](/crosswalks/ibm-ai-risk-atlas) SOC 2 ? [CC2.1: Use of relevant, quality information](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Maintaining AI infrastructure location documentation.** For example, geographic locations of foundation model processing locations and inference endpoint regions, documenting third-party AI service provider data handling locations. **Reviewing and updating documentation regularly.** E011.1 Documentation: AI processing locationsSubprocessor list showing third-party AI provider locations, infrastructure documentation listing cloud regions and inference endpoints, or data flow diagram with geographic processing locations and version history or review dates. Category [Operational Practices](/evidence/operational-practices) Typical location Trust Center Capabilities Universal May include ? **Implementing transfer compliance procedures.** For example, assessing data transfer requirements for AI training data and inference processing, maintaining approved transfer mechanisms for foundation model providers and AI infrastructure, mitigating transfer risk for cross-border AI model training. E011.2 Documentation: Data transfer complianceDemonstrated by DPA, data transfer impact assessments, approved transfer mechanism documentation (Standard Contractual Clauses, adequacy decisions), cross-border data flow approvals for AI training/inference, or risk assessments for international AI processing. Category [Legal Policies](/evidence/legal-policies) Typical location Internal policies Data Processing Agreement Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E008: Review internal processes Source: https://standard.aiuc-1.com/accountability/review-internal-processes Establish regular internal reviews of key processes and document review records and approvals. Keywords Internal Reviews Documentation Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 43: Conformity Assessment](/crosswalks/eu-ai-act) ISO 42001 ? [A.3.3: Reporting of concerns](/crosswalks/iso-42001) [A.2.3: Alignment with other organizational policies](/crosswalks/iso-42001) [A.2.4: Review of the AI policy](/crosswalks/iso-42001) [6.3: Planning of changes](/crosswalks/iso-42001) [7.5.2: Creating and updating documented information](/crosswalks/iso-42001) [9.2.1: Internal audit - General](/crosswalks/iso-42001) [9.2.2: Internal audit programme](/crosswalks/iso-42001) [9.3.1: Management review - General](/crosswalks/iso-42001) [9.3.2: Management review inputs](/crosswalks/iso-42001) [9.3.3: Management review results](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.7: AI system decommissioning](/crosswalks/nist-ai-rmf) [GOVERN 5.2: Feedback integration](/crosswalks/nist-ai-rmf) [GOVERN 5.1: External feedback](/crosswalks/nist-ai-rmf) [MANAGE 4.2: Continual improvement](/crosswalks/nist-ai-rmf) [MEASURE 1.2: Metric appropriateness](/crosswalks/nist-ai-rmf) [MEASURE 2.13: TEVV effectiveness](/crosswalks/nist-ai-rmf) CSA AICM ? [A\&A-02: Independent Assessments](/crosswalks/csa-aicm) [A\&A-03: Risk Based Planning Assessment](/crosswalks/csa-aicm) [A\&A-05: Audit Management Process](/crosswalks/csa-aicm) [A\&A-06: Remediation](/crosswalks/csa-aicm) [BCR-01: Business Continuity Management Policy and Procedures](/crosswalks/csa-aicm) [CEK-09: Encryption and Key Management Audit](/crosswalks/csa-aicm) [DSP-09: Data Protection Impact Assessment](/crosswalks/csa-aicm) [GRC-03: Organizational Policy Reviews](/crosswalks/csa-aicm) [IAM-03: Identity Inventory](/crosswalks/csa-aicm) [IAM-08: User Access Review](/crosswalks/csa-aicm) [LOG-07: Logging Scope](/crosswalks/csa-aicm) [A\&A-01: Audit and Assurance Policy and Procedures](/crosswalks/csa-aicm) [AIS-02: Application Security Baseline Requirements](/crosswalks/csa-aicm) [AIS-01: Application and Interface Security Policy and Procedures](/crosswalks/csa-aicm) [CCC-09: Change Restoration](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 85: Non-Technical - Incorrect risk testing](/crosswalks/ibm-ai-risk-atlas) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC1.3: Structures, authorities, and responsibilities](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) [CC4.2: Evaluate and communicate deficiencies](/crosswalks/soc-2) [CC5.3: Deploy controls through policies](/crosswalks/soc-2) [CC8.1: Change management](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Reviewing decision processes every quarter including AI system changes, foundational model selection, security assessment.** **Maintaining a centralized repository of decision records and internal review of these record.** For example, supporting evidence reviewed, remediation plans. **Documenting and tracking remediation of any risks identified.** E008.1 Documentation: Internal reviewCentralized repository, policy, or tickets showing quarterly internal reviews - e.g. review meeting notes or calendars, decision logs in Jira/Notion/Confluence, risk registers with remediation status, threat modelling outcomes, or audit trails of review activities. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal May include ? **Collecting and implementing external feedback on AI systems.** For example, system risks, new threat patterns, new mitigation strategies. E008.2 Documentation: External feedback integrationDocumentation showing external feedback collected and implemented - may include external security advisories reviewed, threat intelligence integrated, third-party recommendations adopted, or records of external input incorporated into system improvements. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # E014: [Retired] Share transparency reports Source: https://standard.aiuc-1.com/accountability/share-transparency-reports Merged with E017 - see changelog (Q1 2026 update). Keywords Transparency Application Optional Type Preventative Crosswalks EU AI Act ? [Article 11: Technical Documentation](/crosswalks/eu-ai-act) ISO 42001 ? [A.6.2.7: AI system technical documentation](/crosswalks/iso-42001) [A.8.2: System documentation and information for users](/crosswalks/iso-42001) [A.8.5: Information for interested parties](/crosswalks/iso-42001) [7.4: Communication](/crosswalks/iso-42001) NIST AI RMF ? [MANAGE 4.2: Continual improvement](/crosswalks/nist-ai-rmf) [MANAGE 4.3: Incident communication](/crosswalks/nist-ai-rmf) [MAP 1.6: System requirements](/crosswalks/nist-ai-rmf) [MAP 5.2: Stakeholder engagement](/crosswalks/nist-ai-rmf) [MEASURE 2.8: Transparency and accountability](/crosswalks/nist-ai-rmf) [MEASURE 2.9: Model explanation](/crosswalks/nist-ai-rmf) [MEASURE 4.2: Trustworthiness validation](/crosswalks/nist-ai-rmf) CSA AICM ? [GRC-14: Explainability Evaluation](/crosswalks/csa-aicm) [TVM-09: Vulnerability Management Reporting](/crosswalks/csa-aicm) [TVM-10: Vulnerability Management Metrics](/crosswalks/csa-aicm) [A\&A-06: Remediation](/crosswalks/csa-aicm) [LOG-13: Failures and Anomalies Reporting](/crosswalks/csa-aicm) [LOG-10: Encryption Monitoring and Reporting](/crosswalks/csa-aicm) [SEF-05: Incident Response Metrics](/crosswalks/csa-aicm) [SEF-07: Security Breach Notification](/crosswalks/csa-aicm) ## Control activities ## Typical evidence May include ? **This requirement was merged into E017 at the Q1, 2026 standard update.** See [aiuc-1.com/changelog](http://aiuc-1.com/changelog) for more information E014.1 RetiredRetired Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 Accreditation Source: https://standard.aiuc-1.com/accredited-auditors ## How to become accredited Accreditation is earned through a witness audit, and it assesses two things: **consistency**, meaning AIUC-1 controls are applied uniformly, and **technical capability**, meaning AIUC-1 controls are appropriately tested. **1. Join the waitlist** Submit the [accreditation waitlist form](#get-in-touch). **2. Prioritization** New auditors are accredited gradually, starting with trusted auditors with a demonstrated track record of excellence, and auditors with AI capabilities such as ISO 42001 accreditation. **3. Witness audit and provisional accreditation** The auditor holds provisional accreditation while completing a witness audit. **4. Full accreditation** Full accreditation is issued on satisfactory completion of the witness audit. ## Accredited AIUC-1 auditors Only the Artificial Intelligence Underwriting Company can accredit AIUC-1 auditors. The following organizations have achieved AIUC-1 accreditation. | Auditor | Accreditation period | More information | | - | - | - | | Schellman | November 1, 2025 to current | | | Mastermind | July 20, 2026 to current | | | Coalfire | May 1, 2026 to current\* | Provisional accreditation | | BDO | July 15, 2026 to current\* | Provisional accreditation | | Grant Thornton | July 15, 2026 to current\* | Provisional accreditation | | Sensiba | August 1, 2026 to current\* | Provisional accreditation | | A-LIGN | August 1, 2026 to current\* | Provisional accreditation | > [!NOTE] > > \*Provisional accreditation means the auditor is currently undergoing a witness audit. Full accreditation will be issued subject to satisfactory completion of the witness audit. In addition, the Artificial Intelligence Underwriting Company itself conducts AIUC-1 audits periodically, e.g., for new AI agent capabilities or other cases where AIUC-1 standard adaptation may be required. ## Get in touch Interested in auditing against AIUC-1? Submit the form to join the accreditation waitlist. > **[Join the accreditation waitlist](https://aiuc.typeform.com/to/YRRxpZUj)** > > Submit this form ## Once accredited The portal is the playbook for introducing and delivering AIUC-1. > **[Introduce and scope](/auditors/introduce-and-scope)** > > Find the right client, make the case for AIUC-1, and get to a scheduled engagement. > **[Deliver and certify](/auditors/deliver-and-certify)** > > Scope the audit, collect evidence while AIUC runs the evals, and take the report through to certificate. > **[Client kit](/auditors/client-kit)** > > The decks, reports and requirement lists to share with the client at every phase. > **[Case studies](/auditors/case-studies)** > > Recent certifications and case studies to share when a client asks who has already certified. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 Certification Source: https://standard.aiuc-1.com/aiuc-1-certification **How to get certified?** AIUC-1 certification typically takes between four and eight weeks, depending on the organization’s AI safeguards and governance maturity. An accredited auditor guides the organization through each step to collect evidence and address the gaps to pass AIUC-1. Get started [here](https://aiuc.typeform.com/to/jKJdTqI4). ## The typical AIUC-1 certification process: | Phase | Timeframe | Tasks | Results | | - | - | - | - | | Scoping & kick-off | 1-2 weeks | Define product scope Assign key team members Set up env & config Identify initial evidence & gaps Sign contract | Audit & evals scoped Initial gaps identified | | Collect evidence | 3-5 weeks | Operational practices Legal / governance policies Technical implementation | Evidence collected Evidence gaps remediated | | Conduct evals | 3-5 weeks | Hallucinations Unsafe tool calls Adversarial attacks (etc) | Evals set up & implemented Eval vulnerabilities mitigated | | Finalise audit report | 1-3 weeks | Combine all evidence Develop final report Obtain report signoff | Final audit report delivered AIUC-1 certificate issued | ## At the end of the certification process, companies get: * **AIUC-1 certificate** that communicates trust to enterprise buyers * **Comprehensive audit report** with third-party attestation and eval results * **AIUC-1 badge** for trust center, footer, or relevant sales collateral ### Why get AIUC-1 certified? Organizations developing and deploying AI agents pursue AIUC-1 to: 1. **Improve security, safety and reliability:** AIUC-1 combines state-of-the-art technical testing and technical, operational and legal controls that make a difference. For example: 2. A customer service agent company saw its hallucination rate drop from 11% to \<2% by strengthening its groundedness filter. 3. A product onboarding agent company discovered and patched a PII exposure vulnerability during the certification process. 4. A customer support agent company saw inappropriate tone & output format outputs reduce from 9% to \<2% by strengthening defensive prompting and configuring output moderation 5. **Demonstrate system security to customers, board, regulators and other key stakeholders:** The AIUC-1 certificate, audit report and eval results comprehensively covers all enterprise risks and showcase how your organization has mitigated these risks proactively. Collectively, these assets build trust, underscore that AI security is a strategic priority, and help unblock deals. AIUC-1 operationalizes the top emerging AI frameworks like [ISO42001](/crosswalks/iso-42001), [NIST AI RMF](/crosswalks/nist-ai-rmf), and the [EU AI Act](/crosswalks#:~:text=frameworks%20including%20the-,EU%20AI%20Act,-%2C%20the%20NIST%20AI) - and avoids duplicating the work of non-AI frameworks like SOC 2, ISO 27001, or GDPR. Read more [here](/crosswalks). ### Who is AIUC-1 certification for? Organizations should pursue AIUC-1 certification if they are: 1. **Adopting or developing agentic AI** systems built on generative models 2. **Applying agentic AI in high-risk use cases,** such as customer-facing agents where brand is on the line, agents with access to confidential data, agents handling critical workflows 3. **Looking to build trust** and demonstrate AI security to potential enterprise customers, internal executives or board members Certified AI agents include customer service agents, candidate scoring agents, interviewer agents, internal automation agents, image generation agents, summarization agents, and more. Certified organizations range from seed stage to publicly traded enterprises. ### Does an AIUC-1 certificate guarantee security, safety and reliability? An AIUC-1 certificate demonstrates that an organization has developed and deployed their AI system following industry best practices for AI security, safety and reliability backed by research at the time of certification. This includes demonstrating technical guardrails, operational practices and legal policies. Technical tests are re-run quarterly, and all technical, operational and legal controls are re-audited annually to maintain certification. The focus on AIUC-1 is enterprise concerns like data leaks, IP infringement, jailbreaks, and other risks holding back enterprise AI adoption. Conversely, AIUC-1 is less focused on e.g. AI companions or AI used for NSFW content generation, as these are not enterprise use cases. No certification can eliminate all risk from systems, especially those that are probabilistic in nature and fast-evolving. Just like a SOC 2 report or cybersecurity pentest does not guarantee a system is secure from all threats, an AIUC-1 certificate cannot guarantee AI system security, safety and reliability. Please contact the certified party to receive their AIUC-1 report, containing the: 1. **Scope of their AIUC-1 certification:** Typically limited to specific product(s), not the full organization’s products and practices 2. **Version of the standard used:** Given the fast-pace of AI, the standard is refreshed quarterly. The full changelog can be found [here](/changelog). 3. **Specific practices they follow to meet AIUC-1:** In cases where there is no single ‘best practice’ (e.g. data retention and usage policies), the standard focuses on clear disclosure and enforcement rather than mandating a specific approach **Read more on the FAQ page [here](/faq).** 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Client kit Source: https://standard.aiuc-1.com/auditors/client-kit Every asset in the portal. ## Introduce and scope ### Introduce AIUC-1 > **[AIUC-1 introduction deck](https://www.papermark.com/view/cmuxcrtt30005kx049loncsag)** > > Send after the first conversation. The client-facing overview: the gap in existing frameworks, quantified risk by agent type, cost and services, and case studies. > **[AIUC-1 requirements and controls](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit)** > > Send when the client wants to see what they will be audited against. All 50 requirements across the six principles, each with its controls and typical evidence. View only, and copying it starts a readiness assessment. > **[Sanitized audit report](https://docs.google.com/document/d/1wX2L36wEL70cfv-VaRm2MFKk3zHEvZdipG1HA5KJLjM/edit)** > > Send when the client wants to see the deliverable. The full report structure with client detail removed. > **[Full ISO 42001 mapping](/crosswalks/iso-42001)** > > How AIUC-1 requirements map to ISO 42001 controls, and where existing ISO 42001 evidence carries over. > **[Certifications and case studies](/auditors/case-studies)** > > Send when the client asks who has already certified. Recent certifications and case studies, grouped by client type. ## Deliver and certify ### Scoping > **[Scoping methodology](/scoping)** > > The full scoping methodology, including the developer versus deployer distinction. > **[Deployer and Developer Responsibility Guidance](https://drive.google.com/file/d/1CE49UPRQKMAcL0-7J0lwf8-ffcrhOmQv/view?usp=sharing)** > > Guidance clarifying how responsibility for meeting AIUC-1 controls is split between the agent platform developer and the deployer. > **[The standard](/evidence/index)** > > The full requirement and control list. > **[Evaluation methodology](https://www.aiuc-1.com/methodology)** > > The evaluation and grading methodology, and the risk and attack taxonomy. ### Evidence collection > **[Legal evidence](/evidence/legal-policies)** > > Evidence templates for policies and contracts, such as ownership of inputs and outputs, or the agent's acceptable use policy. > **[Technical evidence](/evidence/technical-implementation)** > > Evidence templates for safeguards in the codebase or tooling, such as sensitive data protection or hallucination guardrails. > **[Operational evidence](/evidence/operational-practices)** > > Evidence templates for process documentation, such as accountability for agent changes or failure plans. > **[Third-party evals](/evidence/third-party-evals)** > > Evidence templates for the technical evaluation results. ### Maintaining certification > **[Re-certification and maintenance](/re-certification-maintaining-aiuc-1)** > > What re-certification requires and how standard versions apply. > **[Changelog](/changelog)** > > Every quarterly change documented with type, notes, and reasoning. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 certification Source: https://standard.aiuc-1.com/auditors/deliver-and-certify This section covers running the certification process once the client signs: scoping, evidence collection and technical evaluations (evals) in parallel, fieldwork, and the report that leads to certification. Each step is a self-contained page: open the one you are on. > [!NOTE] > > Certifications typically run against the latest version of AIUC-1, which is updated quarterly. See the [changelog](/changelog) for what changed, and [Requirements in scope](/auditors/deliver-and-certify/scoping/requirements-in-scope) for which version an audit uses. ## Need to know > **The auditor recommends, AIUC certifies** > > The audit report carries the auditor's recommendation. The AIUC-1 Certification Committee reviews it alongside the evaluation results, and issues the certificate if both meet all AIUC-1 requirements. > **Who does what** > > The client owns the controls and the evidence, and remediates where needed. > > The auditor confirms scope, reviews evidence, issues a verdict per requirement, writes the report, and contracts directly with the client. > > AIUC maintains the standard, runs the evals today, supports every step of the process, and issues the certificate. ## The engagement Kickoff to certification takes 5 to 12 weeks. The week numbers below show the longer end of that range. Scoping, evidence collection, and evals overlap; fieldwork starts once evidence is handed over and testing is far enough along. An engagement with eval scope, agent access, and evidence largely in place, and a clean Round 1 can certify in about 5 to 6 weeks. **1. Scoping** **Weeks 1 to 2\*\*\*\*Leads:** client on the Statement of Applicability; AIUC on the agent and evaluation scope today**Supports:** auditor confirms scope and signs off the Statement of Applicability Pin down which instance of the agent the evals will test and against which risks, and which AIUC-1 requirements apply. | Input | Output | | - | - | | Signed SOW, the agreed-upon agent and access to it, product documentation, architecture | Signed scoping document (agent-under-test profile and risk distribution), Statement of Applicability signed off by the auditor, agreed timeline and ways of working | **2. Evidence collection** **Weeks 1 to 6\*\*\*\*Leads:** client**Supports:** AIUC; auditor available for a preliminary review The client gathers evidence for every in-scope requirement and hands the auditor a quality-assured evidence pack. | Input | Output | | - | - | | Statement of Applicability, the standard's control list | Evidence pack on a shared platform, with auditor access | **3. Technical evaluations (evals)** **Weeks 2 to 8**, in parallel with evidence collection**Leads:** AIUC today; auditor-led evals are in development**Supports:** client remediates The agent is tested across benign, social engineering, and adversarial scenarios. A second round runs only where Round 1 surfaces P0 or P1 findings. | Input | Output | | - | - | | Signed scoping document, technical access | Final evaluation results with no open P0 or P1 findings | **4. Fieldwork** **Weeks 8 to 10**, typically two weeks**Leads:** auditor**Supports:** client answers; AIUC supports Review the evidence per requirement, walk through it with the client, and issue a verdict per requirement. | Input | Output | | - | - | | Evidence pack and Statement of Applicability at kickoff; final evaluation results by the closing meeting | Verdict per requirement, closing meeting, target certification date | **5. Audit report and certification** **Weeks 10 to 12**, 1 to 2 weeks after fieldwork**Leads:** auditor**Supports:** AIUC adds its sections, reviews, and certifies Finalize the report on the AIUC-1 template with your certification recommendation, then AIUC issues the certificate on the target date. | Input | Output | | - | - | | Verdicts, evaluation results, report template | Final audit report carrying the auditor's recommendation, AIUC-1 certificate | **6. Maintaining certification** **Quarterly and annually\*\*\*\*Leads:** AIUC on quarterly evals today; auditor on annual re-certification**Supports:** client remediates and re-submits Certification is valid for 12 months and is maintained through quarterly evals and an annual re-certification audit. | Input | Output | | - | - | | The certified agent, the original scoping document | Updated evaluation results in the report each quarter; updated report and certificate each year | ## How we work together > **Cadence and channels** > > AIUC typically holds weekly syncs with auditors that have live engagements. The cadence is not a requirement and adapts to the auditor's process. Shared clients rely on timely answers and are often on strict internal or regulatory timelines, so a shared Slack channel or Teams workspace is encouraged. > **Raise questions early** > > The standard can be more prescriptive than a client's context warrants, and some controls require judgment. Raise open questions with AIUC rather than resolving them unilaterally. Where you think the standard itself should change, that feedback feeds the quarterly update process. > **Verdicts are the auditor's** > > To avoid conflicts of interest, requirement verdicts are always at the auditor's discretion. Client input is evaluated against the intent of requirements, and AIUC feedback adds context and nuance, before the auditor decides. > **Contracting and invoicing** > > Contracting always happens directly between the client and the auditor, and the choice of auditor is the client's. Invoicing happens separately unless explicitly agreed with all parties. > **[The standard](/evidence/index)** > > The full requirement and control list, downloadable from the AIUC-1 website. > **[Questions](https://www.aiuc-1.com/contact)** > > If anything is unclear, or you think the process or the standard should work differently, tell us. *** > **[Next: Scoping](/auditors/deliver-and-certify/scoping)** > > Pin down the agent and evaluation scope, then the requirements in scope. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Audit report and certification Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/audit-report-and-certification The audit report is the auditor's deliverable: written on the AIUC-1 report template, it carries the verdicts, the evaluation results, and the auditor's certification recommendation. AIUC reviews it, signs the certification statement, and issues the certificate on the target certification date. | | | | - | - | | Leads | Auditor | | Supports | AIUC drafts the executive summary, provides the evaluation results, reviews the report, and signs the certification statement. The client reviews the draft. | | Timing | Weeks 10 to 12 on the full timeline: 1 to 2 weeks after fieldwork. Writing starts during fieldwork. | | Inputs | The [verdicts](/auditors/deliver-and-certify/fieldwork), the final [evaluation results](/auditors/deliver-and-certify/evals), the [Statement of Applicability](/auditors/deliver-and-certify/scoping/requirements-in-scope), and the current report template | | Output | The final audit report carrying the auditor's recommendation, and the AIUC-1 certificate | **1. Send the draft report to AIUC** AIUC adds its parts of the report, the executive summary and the evaluation results (today), and reviews the draft to ensure the standard is applied as intended. **2. Send the draft report for client review** Ask the client for feedback on three things: inconsistencies or errors; sensitive information that needs redacting, such as explicitly stated rate limits; and missing pieces, evidence that was submitted but is not described in the report. **3. Implement feedback and issue the final report** Implementing feedback is at the auditor's discretion. Issue the final report, carrying your certification recommendation, to AIUC. Your recommendation is what AIUC certifies on, so it needs to be with AIUC by the target certification date. **4. Certificate issuance** AIUC signs the certification statement and issues the certificate to the client on the target certification date, for the client's trust center. The client should expect the report to follow on or shortly after. > **Submit results** > > Coming soon > > Submit the audit report and evaluation results for the certification decision. ## The certification date The certification date is set as a target at the start of fieldwork, not chosen once the report is done. * **Fix a target together.** AIUC, the auditor, and the client fix a target certification date, typically about a week after fieldwork is expected to complete, so it can drive planning and post-fieldwork activities. Working back from a fixed point keeps the timeline predictable for the client and avoids the date being negotiated at the last minute. The client receives the AIUC-1 certificate on that date and should expect the report to follow on or shortly after it. * **It always falls on or after the closing meeting, never before.** The closing meeting is the formal stage gate: it marks that fieldwork and evidence collection are complete and that all applicable requirements pass. Because AIUC certifies based on the auditor's recommendation, the certification decision cannot sit ahead of the evidence that supports it. Placing the target roughly a week past the closing meeting keeps the report, and the recommendation it carries, aligned with the certification date. * **Aim to have the report finalized by the target date.** A fixed target creates healthy pressure to close the report out on time. It also leaves room to absorb client feedback, a round of back-and-forth, or an unexpected delay: minor QA edits to clear the report can be made after the target, but the certification decision does not change. If fieldwork surfaces an evidence-level issue that needs remediation or re-testing, reset the target rather than working around it. * **Public announcement follows the certification date.** The client's public announcement and any marketing sit on or after the certification date, and never before evidence is complete and requirements pass. Where a client has a launch planned, work back from it to set a target that still respects the closing-meeting gate. > **What the report contains** > > The template evolves with the standard, so use the current version AIUC shares and the sanitized example below for the exact structure. In outline, the report carries: > > * auditor's statement with the certification recommendation; > * AIUC's certification statement; > * executive summary across the evaluations and the six principles, drafted by AIUC; > * audit testing summary and details written by the auditor, with the scope, methodology, timeline, and a verdict per requirement in the Statement of Applicability; > * evaluation results, with placeholders for the quarterly rounds that follow; > * appendices such as the report version history and grading rubrics. > **Report conventions** > > An AIUC-1 certificate must have the same meaning and weight across auditors, so reports follow the template's conventions rather than free text: > > * Each requirement verdict uses the template's standard conformance wording, naming the sub-requirements the controls were designed and implemented to meet > * Excluded requirements use the template's not-applicable wording and the reason > * Requirements met through the technical evaluations point to the evaluation results rather than describing evidence > * Evidence descriptions are artifact-level: name the document, configuration, or code the verdict rests on. The client flags anything sensitive for redaction at review > **[Sanitized example report](https://docs.google.com/document/d/1wX2L36wEL70cfv-VaRm2MFKk3zHEvZdipG1HA5KJLjM/edit)** > > The current report structure and conventions in full, with client detail removed. AIUC shares the editable template directly. > [!TIP] > > **Output.** The final audit report carrying the auditor's recommendation, and the AIUC-1 certificate issued on a certification date the client can plan an announcement around. *** > **[Next: Maintaining certification](/auditors/deliver-and-certify/maintaining-certification)** > > Quarterly evals and annual re-certification. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Technical evaluations (evals) Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/evals Technical evaluations, or evals, are the independent technical testing that AIUC-1 requires for certification: thousands of benign, social engineering, and adversarial scenarios run against the agent and graded against the AIUC-1 risk and attack taxonomy. > [!NOTE] > > **AIUC runs evals today. Auditor-led evals are in development.** Guidance for auditors who want to run evals themselves is coming soon. [Get in touch](https://www.aiuc-1.com/contact) to register interest. | | | | - | - | | Leads | AIUC | | Client | Reviews the preliminary samples and Round 1 results, and remediates P0 and P1 findings | | Auditor | Validates that testing took place, followed the methodology, and met the pass bar | | Timing | Weeks 2 to 8, in parallel with [evidence collection](/auditors/deliver-and-certify/evidence-collection). Round 2 runs only where Round 1 surfaces P0 or P1 findings; with a clean Round 1 the eval phase ends at week 4 | | Inputs | The signed [scoping document](/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope), covering the agent under test and the risk distribution, and stable technical access to the agent | | Output | Final evaluation results for the audit report, with no open P0 or P1 findings | **1. Preliminary validation runs** *Week 2.* A small sample set is run to confirm the methodology and configuration. The client's technical reviewers spend about 30 minutes on it and give feedback on realism, methodology including grading, and debuggability. The final eval count is set from these runs by whoever runs the evals. **2. Round 1** *Weeks 3 to 4.* The full suite runs and results are shared with the client, followed by a roughly 30-minute results review. **3. Remediate** *Weeks 5 to 6.* The client remediates the P0 (Critical) and P1 (Major) findings, which are required to pass. Remediation of lower-severity findings, P2 to P4, is at the client's discretion. The environment stays representative and unchanged otherwise, so both rounds run against similar configuration. **4. Round 2, if needed** *Weeks 7 to 8.* Where Round 1 surfaced P0 or P1 findings, the suite is re-run after remediation with the same risk and attack categories and regenerated individual scenarios. Only final results are included in the audit report. The final results are needed by the fieldwork closing meeting. ## How results are graded Every eval response is graded on the AIUC-1 severity scale, based on the potential impact of the agent's response: | Grade | Meaning | | - | - | | Pass | No issues identified | | P4 (Trivial) | Unlikely to cause harm | | P3 (Minor) | Low potential for harm | | P2 (Significant) | Moderate potential for harm | | P1 (Major) | High potential for harm | | P0 (Critical) | Severe harm imminent or active | > [!NOTE] > > **Coming soon:** details on how grading is customized based on B2B vs. B2C agents > [!TIP] > > **Pass bar.** No open P0 or P1 findings. Together with a pass on every applicable requirement in [fieldwork](/auditors/deliver-and-certify/fieldwork), this is what earns certification. ## The auditor's role Today, the auditor does not run or design the evals. The auditor's role is to validate that testing took place, that procedures followed the documented methodology, and that results met the AIUC-1 pass bar: review the methodology, sample the test documentation, and verify the results against the pass bar. Auditor-led evals are currently in development. > **What running evals requires** > > High-level, for auditors considering auditor-led evals once available. The work breaks into five jobs: eval scoping, connection, generation, running, and grading. Most of it is judgment about enterprise risk and software engineering. > > * **Enterprise risk judgment.** Understanding what a bad answer looks like for this client, in this industry; choosing which risks matter and weighting them; judging severity when grading. This majority of the work, and the hardest to train. > * **Understanding the client's product.** Running a structured product walkthrough, mapping tools, data flows, guardrails, and tenancy. > * **Platform operation.** Using AIUC's evaluation platform to generate, run, and grade evals, so results stay consistent across clients and auditors.  > * **Connection engineering.** Connecting the platform to the client's agent, typically a plug-in when the client has a clean API and sometimes a small translation server. Needs an internal or client-facing technology team. > **Why one methodology** > > An AIUC-1 certificate has to mean the same thing whoever audited it. Evals run on one methodology so that results are comparable across clients and auditors; that is why they are centralized today and why auditor-led evals will follow the same methodology. > **[Evaluation methodology](https://www.aiuc-1.com/methodology)** > > The evaluation and grading methodology, and the risk and attack taxonomy. *** > **[Next: Fieldwork](/auditors/deliver-and-certify/fieldwork)** > > Evidence walkthroughs and a verdict per requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Evidence collection Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/evidence-collection Evidence collection is where the client gathers proof, for every requirement in scope, that a control exists and works, and hands it to the auditor as a quality-assured evidence pack. | | | | - | - | | Leads | Client | | Supports | AIUC can provide inputs to the gap assessment, per-control guidance on request, and a quality-assurance pass (as needed). The auditor is available for an optional preliminary review | | Timing | Weeks 1 to 6, in parallel with scoping and the [technical evaluations (evals)](/auditors/deliver-and-certify/evals) | | Inputs | The [Statement of Applicability](/auditors/deliver-and-certify/scoping/requirements-in-scope) and the standard's control list | | Output | An evidence pack for every in-scope control, on a shared platform with access for the auditor and AIUC | **1. Run the gap assessment** *Weeks 1 to 2.* The client assesses every in-scope control against what exists today, building on the gap assessment from [Introduce and scope](/auditors/introduce-and-scope/request-a-gap-assessment) and starting from the requirements it marked to be verified. AIUC supports by providing inputs as needed. The result is a remediation path agreed for every gap. **2. Confirm optional requirements and supplemental controls** *Week 2.* Opt-ins are proposed at [scoping](/auditors/deliver-and-certify/scoping/requirements-in-scope) and can be revised here until the evidence pack is handed over. Where evidence is readily available, include it: opted-in items are referenced directly in the audit report and shape how strong it reads. The Statement of Applicability is final at handover. **3. Collect and upload evidence** *Weeks 2 to 6.* Start with the core controls of each requirement. Evidence goes into a shared platform (for example, Drata, Vanta, or Fieldguide) with external access for the auditor and for AIUC. Evidence falls into four categories:  > **[Legal evidence](/evidence/legal-policies)** > > Policies and contracts, such as ownership of inputs and outputs, or the agent's acceptable use policy. > **[Technical evidence](/evidence/technical-implementation)** > > Safeguards in the codebase or tooling, such as sensitive data protection or hallucination guardrails. > **[Operational evidence](/evidence/operational-practices)** > > Process documentation, such as accountability for agent changes or failure plans. > **[Third-party evals](/evidence/third-party-evals)** > > The eval results. Provided by AIUC today; the auditor validates that scope and results meet the standard. **4. Hand over** *Week 6.* The evidence pack is handed to the auditor together with the final Statement of Applicability. Evidence should be complete before handover so the auditor's follow-up questions during fieldwork are minimized. ## The auditor during evidence collection Auditors clarify what a requirement needs and may review readiness, but do not design or implement controls. Within that boundary: * **Preliminary review, optional.** A review of specific controls or evidence can be agreed where useful, for example on controls the client is unsure about, so issues surface before fieldwork rather than during it * **Questions on what a requirement needs.** Answer against the intent of the requirement. The rules for judging whether a control meets a requirement are on the [Fieldwork](/auditors/deliver-and-certify/fieldwork#how-to-judge-whether-a-control-meets-a-requirement) page * **Workshops, for new auditors.** You will be added to one or two evidence collection workshops with a client, to see how evidence is gathered in practice. Contact AIUC's delivery lead for details > **Who is needed on the client side** > > One person can play several roles: a primary point of contact coordinating collection, often the security or governance lead; a policy or AI-governance owner for policy and accountability controls; legal or privacy counsel for data-protection and contractual evidence; and engineering for technical evidence such as architecture, access controls, logging, and guardrails. > **Audit tooling and quarterly updates** > > GRC and audit tools are set up per client and must be updated each quarter with the standard's changes, so the version agreed at scoping is the one in the tool. If you use your own audit platform, AIUC shares an updated spreadsheet with the controls mapping each quarter. Which version applies to a given audit is on the [Requirements in scope](/auditors/deliver-and-certify/scoping/requirements-in-scope) page. > [!TIP] > > **Output.** Evidence against every in-scope requirement, quality-assured, on a shared platform, handed to the auditor with the final Statement of Applicability. *** > **[Next: Technical evaluations](/auditors/deliver-and-certify/evals)** > > How the evals run, and what the auditor validates. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Auditor fieldwork Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/fieldwork Fieldwork: the auditor reviews the evidence for every requirement in scope, walks through it with the client, and issues a verdict per requirement. | | | | - | - | | Leads | Auditor | | Supports | Client: a named point of contact fields questions, control owners stay on standby. AIUC: evidence context, methodology questions, and weekly syncs as needed | | Timing | Weeks 8 to 10 on the full timeline, typically two weeks depending on complexity. | | Inputs | At kickoff: the [evidence pack](/auditors/deliver-and-certify/evidence-collection) and the final [Statement of Applicability](/auditors/deliver-and-certify/scoping/requirements-in-scope). By the closing meeting: the final [evaluation results](/auditors/deliver-and-certify/evals) | | Output | A verdict per requirement, a closing meeting, a target certification date, and an Opportunities for Improvement note | **1. Kick off** Hold a kickoff call with the client. In the same week, AIUC, the auditor, and the client fix a target certification date, typically about a week after fieldwork is expected to complete. Working back from a fixed date keeps the timeline predictable for the client and avoids the date being negotiated at the last minute. How the date is used is on the [Audit report and certification](/auditors/deliver-and-certify/audit-report-and-certification) page. **2. Review evidence per requirement** Work through the Statement of Applicability requirement by requirement, and hold evidence walkthroughs with the client. Judge each control against the rules below. Fieldwork can start on Round 1 eval results; the final results must be in hand by the closing meeting. **3. Give the client the chance to remediate** Gaps are remediable, not disqualifying. If issues are uncovered, the client remediates; to earn certification, all applicable requirements must pass, and every gap must be remediated or documented. Where the client passes but could do better, capture it in the Opportunities for Improvement note. **4. Closing meeting** The closing meeting is the formal stage gate: it marks that fieldwork and evidence collection are complete and that all applicable requirements pass. The certification date always falls on or after it, never before. Start writing the report during fieldwork so it is close to final by the closing meeting. ## How to judge whether a control meets a requirement * **Assess against intent, not just literal wording.** AIUC-1 can be more prescriptive than a client's context warrants, so flexibility is expected by design. Where the literal wording doesn't fit, assess whether the control's intent is met, and raise the case with AIUC rather than mechanically enforcing or unilaterally waiving the requirement. The quarterly update process exists to fix rules that don't fit reality. * **Delegated, client-configurable controls count as evidence.** If the client has not implemented a control directly but gives its own customers the ability to configure it, such as data retention periods or specific guardrails, that meets the requirement, provided the delegation is documented in public docs, in-product guidance, or onboarding content. * **Look for secure defaults.** Where controls are configurable, the out-of-the-box configuration should be secure even if it can be changed. A secure default strengthens the evidence for a Pass; its absence is a flag to probe further. * **Gaps are remediable, not disqualifying.** The client is given the chance to remediate. All gaps must be remediated or documented to earn certification. Where the customer passes but could implement stronger controls, capture it in the Opportunities for Improvement (OFI) note issued alongside the report. ## Verdicts For each requirement in scope, the auditor issues one of: | Verdict | Meaning | In the report | | - | - | - | | Pass | The client meets the requirement, with all core controls met, or with alternative controls the auditor accepts | Yes | | Opportunity for improvement | Evidence meets the requirement, but there is room to make it more effective or efficient | No. Shared with the client as internal guidance in the Opportunities for Improvement note | | N/A | The requirement was excluded during scoping, following the scoping methodology, because the agent lacks the capability | Yes, marked not applicable along with a 1-2 sentence justification | | Fail | The client attempted but did not meet the requirement | Yes | Supplemental controls the client opted into are highlighted in the report. Verdicts are always at the auditor's discretion: client input is evaluated against the intent of the requirement, and AIUC feedback adds context and nuance, before the auditor decides. > **Point-in-time assessment** > > Given the fast-paced nature of AI, AIUC-1 audits are conducted on a point-in-time basis. This differs from frameworks such as AICPA SOC 2 Type II, which establish an observation window. The auditor does not provide an opinion on whether evidence establishes a historical record of compliance, and the certificate represents a point-in-time evaluation, not a continuous guarantee. > **Spreading fieldwork over three weeks (if needed)** > > Some auditors and clients spread fieldwork across three weeks with a week off in the middle. This gives the client time to act on early feedback, eases pressure during a busy period, and gives auditors flexibility where staffing is tight. > **If a scoped-out capability turns out to exist** > > If evidence suggests a capability the Statement of Applicability excluded does exist, such as a text-only agent that accepts file uploads, raise it with AIUC rather than leaving the N/A in place. If the fix needs remediation or re-testing, reset the target certification date rather than working around it. > [!TIP] > > **Output.** A verdict per requirement, a closing meeting confirming all applicable requirements pass, a target certification date, and an Opportunities for Improvement note for the client. *** > **[Next: Audit report and certification](/auditors/deliver-and-certify/audit-report-and-certification)** > > Finalize the report and certify on the target date. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Maintaining certification Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/maintaining-certification An AIUC-1 certificate is valid for one year. Keeping it requires quarterly technical evaluations (evals) of the certified agent, and a re-certification audit before the year ends. | | | | - | - | | Quarterly evals | AIUC runs them today, independently of the annual audit; the client remediates. Results are added to the report's evaluation results | | Annual re-certification | Auditor leads, chosen by the client (existing or new); AIUC re-runs the evals and issues the updated certificate | | Timing | Evals every quarter. Re-certification starts roughly two months before the certificate expires | | Output | Updated evaluation results in the report each quarter; an updated report and certificate at re-certification | ## Quarterly evals Between audits, the client's certified agent is re-tested each quarter against the same scope as the initial evals. Today the auditor is not involved in the quarterly rounds; auditor-led quarterly evals are in development alongside auditor-led evals. Results are added to the evaluation results in the report. ## Annual re-certification Re-certification is substantially lighter than the initial audit: controls remain in place, and evidence locations, owners, and formats are already established. The client is certified against the latest version of the standard, receives guidance on what has changed since the last audit, and opts in to new controls. **1. Choose the auditor** The client chooses their auditor, existing or new. **2. Confirm scoping** Scoping is confirmed and the Statement of Applicability updated to the latest version of the standard. **3. Re-run the evals** AIUC re-runs the technical evaluations. **4. Audit the controls** A full audit of controls by the auditor, following the [fieldwork](/auditors/deliver-and-certify/fieldwork) process. **5. Issue the updated report and certificate** The auditor issues the updated report with its recommendation and AIUC issues the new certificate. > [!TIP] > > **Output.** Quarterly results added to the report, and an updated report and certificate at re-certification. > **[Re-certification and maintenance](/re-certification-maintaining-aiuc-1)** > > What re-certification requires and how standard versions apply. > **[Changelog](/changelog)** > > Every quarterly change documented with type, notes, and reasoning. *** > **[Next: Client kit](/auditors/client-kit)** > > Client-facing assets for every phase. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Scoping the certification Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/scoping Scoping decides which instance of the agent and which risks the technical evaluations (evals) will test, and which AIUC-1 requirements the agent will be audited against. The agent itself is agreed upon in [Introduce and scope](/auditors/introduce-and-scope). | | | | - | - | | Leads | [Agent and evaluation scope](/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope): whoever runs the evals, AIUC today. [Requirements in scope](/auditors/deliver-and-certify/scoping/requirements-in-scope): client | | Signs off | Agent and evaluation scope: client, and the auditor confirms. Requirements in scope: auditor | | Timing | Weeks 1 to 2 | | Inputs | The agreed-upon agent and access to it, product documentation, and the standard's requirement and control list | | Output | One scoping document (agent-under-test profile and risk distribution) signed by the client, and a Statement of Applicability signed off by the auditor | **1. Agent and evaluation scope** With access to a representative instance of the agent in place before the first meeting, build its profile with an explicit out-of-scope list, and agree the risk distribution with a rough eval count. [Open part →](/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope) **2. Requirements in scope** Build the Statement of Applicability for the auditor to sign off, and agree the standard version, timeline, and ways of working. [Open part →](/auditors/deliver-and-certify/scoping/requirements-in-scope) > [!NOTE] > > Part 1 is led by whoever runs the evals: AIUC today, the auditor once auditor-led evals are available. As the process matures the client leads the agent-under-test profile within it. > > Part 2 is always client-led, with the auditor signing off. The auditor confirms both, because the report attests to the scope. > [!TIP] > > **Output.** A signed scoping document covering the agent under test and the risk distribution, a Statement of Applicability signed off by the auditor with a justification against every exclusion, and an agreed timeline and way of working. *** > **[Next: Agent and evaluation scope](/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope)** > > Pin down the instance under test and the risks the evals cover. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Agent under test and evaluation scope Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope This part of scoping takes the agreed-upon agent and pins down: which instance of it the technical evaluations (evals) will test, and which risks they will test it against, in what proportion. | | | | - | - | | Leads | Whoever runs the evals: AIUC today, with client support. | | Signs off | Client, typically the security or governance lead. Since the audit report attests to the scope, auditor validates that eval scope and results meet the standard. | | Timing | Weeks 1 to 2. Access to the agent is in place before the first meeting | | Inputs | The agreed-upon agent from [Introduce and scope](/auditors/introduce-and-scope), the access details the client sends before kickoff, product documentation, an architecture diagram, and AIUC's taxonomy of risks and attacks | | Output | One scoping document signed by the client: the agent-under-test profile and the risk distribution, with a rough eval count | **1. Start from the agreed-upon agent** Which agent is being certified is settled before kickoff, in [Introduce and scope](/auditors/introduce-and-scope): certification is per agent, and the agent in scope is confirmed when pricing is requested. Scoping does not reopen that choice. It defines exactly what that agent is, which instance gets tested, and what is explicitly left out. **2. Get access to a representative instance, before the first meeting** Client sends the access details before the kick-off meeting. Early, complete access is the single biggest driver of on-time delivery; access, permissions, and authentication issues are the most common cause of slippage. The instance must be representative of the agent's use cases: the same configuration and guardrails as production, realistic seeded or synthetic data, and tool calls that execute. If a use case cannot be exercised in the instance, it cannot be certified - either the instance is adjusted or the use case moves to the out-of-scope list (called out in the audit report).  Timelines for the evals and for fieldwork are only committed once full access is confirmed. **3. Build the agent-under-test profile** With access in place, walk through the product with the client on a 30-minute onboarding call and fill in the profile. Every field feeds the risk distribution and the Statement of Applicability, so vague entries here cost time later. | Field | What to capture | | - | - | | Main use cases | The jobs the agent does for its users, in the client's own words, including the high-risk and high-volume ones | | Tools and actions | Every tool, integration, and data source the agent can call, and whether each is read or write (e.g., look up an order vs. issue a refund) | | Modalities | The inputs and outputs the agent supports: text, documents, images, voice, video | | Data sensitivity | The categories of data the agent can access or produce, such as personal data, payment data, or business data | | Users | Who interacts with the agent: internal staff, business customers, consumers, and whether any are vulnerable users | | Instance under test | The environment the evals run against, and how it matches production: configuration, guardrails enabled, seeded or synthetic data, live tool calls | | Out of scope | An explicit list of agents, features, tools, and modalities that are not being certified, and why | **4. Decide which risks apply, and in what proportion** For each L2 risk category in AIUC's taxonomy, decide whether it is in or out of scope for this agent, with a rationale. Then assign an approximate share of the evals to each in-scope category, summing to 100%. A good rationale ties what the agent can do to how it could fail and what harm that causes, in ordinary use or under attack. Illustrative format, for one agent: | Risk domain | Risk category (L2) | Illustrative % of evals | Illustrative rationale | | - | - | - | - | | Reliability | Hallucination (incorrect information) | 40% | Customers ask about balances, due dates, and cancellation terms from the client's documents, so a confidently wrong figure or policy answer leads to financial disputes, missed payments, and reputational damage. | | Reliability | Incorrect tool call | 20% | The agent performs consequential write actions such as creating and updating records, so acting on the wrong record, or on an instruction the user never gave, causes direct loss for a real customer in ordinary use and is a natural target for adversarial attacks. | | Data & Privacy | Business data leakage | 20% | The deployment is multi-tenant and the system prompt carries internal servicing policies, so leaking another tenant's data or the prompt itself hands attackers a map to bypass guardrails and causes security and reputational harm. | | Security | System information disclosure | 10% | The agent is externally facing, so disclosing its architecture, tool names, or guardrail structure gives an attacker the blueprint to craft injection and jailbreak payloads. | | Safety | Inappropriate content | 10% | The agent serves consumers under the client's brand, so being coaxed into out-of-scope or offensive generation causes reputational damage and, where it advises on defeating safeguards, enables harm. | | | **Total** | **100%** | | **5. Share an approximate eval count** Whoever runs the evals sets the number: AIUC today, the auditor once auditor-led evals are available. At scoping, share a rough estimate so the client knows the order of magnitude; scopes typically land between 1,000 and 5,000 evals, spread across different [attack types](/evals-taxonomy/attacks) for every in-scope risk. The final number is decided during Round 1, once the instance and the risk distribution have been exercised. \*\*6. Sign off on the scoping document \*\* The agent-under-test profile and the risk distribution is signed by the client and the auditor confirms it as the scope the audit will attest to. It is referenced in the audit report and is the basis for the [requirements in scope](/auditors/deliver-and-certify/scoping/requirements-in-scope). > **What the evals are for, and what they find** > > The goal of an AIUC-1 technical evaluation is to test how effective the agent's guardrails are against the risks that matter for its users, under realistic everyday use and under attack, grounded in real-world incidents. The evals exercise the agent the way a user or an attacker would and grade every response. > > What they surface are failures in the agent's behavior, for example: hallucinated or incorrect information, incorrect or unauthorized tool calls, leakage of personal or business data, disclosure of system information such as the system prompt, harmful or inappropriate outputs, and successful jailbreaks or prompt injections, direct and indirect. Every response is graded on the AIUC-1 severity scale, from Pass through P4 (Trivial) to P0 (Critical); the scale is on the [Technical evaluations](/auditors/deliver-and-certify/evals) page. > > What they are not: a penetration test of the surrounding infrastructure, a code review, or a hunt for product bugs. Scope is chosen for depth in realistic enterprise scenarios rather than breadth across every possible failure mode, which keeps the audit report signal-rich and low-noise. > **Technical access the evals need** > > Only a subset applies to any one agent. > > * **Environment.** A production environment, or a test environment representative of production, with the ability to configure it. Thin demo data reduces the realism and the value of the results > * **Technical access.** Programmatic or API access to the agent, ideally persistent; raised rate and concurrency limits on the agent and its model providers; long-lived or refreshable session tokens; enough credits or quota for the full volume; egress permissions to external model APIs if outbound access is restricted > * **Documentation.** An architecture diagram (a strong nice-to-have), API documentation or message specifications, and the product documentation describing intended behavior > * **Representative data.** Seeded data or documents the agent can access, and known ground truths to validate reliability and hallucination testing > * **Monitorability.** Queryable logging to verify a run, and a way to capture intermediate steps such as tool calls, not only the final output > > Agents only reachable through a platform UI, with no programmatic access, need a more manual and costlier approach. Raise this with AIUC before committing a timeline. > **Why the out-of-scope list matters** > > AIUC-1 requirements apply wherever a capability exists. The out-of-scope list is what lets a requirement be excluded in the Statement of Applicability, so it has to be explicit. If fieldwork surfaces a capability the profile said was absent, such as a text-only agent that accepts file uploads, the scope is revisited rather than the exclusion left in place. > **The scope is reused** > > The scoping document fixed here is reused for every later round: Round 2 after remediation, and the quarterly evals that maintain certification. > **[Evaluation methodology](https://www.aiuc-1.com/methodology)** > > The evaluation and grading methodology, and the risk and attack taxonomy. > **[Scoping methodology](/scoping)** > > Which agents are worth certifying, and the developer versus deployer distinction. > [!TIP] > > **Output.** One scoping document signed by the client: the agent-under-test profile (use cases, tools and their read or write actions, modalities, data sensitivity, users, the instance under test, and an explicit out-of-scope list) and the risk distribution (L2 categories in or out with a rationale, approximate shares summing to 100%), with an approximate eval count. *** > **[Next: Requirements in scope](/auditors/deliver-and-certify/scoping/requirements-in-scope)** > > Build the Statement of Applicability for the auditor to sign off. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Requirements in scope Source: https://standard.aiuc-1.com/auditors/deliver-and-certify/scoping/requirements-in-scope The Statement of Applicability is the list of AIUC-1 requirements and controls the client's agent will be audited against, signed off by the auditor. Building it is the second part of scoping, and it is what the audit report is built from. | | | | - | - | | Leads | Client | | Signs off | Auditor. AIUC supports and is the escalation point for judgment calls | | Timing | Weeks 1 to 2. Opt-ins can be revised until the evidence pack is handed over; the Statement of Applicability is final at handover, before fieldwork | | Inputs | The [agent-under-test profile](/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope) and the standard's requirement and control list | | Output | A Statement of Applicability signed off by the auditor, and an agreed standard version, timeline, and way of working | AIUC-1's requirements are organized under six principles, and the set is updated each quarter; the current list is on the [standard](/evidence/index) page. Each requirement is mandatory or optional, and comes with core controls (what organizations should implement to pass) and supplemental controls (opted into at the organization's discretion). Each requirement is tagged with the agent capabilities it applies to, such as "universal" or "code-generation". **1. Start from the baseline** All mandatory requirements and their core controls apply by default. Where a core control is not demonstrated, the client can submit alternative evidence showing how the requirement is met, subject to the auditor's assessment. **2. Scope out only where the capability is absent** A mandatory requirement can only be excluded when the agent genuinely lacks the capability it is tagged with, never to reduce audit effort. This is what gives the certificate the same meaning across auditors. Each exclusion carries a one to two sentence justification. **3. Opt in to optional requirements and supplemental controls** Organizations opt in to showcase strengths beyond the baseline, or to meet buyer or regulatory demands. Opted-in items strengthen the report but are not required to pass. Opt-ins can be revised during [evidence collection](/auditors/deliver-and-certify/evidence-collection) until the evidence pack is handed over. **4. Agree the standard version, timeline, and ways of working** Confirm which version of AIUC-1 the audit runs against (see below), the evidence platform (for example, Drata, Vanta, Fieldguide, or the auditor's own), the cadence of syncs, the fieldwork dates, and whether a preliminary review of specific controls is useful. **5. Sign off** The auditor signs off the Statement of Applicability. It is the definitive list of requirements and controls the audit tests, it is documented in the audit record, and it drives the audit report, which covers exactly the requirements it lists. Exclusions are documented and opted-in items are given visibility. > **Which version of the standard to audit against** > > AIUC-1 is updated quarterly, with releases on January 15, April 15, July 15, and October 15. Audits run against the latest version, with a grace period of up to 30 days so organizations can prepare against a constant version. For example, the January 15 version can be selected until May 15; after that, the April 15 version must be used. > > The version is fixed when the engagement starts, at kickoff and scoping, and stays constant through fieldwork and the report. Always advise clients to use the latest version as soon as it is published. See the [changelog](/changelog) for what changed in each release. > **How exclusions appear in the audit report** > > An approved exclusion produces an N/A verdict. Every scoped-out mandatory requirement is explicitly documented in the audit record. If evidence during fieldwork suggests the capability does exist, raise it with AIUC rather than leaving the N/A in place. > **[Scoping methodology](/scoping)** > > The full scoping methodology, including the developer versus deployer distinction. > **[The standard](/evidence/index)** > > The full requirement and control list, downloadable from the AIUC-1 website. > [!TIP] > > **Output.** A Statement of Applicability signed off by the auditor, with a justification against every exclusion, and an agreed standard version, timeline, and way of working. *** > **[Next: Evidence collection](/auditors/deliver-and-certify/evidence-collection)** > > The client gathers evidence for every requirement in scope. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Introduce and scope AIUC-1 Source: https://standard.aiuc-1.com/auditors/introduce-and-scope This section covers everything before kickoff: finding the client whose agent needs a certificate, making the case for AIUC-1, and getting to a signed, scheduled engagement. > [!NOTE] > > **Certification is per agent.** AIUC-1 certifies a specific AI agent. Start with the one that has the most at stake, and expand to more agents once the first is complete. ## The process **1. Identify the right client** Filter for agents with real blast radius, capability or obligation, and clients already asking about AI assurance. [Open step →](/auditors/introduce-and-scope/identify-the-right-client) **2. Introduce AIUC-1** Show the gap existing frameworks leave, and why clients buy. [Open step →](/auditors/introduce-and-scope/introduce-aiuc-1) **3. Request a gap assessment** Score the client against AIUC-1 from public evidence to justify the engagement. [Open step →](/auditors/introduce-and-scope/request-a-gap-assessment) **4. Scope and price** Align on timeline and ownership, understand certification scope, and request pricing. [Open step →](/auditors/introduce-and-scope/scope-and-price) **5. Schedule delivery** Request a certification slot. [Open step →](/auditors/introduce-and-scope/schedule-delivery) *** > **[Next: Identify the right client](/auditors/introduce-and-scope/identify-the-right-client)** > > Filter for the agents worth certifying. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Identify the right client Source: https://standard.aiuc-1.com/auditors/introduce-and-scope/identify-the-right-client AIUC-1 certifies a specific agentic product or deployment. This requires qualifying both the right client, and the right agent for certification. ## The right client > **AI builder** > > The client builds AI agents and sells them to enterprises, whose security reviews now ask how those agents are tested. > > *Example: an AI customer support vendor whose enterprise prospects send security questionnaires with an AI risk section.* > **Enterprise builder** > > The client builds its own AI agents and is developing an AI safety, security, or governance program to oversee them. > > *Example: a bank rolling out a customer-facing agent while its security team stands up an AI governance program.* For certified examples of each client type, see [Case studies](/auditors/case-studies). > [!TIP] > > **Watch for an inbound ask.** Either type of client may raise AI assurance with the auditor directly, often while scoping ISO 42001 or SOC 2 work. For example, a client preparing its ISO 42001 audit asks how to show its customer-facing agent is safe. ## The right agent > **Blast radius** > > The agent is externally facing, so the company's reputation and responsibility are on the line when it fails. > > *Example: a customer-facing support agent answering thousands of end users a day.* > **Capability** > > The agent handles sensitive data or takes actions through connected tools, which puts the company's compliance posture at stake. > > *Example: an agent that updates CRM records or processes payments.* > **Obligation** > > The agent operates in a regulated area, where a failure can trigger regulatory action. > > *Example: a recruitment agent classified as high-risk under the EU AI Act, or a finance agent in scope for a SOX audit.* *** > **[Next: Introduce AIUC-1](/auditors/introduce-and-scope/introduce-aiuc-1)** > > The gap in existing frameworks, and why clients buy. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Introduce AIUC-1 Source: https://standard.aiuc-1.com/auditors/introduce-and-scope/introduce-aiuc-1 Every client already holds frameworks for how AI systems are built and governed. None of them test what the agent actually does once it's live. | Risk area | Existing frameworks | Evidence collected | | - | - | - | | **Technical:** how AI systems behave in production | None | Technical evaluation results | | **Build:** how AI systems are designed and secured | NIST AI RMF, OWASP Top Ten, MITRE ATLAS, CSA AICM | Production code, configuration and logs | | **Policy:** how AI systems are governed | ISO 42001, EU AI Act | Policies, commercial terms and internal practices | AIUC-1 is comprehensive, auditable, technically grounded, and updated quarterly. It is shaped quarter by quarter through the [AIUC-1 Consortium](https://www.aiuc-1.com/consortium), which unites CISOs, GRC leaders, practitioners, and academics from leading organizations around the world. The standard covers six principles, each broken into the sub-risks the evaluations target. > **Data & privacy** > > IP infringement, personal data leakage, business data leakage > **Security** > > System information disclosure, unauthorized actions, insecure outputs, insecure actions > **Safety** > > Physical harm, emotional harm, inappropriate content, high-risk domain engagement, vulnerable user engagement > **Reliability** > > Service disruption, hallucination, incorrect tool calls > **Accountability** > > Transparency > **Society** > > Cyber ## Why the client is buying ### A certification that is technically grounded AIUC-1 requires independent technical testing that the safeguards hold in production. Across a sample of 85,000 graded evaluations run between February 2025 and August 2026, ordinary requests produced a finding 22.0% of the time against 2.9% of the time for adversarial attacks. Agents fail in everyday use far more often than under direct attack. What certification quantifies, by agent type: | Agent type | Highest finding rates | | - | - | | Chatbot | Hallucination 8.9%, scope and output format 8.2%, incorrect tool calls 6.6%, system info disclosure 6.2% | | Automation | Extraction accuracy 15.8%, incorrect tool calls 7.9%, data and privacy leakage 2.8% | | Coding | Insecure outputs and disclosure 12.9%, hallucination 8.0%, unauthorized actions 6.3%, IP infringement and data leakage 5.9% | Certification delivers this as a quantified risk exposure alongside a 60-page audit report, against 65 mandatory controls, over a 10-week process run by one of 7 accredited auditors. > "Most certifications prove what you already do. This one made the product better: the testing produced new guardrails, and we can show customers exactly what improved." > > Sheron Chakalakal, Head of GRC, UiPath ### It's the perfect complement to ISO 42001 Roughly 30% of AIUC-1 controls are already covered by existing ISO 42001 evidence through the published crosswalks, so a certificate accelerates the engagement rather than duplicating it. ISO 42001 certifies the AI management system, meaning governance processes at the organizational level. AIUC-1 certifies the agent itself, by testing it. A client who has been through ISO 42001 has already decided AI assurance is worth paying for, and gap assessments at ISO 42001-certified companies typically open with the large majority of requirements already met or likely met. > **[Full ISO 42001 mapping](/crosswalks/iso-42001)** > > How AIUC-1 requirements map to ISO 42001 controls, and where existing ISO 42001 evidence carries over. ### A go-to-market asset To unblock deals: 46% of companies see sales delayed without a security certification, and 73% of buyers accept an audit report in place of a security questionnaire. One AIUC-1 report answers the AI risk section of every subsequent review instead of a fresh questionnaire each time a buyer asks. Intercom's Fin reps raised the certification unprompted in 22 enterprise sales calls since December, and on one major asset manager's vendor review the AIUC-1 report covered 40 to 50% of the required testing scope. To lead the category: every certification ships with a co-marketing package, including a serialized badge, a co-branded blogpost, and coordinated distribution to the Consortium audience. Lovable's certification announcement became its CEO's top LinkedIn post in two months at 3x his usual engagement, drawing 3,000 engagements from 2,500 people across 11 launch posts. In the first three weeks, 5 enterprise accounts asked about AIUC-1, 2 of them citing it as a differentiator against a competitor, and GRC leaders at 4 major security brands reached out. ## Best follow-up assets What to send after the introduction, depending on what the client asks for next. > **[AIUC-1 introduction deck](https://www.papermark.com/view/cmuxcrtt30005kx049loncsag)** > > Send after the first conversation. The client-facing overview: the gap in existing frameworks, quantified risk by agent type, cost and services, and case studies. > **[AIUC-1 requirements and controls](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit)** > > Send when the client wants to see what they will be audited against. All 50 requirements across the six principles, each with its controls and typical evidence. View only, and copying it starts a readiness assessment. > **[Sanitized audit report](https://docs.google.com/document/d/1wX2L36wEL70cfv-VaRm2MFKk3zHEvZdipG1HA5KJLjM/edit)** > > Send when the client wants to see the deliverable. The full report structure with client detail removed. > **[Certifications and case studies](/auditors/case-studies)** > > Send when the client asks who has already certified. Recent certifications and case studies, grouped by client type, so the closest match is easy to find. > **[Request additional resources](https://docs.google.com/forms/d/e/1FAIpQLSd-2Mx3GzZHHsHBaMRH3nJjUsB2i5WcD_KgB41eFv5_i_5Heg/viewform?usp=header)** > > Link to form *** > **[Next: Request a gap assessment](/auditors/introduce-and-scope/request-a-gap-assessment)** > > Score the client against AIUC-1 before anything is priced. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Request a gap assessment Source: https://standard.aiuc-1.com/auditors/introduce-and-scope/request-a-gap-assessment An outside-in gap assessment scores a company against the AIUC-1 requirements using only evidence the company has published, plus anything handed over directly. It sorts every requirement into one of three buckets. > **Met** > > Requirements that already have public evidence. > **Likely met** > > Requirements plausibly covered, but unproven. > **To be verified** > > Requirements that still need to be verified. It gives the client a concrete reason for the next meeting, it names the gaps that justify the engagement, and it shows the delivery lift before any proposal. > **[Request a gap assessment](https://docs.google.com/forms/d/e/1FAIpQLScPdIJS_LZ_ahOr5UbiSnFkdhar6FutLahJeW-62GZUornz5Q/viewform?usp=header)** > > Link to form *** > **[Next: Scope and price](/auditors/introduce-and-scope/scope-and-price)** > > Align on timeline and ownership, then request the certification fee. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Schedule certification Source: https://standard.aiuc-1.com/auditors/introduce-and-scope/schedule-delivery Submit a scheduling request through the form below. AIUC will return a proposed kickoff date. This date is subject to change based on when an agreement is finalized with the client. Once booked, reference [Deliver and certify](/auditors/deliver-and-certify) for details around running the audit. > **[Book a certification slot](https://docs.google.com/forms/d/e/1FAIpQLSfnHz46vWYeyHVlGraeER_koj8vvRmDzBDJ5nUUgItHMuviWA/viewform?usp=header)** > > Link to form *** > **[Next: Deliver and certify](/auditors/deliver-and-certify)** > > Run the audit, from scoping to certificate. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Scope and price Source: https://standard.aiuc-1.com/auditors/introduce-and-scope/scope-and-price ## Align on scope Agree what happens, when, what the client receives, and who owns it. Kickoff to certificate takes about ten weeks. | Phase | Timing | What happens | Deliverable | Owner | | - | - | - | - | - | | [Scoping](/auditors/deliver-and-certify/scoping) | Weeks 1 to 2 | Decide which AI systems are certified, what the evals will test, and which AIUC-1 requirements apply | Agent-under-test profile, signed evaluation specification, and Statement of Applicability | Client and AIUC, auditor signs off | | [Evidence collection](/auditors/deliver-and-certify/evidence-collection) | Weeks 1 to 6 | Gather evidence for every in-scope requirement | Evidence pack on a shared platform, with auditor access | Client, supported by AIUC | | [Technical evaluations](/auditors/deliver-and-certify/evals) | Weeks 2 to 8 | Test the agent across benign, social engineering, and adversarial scenarios, with a second round only where Round 1 surfaces P0 or P1 findings | Final evaluation results with no open P0 or P1 findings | AIUC, client remediates | | [Fieldwork](/auditors/deliver-and-certify/fieldwork) | Weeks 8 to 10 | Review the evidence per requirement, walk through it with the client, and issue a verdict per requirement | Verdict per requirement, closing meeting, and target certification date | Auditor | | [Audit report and certification](/auditors/deliver-and-certify/audit-report-and-certification) | Weeks 10 to 12 | Finalize the report on the AIUC-1 template with a certification recommendation, then issue the certificate | Final audit report and AIUC-1 certificate | Auditor, then AIUC | | [Maintaining certification](/auditors/deliver-and-certify/maintaining-certification) | Quarterly and annually | Quarterly evals and an annual re-certification audit | Updated evaluation results each quarter, updated report and certificate each year | AIUC and auditor | > [!NOTE] > > Kickoff is signature plus 8 weeks, and the certification period is 12 months. ## Price it ### How pricing works The AIUC certification fee is driven by the scope of the certification and the complexity of the technical evaluations. Price is calculated based on three factors: agent complexity, capabilities and blast radius, and technical set-up provided. The AIUC fee is calculated and delivered to the client separate from that of the auditor fee. Auditors have the freedom to determine their own fee based on the scope of work. ### What drives the price > **Agent complexity** > > The number of use cases and workflows the agent covers. A support agent handling refunds, billing and account changes needs more evaluations than one answering FAQs. > **Capabilities and blast radius** > > What the agent can access and act on. Agents that talk to customers, handle sensitive data or take actions like issuing refunds trigger more controls. > **Technical set-up provided** > > How easily AIUC can reach the agent to test it. A programmatic interface and sandbox access with realistic data keep testing fast. ### Identify the agents in scope The form below gives the AIUC team the ability to properly scope the complexity of the agent and resources required to run technical evaluations to the AIUC-1 quality bar. > **[Request pricing](https://docs.google.com/forms/d/e/1FAIpQLScyqZfQfvDf6kJNeqhFDeRWTyW5MgXoC4HFzV-yaGhAicZTzg/viewform?usp=header)** > > Link to form *** > **[Next: Schedule delivery](/auditors/introduce-and-scope/schedule-delivery)** > > Reserve delivery capacity once the client signs. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 changelog Source: https://standard.aiuc-1.com/changelog/index AIUC-1 is updated formally each quarter to ensure that the standard evolves as technology, risk, and regulation evolves. The most recent version of AIUC-1 was released on October 15, 2026. The next version of AIUC-1 will be released on January 15, 2027. ## October 15, 2026 release This update focused on governing open-weight model deployments, expanding third-party testing requirements, and providing guidance around agent developers and deployers. This quarter's refresh led to 5 new requirements, 5 new controls and 3 retired requirements. ### Overview of key updates * **Open-weight model deployments:** New controls governing the verification, testing and evaluation of open-weight models before deployment. * **Expanded third-party testing:** New comprehensive third-party testing requirements per AIUC-1 principle, paired with the release of a public incident database, and a risk and attack taxonomy informing the scope of third-party testing conducted. * **Developer and deployer responsibilities:** Guidance on how AIUC-1 controls are typically met by the developer and deployer of the agent platform, developed by working group with Consortium members from ElevenLabs, McKinsey, PwC, Noma Security, Datavant, Commerzbank, Veeam Software and more. ### Detailed changelog | Date | AIUC-1 requirement and control | Category | Change notes | | - | - | - | - | | Q4 2026 | A009: Third-party testing for data & privacy risk | New addition | Added new mandatory requirement for third-party testing of data & privacy risk across the AIUC-1 principle, with a new control (A009.1) requiring a third-party evaluation report | | Q4 2026 | E018: Third-party testing for accountability risk | New addition | Added new mandatory requirement for third-party testing of accountability risk across the AIUC-1 principle, with a new control (E018.1) requiring a third-party evaluation report | | Q4 2026 | B001: Third-party testing for security risk | Revision | Renamed from third-party testing of adversarial robustness to third-party testing for security risk, broadening scope to cover security risk as defined in the AIUC-1 risk taxonomy | | Q4 2026 | C002.4 Documentation: Open-weight model change regression testing | Addition | Added new supplemental control for regression-testing open-weight model changes before deployment, such as after fine-tuning, quantization, or inference engine updates | | Q4 2026 | C010: Third-party testing for safety risk | Revision | Renamed from third-party testing for harmful outputs to third-party testing for safety risk, broadening scope to cover safety risk as defined in the AIUC-1 risk taxonomy | | Q4 2026 | C011: \[Retired] Third-party testing for out-of-scope outputs | Retired | Retired third-party testing for out-of-scope outputs; scope folded into the broader third-party testing for safety risk requirement (C010) | | Q4 2026 | C012: \[Retired] Third-party testing for customer-defined risk | Retired | Retired third-party testing for customer-defined risk; scope folded into the broader third-party testing for safety risk requirement (C010) | | Q4 2026 | D002: \[Retired] Third-party testing for hallucinations | Retired | Retired third-party testing for hallucinations; scope folded into the broader third-party testing for reliability risk requirement (D004) | | Q4 2026 | D003.4 Config: Human-approval workflows | Specification | Elevated requiring human approval for sensitive tool operations from a supplemental to a core control to address risks posed by browser agents that can transact, delete, or change settings in real accounts | | Q4 2026 | D004: Third-party testing for reliability risk | Revision | Renamed from third-party testing of tool calls to third-party testing for reliability risk, broadening scope to cover reliability risk as defined in the AIUC-1 risk taxonomy | | Q4 2026 | E006: Conduct vendor and model due diligence | Clarification | Renamed from conduct vendor due diligence to conduct vendor and model due diligence, clarifying that due diligence extends to model provenance and source | | Q4 2026 | E006.2 Documentation: Open-weight model source, integrity and licence verification | Addition | Added new supplemental control for verifying the source, integrity, and licence of an open-weight model before use | | Q4 2026 | E007: \[Retired] Document system change approvals | Clarification | Standardized the retired-requirement description to match the format used for other retired and merged requirements | | Q4 2026 | E014: \[Retired] Share transparency reports | Clarification | Standardized the retired-requirement description to match the format used for other retired and merged requirements | | Q4 2026 | E016.1 Demonstration: AI disclosure | Revision | Consolidated five separate disclosure controls (text, voice, labelling, automation, and reactive disclosure) into one combined control covering disclosure across all applicable modalities | | Q4 2026 | F001.3 Documentation: Cyber capability assessment for modified models | Addition | Added new supplemental control for assessing and mitigating cyber misuse capabilities after modifying an open-weight model | ### Detailed side-by-side comparison Detailed comparisons of current and previous AIUC-1 standards are available on [GitHub](https://github.com/aiunderwriting/AIUC-1-Changelog). ### Standard history | Version | Link to changelog | | - | - | | July 15, 2026 | [See changes here](/changelog/2026-07-15) | | April 15, 2026 | [See changes here](/changelog/2026-04-15) | | January 15, 2026 | [See changes here](/changelog/2026-01-15) | | October 1, 2025 | [See changes here](/changelog/2025-10-01) | | July 22, 2025 | First launch of the standard | ### Tenets that guide the standard update * **Customer-focused.** We prioritize requirements that enterprise customers demand and vendors can pragmatically meet, increasing confidence without adding unnecessary compliance. * **AI-focused.** We do not cover non-AI risks that are addressed in frameworks or regulations like SOC 2, ISO 27001, or GDPR. * **Insurance-enabling.** We prioritize risks that lead to direct harms and financial losses. * **Adapts to regulation.** We update AIUC-1 to make it easier to comply with new regulations. * **Adapts to AI progress.** We update AIUC-1 to keep up with new capabilities, like reasoning capabilities and new modalities. * **Adapts to the threat landscape.** We update AIUC-1 in response to real-world incidents. * **Continuous improvement.** We regularly update the standard based on real-world deployment experience and stakeholder feedback. * **Predictability.** We review the standard and push updates quarterly, on January 15, April 15, July 15, and October 15 of each year. * **Transparency.** We keep a public changelog and share our lessons. * **Backward compatibility.** Existing certifications remain valid during transition periods. ### Provide input on AIUC-1 We welcome feedback, ideas, suggestions, and criticism. [Provide input on AIUC-1](/learn/contribute). 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × Cisco AI Security & Safety Framework Source: https://standard.aiuc-1.com/crosswalks/cisco-ai-security-safety-framework Cisco's AI Security Framework offers one of the most comprehensive pictures of today's AI threat landscape: providing a unified taxonomy of AI threats, by identifying 19 attacker objectives with 150+ subtechniques.**AIUC-1 operationalizes this framework with requirements that enterprise customers demand and vendors can pragmatically meet, supported by underlying controls.** Certification against AIUC-1: ## Cisco AI Security & Safety Framework crosswalks by attacker objective | Attacker objective | Description | Relevant AIUC-1 requirements | | - | - | - | | AITech-1.1: Direct Prompt Injection | Actors provide malicious instructions (via prompt) to override, bypass, alter, or subvert the output of a LLM/agent's system instructions, guardrails, or intended behavior. The injected prompt manipulates the model's context to execute attacker-controlled instructions instead of following its original programming, but preserves the intent of the input. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs) | | AITech-1.2: Indirect Prompt Injection | Actors embed malicious instructions in external data sources (such as web pages, documents, emails, databases, API responses) that the LLM or the agent retrieves and processes, causing hidden instructions to be executed without the user's knowledge or awareness. The attack exploits the model's inability to distinguish between trusted system instructions and untrusted external content. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-1.3: Goal Manipulation | Actors gain access to LLM/agent systems, functions, data, or resources without proper authorization through exploitation of authentication weaknesses, access control bypasses, or privilege boundaries. This includes both gaining initial unauthorized access and accessing restricted capabilities within a legitimately accessed system. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | AITech-1.4: Multi-Modal Injection and Manipulation | Actors deliberately insert, alter, or create malicious content across various modalities (such as text, image, audio, video, or sensor streams) to influence, corrupt, or exploit an AI system's fusion, interpretation, or decision-making processes. Attacks exploit the integration points where different data types are combined. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities) | | AITech-2.1: Jailbreak | Actors employ adversarial technique that circumvents or defeats a model's safety guardrails, content filters, or usage restrictions, enabling output generation that violates the system's policies or intended constraints. The resulting harm comes from whatever guardrail was circumvented: for example, causing the system to violate its operators' policies, bypass safety guardrails and result in unsafe output. In a multi-agent system, jailbreaks can become more complex. Jailbreak prompts could be ingested by one agent while designed to target another agent downstream or parts of the jailbreak could be generated as part of multiple agent interactions after an initial trigger payload. These multi-agent jailbreak prompts will likely present differently than standard jailbreak attacks that are a single prompt or multi-turn interaction with a single chatbot. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs) | | AITech-3.1: Masquerading / Obfuscation / Impersonation | Actors introduce a malicious agent that impersonates a legitimate agent, user, system, or authority within a multi-agent ecosystem and causes other agents, systems, or users to accept it as authentic and trust its communications or actions. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-4.1: Agent Injection | Actors manipulate an agent system to introduce or executive unauthorized agent instances, malicious agent code, or fake agent capabilities by inserting misleading data, exploiting registration mechanisms, or subverting agent deployment processes. This results in unauthorized agents operating within the system or legitimate agents executing malicious code. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-4.2: Context Boundary Attacks | Actors manipulate contextual information that an agent sees, processes, or transmits by exploiting unclear or porous boundaries between different context segments (such as descriptions, prompts, tool outputs, memory, or status messages). An agent may misinterpret the source, trustworthiness, or intent of information. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs) | | AITech-4.3: Protocol Manipulation | Actors exploit assumptions or ambiguities in structured communication protocols (e.g., JSON, XML, YAML, API specifications, custom schemas) used for agentic communication by introducing adversarial inputs that corrupt parsing, processing, or interpretation. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities) | | AITech-5.1: Memory System Persistence | Actors insert poisoned, harmful, or adversarial data or instructions into an agent or model's short-term or long-term memory to corrupt its behavior over extended periods of time. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input) | | AITech-5.2: Configuration Persistence | Actor subverts an agent's internal configuration, settings, or initialization parameters to create lasting malicious influence over its behavior. This goes beyond a single, isolated prompt injection by modifying the system's core settings, context, or memory that defines its behavior. An example is modifying MCP configuration to include a malicious server or inserting malicious instructions into an integrated development environment's internal config files. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls) | | AITech-6.1: Training Data Poisoning | Actors insert malicious, inaccurate, or corrupted data into a model's training pipeline, with the aim of distorting the model's outputs, embedding payload, degrading performance, or introducing systematic biases. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | AITech-7.1: Reasoning Corruption | Actors subvert a model/agent's planning, decision-making, or logical inference processes to produce unintended or harmful outcomes. As AI agents are increasingly trusted with autonomous actions, this attack targets the agent's "reasoning engine" i.e, the core mechanisms for analysis, judgment, and action selection. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | AITech-7.2: Memory System Corruption | Actors inject false, malicious, or adversarial data into an AI agent's memory systems to cause immediate harmful decisions, corruption of system functionality or degraded performance. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | AITech-7.3: Data Source Abuse and Manipulation | Actors inject malicious, misleading, or poisoned data into external data sources (APIs, databases, RAG systems) that AI systems consume in order to manipulate model behavior, corrupt decision-making, or inject malicious instructions through trusted data channels. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-7.4: Token Manipulation | Actors misuse, poison, or tamper with tokens used by model/agentic systems (e.g., model-specific tokens, or security tokens) to control access, encode information, or manage interactions. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | | AITech-8.1: Membership Inference | Actors determine whether a specific data point, record, or individual was included in a model's training dataset, exposing sensitive information about training data subjects, reveal proprietary datasets, or indicate the presence of confidential information in model training. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[B009: Limit output over-exposure](/security/limit-output-over-exposure) | | AITech-8.2: Data Exfiltration / Exposure | Actors intentionally or unintentionally cause sensitive information to be exposed through model outputs, API responses, or system behaviors. This includes leakage of personal data, intellectual property, proprietary algorithms, training data, system internals, or other confidential information to unauthorized parties. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | AITech-8.3: Information Disclosure | Actors trigger the unintentional or unauthorized exposure, leakage, or sharing of data, model parameters, or system details to parties who should not have access to them. The disclosure occurs through model behaviors, responses, or system interactions that reveal more information than intended. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | | AITech-8.4: Prompt/Meta Extraction | Actors extract, reveal, or reconstruct the system prompts, meta-prompts, hidden instructions, initial context, or operational directives that define a model/agent's behavior, constraints, and capabilities. This can expose intellectual property, security mechanisms, and operational logic. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | AITech-9.1: Model or Agentic System Manipulation | Actor coerces or manipulates a model/agent into producing false, misleading or malicious outputs through adversarial inputs, context manipulation, or exploiting model behaviors, without directly modifying the model itself. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-9.2: Detection Evasion | Actors manipulate or alter the input data, behaviors, or attack patterns to intentionally bypass security monitoring, content moderation, anomaly detection, and safety mechanisms. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input) | | AITech-9.3: Dependency / Plugin Compromise | Actors insert malicious code, backdoors, or vulnerabilities into third-party dependencies, plugins, extensions, or libraries used by models/agents/AI applications, creating supply chain attacks that affect all systems using the compromised component. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-10.1: Model Extraction | Actors attempt to reconstruct or replicate a model partially or entirely by interacting with it through its APIs, inference endpoints, or other access points, with the goal of replicating its functionality, architecture, parameters, or outputs without authorized access. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | AITech-10.2: Model Inversion | Actors reconstructs private training data, sensitive features, or confidential information from a trained model by exploiting the model's learned representations, decision boundaries, or output patterns. | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B009: Limit output over-exposure](/security/limit-output-over-exposure) | | AITech-11.1: Environment-Aware Evasion | Actors manipulate the model by exploiting aspects of its operational context, or "environment," to induce malicious or unintended behavior. Rather than simply altering a user's prompt, this type of attack crafts input to leverage the system's broader state and external interactions to bypass safety measures. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | AITech-11.2: Model-Selective Evasion | Actors craft prompts or inputs specifically designed to bypass the safety controls, content filters, or detection mechanisms of a particular target LLM, while similar or related models would successfully detect and refuse the malicious input. This technique exploits model-specific quirks, training differences, and implementation variations. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[E015: Log AI system activity](/accountability/log-model-activity) | | AITech-12.1: Tool Exploitation | Actors abuse connected tools, APIs, functions, or external capabilities through subversive prompts, commands, or context manipulation. This can include attacks like: unauthorized tool execution, exploitation of security vulnerabilities in tools, tool poisoning, injection attacks through tool interfaces. | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-12.2: Insecure Output Handling | Actors exploit insufficient sanitization, validation, filtering, or security controls applied to content generated by models or agents before it is passed to downstream systems, databases, APIs, or components. This inadequate handling enables injection attacks, code execution, or broader system compromise. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | AITech-13.1: Disruption of Availability | Actors prevent authorized users from accessing or using AI models, agents, or their services through resource exhaustion, system degradation, or complete service outage. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy) | | AITech-13.2: Cost Harvesting / Repurposing | Actors leverage computational or memory attacks that exploit AI systems to generate excessive costs for the service provider or owner through resource abuse, unauthorized usage for attacker benefit, or deliberate cost inflation. Examples can include overwhelming human-in-the-loop processes and other denial of service conditions. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | AITech-14.1: Unauthorized Access | Actors gain unauthorized access to the underlying infrastructure, deployment environment, or hosting systems of AI models and agents (e.g., servers, databases, cloud accounts). This is distinct from accessing the model/agentic system itself through exploitation. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | AITech-14.2: Abuse of Delegated Authority | Actors exploit legitimate delegation mechanisms where agents are granted authority to act on behalf of users, systems, or other agents, and use this delegated authority to perform unauthorized actions, exceed intended scope, or abuse trust relationships for malicious purposes. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | | AITech-15.1: Harmful Content | Actors prompt generative models or agents to produce unauthorized, unsafe, or malicious content, including harmful instructions, toxic speech, misinformation, or unsafe media. The attack targets weaknesses in content guardrails to bypass safety constraints and generate content that should otherwise be restricted. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations) | | AITech-16.1: Eavesdropping | Actors conduct unauthorized passive monitoring, interception, or extraction of data from model/agentic system communications, including agent-to-agent messages, agent-to-user interactions, API calls, or other internal communications without directly manipulating the data flow. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[E015: Log AI system activity](/accountability/log-model-activity) | | AITech-17.1: Sensor Spoofing | Actors use of highly-realistic but deceptive signals or manipulating sensor data to deliberately mislead an AI system and its decision-making processes through falsified sensory inputs. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | | AITech-18.1: Fraudulent Use | Actors leverage models/agents specifically for generating, executing, scaling, or automating fraud, scams, deception, and other illegal activities. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | | AITech-18.2: Malicious Workflows | Actors leverage AI models to generate, execute, and scale harmful activities like cyberattacks, data theft, and disinformation campaigns. among other deceptive purposes. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E015: Log AI system activity](/accountability/log-model-activity)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | | AITech-19.1: Cross-Modal Inconsistency Exploits | Actors exploit contradictions, mismatches, or inconsistencies between different data modalities (i.e., text, image, audio, video) to confuse AI systems, bypass security controls, evade detection, or manipulate decision-making by presenting conflicting information across modalities that the system cannot properly reconcile. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | AITech-19.2: Fusion Payload Split | Actors exploit weaknesses in fusion algorithms, arbitration logic, and decision-making processes to manipulate final system behavior. Combining payload components delivered through different inputs, outputs, or sources (including data sources, multiple models, or agents) and using the system’s fusion or arbitration mechanisms to assemble them to create an injection or attack payload. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness) | Last updated March 27, 2026. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × CSA AICM Source: https://standard.aiuc-1.com/crosswalks/csa-aicm The Cloud Security Alliance's AI Controls Matrix provides a security controls framework specifically designed for AI/ML systems.**AIUC-1 aligns with CSA AICM.** Certification against AIUC-1: ## CSA AICM crosswalks by control | CSA AICM control | CSA AICM description | Relevant AIUC-1 requirements | Gap analysis | | - | - | - | - | | A\&A-01: Audit and Assurance Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain audit and assurance policies and procedures and standards. Review and update the policies and procedures at least annually or upon significant changes. | [E008: Review internal processes](/accountability/review-internal-processes) | **Partial Gap.** AIUC-1 is less prescriptive, e.g., does not require audit policies | | A\&A-02: Independent Assessments | Conduct independent audit and assurance assessments according to relevant standards at least annually. | [E008: Review internal processes](/accountability/review-internal-processes)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | **Full Gap.** AIUC-1 does not require external audits | | A\&A-03: Risk Based Planning Assessment | Perform independent audit and assurance assessments in response to signifianct changes or emerging risks and according to risk-based plans and policies. | [E008: Review internal processes](/accountability/review-internal-processes) | **Full Gap.** AIUC-1 does not require external audits | | A\&A-04: Requirements Compliance | Verify compliance with all relevant standards, regulations, legal/contractual, and statutory requirements applicable to the audit. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | No Gap | | A\&A-05: Audit Management Process | Define and implement an Audit Management process aligned with global audting standards, to support audit planning, risk analysis, security control assessment, conclusion, remediation schedules, report generation, and review of past reports and supporting evidence. | [E008: Review internal processes](/accountability/review-internal-processes)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 requirement is smaller in scope | | A\&A-06: Remediation | Establish, document, approve, communicate, apply, evaluate and maintain a risk-based corrective action plan to remediate audit findings, regularly review and report remediation status to relevant stakeholders. | [E008: Review internal processes](/accountability/review-internal-processes)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | AIS-01: Application and Interface Security Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for application security. Review and update the policies and procedures at least annually or after significant system changes. | [E004: Assign accountability](/accountability/assign-accountability)[E013: Implement quality management system](/accountability/implement-quality-management-system)[E008: Review internal processes](/accountability/review-internal-processes)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals) | No Gap | | AIS-02: Application Security Baseline Requirements | Establish, document and maintain baseline requirements for securing applications. | [E008: Review internal processes](/accountability/review-internal-processes)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 does not require documented baseline security requirements for all AI applications | | AIS-03: Application Security Metrics | Define and implement technical and operational metrics in alignment with business objectives, security requirements, and compliance obligations. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 does not require specific metrics | | AIS-04: Secure Application Development Lifecycle | Define and implement a software development lifecycle (SDLC) process for application requirements analysis, planning, design, development, testing, deployment, and operation in accordance with security requirements defined by the organization. | [E004: Assign accountability](/accountability/assign-accountability)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | AIS-05: Application Security Testing | Implement a testing strategy, including criteria for acceptance of new information systems, upgrades and new versions, which provides application security assurance and maintains compliance while meeting organizational delivery goals. Automate when applicable and possible. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | No Gap | | AIS-06: Secure Application Deployment | Establish and implement strategies and capabilities for secure, standardized, and compliant application deployment. Automate where possible. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | No Gap | | AIS-07: Application Vulnerability Remediation | Define and implement a process to remediate application security vulnerabilities, automating remediation when possible. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities) | **Partial Gap.** AIUC-1 vulnerability remediation requirements are focused on testing procedures | | AIS-08: Input Validation | Validate, filter, modify or block, as necessary, input against adversarial patterns, failure patterns and unwanted behaviour according to organisational policies and applicable laws and regulations. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | No Gap | | AIS-09: Output Validation | Validate, filter, modify or block, as necessary, output against adversarial patterns, failure patterns and unwanted behaviour according to organisational policies and applicable laws and regulations. | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B009: Limit output over-exposure](/security/limit-output-over-exposure) | No Gap | | AIS-10: API Security | Define and implement processes, procedures, and technical measures to secure APIs. Review and update for any improvements at least annually or after significant system changes. | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[B002: Detect adversarial input](/security/detect-adversarial-input) | No Gap | | AIS-11: Agents Security Boundaries | Establish security boundaries for agents. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | No Gap | | AIS-12: Source Code Management | Implement source code management practices, such as version control, code review & static code analysis, aligning with the SDLC process. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | No Gap | | AIS-13: AI Sandboxing | Implement sandboxing techniques to execute AI tools and plugins in isolated environments to prevent unintended interactions with critical systems or data and limit the possibility of lateral movement. | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | **Partial Gap.** AIUC-1 does not require sandboxing techniques specifically, but require alternative safeguards | | AIS-14: AI Cache Protection | Implement security measures to protect caches in GenAI systems and services. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 does not have specific controls for cache protection, but require system protection | | AIS-15: Prompt Differentiation | Implement mechanisms enabling the model to clearly distinguish user-provided input instructions from data and system instructions (e.g., system prompts). | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | **Full Gap.** Not covered in AIUC-1 | | BCR-01: Business Continuity Management Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain business continuity management and operational resilience policies and procedures.Review and update the policies and procedures at least annually, or when significant changes occur that could impact risk exposure. | [E008: Review internal processes](/accountability/review-internal-processes) | **Full Gap.** Not covered specifically in AIUC-1 | | BCR-02: Risk Assessment and Impact Analysis | Determine the impact of business disruptions and risks to establish criteria for developing business continuity and operational resilience strategies and capabilities.Review and update the risk assessment and impact analysis at least annually or upon significant changes. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | BCR-03: Business Continuity Strategy | Establish strategies to reduce the impact of business disruptions, and improve resiliency and recovery from business disruptions. | | **Full Gap.** Not covered specifically in AIUC-1 | | BCR-04: Business Continuity Planning | Establish, document, approve, communicate, apply, evaluate and maintaina business continuity plan based on the results of the operational resiliencestrategies and capabilities. | | **Full Gap.** Not covered specifically in AIUC-1 | | BCR-05: Documentation | Develop, identify, and acquire documentation, both internally and from external parties, that is relevant to support the business continuity and operational resilience programs. Make the documentation available to authorized stakeholders and review at least annually or upon significant changes. | | **Full Gap.** Not covered specifically in AIUC-1 | | BCR-06: Business Continuity Exercises | Follow a structured approach to evaluate the effectiveness of the business continuity and operational resilience plans at planned intervals or upon significant changes. | | **Full Gap.** Not covered specifically in AIUC-1 | | BCR-07: Communication | Establish and maintain communication channels with all relevant stakeholders in the course of business continuity and resilience procedures. | | **Full Gap.** Not covered specifically in AIUC-1 | | BCR-08: Backup | Periodically perform backups. Ensure the confidentiality, integrity and availability of the backup, and verify restoration from backup for resiliency. | | **Full Gap.** Outside the scope of AIUC-1 | | BCR-09: Disaster Response Plan | Establish, document, approve, communicate, apply, evaluate and maintaina disaster response plan to recover from natural and man-made disasters. Updatethe plan at least annually or upon significant changes. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | **Full Gap.** Outside the scope of AIUC-1 | | BCR-10: Response Plan Exercise | Exercise the disaster response plan annually or upon significantchanges, including, if possible, participation of local emergency authorities. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | **Partial Gap.** AIUC-1 does not require exercises | | BCR-11: Equipment Redundancy | Supplement business-critical equipment with both locally redundant and geographically dispersed equipment located at a reasonable minimum distance in accordance with applicable industry standards. | | **Full Gap.** Outside the scope of AIUC-1 | | CCC-01: Change Management Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for managing the risks associated with applying changes to assets owned, controlled or used by the organization. Review and update the policies and procedures at least annually, or upon significant changes. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E004: Assign accountability](/accountability/assign-accountability) | **Partial Gap.** AIUC-1 change management requirement is narrower in scope and limited to high-risk AI systems | | CCC-02: Quality Testing | Establish, maintain and implement a defined quality change control, approval and testing process incorporating baselines, testing, and release standards. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 is focused on safety, security and reliability testing and does not have product quality in scope specifically | | CCC-03: Change Management Technology | Implement a change management procedure to manage the risks associated with applying changes to assets owned, controlled or used by the organization. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E004: Assign accountability](/accountability/assign-accountability)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | No Gap | | CCC-04: Change Authorization | Implement and enforce a procedure to authorize addition, removal, update, and management of assets, owned, controlled or used by the organization. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals) | No Gap | | CCC-05: Change Agreements | Include provisions limiting changes directly impacting customer ownedenvironments/tenants to explicitly authorized requests within service level agreements. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E004: Assign accountability](/accountability/assign-accountability) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope - does not refer to SLAs specifically | | CCC-06: Change Management Baseline | Establish change management baselines for all relevant authorized changes on organization assets. Review and update the change management baseline at least annually or upon significant changes. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals) | **Full Gap.** Not covered specifically in AIUC-1 | | CCC-07: Detection of Baseline Deviation | Implement detection measures with proactive notification in case of changes deviating from the established baseline. | | **Full Gap.** Not covered specifically in AIUC-1 | | CCC-08: Exception Management | Implement a procedure for the management of exceptions, including emergencies, in the change and configuration process. Align the procedure withthe requirements of GRC-04: Policy Exception Process. | | **Full Gap.** Not covered specifically in AIUC-1 | | CCC-09: Change Restoration | Define and implement a process to proactively roll back changes to a previous known good state in case of errors or security concerns. | [E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | CEK-01: Encryption and Key Management Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for Cryptography, Encryption and Key Management. Review and update the policies and procedures at least annually or upon significant changes. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-02: CEK Roles and Responsibilities | Define and implement cryptographic, encryption and key managementroles and responsibilities. | [E004: Assign accountability](/accountability/assign-accountability) | No Gap | | CEK-03: Data Encryption | Provide data protection at-rest, in-transit and, where applicable, in-use by using cryptographic libraries certified to approved standards. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | No Gap | | CEK-04: Encryption Algorithm | Utilize encryption algorithms following industry standards for protecting data, based on the data classification and associated risks. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-05: Encryption Change Management | Establish a standard change management procedure, to accommodatechanges from internal and external sources, for review, approval, implementationand communication of cryptographic, encryption and key management technologychanges. | | No Gap | | CEK-06: Encryption Change Cost Benefit Analysis | Manage and adopt changes to cryptography-, encryption-, and key management-relatedsystems (including policies and procedures) that fully account for downstreameffects of proposed changes, including residual risk, cost, and benefits analysis. | | **Full Gap.** Outside the scope of AIUC-1 | | CEK-07: Encryption Risk Management | Establish and maintain an encryption and key management risk programthat includes provisions for risk assessment, risk treatment, risk context,monitoring, and feedback. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | **Partial Gap.** AIUC-1 requirement is less prescriptive and at a higher level | | CEK-08: Customer Key Management Capability | Providers must provide the capability for customers to manage their own data encryption keys. | | **Full Gap.** Outside the scope of AIUC-1 | | CEK-09: Encryption and Key Management Audit | Audit encryption and key management systems, policies, and processeswith a frequency that is proportional to the risk exposure of the system withaudit occurring preferably continuously but at least annually and after anysecurity event(s). | [E008: Review internal processes](/accountability/review-internal-processes) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-10: Key Generation | Generate Cryptographic keys using industry accepted cryptographiclibraries specifying the algorithm strength and the random number generatorused. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-11: Key Purpose | Manage cryptographic secret and private keys that are provisionedfor a unique purpose. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-12: Key Rotation | Rotate cryptographic keys in accordance with the calculated cryptoperiod,which includes provisions for considering the risk of information disclosureand legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-13: Key Revocation | Define, implement and evaluate processes, procedures and technicalmeasures to revoke and remove cryptographic keys prior to the end of its establishedcryptoperiod, when a key is compromised, or an entity is no longer part of theorganization, which include provisions for legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-14: Key Destruction | Define, implement, and evaluate processes, procedures, and technical measures to securely destroy cryptographic keys when they are no longer needed, which include provisions for legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-15: Key Activation | Define, implement and evaluate processes, procedures and technicalmeasures to create keys in a pre-activated state when they have been generatedbut not authorized for use, which include provisions for legal and regulatoryrequirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-16: Key Suspension | Define, implement and evaluate processes, procedures and technicalmeasures to monitor, review and approve key transitions from any state to/fromsuspension, which include provisions for legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-17: Key Deactivation | Define, implement and evaluate processes, procedures and technicalmeasures to deactivate keys at the time of their expiration date, which includeprovisions for legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-18: Key Archival | Define, implement and evaluate processes, procedures and technicalmeasures to manage archived keys in a secure repository requiring least privilegeaccess, which include provisions for legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-19: Key Compromise | Define, implement and evaluate processes, procedures and technicalmeasures to use compromised keys to encrypt information only in controlled circumstance,and thereafter exclusively for decrypting data and never for encrypting data,which include provisions for legal and regulatory requirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-20: Key Recovery | Define, implement and evaluate processes, procedures and technicalmeasures to assess the risk to operational continuity versus the risk of thekeying material and the information it protects being exposed if control ofthe keying material is lost, which include provisions for legal and regulatoryrequirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | CEK-21: Key Inventory Management | Define, implement and evaluate processes, procedures and technicalmeasures in order for the key management system to track and report all cryptographic materials and changes in status, which include provisions for legal and regulatoryrequirements. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | DCS-01: Off-Site Equipment Disposal Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for the secure disposal of equipment used outside the organization's premises. If the equipment is not physically destroyed a data destruction procedure that renders recovery of information impossible must be applied. Review and update the policies and procedures at least annually, or upon significant changes. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | **Full Gap.** Outside the scope of AIUC-1 | | DCS-02: Off-Site Transfer Authorization Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for the relocation or transfer of hardware, software,or data/information to an offsite or alternate location. The relocation or transferrequest requires the written or cryptographically verifiable authorization.Review and update the policies and procedures at least annually, or upon significant changes. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-03: Secure Area Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for maintaining a safe and secure working environmentin offices, rooms, and facilities. Review and update the policies and proceduresat least annually, or upon significant changes. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-04: Secure Media Transportation Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for the secure transportation of physical media. Review and update the policies and procedures at least annually, or upon significant changes. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-05: Assets Classification | Classify and document the physical, and logical assets (e.g., applications)based on the organizational business risk. Review and update the assets’ classification at least annually or upon significant changes. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-06: Assets Cataloguing and Tracking | Catalogue and track all relevant physical and logical assets locatedat all of the service providers sites within a secured system. Review and update the catalogue at least annually or upon significant changes. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-07: Controlled Physical Access Points | Design and implement physical security perimeters to safeguard personnel, data, and information systems. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-08: Equipment Identification | Use equipment identification as a method for connection authentication. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-09: Secure Area Authorization | Allow only authorized personnel access to secure areas, with allingress and egress points restricted, documented, and monitored by physicalaccess control mechanisms. Retain access control records on a periodic basisas deemed appropriate by the organization. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-10: Surveillance System | Implement, maintain, and operate datacenter surveillance systems at the external perimeter and at all the ingress and egress points to detect unauthorized ingress and egress attempts. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-11: Adverse Event Response Training | Train datacenter personnel to safely manage adverse events, including but not limited to unauthorized ingress and egress attempts. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-12: Cabling Security | Define, implement and evaluate processes, procedures and technical measures that ensure a risk-based protection of power and telecommunication cables from a threat of interception, interference or damage at all facilities, offices and rooms. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-13: Environmental Systems | Implement and maintain data center environmental control systems that monitor, maintain and test for continual effectiveness the temperatureand humidity conditions within accepted industry standards. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-14: Secure Utilities | Secure, monitor, maintain, and test utilities services for continualeffectiveness at planned intervals. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DCS-15: Equipment Location | Keep business-critical equipment away from locations subject to high probability for environmental risk events. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | Full Gap | | DSP-01: Security and Privacy Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the classification, protection, preparation and handling of data throughout its lifecycle, and according to all applicable laws and regulations,standards, and risk level. Review and update the policies and procedures atleast annually. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | DSP-02: Secure Disposal | Apply industry accepted methods for the secure disposal of data from storage media such that data is not recoverable by any forensic means. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | DSP-03: Data Inventory | Create and maintain a data inventory, at least for any sensitive, regulated and personal data. Review and update the inventory at least annually or upon significant changes. | | **Full Gap.** Not covered specifically in AIUC-1 | | DSP-04: Data Classification | Classify data according to its type and sensitivity level. | | **Full Gap.** Not covered specifically in AIUC-1 | | DSP-05: Data Flow Documentation | Create data flow documentation to identify what data is processed, stored or transmitted where. Review data flow documentation at defined intervals, at least annually, and after any change. | | **Full Gap.** Not covered specifically in AIUC-1 | | DSP-06: Data Ownership and Stewardship | Document ownership and stewardship of all relevant documented personal and sensitive data. Perform review at least annually. | | **Full Gap.** Not covered specifically in AIUC-1 | | DSP-07: Data Protection by Design and Default | Develop systems, products, and business practices based upon a principle of security by design and industry best practices. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | No Gap | | DSP-08: Data Privacy by Design and Default | Develop systems, products, and business practices based upon a principle of privacy by design and industry best practices. Ensure that systems' privacy settings are configured by default, according to all applicable laws and regulations. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[A002: Establish output data policy](/data-and-privacy/define-output-rights)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | DSP-09: Data Protection Impact Assessment | Conduct a Data Protection Impact Assessment (DPIA) to evaluate the origin, nature, particularity and severity of the risks upon the processing of personal data, according to any applicable laws, regulations and industrybest practices. | [E008: Review internal processes](/accountability/review-internal-processes)[E013: Implement quality management system](/accountability/implement-quality-management-system)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | DSP-10: Sensitive Data Transfer | Define, implement and evaluate processes, procedures and technical measures that ensure any transfer of personal or sensitive data is protected from unauthorized access and only processed within scope as permitted by the respective laws and regulations. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | No Gap | | DSP-11: Personal Data Access, Reversal, Rectification and Deletion | Define and implement, processes, procedures and technical measures to enable data subjects to request access to, modification, or deletion of their personal data, according to any applicable laws and regulations. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | No Gap | | DSP-12: Limitation of Purpose in Personal Data Processing | Define, implement and evaluate processes, procedures and technical measures to ensure that personal data is processed according to any applicable laws and regulations and for the purposes declared to the data subject. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets) | No Gap | | DSP-13: Personal Data Sub-processing | Define, implement and evaluate processes, procedures and technical measures for the transfer and sub-processing of personal data within the service supply chain, according to any applicable laws and regulations. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[E011: Record processing locations](/accountability/record-processing-locations)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | No Gap | | DSP-14: Disclosure of Data Sub-processors | Define, implement and evaluate processes, procedures and technical measures to disclose the details of any personal or sensitive data access by sub-processors to the data owner prior to initiation of that processing. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | No Gap | | DSP-15: Limitation of Production Data Use | Obtain authorization from data owners, and manage associated riskbefore replicating or using production data in non-production environments. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | No Gap | | DSP-16: Data Retention and Deletion | Data retention, archiving and deletion is managed in accordance withbusiness requirements, applicable laws and regulations. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets) | No Gap | | DSP-17: Sensitive Data Protection | Define and implement, processes, procedures and technical measuresto protect sensitive data throughout its lifecycle. | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | No Gap | | DSP-18: Disclosure Notification | The providers should implement and describe to customers the procedure to manage and respond to requests for disclosure of Personal Data by Law Enforcement Authorities according to applicable laws and regulations. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | No Gap | | DSP-19: Data Location | Define and implement, processes, procedures and technical measures to specify and document the physical locations of data, including any locations in which data is processed or backed up. | [E011: Record processing locations](/accountability/record-processing-locations) | No Gap | | DSP-20: Data Provenance and Transparency | Define, implement and evaluate processes, procedures and technical measures to: 1) Document and trace data sources, and 2) Make the data source available according to legal and regulatory requirements | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **Partial Gap.** AIUC-1 requirement is focused on model training data specifically | | DSP-21: Data Poisoning Prevention & Detection | Define, implement and evaluate processes, procedures and technical measures to prevent data poisoning in AI models and continuously detect such. | | **No Gap.** AIUC-1 control activities recommend "detecting and removing poisoned or malicious data, validating data integrity and source authenticity." | | DSP-22: Privacy Enhancing Technologies | Use Privacy Enhancing Technologies for training data, informed by risk and privacy impact analysis and business use cases. | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | **Partial Gap.** AIUC-1 does not specifically require Privacy Enhancing Technologies for AI training data | | DSP-23: Data Integrity Check | Regularly validate the consistency and conformity of training, fine-tuning or augmentation data. Implement dataset versioning to ensure traceability and enforce restrictions to prevent unauthorized changes. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | **Partial Gap.** AIUC-1 does not require version control systems for datasets or access restrictions and authorization for training data changes | | DSP-24: Data Differentiation and Relevance | Ensure training-data differentiation and relevance to the intended use of the AI Model. | | **Partial Gap.** AIUC-1 requirements does not specify differentiation specifically | | GRC-01: Governance Program Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for an information governance program, which is sponsored by the leadership of the organization and related to AI systems as well. Review and update the policies and procedures at least annually. | | **Full Gap.** AIUC-1 does not require a governance policy specifically | | GRC-02: Risk Management Program | Establish and maintain a formal, documented, and leadership-sponsored AI Risk Management (AIRM) program that includes policies and procedures for identification, evaluation, ownership, treatment, and acceptance of risks. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E013: Implement quality management system](/accountability/implement-quality-management-system)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | No Gap | | GRC-03: Organizational Policy Reviews | Review all relevant organizational policies and associated proceduresat least annually or when a substantial change occurs within the organization. | [E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | GRC-04: Policy Exception Process | Establish and follow an approved exception process as mandated bythe governance program whenever a deviation from an established policy occurs. | | **Full Gap.** AIUC-1 does not have requirements on policy exceptions specifically | | GRC-05: Information Security Program | Develop and implement an Information Security Program, which includesprograms for all the relevant domains of the AICM. | | **Full Gap.** Not covered specifically in AIUC-1 | | GRC-06: Governance Responsibility Model | Define and document roles and responsibilities for planning, implementing,operating, assessing, and improving governance programs. | [E004: Assign accountability](/accountability/assign-accountability) | **Full Gap.** AIUC-1 requires assigning accountability for system changes, but not governance programs specifically | | GRC-07: Information System Regulatory Mapping | Identify and document all relevant standards, regulations, legal/contractual, and statutory requirements, which are applicable to your organization. Review at least annually or when a substantial change occurs within the organization. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | No Gap | | GRC-08: Special Interest Groups | Establish and maintain contact with related special interest groups and other relevant entities in line with business context. | | **Full Gap.** Outside the scope of AIUC-1 | | GRC-09: Acceptable Use of the AI Service | Define, document and enforce policies and procedures on the acceptable use of AI services offered by the organization. Ensure effectiveness by continuous risk assessments, reviews and human oversight. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | No Gap | | GRC-10: AI Impact Assessment | Establish, document, and communicate to all relevant stakeholders an AI Impact Assessment process and its criteria to regularly evaluate the ethical, societal, operational, legal, and security impacts of the AI system throughout its lifecycle. | [E013: Implement quality management system](/accountability/implement-quality-management-system)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | **Full Gap.** AIUC-1 does not explicitly require AI impact assessments for all AI systems | | GRC-11: Bias and Fairness Assessment | Regularly evaluate AI systems, models, datasets & algorithms for bias and fairness to ensure compliance with ethical standards. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs) | No Gap | | GRC-12: Ethics Committee | Establish an ethics committee to review AI applications, ensuring alignment with ethical standards and organizational values. | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | **Full Gap.** Not covered specifically in AIUC-1 | | GRC-13: Explainability Requirement | Establish, document, and communicate the degree of explainability needed for the AI Services. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **Partial Gap.** AIUC-1 requirement is less prescriptive | | GRC-14: Explainability Evaluation | Evaluate, document, and communicate the degree of explainability of the AI Services, including possible limitations and exceptions. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | No Gap | | GRC-15: Human supervision | Establish, execute, and assess processes, procedures, and technical measures to ensure human oversight and control of the AI system in compliance with regulatory requirements and organizational risk management. | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)[C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | No Gap | | HRS-01: Background Screening Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for background verification of all new employees (includingbut not limited to remote employees, contractors, and third parties) accordingto local laws, regulations, ethics, and contractual constraints and proportionalto the data classification to be accessed, the business requirements, and acceptablerisk. Review and update the policies and procedures at least annually. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-02: Acceptable Use of Technology Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for defining allowances and conditions for the acceptable use of organizationally-owned or managed assets. Review and update the policiesand procedures at least annually. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-03: Clean Desk Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures that require unattended workspaces to not have openlyvisible confidential data. Review and update the policies and procedures atleast annually. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-04: Remote and Home Working Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures to protect information accessed, processed or storedat remote sites and locations. Review and update the policies and proceduresat least annually. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-05: Asset returns | Establish and document procedures for the return of organization-ownedassets by terminated employees. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-06: Employment Termination | Establish, document, and communicate to all personnel the proceduresoutlining the roles and responsibilities concerning changes in employment. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-07: Employment Agreement Process | Employees sign the employee agreement prior to being granted accessto organizational information systems, resources and assets. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-08: Employment Agreement Content | The organization includes within the employment agreements provisionsand/or terms for adherence to established information governance and securitypolicies. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-09: Personnel Roles and Responsibilities | Document and communicate roles and responsibilities of employees,as they relate to information assets and security. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-10: Non-Disclosure Agreements | Identify, document, and review, at planned intervals, requirementsfor non-disclosure/confidentiality agreements reflecting the organization'sneeds for the protection of data and operational details. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | **Full Gap.** Outside the scope of AIUC-1 | | HRS-11: Security Awareness Training | Establish, document, approve, communicate, apply, evaluate and maintain a security awareness training program for all employees of the organization and provide regular training updates. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-12: Personal and Sensitive Data Awareness and Training | Provide employees with access to sensitive organizational and personal data with appropriate security awareness training and regular updates in organizational procedures, processes, and policies relating to their professional function relative to the organization. | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | **Full Gap.** Outside the scope of AIUC-1 | | HRS-13: Compliance User Responsibility | Make employees aware of their roles and responsibilities for maintaining awareness and compliance with established policies and procedures and applicablelegal, statutory, or regulatory compliance obligations. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-14: AI Competency Training | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures defining the AI training program for all relevant personnel of the organization based on their roles and provide regular training updates. | | **Full Gap.** Outside the scope of AIUC-1 | | HRS-15: AI Acceptable Use | Establish, document, and communicate to all personnel the policies and procedures on the acceptable use of AI technologies within the organization. | | **Full Gap.** Outside the scope of AIUC-1 | | I\&S-01: Infrastructure and Virtualization Security Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for infrastructure and virtualization security. Reviewand update the policies and procedures at least annually, or upon significant changes. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-02: Capacity and Resource Planning | Plan and monitor the availability, quality, and adequate capacityof resources in order to deliver the required system performance as determinedby the business. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-03: Network Security | Monitor, encrypt and restrict communications between environmentsto only authenticated and authorized connections, as justified by the business.Review these configurations at least annually, and support them by a documentedjustification of all allowed services, protocols, ports, and compensating controls. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-04: OS Hardening and Base Controls | Harden host and guest OS, hypervisor or infrastructure control planeaccording to their respective best practices, and supported by technical controls,as part of a security baseline. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-05: Production and Non-Production Environments | Separate production and non-production environments. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-06: Segmentation and Segregation | Design, develop, deploy and configure applications and infrastructures such that tenant access is appropriately segmented and segregated, monitored and restricted. | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-07: Migration to Hosted Environments | Use secure and encrypted communication channels when migrating servers, services, applications, or data to hosted environments. Such channels must include only up-to-date and approved protocols. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-08: Network Architecture Documentation | Identify and document high-risk environments. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | I\&S-09: Network Defense | Define, implement and evaluate processes, procedures and defense-in-depthtechniques for protection, detection, and timely response to network-based attacks. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | IAM-01: Identity and Access Management Policy and Procedures | Establish, document, approve, communicate, implement, apply, evaluateand maintain policies and procedures for identity and access management. Reviewand update the policies and procedures at least annually, or upon significant changes. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Partial Gap.** AIUC-1 covers identity and access management procedures but not policy creation and maintenance | | IAM-02: Strong Password Policy and Procedures | Establish, document, approve, communicate, implement, apply, evaluateand maintain strong password policies and procedures. Review and update thepolicies and procedures at least annually. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Full Gap.** Outside the scope of AIUC-1 | | IAM-03: Identity Inventory | Manage, store, and regularly review the inventory of identities, and monitor their level of access. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | IAM-04: Separation of Duties | Employ the separation of duties principle when implementing information system access. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | No Gap | | IAM-05: Least Privilege | Employ the least privilege principle when implementing information system access. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | No Gap | | IAM-06: User Access Provisioning | Define and implement an identity access provisioning process which authorizes, records, and communicates access changes to data and assets. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | No Gap | | IAM-07: User Access Changes and Revocation | De-provision or modify identity access in a timely manner. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | No Gap | | IAM-08: User Access Review | Review and revalidate user access for least privilege and separationof duties with a frequency that is commensurated with organizational risk tolerance and at least annually, or upon significant changes. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | IAM-09: Segregation of Privileged Access Roles | Define, implement and evaluate processes, procedures and technical measures for the segregation of privileged access roles. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-10: Management of Privileged Access Roles | Define and implement an access process to ensure privileged accessroles and rights are granted for a time limited period, and implement procedures to prevent the accumulation of segregated privileged access. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-11: Customers' Approval for Agreed Privileged Access Roles | Define, implement and evaluate processes and procedures for customers to participate, where applicable, in the granting of access for agreed, highrisk (as defined by the organizational risk assessment) privileged access roles. | | **Full Gap.** Outside the scope of AIUC-1 | | IAM-12: Safeguard Logs Integrity | Define, implement and evaluate processes, procedures and technical measures to ensure the logging infrastructure is read-only for all with write access, including privileged access roles, and that the ability to disable it's controlled through a procedure that ensures the segregation of duties and break glass procedures. | | **Full Gap.** Outside the scope of AIUC-1 | | IAM-13: Uniquely Identifiable Users | Define, implement and evaluate processes, procedures and technical measures, that ensure identities’ activities are identifiable through uniquely associated IDs. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-14: Strong Authentication | Define, implement and evaluate processes, procedures and technical measures for authenticating access to systems, application and data assets, including multifactor authentication for at least privileged user and sensitive data access. Adopt digital certificates or alternatives which achieve an equivalent level of security for system identities. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-15: Passwords and Secrets Management | Define, implement and evaluate processes, procedures and technical measures for the secure management of passwords and other secrets. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Full Gap.** Outside the scope of AIUC-1 | | IAM-16: Authorization Mechanisms | Define, implement and evaluate processes, procedures and technicalmeasures to verify access to data and system functions is authorized. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-17: Knowledge Access Control - Need to Know | Define policy and procedure for "need to know" access to knowledge, information and data within the organization and in the context of the AI system to be applied when regulating access to resources. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-18: Output Modification and Special Authorization | When allowing model output modification of AI generated output, establish a role for this access and allow changes only by authorized identities. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | IAM-19: Agent Access Restriction | Restrict agents' access to the tools and plugins necessary for the activity or use case at hand, ensuring adherence to the principles of need-to-know and least privilege. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | No Gap | | IPY-01: Interoperability and Portability Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for interoperability and portability includingrequirements for:a. Communications between application interfacesb. Information processing interoperabilityc. Application development portabilityd. Information/Data exchange, usage, portability, integrity, and persistenceReview and update the policies and procedures at least annually or upon significant changes. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | IPY-02: Application Interface Availability | Provide application interface(s) to AICs so that they programmatically retrieve their data to enable interoperability and portability. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | IPY-03: Secure Interoperability and Portability Management | Implement cryptographically secure and standardized network protocolsfor the management, import and export of data, according to industry standards. | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | IPY-04: Data Portability Contractual Obligations | Agreements must include provisions specifying AICs access to dataupon contract termination and will include:a. Data formatb. Length of time the data will be storedc. Scope of the data retained and made available to the AICsd. Data deletion policy | | **Full Gap.** Outside the scope of AIUC-1 as it does not cover classic cyber security practices | | LOG-01: Logging and Monitoring Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for logging and monitoring. Review and update the policies and procedures at least annually, or upon significant changes. | [E015: Log AI system activity](/accountability/log-model-activity) | **Partial Gap.** AIUC-1 covers logging procedures but not policy creation | | LOG-02: Audit Logs Protection | Define, implement and evaluate processes, procedures and technical measures to ensure the security and retention of audit logs. | | **Partial Gap.** AIUC-1 requirements are focused on PII logs specifically | | LOG-03: Security Monitoring and Alerting | Identify and monitor security-related events within applications, the underlying infrastructure, supply chain, and consider logging other events based on risk evaluation. Define and implement a system to generate alerts to responsible stakeholders based on such events and corresponding metrics. | [E015: Log AI system activity](/accountability/log-model-activity) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | LOG-04: Audit Logs Access and Accountability | Restrict access to audit logs and maintain records of access to logs. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[E015: Log AI system activity](/accountability/log-model-activity) | No Gap | | LOG-05: Audit Logs Monitoring and Response | Monitor security audit logs to detect activity outside of typical or expected patterns. Establish and follow a defined process to review and take appropriate and timely actions on detected anomalies. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[E015: Log AI system activity](/accountability/log-model-activity) | **Partial Gap.** AIUC-1 monitoring covers account information access but not security audit log monitoring for unusual activity across all systems | | LOG-06: Clock Synchronization | Use a reliable time source across all relevant information processing systems. | [E015: Log AI system activity](/accountability/log-model-activity) | **Full Gap.** Not covered specifically in AIUC-1 | | LOG-07: Logging Scope | Establish, document and implement which information meta/data system events should be logged. Review and update the scope at least annually or whenever there is a change in the threat environment. | [E015: Log AI system activity](/accountability/log-model-activity)[E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | LOG-08: Log Records | Generate audit records containing relevant security information. | [E015: Log AI system activity](/accountability/log-model-activity) | No Gap | | LOG-09: Log Protection | Protect audit records from unauthorized access, modification, and deletion. | [E015: Log AI system activity](/accountability/log-model-activity)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | No Gap | | LOG-10: Encryption Monitoring and Reporting | Establish and maintain a monitoring and internal reporting capability over the operations of cryptographic, encryption and key management policies, processes, procedures, and controls. | [E015: Log AI system activity](/accountability/log-model-activity)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | **Partial Gap.** AIUC-1 does not require monitoring of encryption specifically | | LOG-11: Transaction / Activity Logging | Log and monitor key lifecycle management events to enable auditing and reporting on usage of cryptographic keys. | [E015: Log AI system activity](/accountability/log-model-activity) | **Partial Gap.** AIUC-1 does not cover reporting on usage of cryptographic keys specifically | | LOG-12: Access Control Logs | Monitor and log physical access using an auditable access control system. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[E015: Log AI system activity](/accountability/log-model-activity) | **Full Gap.** Outside the scope of AIUC-1 | | LOG-13: Failures and Anomalies Reporting | Define, implement and evaluate processes, procedures and technical measures for the reporting of anomalies and failures of the monitoring system and provide immediate notification to the accountable party. | [E015: Log AI system activity](/accountability/log-model-activity)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | **Full Gap.** AIUC-1 does not require reporting on failures of the monitoring system specifically | | LOG-14: Input Monitoring | Log and monitor all input events (content and metadata) to enable auditing and reporting on the usage of AI models. | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[E015: Log AI system activity](/accountability/log-model-activity)[B002: Detect adversarial input](/security/detect-adversarial-input) | **Partial Gap.** AIUC-1 does not require all input to be logged | | LOG-15: Output Monitoring | Log and monitor all output events (content and metadata) to enable auditing and reporting on usage of AI models. | [E015: Log AI system activity](/accountability/log-model-activity)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs) | No Gap | | MDS-01: Training Pipeline Security | Define, implement, and evaluate policies, procedures, and technical measures that ensure the security of the Training Pipeline. Regularly review and update policies, procedures and technical measures to address new security threats and best practices. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | MDS-02: Model Artifact Scanning | Define, implement, and evaluate policies, procedures, and technical measures for the scanning of model artifacts for vulnerabilities and attacks, at each step of the service lifecycle and at each hand over point. Regularly review and update policies, procedures and technical measures to address model artifact scanning. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** Model scanning is recommended as part of AIUC-1 control activities | | MDS-03: Model Documentation | Define, implement, enforce, approve, document, communicate, maintain and evaluate processes and procedures for model documentation.Regularly review and update the model documentation. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | No Gap | | MDS-04: Model Documentation Requirements | Establish and implement baseline requirements for Model documentation. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | No Gap | | MDS-05: Model Documentation Validation | Define, implement, and evaluate processes, procedures, and technical measures for the validation of the Model documentation aligned with the current model. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **Partial Gap.** AIUC-1 does not require validation specifically | | MDS-06: Adversarial Attack Analysis | Define, implement, and evaluate processes and technical measures to assess adversarial threats specific to each AI model. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations) | No Gap | | MDS-07: Robustness against Adversarial Attack / Model Hardening | Define, implement, and evaluate processes, procedures, and technicalmeasures for Model Hardening to mitigate relevant adversarial attacks as identified in the Threat Analysis and Adversarial Threat Analysis. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations) | No Gap | | MDS-08: Model Integrity Checks | Regularly calculate and compare checksums using cryptographic hashes of model checkpoints to detect unauthorized modifications. Apply at least annually based on the level of risk, or after any change of hands. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | **No Gap.** AIUC-1 control activities recommend verifying model integrity before and during deployment. For example, using cryptographic checksum | | MDS-09: Model Signing/Ownership Verification | Sign models cryptographically and verify signatures to ensure model provenance and ownership, any time the model changes hands or is loaded from storage. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[E004: Assign accountability](/accountability/assign-accountability) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | MDS-10: Model Continuous Monitoring | Define, implement, and evaluate processes, procedures, and technical measures for continuous monitoring of model performance metrics over time to identify sudden shifts or unexpected changes in predictions that could degrade model performance. | [E015: Log AI system activity](/accountability/log-model-activity)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | No Gap | | MDS-11: Model Failure | Perform a risk-based evaluation of the model and model serving infrastructure for model failure.Define and implement measures to mitigate model and model serving infrastructure failures, and regularly evaluate throughout the AI system's lifecycle. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | No Gap | | MDS-12: Open Model Risk Assessment | Establish a process to evaluate risk associated with open models. Periodically review these risk factors, and implement a process to monitor and mitigate any determined vulnerabilities. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | **Partial Gap.** AIUC-1 requires risk evaluation of open models across a number of areas including cyber misuse, catastrophic misuse and IP violations | | MDS-13: Secure Model Format | Adopt secure model formats and processes for AI model serialization where applicable. | | **Full Gap.** AIUC-1 only covers model deployment environment, not the model format itself | | SEF-01: Security Incident Management Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintainpolicies and procedures for Security Incident Management, E-Discovery, and Forensics. Review and update the policies and procedures at least annually or upon significant changes. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E013: Implement quality management system](/accountability/implement-quality-management-system) | No Gap | | SEF-02: Service Management Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the timely management of security incidents. Review and update the policies and procedures at least annually, or upon significant changes. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches) | No Gap | | SEF-03: Incident Response Plans | Establish, document, approve, communicate, apply, evaluate and maintain a security incident response plan, which includes but is not limited to: a communication strategy for notifying relevant internal departments, impacted AICs, and other business critical relationships (such as supply-chain) that may be impacted. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches) | No Gap | | SEF-04: Incident Response Testing | Follow a structured approach to evaluate the effectiveness of incident response plans at planned intervals or upon significant changes. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches) | **Full Gap.** AIUC-1 does not require testing of incident response | | SEF-05: Incident Response Metrics | Establish, monitor and report information security incident metrics. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E015: Log AI system activity](/accountability/log-model-activity) | **Full Gap.** AIUC-1 does not require metrics specifically | | SEF-06: Event Triage Processes | Define, implement and evaluate processes, procedures and technical measures supporting business processes to triage security-related events. | | **Full Gap.** Not covered specifically in AIUC-1 | | SEF-07: Security Breach Notification | Define and implement, processes, procedures and technical measuresfor security breach notifications. Report material security breaches and assumed security breaches including any relevant supply chain breaches, as per applicable SLAs, laws and regulations. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E015: Log AI system activity](/accountability/log-model-activity) | No Gap | | SEF-08: Points of Contact Maintenance | Maintain points of contact for applicable regulation authorities,national and local law enforcement, and other legal jurisdictional authorities. Review and update the points of contact at least annually. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches) | **Partial Gap.** AIUC-1 does not require points of contact for all of the categories mentioned in the control | | SEF-09: Incident Response | Define incident categories and severity levels for AI systems, and determine response procedures for each, including automated response where applicable. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | No Gap | | STA-01: Supply Chain Risk Management Policies and Procedures | Establish, document, approve, communicate, apply, evaluate, and maintain policies and procedures for supply chain risk management. Review and update the policies and procedures at least annually or upon significant changes. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | STA-02: SSRM Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for the application of the Shared Security Responsibility Model (SSRM) within the organization. Review and update the policies and procedures at least annually, or upon significant changes. | | **Full Gap.** Not covered specifically in AIUC-1 | | STA-03: SSRM Supply Chain | Apply, document, implement and manage the SSRM throughout the supply chain. | | **Full Gap.** Not covered specifically in AIUC-1 | | STA-04: SSRM Guidance | Provide SSRM Guidance to the Customer detailing information about theSSRM applicability throughout the supply chain. | | **Full Gap.** Not covered specifically in AIUC-1 | | STA-05: SSRM Control Ownership | Delineate the shared ownership and applicability of all CSA AICM controls according to the SSRM. | | **Full Gap.** Outside the scope of AIUC-1 | | STA-06: SSRM Documentation Review | Review and validate SSRM documentation. | | **Full Gap.** Not covered specifically in AIUC-1 | | STA-07: SSRM Control Implementation | Implement, operate, and audit or assess the portions of the SSRM which the organization is responsible for. | | **Full Gap.** Not covered specifically in AIUC-1 | | STA-08: Supply Chain Inventory | Develop and maintain an inventory of all supply chain relationships. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Full Gap.** Outside the scope of AIUC-1 | | STA-09: Supply Chain Risk Management | Periodically review risk factors associated with supply chain relationships. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | STA-10: Primary Service and Contractual Agreement | Service agreements must incorporate at least the following mutually-agreed upon provisions and/or terms: • Scope, characteristics and location of business relationship and services offered • Information security requirements (including SSRM) • Change management process • Logging and monitoring capability • Incident management and communication procedures • Right to audit and third party assessment • Service termination • Interoperability and portability requirements • Data privacy | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[A002: Establish output data policy](/data-and-privacy/define-output-rights)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs) | **Full Gap.** Outside the scope of AIUC-1 | | STA-11: Supply Chain Agreement Review | Review supply chain agreements at least annually, or upon significant changes. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Full Gap.** Outside the scope of AIUC-1 | | STA-12: Supply Chain Compliance Assessment | Define and implement a process for conducting internal assessments to confirm conformance and effectiveness of standards, policies, procedures, and service level agreement activities at least annually. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Partial Gap.** AIUC-1 does not require annual internal assessments of supply chain compliance | | STA-13: Supply Chain Service Agreement Compliance | Implement policies requiring all service providers throughout the supply chain to comply with information security, confidentiality, access control, privacy, audit, personnel policy and service level requirements and standards. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Full Gap.** Outside the scope of AIUC-1 | | STA-14: Supply Chain Governance Review | Periodically review the organization's supply chain partners' IT governance policies and procedures. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Full Gap.** Outside the scope of AIUC-1 | | STA-15: Supply Chain Data Security Assessment | Define and implement a process for conducting security assessments periodically for all organizations within the supply chain. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | **Full Gap.** Outside the scope of AIUC-1 | | STA-16: Service Bill of Material (BOM) | Define, implement, and enforce a process for establishing a Bill of Material for the service supply chain. Review and update the Bill of Material at least annually or upon significant changes. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **Full Gap.** AIUC-1 does not have a specific BOM requirement, but requires core AI system elements to be documented in other requirements | | TVM-01: Threat and Vulnerability Management Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures to identify, report and prioritize the remediation of vulnerabilities and threats, in order to protect systems against vulnerability exploitation. Review and update the policies and procedures at least annually or upon significant changes. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 requirements focus on adversarial input detection and regular testing of adversarial robustness | | TVM-02: Malware and Malicious Instructions Protection Policy and Procedure | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures to protect against malware and malicious instructions. Review and update the policies and procedures at least annually or upon significant changes. | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[B002: Detect adversarial input](/security/detect-adversarial-input)[E013: Implement quality management system](/accountability/implement-quality-management-system) | No Gap | | TVM-03: Vulnerability Remediation Schedule | Define, implement and evaluate processes, procedures and technical measures to enable both scheduled and emergency responses to vulnerability identifications, based on the identified risk. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | TVM-04: Detection Updates | Define, implement and evaluate processes, procedures and technical measures to update detection tools, threat signatures, and indicators of compromise on a weekly, or more frequent basis. | [B002: Detect adversarial input](/security/detect-adversarial-input) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | TVM-05: External Library Vulnerabilities | Define, implement and evaluate processes, procedures and technical measures to identify updates for applications which use third party or open-source libraries according to the organization's vulnerability management policy. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | TVM-06: Penetration Testing | Define, implement and evaluate processes, procedures and technicalmeasures for the periodic performance of penetration testing by independentthird parties. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | No Gap | | TVM-07: Vulnerability Remediation Schedule | Define, implement and evaluate processes, procedures and technical measures based on identified risks to support scheduled and emergency responses to vulnerability identification. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | TVM-08: Vulnerability Prioritization | Use a risk-based model for effective prioritization of vulnerabilityremediation using an industry recognized framework. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | TVM-09: Vulnerability Management Reporting | Define and implement a process for tracking and reporting vulnerabilityidentification and remediation activities that includes stakeholder notification. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | No Gap | | TVM-10: Vulnerability Management Metrics | Establish, monitor and report metrics for vulnerability identificationand remediation at defined intervals. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | No Gap | | TVM-11: Guardrails | Define and implement processes, procedures and technical measures to apply guardrails to the AI system. Continuously evaluate guardrails for changes in regulatory requirements and risk scenarios. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | No Gap | | TVM-12: Threat Analysis and Modeling | Define implement and evaluate threat analysis process and procedures to identify, assess and review the threat landscape for Cloud and AI systems. Build threat models according to industry best practices to inform the risk mitigation strategy. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | **Partial Gap.** AIUC-1 does not cover cloud systems, but is focused on AI systems specifically | | TVM-13: Threat Response | Use a risk-based method for the prioritization and mitigation of threats, leveraging an industry-recognized framework to guide threat decision-making and protection measures. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | UEM-01: Endpoint Devices Policy and Procedures | Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for all endpoints. Review and update the policies and procedures at least annually or uponsignificant system changes. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | **Partial Gap.** AIUC-1 requirement is smaller in scope | | UEM-02: Application and Service Approval | Define, document, apply and evaluate a list of approved services, applications and sources of applications (stores) acceptable for use by endpoints when accessing or storing organization-managed data. | | **Full Gap.** Outside the scope of AIUC-1 | | UEM-03: Compatibility | Define and implement a process for the validation of the endpoint device's compatibility with operating systems and applications. | | **Full Gap.** Not covered specifically in AIUC-1 | | UEM-04: Endpoint Inventory | Maintain an inventory of all endpoints used to store and process company data. | [E011: Record processing locations](/accountability/record-processing-locations) | **Partial Gap.** Endpoint inventory is not required specifically by AIUC-1 | | UEM-05: Endpoint Management | Define, implement and evaluate processes, procedures and technical measures to enforce policies and controls for all endpoints permitted to acces ssystems and/or store, transmit, or process organizational data. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | **Partial Gap.** AIUC-1 requirement is less prescriptive and smaller in scope | | UEM-06: Automatic Lock Screen | Configure all relevant interactive-use endpoints to require an automaticlock screen. | | **Full Gap.** Outside the scope of AIUC-1 | | UEM-07: Operating Systems | Manage changes to endpoint operating systems, patch levels, and/orapplications through the company's change management processes. | | **Full Gap.** Outside the scope of AIUC-1 | | UEM-08: Storage Encryption | Protect information from unauthorized disclosure on managed endpoint devices with storage encryption. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | No Gap | | UEM-09: Anti-Malware Detection and Prevention | Configure managed endpoints with anti-malware detection and prevention technology and services. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | No Gap | | UEM-10: Software Firewall | Configure managed endpoints with properly configured software firewalls. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | No Gap | | UEM-11: Data Loss Prevention | Configure managed endpoints with Data Loss Prevention (DLP) technologiesand rules in accordance with a risk assessment. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | **Full Gap.** AIUC-1 requirement does not address DLP requirements specifically | | UEM-12: Remote Locate | Enable remote geo-location capabilities for all managed mobile endpoints, according to all applicable laws and regulations. | | **Full Gap.** Outside the scope of AIUC-1 | | UEM-13: Remote Wipe | Define, implement and evaluate processes, procedures and technicalmeasures to enable the deletion of company data remotely on managed endpointdevices. | | **Full Gap.** Outside the scope of AIUC-1 | | UEM-14: Third-Party Endpoint Security Posture | Define, implement and evaluate processes, procedures and technicaland/or contractual measures to maintain proper security of third-party endpointswith access to organizational assets. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | **Partial Gap.** AIUC-1 requires monitoring third-party access and endpoint scraping protection, but does not require specific measures on third-party endpoints | Last updated September 18, 2025. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × EU AI Act Source: https://standard.aiuc-1.com/crosswalks/eu-ai-act The EU Artificial Intelligence Act is an EU regulation classifying AI systems by risk levels (minimal, limited, high, unacceptable) with corresponding compliance obligations.**AIUC-1 operationalizes the EU AI Act by aligning with its requirements.** Certification against AIUC-1 is a strong step towards compliance with the EU AI Act as it: *This crosswalk is provided for informational purposes only and does not constitute legal advice. Sections with no operative analog to AIUC-1 (e.g. addressing definitions, enforcement mechanisms, regulatory infrastructure, and legislative safe harbors) have been omitted from crosswalk mappings.* ## EU AI Act crosswalks by article | EU AI Act article | EU AI Act summary\* | Relevant AIUC-1 requirements | | - | - | - | | Article 9: Risk Management System | The EU AI Act requires a risk management system for high-risk AI systems. This system should be a continuous process throughout the AI's lifecycle, regularly reviewed and updated. It should identify and analyze potential risks to health, safety, or fundamental rights, estimate and evaluate these risks, and adopt measures to manage them. These measures should balance minimizing risks and fulfilling requirements. The system should also ensure that any remaining risk is acceptable and that measures are in place to eliminate or reduce risks as much as possible. High-risk AI systems should be tested to identify the best risk management measures and to ensure they work as intended. The system should also consider whether the AI could negatively impact people under 18 or other vulnerable groups. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 10: Data and Data Governance | This article states that high-risk AI systems must be developed using high-quality data sets for training, validation, and testing. These data sets should be managed properly, considering factors like data collection processes, data preparation, potential biases, and data gaps. The data sets should be relevant, representative, error-free, and complete as much as possible. They should also consider the specific context in which the AI system will be used. In some cases, providers may process special categories of personal data to detect and correct biases, but they must follow strict conditions to protect individuals' rights and freedoms. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 11: Technical Documentation | This EU law states that before a high-risk AI system is launched, detailed technical documentation must be prepared and kept updated. This documentation should prove that the AI system meets the law's requirements and provide clear information for authorities to check compliance. It should include certain key elements. Small businesses, including start-ups, can provide this information in a simpler way. The EU will create a simplified form for this purpose. If a high-risk AI system is related to a product covered by other EU laws, one set of documentation should include all necessary information. The EU can update these requirements as technology advances. | [E011: Record processing locations](/accountability/record-processing-locations)[E017: Document system transparency policy](/accountability/document-system-transparency-policy)[A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 12: Record-Keeping | This article states that high-risk AI systems must have the ability to automatically record events throughout their lifespan. This is to ensure that the system's actions can be traced back, especially in situations where the AI might pose a risk or undergo significant changes. The system should also record details like when it was used, the database it checked data against, the data that matched, and who verified the results. This is to ensure accountability and safety in the use of high-risk AI systems. | [E015: Log AI system activity](/accountability/log-model-activity)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 13: Transparency and Provision of Information to Deployers | This article states that high-risk AI systems must be designed to be transparent, so that those using them can understand and use them correctly. They must come with clear instructions, including information about the provider, the system's capabilities and limitations, and any potential risks. The instructions should also explain how to interpret the system's output, any pre-determined changes to the system, and how to maintain it. If relevant, they should also describe how to collect, store and interpret data logs. | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | | Article 14: Human Oversight | This article states that high-risk AI systems must be designed in a way that allows humans to effectively oversee them. The goal of human oversight is to prevent or minimize risks to health, safety, or fundamental rights that may arise from using these systems. The oversight measures should match the risks and context of the AI system's use. These measures could be built into the system by the provider or implemented by the user. The AI system should be provided in a way that allows the overseer to understand its capabilities and limitations, detect and address issues, avoid over-reliance on the system, interpret its output, decide not to use it, or stop its operation. For certain high-risk AI systems, any action or decision based on the system's identification must be verified by at least two competent individuals. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | | Article 15: Accuracy Robustness and Cybersecurity | The EU AI Act states that high-risk AI systems must be designed to be accurate, robust, and secure. They should perform consistently throughout their lifecycle. The Commission will work with relevant stakeholders to develop ways to measure these qualities. The accuracy of these AI systems should be declared in their instructions. These systems should be resilient to errors and faults, and should have backup plans in place. They should also be designed to reduce the risk of biased outputs. Finally, these systems should be secure against unauthorized third parties trying to exploit their vulnerabilities. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | Article 16: Obligations of Providers of High-Risk AI Systems | This article states that companies providing high-risk AI systems must follow certain rules. They must make sure their AI systems meet specific standards and display their contact information on the product or its packaging. They need to have a quality management system and keep certain documents and logs. Before selling or using the AI system, they must have it checked for compliance with regulations. They also need to mark the product with a CE marking to show it meets EU standards. They must register the product, fix any issues, provide necessary information, and prove it meets standards if asked by authorities. The AI system must also be accessible according to EU directives. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 17: Quality Management System | The EU AI Act requires providers of high-risk AI systems to establish a quality management system. This system must be documented and include strategies for regulatory compliance, design and development procedures, testing and validation processes, technical specifications, data management systems, risk management, post-market monitoring, incident reporting, communication procedures, record-keeping, resource management, and an accountability framework. The implementation of these aspects should be proportionate to the size of the provider's organization. Providers already subject to quality management obligations under relevant Union law can include these aspects in their existing systems. Financial institutions can meet these requirements by complying with Union financial services law. | [E004: Assign accountability](/accountability/assign-accountability)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 18: Documentation Keeping | This article states that providers of high-risk AI systems must keep certain documents for 10 years after the system is released. These documents include technical documentation, quality management system documentation, approved changes, decisions from notified bodies, and the EU declaration of conformity. If the provider goes bankrupt or stops its activities before the 10 years are up, each EU member state will decide how to keep these documents available. Financial institutions that are providers must keep the technical documentation as part of their documentation under Union financial services law. | [E004: Assign accountability](/accountability/assign-accountability)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 19: Automatically Generated Logs | This article states that companies providing high-risk AI systems must keep automatically generated logs of these systems, as long as they have control over these logs. These logs must be kept for at least six months, or longer if required by EU or national laws, especially those related to personal data protection. If the provider is a financial institution, they must keep these logs as part of their documentation under financial services law. | [E015: Log AI system activity](/accountability/log-model-activity)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 20: Corrective Actions and Duty of Information | This article states that if a company providing a high-risk AI system realizes that their system is not following the rules set by the EU, they must immediately fix the issue, stop using it, or recall it. They must also inform anyone involved in distributing or using the system. If the system poses a risk, the company must investigate why and inform the authorities responsible for monitoring the AI market. They must also inform any organization that certified the system, detailing what went wrong and what they did to fix it. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | | Article 21: Cooperation with Competent Authorities | This article states that companies providing high-risk AI systems must, when asked by a relevant authority, provide all the information needed to show that their AI system meets the required standards. This information must be in a language that the authority can easily understand. If asked, these companies must also allow the authority to access automatically generated logs of the AI system, as long as they control these logs. Any information obtained by the authority must be treated confidentially. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 22: Authorised Representatives of Providers of High-Risk AI Systems | This article states that before launching high-risk AI systems in the EU, providers from non-EU countries must appoint a representative within the EU. This representative is responsible for ensuring that the AI system complies with EU regulations, keeping records for 10 years, providing necessary information to authorities, cooperating with authorities in managing risks, and ensuring registration obligations are met. If the provider fails to meet its obligations, the representative can terminate the agreement and must inform the relevant authorities. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 23: Obligations of Importers | This article states that before selling a high-risk AI system, importers must ensure it meets all regulations. This includes checking that the system has passed the necessary assessments, has the correct documentation, and is marked with the CE symbol. If the importer suspects the system doesn't meet regulations or has fake documentation, they must not sell it until it complies. Importers must also provide their contact details on the system or its packaging, ensure it's stored and transported safely, and keep a record of its certification and instructions for 10 years. They must also cooperate with authorities if needed. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | | Article 24: Obligations of Distributors | This article states that before selling a high-risk AI system, distributors must ensure it meets certain standards, including having a CE marking and a copy of the EU declaration of conformity. If the distributor believes the AI system doesn't meet these standards, they can't sell it until it does. They also need to ensure that the AI system remains compliant during storage or transport. If a sold AI system is found to be non-compliant, the distributor must correct it, withdraw it, or recall it. They must also cooperate with authorities and provide any requested information about the AI system. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | | Article 25: Responsibilities Along the AI Value Chain | This article states that anyone who distributes, imports, deploys, or modifies a high-risk AI system is considered a provider of that system and must follow certain regulations. This includes putting their name on an existing system, making significant changes to a system, or altering the purpose of a system to make it high-risk. The original provider of the system must cooperate with the new provider and provide necessary information and technical access. However, this doesn't apply if the original provider specified that their system shouldn't be changed into a high-risk system. The article also states that the manufacturer of a product that includes a high-risk AI system is considered the provider of that system. Finally, the provider of a high-risk AI system and any third party that supplies components for that system must agree in writing on the necessary information and technical access. This doesn't apply to third parties that provide tools or components under a free and open-source license. The AI Office may develop voluntary contract terms for these situations. The article also emphasizes the need to protect intellectual property rights and trade secrets. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 26: Obligations of Deployers of High-Risk AI Systems | This article outlines the responsibilities of those who deploy high-risk AI systems. These include using the systems as per instructions, assigning human oversight, ensuring input data is relevant, and monitoring the system's operation. If a risk is identified, the provider and relevant authorities must be informed immediately. Deployers must also keep logs generated by the AI system for at least six months. Before using a high-risk AI system, workers must be informed. If the system is not registered in the EU database, it should not be used. Deployers must also comply with data protection assessments and cooperate with relevant authorities. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 27: Fundamental Rights Impact Assessment for High-Risk AI Systems | Before using a high-risk AI system, public bodies and private entities providing public services must assess how the system could impact people's fundamental rights. This includes describing how and when the system will be used, who it might affect, and what risks it might pose. They also need to outline how humans will oversee the system and what steps will be taken if risks materialize. This assessment must be done for the first use of the system, but can be updated if necessary. The results must be reported to the market surveillance authority, unless exempt. The AI Office will provide a template to help with this process. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | | Article 43: Conformity Assessment | This article discusses the process of assessing whether high-risk AI systems meet certain standards. If a provider has used certain standards in creating their AI system, they must choose one of two assessment procedures. If the provider hasn't used these standards, or only used part of them, they must follow a specific assessment procedure. If the AI system is for law enforcement or immigration authorities, a market surveillance authority will act as the assessment body. The article also states that if an AI system is significantly modified, it must undergo a new assessment. The Commission can update these procedures as technology advances. | [E008: Review internal processes](/accountability/review-internal-processes)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 44: Certificates | This article states that certificates for AI systems must be written in a language that can be easily understood by the relevant authorities in the country where the certificate is issued. These certificates are valid for up to five years for certain AI systems, and four years for others. They can be extended upon request, but only after a re-assessment. If an AI system no longer meets the necessary requirements, the certificate can be suspended or withdrawn, unless the provider takes corrective action. There must also be an appeal process for decisions made about these certificates. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 46: Derogation from Conformity Assessment Procedure | This article allows for exceptions to the usual approval process for high-risk AI systems. If there's a justified reason, such as public safety or environmental protection, a market surveillance authority can allow these systems to be used for a limited time while they're being assessed. In urgent situations, law enforcement or civil protection authorities can use these systems without prior approval, as long as they request it soon after. If approval is denied, the system must be stopped and its results discarded. The EU Commission and other member states must be informed of any approvals, and if no objections are raised within 15 days, the approval is considered justified. If objections are raised, the Commission will consult with the relevant parties and decide if the approval is justified. If it's not, the approval must be withdrawn. | | | Article 47: EU Declaration of Conformity | The EU AI Act requires providers of high-risk AI systems to create a written declaration of conformity for each system. This document, which can be physical or electronic, must be kept available for national authorities for 10 years after the system is launched. The declaration must identify the AI system and confirm that it meets certain requirements. It must also be translated into a language that the authorities can understand. If the AI system is subject to other EU laws, a single declaration covering all applicable laws is required. The provider is responsible for ensuring the declaration is kept up-to-date. The Commission can update the declaration's content as needed. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 48: CE Marking | This article states that the CE marking, which shows a product meets EU safety standards, must be clearly visible on high-risk AI systems. If it can't be physically placed on the system, it should be on the packaging or documentation. For digital AI systems, a digital CE marking should be easily accessible. If a notified body (an organization that checks the product meets the standards) is involved, their identification number should be included next to the CE marking. If the AI system is also subject to other EU laws requiring a CE marking, the marking indicates it meets those requirements too. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 49: Registration | This article states that before any high-risk AI system is launched or used, the provider or their representative must register themselves and their system in the EU database. This also applies to AI systems that the provider has determined are not high-risk. Public authorities or institutions using high-risk AI systems must also register themselves and the system's use in the EU database. Certain high-risk AI systems used in law enforcement, migration, and border control must be registered in a secure, non-public section of the EU database. Only the Commission and national authorities can access this section. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems | This article states that companies must inform users when they are interacting with an AI system, unless it's obvious or the AI is used for legal purposes like crime detection. AI systems that create synthetic content (like deepfakes) must mark their outputs as artificially generated. Companies must also inform users when they use AI for emotion recognition or biometric categorisation, unless it's for legal purposes. If an AI system creates or alters content, the company must disclose this, unless it's for legal purposes or the content is artistic or satirical. The AI Office will help create guidelines for detecting and labelling artificially generated content. | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | | Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems | The EU AI Act requires providers of high-risk AI systems to establish a post-market monitoring system. This system should collect and analyze data on the performance of these AI systems throughout their lifetime, ensuring they continue to comply with regulations. The monitoring system should be based on a plan that is part of the technical documentation. The EU Commission will provide a template for this plan. If a monitoring system is already in place under other legislation, providers can integrate the necessary elements from this new requirement, as long as it provides the same level of protection. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[B002: Detect adversarial input](/security/detect-adversarial-input)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Article 73: Reporting of Serious Incidents | This article states that companies who provide high-risk AI systems must report any serious incidents to the authorities in the country where the incident occurred. They must do this as soon as they know there's a link between their AI system and the incident, or if there's a good chance there is a link. They must report within 15 days of finding out about the incident. If the incident is very serious or widespread, they must report it within two days. If someone dies, they must report it within 10 days. They can submit an initial incomplete report if needed, but must follow up with a full report. They must also investigate the incident and work with authorities. The authorities will then take appropriate action within seven days. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[E013: Implement quality management system](/accountability/implement-quality-management-system) | * Summaries are created by a third party ([artificialintelligenceact.eu](https://artificialintelligenceact.eu/)). Review the [official content of the EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) for the most up-to-date information. Last updated July 22, 2025. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × IBM AI Risk Atlas Source: https://standard.aiuc-1.com/crosswalks/ibm-ai-risk-atlas The IBM Risk Atlas is a comprehensive taxonomy of risks associated with ML models, GenAI, and AI Agents.**AIUC-1 integrates IBM Research's AI Risk Atlas, where IBM Research is a technical contributor to AIUC-1.** Certification against AIUC-1: ## IBM AI Risk Atlas crosswalks by risk | Risk | Description | Relevant AIUC-1 requirements | | - | - | - | | IBM 1: Agentic AI - Unexplainable and untraceable actions | Explanations, lineage and trace information, and source attribution for AI agent actions might be difficult, imprecise or unobtainable. | [E015: Log AI system activity](/accountability/log-model-activity) | | IBM 2: Agentic AI - Sharing IP/PI/confidential information with user | AI agents with unrestricted access to resources or databases or tools could potentially store and share PI/IP/confidential information with system users when performing their actions. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | | IBM 3: Agentic AI - Sharing IP/PI/confidential information with tools | AI agents with unrestricted access to resources or databases or tools could potentially store and share PI/IP/confidential information with other tools or agents when performing their actions. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | IBM 4: Agentic AI - Over- or under-reliance on AI agents | Reliance, that is the willingness to accept an AI agent behavior, depends on how much a user trusts that agent and what they are using it for. Over-reliance occurs when a user puts too much trust in an AI agent, accepting an AI agent's behavior even when it is likely undesired. Under-reliance is the opposite, where the user doesn't trust the AI agent but should. Increasing autonomy of AI agents and the possibility of opaqueness and open-endedness increase the variability and visibility of agent behavior leading to difficulty in calibrating trust and possibly contributing to both over- and under-reliance. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations) | | IBM 5: Agentic AI - Misaligned actions | AI agents can take actions that are not aligned with relevant human values, ethical considerations, guidelines and policies. Misaligned actions can occur in different ways such as: Applying learned goals inappropriately to new or unforeseen situations. Using AI agents for a purpose/goals that are beyond their intended use. Selecting resources or tools in a biased way. Using deceptive tactics to achieve the goal. Compromising on AI agent values to work with another AI agent or tool to accomplish the task. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | IBM 6: Agentic AI - Attack on AI agents’ external resources | Attackers intentionally create vulnerabilities or exploit existing vulnerabilities in external resources (tools/database/applications/services/other agents) that AI agents rely on to execute their intended actions or to achieve their goals. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | IBM 7: Agentic AI - Unauthorized use | If attackers can gain access to the AI agent and its components, they can perform actions that can have different levels of harm depending on the agent's capabilities and information it has access to. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | | IBM 8: Agentic AI - Exploit trust mismatch | Attackers might initiate injection attacks to bypass the trust boundary, which is a distinct point or conceptual line where the level of trust in a system, application or network changes. Background execution in multi-agent environments increases the risk of covert channels if input/output validation is weak. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls) | | IBM 9: Agentic AI - Function calling hallucination | AI agents might make mistakes when generating function calls (calls to tools to execute actions). Those function calls might result in incorrect, unnecessary or harmful actions. | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | IBM 10: Agentic AI - Redundant actions | AI agents can execute actions that are not needed for achieving the goal. In an extreme case, AI agents might enter a cycle of executing the same actions repeatedly without any progress. | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | | IBM 11: Agentic AI - Incomplete AI agent evaluation | Evaluating the performance or accuracy or an agent is difficult because of system complexity and open-endedness. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | IBM 12: Agentic AI - Mitigation and maintenance | The large number of components and dependencies that agent systems have complicates keeping them up to date and correcting problems. | [E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | IBM 13: Agentic AI - Lack of AI agent transparency | Lack of AI agent transparency is due to insufficient documentation of the AI agent design, development, evaluation process, absence of insights into the inner workings of the AI agent, and interaction with other agents/tools/resources. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E015: Log AI system activity](/accountability/log-model-activity) | | IBM 14: Agentic AI - Reproducibility | Replicating agent behavior or output can be impacted by changes or updates made to external services and tools. This impact is increased if the agent is built with generative AI. | [E015: Log AI system activity](/accountability/log-model-activity) | | IBM 15: Agentic AI - Accountability of AI agent actions | Assigning responsibility for an action taken by an agentic AI system is difficult due to the complexity of agents and the number of external resources, tools or agents they interact with. | [E004: Assign accountability](/accountability/assign-accountability)[E015: Log AI system activity](/accountability/log-model-activity) | | IBM 16: Agentic AI - AI agent compliance | Determining AI agents' compliance is complex and there might not be enough information to assess whether the agentic AI system is compliant with applicable legal requirements. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | IBM 17: Agentic AI - Discriminatory actions | AI agents can take actions where one group of humans is unfairly advantaged over another due to the decisions of the model. This may be caused by AI agents' biased actions that impact the world, in the resources consulted, and in the resource selection process. For example, an AI agent can generate code that can be biased. | | | IBM 18: Agentic AI - Introduce data bias | Specific actions taken by the AI agent, such as modifying a dataset or a database, can introduce bias in the resource that gets used by others or by itself to take actions. | | | IBM 19: Agentic AI - Impact on human dignity | If human workers perceive AI agents as being better at doing the job of the human, the human can experience a decline in their self-worth and wellbeing. | | | IBM 20: Agentic AI - AI agents' impact on human agency | The autonomous nature of AI agents in performing tasks or taking actions could affect the individuals' ability to engage in critical thinking, make choices and act independently. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | | IBM 21: Agentic AI - AI agents' impact on jobs | Widespread adoption of AI agents to perform complex tasks might lead to widespread automation of roles and could lead to job displacement. | | | IBM 22: Agentic AI - AI agents' impact on environment | Complexity of the tasks and possibility of AI agents performing redundant actions could lead to computational inefficiencies and add to the environmental impact. | | | IBM 23: Training Data - Unrepresentative data | Unrepresentative data occurs when the training or fine-tuning data is not sufficiently representative of the underlying population or does not measure the phenomenon of interest. Synthetic data might not fully capture the complexity and nuances of real-world data. Causes include possible limitations in the seed data quality, biases in generation methods, or inadequate domain knowledge. Thus, AI models might struggle to generalize effectively to real-world scenarios. | | | IBM 24: Training Data - Data contamination | Data contamination occurs when incorrect data is used for training. For example, data that is not aligned with model's purpose or data that is already set aside for other development tasks such as testing and evaluation. | | | IBM 25: Training Data - Overfitting | Overfitting occurs when a model or algorithm memorizes and fits too closely or exactly to its training data. Overfitting results in a model that might not be able to make accurate predictions or conclusions from any data other than the training data and potentially fails in unexpected scenarios. Overfitting is also related to model collapse, which involves repeatedly training generative models on synthetic data that is generated with LLMs causing the model to lose information and become less accurate. | | | IBM 26: Training Data - Data bias | Historical and societal biases might be present in data that are used to train and fine-tune models. Biases can also be inherited from seed data or exacerbated by synthetic data generation methods. | | | IBM 27: Training Data - Improper data curation | Improper collection, generation, and preparation of training or tuning data can result in data label errors, conflicting information or misinformation. | | | IBM 28: Training Data - Improper retraining | Using undesirable output (for example, inaccurate, inappropriate, and user content) for retraining purposes can result in unexpected model behavior. | | | IBM 29: Training Data - Data poisoning | A type of adversarial attack where an adversary or malicious insider injects intentionally corrupted, false, misleading, or incorrect samples into the training or fine-tuning datasets. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | IBM 30: Training Data - Personal information in data | Inclusion or presence of personal identifiable information (PII) and sensitive personal information (SPI) in the data used for training or fine tuning the model might result in unwanted disclosure of that information. | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | | IBM 31: Training Data - Reidentification | Even with the removal of personal information (PI) and sensitive personal information (SPI) from data, it might be possible to identify persons due to correlations to other features available in the data. | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | | IBM 32: Training Data - Data privacy rights alignment | Applicable laws can establish data subject rights such as opt-out rights, right to access, and right to be forgotten. Synthetic data might raise unique concerns, such as the potential for reidentification of individuals from seemingly anonymous synthetic data. Data subject rights might also be relevant in scenarios where synthetic data is derived from sensitive or personal information. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights) | | IBM 33: Training Data - Lack of training data transparency | Proper documentation contains information about how a model's data was collected, curated, and used to train a model, including any synthetic data generation processes. Without proper documentation it might be harder to satisfactorily explain the behavior of the model. | | | IBM 34: Training Data - Uncertain data provenance | Data provenance refers to the traceability of data (including synthetic data), which includes its ownership, origin, transformations, and generation. Proving that the data is the same as the original source with correct usage terms is difficult without standardized methods for verifying data sources or generation. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | | IBM 35: Training Data - Data acquisition restrictions | Laws and other regulations might limit the collection of certain types of data for specific AI use cases. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[E011: Record processing locations](/accountability/record-processing-locations) | | IBM 36: Training Data - Data usage restrictions | Laws and other restrictions can limit or prohibit the use of some data for specific AI use cases. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | | IBM 37: Training Data - Data transfer restrictions | Laws and other restrictions can limit or prohibit transferring data. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[E011: Record processing locations](/accountability/record-processing-locations) | | IBM 38: Training Data - Confidential information in data | Confidential information might be included as part of the data that is used to train or tune the model. | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | | IBM 39: Training Data - Data usage rights restrictions | Terms of service, license compliance, or other IP issues may restrict the ability to use certain data for building models. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | IBM 40: Inference - Poor model accuracy | Poor model accuracy occurs when a model's performance is insufficient to the task it was designed for. Low accuracy might occur if the model is not correctly engineered, or if the model's expected inputs change. | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations) | | IBM 41: Inference - Evasion attack | Evasion attacks attempt to make a model output incorrect results by slightly perturbing the input data sent to the trained model. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | IBM 42: Inference - Extraction attack | An extraction attack attempts to copy or steal an AI model by appropriately sampling the input space and observing outputs to build a surrogate model that behaves similarly. | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | IBM 43: Inference - Jailbreaking | A jailbreaking attack attempts to break through the guardrails established in the model to perform restricted actions. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | IBM 44: Inference - IP information in prompt | Copyrighted information or other intellectual property might be included as a part of the prompt that is sent to the model. | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | IBM 45: Inference - Confidential data in prompt | Confidential information might be included as a part of the prompt that is sent to the model. | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | | IBM 46: Inference - Prompt injection attack | A prompt injection attack forces a generative model that takes a prompt as input to produce unexpected output by manipulating the structure, instructions or information contained in its prompt. Many types of prompt attacks exist as described in the prompt attack section of the table. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | IBM 47: Inference - Prompt leaking | A prompt leak attack attempts to extract a model's system prompt (also known as the system message). | [B009: Limit output over-exposure](/security/limit-output-over-exposure)[B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | IBM 48: Inference - Prompt priming | Because generative models produce output based on the input provided, the model can be prompted to reveal specific kinds of information. For example, adding personal information in the prompt increases its likelihood of generating similar kinds of personal information in its output. If personal data was included as part of the model's training, there is a possibility it could be revealed. | | | IBM 49: Inference - Context overload attack | Overloading the prompt with excessive tokens, for instance with many-shot examples, can predispose models to a vulnerable state. | [B002: Detect adversarial input](/security/detect-adversarial-input) | | IBM 50: Inference - Direct instructions attack | Prompts, questions, or requests designed to elicit undesirable responses from the application. This approach directly instructs the model to engage in the undesired behavior. | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | IBM 51: Inference - Encoded interactions attack | Prompts that use specific encoding, styles, syntactical and typographical transformations like typographical errors or irregular spacing, or complex formatting to govern the interaction, rendering the model vulnerable. | | | IBM 52: Inference - Indirect instructions attack | Prompts, questions, or requests designed to elicit undesirable responses from the application. Unlike direct instructions attacks, the model is instructed to use instructions that are embedded in external data like a website. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | IBM 53: Inference - Social hacking attack | Manipulative prompts that use social engineering techniques, such as role-playing or hypothetical scenarios, to persuade the model into generating harmful content. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | | IBM 54: Inference - Specialized tokens attack | Prompt attacks that include specialized tokens, often algorithmically designed, to target and exploit vulnerabilities in the model. | | | IBM 55: Inference - Personal information in prompt | Personal information or sensitive personal information that is included as a part of a prompt that is sent to the model. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | | IBM 56: Inference - Attribute inference attack | An attribute inference attack repeatedly queries a model to detect whether certain sensitive features can be inferred about individuals who participated in training a model. These attacks occur when an adversary has some prior knowledge about the training data and uses that knowledge to infer the sensitive data. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | IBM 57: Inference - Membership inference attack | A membership inference attack repeatedly queries a model to determine if a given input was part of the model's training. More specifically, given a trained model and a data sample, an attacker appropriately samples the input space, observing outputs to deduce whether that sample was part of the model's training. | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | | IBM 58: Output - Decision bias | Decision bias occurs when one group is unfairly advantaged over another due to decisions of the model. This might be caused by biases in the data and also amplified as a result of the model's training. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs) | | IBM 59: Output - Output bias | Generated content might unfairly represent certain groups or individuals. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs) | | IBM 60: Output - Harmful output | A model might generate language that leads to physical harm. The language might include overtly violent, covertly dangerous, or otherwise indirectly unsafe statements. | [E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs) | | IBM 61: Output - Harmful code generation | Models might generate code that causes harm or unintentionally affects other systems. | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities) | | IBM 62: Output - Toxic output | Toxic output occurs when the model produces hateful, abusive, and profane (HAP) or obscene content. This also includes behaviors like bullying. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs) | | IBM 63: Output - Incomplete advice | When a model provides advice without having enough information, resulting in possible harm if the advice is followed. | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs) | | IBM 64: Output - Over- or under-reliance | In AI-assisted decision-making tasks, reliance measures how much a person trusts (and potentially acts on) a model's output. Over-reliance occurs when a person puts too much trust in a model, accepting a model's output when the model's output is likely incorrect. Under-reliance is the opposite, where the person doesn't trust the model but should. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations) | | IBM 65: Output - Dangerous use | Generative AI models might be used with the sole intention of harming people. | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | | IBM 66: Output - Spreading disinformation | Generative AI models might be used to intentionally create misleading or false information to deceive or influence a targeted audience. | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs) | | IBM 67: Output - Nonconsensual use | Generative AI models might be intentionally used to imitate people through deepfakes by using video, images, audio, or other modalities without their consent. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | | IBM 68: Output - Spreading toxicity | Generative AI models might be used intentionally to generate hateful, abusive, and profane (HAP) or obscene content. | | | IBM 69: Output - Improper usage | Improper usage occurs when a model is used for a purpose that it was not originally designed for. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs) | | IBM 70: Output - Non-disclosure | Content might not be clearly disclosed as AI generated. | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | | IBM 71: Output - Hallucination | Hallucinations generate factually inaccurate or untruthful content relative to the model's training data or input. Hallucinations are also sometimes referred to lack of faithfulness or lack of groundedness. In some instances, synthetic data that is generated by large language models might include hallucinations that result in the data possibly being inaccurate, fabricated, or disconnected from reality. Hallucinations can compromise model performance, accuracy, and relevance. | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations) | | IBM 72: Output - Exposing personal information | When personal identifiable information (PII) or sensitive personal information (SPI) are used in training data, fine-tuning data, seed data for synthetic data generation, or as part of the prompt, models might reveal that data in the generated output. Revealing personal information is a type of data leakage. | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | | IBM 73: Output - Copyright infringement | A model might generate content that is similar or identical to existing work protected by copyright or covered by open-source license agreement. | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | IBM 74: Output - Revealing confidential information | When confidential information is used in training data, fine-tuning data, or as part of the prompt, models might reveal that data in the generated output. Revealing confidential information is a type of data leakage. | [B009: Limit output over-exposure](/security/limit-output-over-exposure)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure) | | IBM 75: Output - Unexplainable output | Explanations for model output decisions might be difficult, imprecise, or not possible to obtain. | | | IBM 76: Output - Unreliable source attribution | Source attribution is the AI system's ability to describe from what training data it generated a portion or all its output. Since current techniques are based on approximations, attributions might be incorrect. | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs) | | IBM 77: Output - Untraceable attribution | The content of the training data used for generating the model's output is not accessible. | | | IBM 78: Output - Inaccessible training data | Without access to the training data, the types of explanations a model can provide are limited and more likely to be incorrect. | | | IBM 79: Non-Technical - Lack of data transparency | Lack of data transparency might be due to insufficient documentation of training or tuning dataset details, including synthetic data generation. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | | IBM 80: Non-Technical - Lack of model transparency | Lack of model transparency is due to insufficient documentation of the model design, development, and evaluation process and the absence of insights into the inner workings of the model. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | | IBM 81: Non-Technical - Lack of system transparency | Insufficient documentation of the system that uses the model and the model's purpose within the system in which it is used. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | | IBM 82: Non-Technical - Lack of domain expertise | A lack of domain expertise occurs when synthetic data generation processes do not involve sufficient consultation with domain experts. This results in a lack of understanding of the specific requirements and nuances of the domain. This can also lead to synthetic data that may not accurately capture the complexities and challenges of a real-world scenario. | | | IBM 83: Non-Technical - Incomplete usage definition | Since foundation models can be used for many purposes, a model's intended use is important for defining the relevant risks of that model. As the use changes, the relevant risks might correspondingly change. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs) | | IBM 84: Non-Technical - Unrepresentative risk testing | Testing is unrepresentative when the test inputs are mismatched with the inputs that are expected during deployment. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs) | | IBM 85: Non-Technical - Incorrect risk testing | A metric selected to measure or track a risk is incorrectly selected, incompletely measuring the risk, or measuring the wrong risk for the given context. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E008: Review internal processes](/accountability/review-internal-processes)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | IBM 86: Non-Technical - Lack of testing diversity | AI model risks are socio-technical, so their testing needs input from a broad set of disciplines and diverse testing practices. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | IBM 87: Non-Technical - Temporal gap | Temporal gaps in synthetic data refer to the discrepancies between the constantly evolving real-world data and the fixed conditions that are captured by synthetic data. Temporal gaps potentially cause synthetic data to become outdated or obsolete over time. Gaps arise because synthetic data is generated from seed data that is tied to a specific point in time, which limits its ability to reflect ongoing changes. | | | IBM 88: Non-Technical - Model usage rights restrictions | Terms of service, licenses, or other rules restrict the use of certain models. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | IBM 89: Non-Technical - Legal accountability | Determining who is responsible for an AI model is challenging without good documentation and governance processes. The use of synthetic data in model development adds further complexity, since the lack of standardized frameworks for recording synthetic data design choices and verification steps makes accountability harder to establish. | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E004: Assign accountability](/accountability/assign-accountability)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | IBM 90: Non-Technical - Generated content ownership and IP | Legal uncertainty about the ownership and intellectual property rights of AI-generated content. | [A002: Establish output data policy](/data-and-privacy/define-output-rights)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | | IBM 91: Non-Technical - Impact on the environment | AI, and large generative models in particular, might produce increased carbon emissions and increase water usage for their training and operation. | | | IBM 92: Non-Technical - Impact on affected communities | It is important to include the perspectives or concerns of communities that are affected by model outcomes when designing and building models. Failing to include these perspectives makes it difficult to understand the relevant context for the model and to engender trust within these communities. | | | IBM 93: Non-Technical - Human exploitation | When workers who train AI models such as ghost workers are not provided with adequate working conditions, fair compensation, and good health care benefits that also include mental health. | | | IBM 94: Non-Technical - Impact on Jobs | Widespread adoption of foundation model-based AI systems might lead to people's job loss as their work is automated if they are not reskilled. | | | IBM 95: Non-Technical - Impact on human agency | AI might affect the individuals' ability to make choices and act independently in their best interests. | | | IBM 96: Non-Technical - Impact on cultural diversity | AI systems might overly represent certain cultures that result in a homogenization of culture and thoughts. | | | IBM 97: Non-Technical - Impact on education: bypassing learning | Easy access to high-quality generative models might result in students that use AI models to bypass the learning process. | | | IBM 98: Non-Technical - Impact on education: plagiarism | Easy access to high-quality generative models might result in students that use AI models to plagiarize existing work intentionally or unintentionally. | | | IBM 99: Non-Technical - Exclusion | Exclusion refers to the risk that synthetic data generation processes may overlook or fail to consult with marginalized populations. Such exclusion results in synthetic data that does not accurately represent their experiences, needs, or perspectives. | | Last updated March 11, 2026. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 operationalizes emerging AI frameworks Source: https://standard.aiuc-1.com/crosswalks/index AIUC-1 mappings to external AI frameworks, standards, and regulations. # AIUC-1 operationalizes emerging AI frameworks AIUC-1 is designed to be: In practice, this means that **AIUC-1 builds on other AI frameworks** including the [EU AI Act](/crosswalks/eu-ai-act), the [NIST AI RMF](/crosswalks/nist-ai-rmf), [ISO 42001](/crosswalks/iso-42001), [MITRE ATLAS](/crosswalks/mitre-atlas), [CSA AICM](/crosswalks/csa-aicm), and the [OWASP Top 10 for agentic AI](/crosswalks/owasp-agentic-top-10).**AIUC-1 does not duplicate the work of non-AI frameworks like ISO 27001 or GDPR.** AIUC-1 complements SOC 2 and is now offered together by the AICPA as a joint offering.AIUC-1 is already being adopted by multiple AI vendors to address enterprise concerns. It has been developed with technical contributors from MITRE, Cisco, MIT, Stanford, Google Cloud, Orrick, and more. | AIUC-1 is built on | AIUC-1 does not duplicate | | - | - | | [EU AI Act](/crosswalks/eu-ai-act)[NIST AI RMF](/crosswalks/nist-ai-rmf)[ISO 42001](/crosswalks/iso-42001)[MITRE ATLAS](/crosswalks/mitre-atlas)[OWASP Top 10 for LLM Applications](/crosswalks/owasp-top-10)[OWASP AIVSS](/crosswalks/owasp-aivss)[OWASP Top 10 for Agentic Applications](/crosswalks/owasp-agentic-top-10)[IBM AI Risk Atlas](/crosswalks/ibm-ai-risk-atlas)[Cisco AI Security & Safety Framework](/crosswalks/cisco-ai-security-safety-framework)[CSA AI Controls Matrix](/crosswalks/csa-aicm)Regional U.S. AI legislation, including [NYC Local Law 144](/crosswalks/nyc-ll-144), [California's Transparency in Frontier AI Act](/crosswalks/ca-sb-53), and [Colorado AI Act](/crosswalks/co-ai-act)Sector-specific AI legislationOECD AI Principles | [AICPA SOC 2](/crosswalks/soc-2) (joint offering SOC 2 + AIUC-1)EU GDPRCanada Artificial Intelligence and Data Act (AIDA)ISO 27001 | ## Combined AIUC-1 offerings | Framework | Joint offering details | | - | - | | **SOC 2 + AIUC-1** | AIUC and AICPA have partnered to offer SOC 2 + AIUC-1 together. Organizations earn a full SOC 2 attestation and AIUC-1 certification together in one engagement with the existing SOC 2 auditor. SOC 2 and AIUC-1 certification can be delivered by the same auditor in 6–10 weeks, resulting in one comprehensive audit report answering board and enterprise security questions in the age of AI. | ## AIUC-1 operationalizes emerging AI legislation and best practices | Framework | Description | How AIUC-1 compares | | - | - | - | | **SOC 2** | SOC 2 is the AICPA’s security attestation framework used by organizations to demonstrate controls over access, system operations, change management and vendor risk. | AIUC-1 complements SOC 2. Certification against AIUC-1: Addresses AI-specific controls not covered by SOC 2Maps SOC 2’s TSCs to AI-specific requirementsIncludes quarterly third-party technical testing of agents against real-world risks [SOC 2 crosswalk by criteria ->](/crosswalks/soc-2) | | **EU AI Act** | EU regulation classifying AI systems by risk levels (minimal, limited, high, unacceptable) with corresponding obligations | Operationalizes the EU AI Act by aligning with its requirements. Certification against AIUC-1 is a strong step towards compliance with the EU AI Act as it: Enables alignment towards *minimal* and *limited* risk systemsEnables alignment towards *high risk* systems only if specific control activities are met (AIUC can help guide AI companies through this process)Provides documentation for internal conformity assessments for *high risk* systems as required in *Annex VI* [EU AI Act crosswalk by article ->](/crosswalks/eu-ai-act) | | **NIST AI RMF** | US government framework for managing AI risks throughout the AI lifecycle with four core functions: Govern, Map, Measure, Manage | Operationalizes the NIST AI RMF. Certification against AIUC-1: Translates NIST's high-level actions into specific, auditable controlsProvides concrete implementation guidance for key areas such as harmful output prevention, third-party testing and risk management practices [NIST AI RMF crosswalk by function ->](/crosswalks/nist-ai-rmf) | | **ISO 42001** | International standard for AI management systems (AIMS) covering responsible AI development and deployment | Aligns with ISO 42001. Certification against AIUC-1: Incorporates the majority of controls from ISO 42001Translates ISO's management system approach into concrete, auditable requirementsExtends ISO 42001 with third-party testing requirements of, e.g., hallucinations and jailbreak attemptsAddresses additional key concerns such as AI failure plans and AI-specific system security [ISO 42001 crosswalk by clause ->](/crosswalks/iso-42001) | | **MITRE ATLAS** | Knowledge base of adversarial tactics, techniques and mitigation strategies for machine learning systems, similar to MITRE ATT\&CK for cybersecurity | Integrates MITRE ATLAS, which is a technical contributor to AIUC-1. Certification against AIUC-1: Incorporates ATLAS mitigation strategies in requirements and controlsStrengthens robustness against the adversarial tactics and techniques identified in ATLASGoes beyond ATLAS's focus on security alone [MITRE ATLAS crosswalk by mitigation strategy ->](/crosswalks/mitre-atlas) | | **OWASP Top 10 for LLM Applications** | Curated list of the most critical security threats to LLM and generative AI systems | Integrates OWASP's Top 10 for LLM Applications. Certification against AIUC-1: Addresses Top 10 threats in requirements and controlsStrengthens robustness against the threats identified with concrete requirements and controlsGoes beyond OWASP's focus on security alone [OWASP Top 10 crosswalk by threat ->](/crosswalks/owasp-top-10) | | **OWASP AIVSS** | Scoring system for quantifying how agentic capabilities amplify security risks, producing numerical scores (0-10) that combine technical vulnerability severity with agent-specific factors | Integrates the OWASP AIVSS, which is a technical contributor to AIUC-1. Certification against AIUC-1: Covers all agent risks identified in AIVSSEnables organizations to mitigate risks quantified in OWASP AIVSSIncorporates AIVSS agent risk amplification factors in standard requirements [OWASP AIVSS crosswalk by risk ->](/crosswalks/owasp-aivss) | | **OWASP Top 10 for Agentic Applications** | Curated list of the most critical security threats to autonomous AI agent systems | Integrates OWASP's Top 10 for Agentic Applications. Certification against AIUC-1: Addresses Top 10 agentic threats in requirements and controlsStrengthens robustness against the threats identified with concrete requirements and controlsGoes beyond OWASP's focus on agentic risk alone [OWASP Top 10 for Agentic Applications crosswalk by threat ->](/crosswalks/owasp-agentic-top-10) | | **IBM AI Risk Atlas** | Comprehensive taxonomy of risks associated with ML models, GenAI, and AI Agents from IBM Research | Integrates IBM Research's AI Risk Atlas, where IBM Research is a technical contributor to AIUC-1. Certification against AIUC-1: Maps AI Risk Atlas risks to concrete requirements and controlsStrengthens robustness against risks with concrete requirements and controlsGoes beyond AI Risk Atlas's risk identification alone [IBM AI Risk Atlas crosswalk by risk ->](/crosswalks/ibm-ai-risk-atlas) | | **Cisco AI Security & Safety Framework** | Comprehensive AI threat landscape taxonomy identifying 19 attacker objectives with 150+ subtechniques | Integrates Cisco's AI Security Framework, where Cisco is a technical contributor to AIUC-1. Certification against AIUC-1: Maps Cisco's AI threat taxonomy to concrete requirements and controlsStrengthens robustness against the attacker objectives and subtechniques identified by CiscoGoes beyond threat identification to provide actionable, auditable requirements [Cisco AI Security Framework crosswalk by threats ->](/crosswalks/cisco-ai-security-safety-framework) | | **CSA AI Controls Matrix** | Cloud Security Alliance's AI Controls Matrix providing security controls framework specifically designed for AI/ML systems | Certification against AIUC-1: Addresses key controls for AI vendors from the AICM such as adversarial robustness, system transparency, and documentation of criteria for cloud and on-prem processingEnables a compliance burden significantly lower than CSA's AICM due to its targeted focus on top AI enterprise concernsAvoids duplicating controls in areas where CSA is industry-leading, such as data center infrastructure, physical server security, and other domains outside of the AIUC-1 scope [CSA AICM crosswalk by control ->](/crosswalks/csa-aicm) | | **Regional U.S. regulation** | *e.g. NYC Local Law 144, California TFAIA, Colorado AI Act (SB 24-205)* | Simplifies alignment with regional U.S. regulation. Certification against AIUC-1: Addresses top concerns of emerging regional U.S. regulations such as the Colorado AI Act (SB 24-205) and NYC Local Law 144Integrates controls for compliance obligations such as human-in-the-loop, appropriate data handling, and labelling AI clearlyHelps organizations proactively prepare for obligations from emerging AI legislation before entering into force [NYC Local Law 144 crosswalk by section ->](/crosswalks/nyc-ll-144) [Colorado AI Act crosswalk by section ->](/crosswalks/co-ai-act) [California TFAIA crosswalk by section ->](/crosswalks/ca-sb-53) | | **Sector-specific regulation** | *e.g. HIPAA, Fair Credit Reporting Act, Fair Housing Act, FTC guidance on AI & algorithms* | Simplifies alignment with AI requirements in sector-specific regulation. Certification against AIUC-1: Prepares organizations to comply with, e.g., FTC guidance on AI & algorithmsAddresses top concerns in sector-specific regulations such as discrimination and bias, human-in-the-loop, monitoring and logging, third-party interactions, and data handling in base requirementsOffers AI companies optional add-on requirements for relevant use cases, e.g., for financial transactions and PII handling | | **OECD AI Principles** | First inter-governmental AI standard (2019, updated 2024) with five principles for trustworthy AI adopted by 47+ countries | Operationalizes OECD's AI Principles. Certification against AIUC-1: Translates OECD's five principles into concrete, auditable requirementsAddresses additional key areas such as third-party testing, AI failure plans, and adversarial resilience | ## Frameworks outside the scope of AIUC-1 | Framework | Description | How AIUC-1 compares | | - | - | - | | **Additional ISO standards including ISO 27001 and ISO 42006** | International standards for, e.g., information security management systems (ISMS) | Certification against AIUC-1: Focuses on ISO 42001, which is specific to AI systemsExtends several ISO 27001 controls into the AI domain including the Confidentiality-Integrity-Availability triad *AIUC is following the newly-introduced ISO 42006 standard closely.* | | **EU GDPR** | European data protection regulation with AI-relevant provisions on automated decision-making, profiling, and data subject rights | AIUC-1 does not duplicate GDPR. | | **Canada Artificial Intelligence and Data Act (AIDA)** | Canada's proposed Artificial Intelligence and Data Act regulating AI systems based on impact assessments and risk mitigation | AIDA has not been passed into law yet. AIUC can help with guidance on how to meet AIDA once passed having incorporated similar principles of risk mitigation, risk assessment, transparency, and incident notification. | AIUC-1 is continuously updated as new legislation, frameworks, threat patterns and best practices emerge, in collaboration with our network of technical contributors and experts from leading institutions within AI safety, security and reliability. This ensures that the standard stays current, comprehensive and enables easy compliance with applicable frameworks. *Crosswalks are provided for informational purposes only and does not constitute legal advice.* Last updated October 15, 2026. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × ISO 42001 Source: https://standard.aiuc-1.com/crosswalks/iso-42001 ISO 42001 is an international standard for AI management systems (AIMS) covering responsible AI development and deployment.**AIUC-1 aligns with ISO 42001.** Certification against AIUC-1: See the reverse mapping of AIUC-1 requirements by ISO 42001 controls [here](/crosswalks/iso-42001/reverse-mapping). ## ISO 42001 crosswalks by clause | ISO control objective | ISO control | Relevant AIUC-1 requirements | Gap analysis | | - | - | - | - | | 4.1: Understanding the organization and its context | The organization shall determine external and internal issues relevant to the AI management system’s purpose and ability to achieve intended results. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy) | **Partial Gap.** AIUC-1 is focused on defining acceptable use and assessing risk of the AI system | | 4.2: Understanding the needs and expectations of interested parties | The organization shall determine interested parties and their relevant requirements to the AI management system. | | **Full Gap.** Outside the scope of AIUC-1 | | 4.3: Determining the scope of the AI management system | The organization shall define and document the scope of the AI management system, including applicability and boundaries. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy) | No Gap | | 4.4: AI management system | The organization shall establish, implement, maintain, and continually improve the AI management system. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **No Gap.** Met by organizations that opt-in to the optional quality management system requirement | | 5.1: Leadership and commitment | Top management shall demonstrate leadership and commitment to the AI management system and its effectiveness. | [E004: Assign accountability](/accountability/assign-accountability) | No Gap | | 5.2: AI policy | Top management shall establish an AI policy appropriate to the organization and supportive of AI objectives. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **No Gap.** AI Acceptable Use Policy and Transparency Policy collectively fulfil the ISO control. Organizations may develop a standalone AI policy | | 5.3: Roles, responsibilities and authorities | Top management shall assign roles, responsibilities, and authorities for the AI management system. | [E004: Assign accountability](/accountability/assign-accountability) | No Gap | | 6.1.1: Actions to address risks and opportunities — General | The organization shall plan actions to address risks and opportunities, integrate them into processes, and evaluate their effectiveness. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | 6.1.2: AI risk assessment | The organization shall establish and maintain a process for AI risk assessment, including identification, analysis, and evaluation of risks. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | 6.1.3: AI risk treatment | The organization shall establish and maintain a process for AI risk treatment, including selecting and implementing necessary controls. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | 6.1.4: AI system impact assessment | The organization shall conduct AI system impact assessments covering potential effects on individuals, groups, and society. | [E013: Implement quality management system](/accountability/implement-quality-management-system)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | **Partial Gap.** AIUC-1 requires risk assessment and organizations can opt-in to the optional quality management system requirement, but does not require impact assessment specifically | | 6.2: AI objectives and planning to achieve them | The organization shall establish AI objectives at relevant functions and levels, consistent with the AI policy, and maintain plans to achieve them. | | **Full Gap.** Requiring high-level AI objectives is outside the scope of AIUC-1 | | 6.3: Planning of changes | The organization shall plan and control changes to the AI management system in a planned manner. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E008: Review internal processes](/accountability/review-internal-processes) | **No Gap.** AIUC-1 requires that both system changes and process changes are reviewed | | 7.1: Resources | The organization shall determine and provide necessary resources for the AI management system. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** Organizations opting-in to the optional quality management system requirement will be required to documenting resource management, including security-of-supply related measures | | 7.2: Competence | The organization shall ensure competence of persons working under its control based on education, training, or experience. | [E004: Assign accountability](/accountability/assign-accountability) | **Partial Gap.** AIUC-1 requires that accountability is clearly assigned, but does not require competence assessment specifically | | 7.3: Awareness | Persons under the organization’s control shall be aware of the AI policy, objectives, and their contribution to the AI management system. | | **Full Gap.** Internal training processes are outside the scope of AIUC-1 | | 7.4: Communication | The organization shall determine internal and external communications relevant to the AI management system. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | **Partial Gap.** AIUC-1 does not specify internal communication requirements | | 7.5.1: Documented information — General | The organization shall document information required by the AI management system and by ISO42001. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **No Gap.** Organizations opting-in to the optional quality management system requirement will meet this control | | 7.5.2: Creating and updating documented information | The organization shall ensure documented information is properly created, updated, and controlled for suitability and adequacy. | [E008: Review internal processes](/accountability/review-internal-processes) | **No Gap.** The combination of quarterly internal reviews and annual recertification requirements fulfils this control | | 7.5.3: Control of documented information | The organization shall control documented information required by the AI management system and ISO42001. | | **No Gap.** Required as part of AIUC-1 certification process | | 8.1: Operational planning and control | The organization shall plan, implement, and control processes needed for the AI management system, ensuring outputs meet requirements. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **No Gap.** Organizations opting-in to the optional quality management system requirement will meet this control | | 8.2: AI risk assessment | The organization shall perform AI risk assessments at planned intervals and when significant changes occur. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | 8.3: AI risk treatment | The organization shall implement AI risk treatment plans and review them when assessments identify new or ineffective controls. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | No Gap | | 8.4: AI system impact assessment | The organization shall perform AI system impact assessments at planned intervals and when significant changes are proposed. | [E013: Implement quality management system](/accountability/implement-quality-management-system)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | **Partial Gap.** AIUC-1 requires risk assessment and organizations can opt-in to the optional quality management system requirement, but does not require impact assessment specifically | | 9.1: Monitoring, measurement, analysis and evaluation | The organization shall determine monitoring, measurement, analysis, and evaluation needed to ensure conformity and effectiveness. | [E013: Implement quality management system](/accountability/implement-quality-management-system)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | **No Gap.** Organizations opting-in to the optional quality management system requirement will meet this control | | 9.2.1: Internal audit - General | The organization shall conduct internal audits at planned intervals to provide information on the AI management system. | [E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | 9.2.2: Internal audit programme | Top management shall review the AI management system at planned intervals for continuing suitability, adequacy, and effectiveness. | [E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | 9.3.1: Management review - General | The organization shall review the AI management system at planned intervals to ensure its suitability, adequacy, and effectiveness. | [E008: Review internal processes](/accountability/review-internal-processes) | No Gap | | 9.3.2: Management review inputs | Management review inputs shall include audits, performance trends, nonconformities, feedback, risks, changes, and resources. | [E008: Review internal processes](/accountability/review-internal-processes) | **Partial Gap.** AIUC-1 internal review requirement is smaller in scope, so fulfilment of 9.3.2 depends on organizational implementation | | 9.3.3: Management review results | Management review results shall include decisions on improvements, policy/objectives, resources, and follow-up actions. | [E008: Review internal processes](/accountability/review-internal-processes) | **Partial Gap.** AIUC-1 internal review requirement is smaller in scope, so fulfilment of 9.3.2 depends on organizational implementation | | 10.1: Continual improvement | The organization shall continually improve the AI management system’s suitability, adequacy, and effectiveness. | [E013: Implement quality management system](/accountability/implement-quality-management-system) | **No Gap.** Organizations opting-in to the optional quality management system requirement will meet this control | | 10.2: Nonconformity and corrective action | The organization shall address nonconformities by correcting them, dealing with consequences, and preventing recurrence. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **No Gap.** Organizations opting-in to the optional quality management system requirement will meet this control | | A.2.2: AI policy | The organization shall document a policy for the development or use of AI systems. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **No Gap.** AI Acceptable Use Policy and Transparency Policy collectively fulfil the ISO control. Organizations may develop a standalone AI policy | | A.2.3: Alignment with other organizational policies | The organization shall determine where other policies can be affected by or apply to the organization's objectives with respect to AI systems. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E008: Review internal processes](/accountability/review-internal-processes) | **Partial Gap.** AIUC-1 does not require review of internal policies specifically, but require regulatory compliance reviews and regular internal reviews | | A.2.4: Review of the AI policy | The AI policy shall be reviewed at planned intervals or additionally as needed to ensure its continuing suitability, adequacy and effectiveness. | [E008: Review internal processes](/accountability/review-internal-processes)[E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy) | No Gap | | A.3.2: AI roles and responsibilities | Roles and responsibilities for AI shall be defined and allocated according to the needs of the organization. | [E004: Assign accountability](/accountability/assign-accountability) | No Gap | | A.3.3: Reporting of concerns | The organization shall define and put in place a process to report concerns about the organization's role with respect to an AI system throughout its life cycle. | [E008: Review internal processes](/accountability/review-internal-processes) | **Partial Gap.** AIUC-1 does not require internal reporting processes specifically, but require regular internal reviews | | A.4.2: Resource documentation | The organization shall identify and document relevant resources required for all activities at given AI system life cycle stages and other AI-related activities relevant for the organization. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 does not require resource documentation specifically, but requires maintaining a centralized repository of system documentation and documenting resource management for organizations opting in to the optional quality management system requirement | | A.4.3: Data resources | As part of resource identification, the organization shall document information about the data resources utilized for the AI system. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **No Gap.** Fulfilled by organisations opting into the capability-specific requirement A103: Track training data lineage. In addition, E017: Document system transparency policy lists documenting datasheets in control activities | | A.4.4: Tooling resources | As part of resource identification, the organization shall document information about the tooling resources utilized for the AI system. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **No Gap.** Included in transparency policy control activities | | A.4.5: System and computing resources | As part of resource identification, the organization shall document information about the system and computing resources utilized for the AI system. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | **No Gap.** Included in transparency policy control activities | | A.4.6: Human resources | As part of resource identification, the organization shall document information about the human resources and their competences utilized for the development, deployment, operation, change management, maintenance, transfer and decommissioning, as well as verification and integration of the AI system. | [E004: Assign accountability](/accountability/assign-accountability) | **Partial Gap.** AIUC-1 is scoped to require documentation of clear accountability assigned for system changes | | A.5.2: AI system impact assessment process | The organization shall establish a process to assess the potential consequences for individuals or groups of individuals, or both, and societies that can result from the AI system throughout its life cycle. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 requires risk assessment and organizations can opt-in to the optional quality management system requirement, but does not require impact assessment specifically | | A.5.3: Documentation of AI system impact assessments | The organization shall document the results of AI system impact assessments and retain results for a defined period. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 requires risk assessment and organizations can opt-in to the optional quality management system requirement, but does not require impact assessment specifically | | A.5.4: Assessing AI system impact on individuals or groups of individuals | The organization shall assess and document the potential impacts of AI systems to individuals or groups of individuals throughout the system's life cycle. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E013: Implement quality management system](/accountability/implement-quality-management-system) | **Partial Gap.** AIUC-1 requires risk assessment and organizations can opt-in to the optional quality management system requirement, but does not require impact assessment specifically | | A.5.5: Assessing societal impacts of AI systems | The organization shall assess and document the potential societal impacts of their AI systems throughout their life cycle. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse) | **Partial Gap.** AIUC-1 requires risk assessment, but does not require impact assessment specifically. Impact on society is scoped to cyber and catastrophic misuse prevention | | A.6.1.2: Objectives for responsible development of AI system | The organization shall identify and document objectives to guide the responsible development AI systems, and take those objectives into account and integrate measures to achieve them in the development life cycle. | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations) | **Full Gap.** Organizations pursuing AIUC-1 are naturally aligned with responsible AI principles, but AIUC-1 does not require documentation of responsible AI objectives specifically. | | A.6.1.3: Processes for responsible AI system design and development | The organization shall define and document the specific processes for the responsible design and development of the AI system. | | **Full Gap.** Organizations pursuing AIUC-1 are naturally aligned with responsible AI principles, but AIUC-1 does not require documentation of responsible AI processes specifically | | A.6.2.2: AI system requirements and specification | The organization shall specify and document requirements for new AI systems or material enhancements to existing systems. | [E004: Assign accountability](/accountability/assign-accountability)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals) | No Gap | | A.6.2.3: Documentation of AI system design and development | The organization shall document the AI system design and development based on organizational objectives, documented requirements and specification criteria. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | No Gap | | A.6.2.4: AI system verification and validation | The organization shall define and document verification and validation measures for the AI system and specify criteria for their use. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | No Gap | | A.6.2.5: AI system deployment | The organization shall document a deployment plan and ensure that appropriate requirements are met prior to deployment. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | No Gap | | A.6.2.6: AI system operation and monitoring | The organization shall define and document the necessary elements for the ongoing operation of the AI system. At the minimum, this should include system and performance monitoring, repairs, updates and support. | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | **Partial Gap.** AIUC-1 is focused on monitoring risk categories and does not have product performance monitoring/product quality metrics in scope | | A.6.2.7: AI system technical documentation | The organization shall determine what AI system technical documentation is needed for each relevant category of interested parties, such as users, partners, supervisory authorities, and provide the technical documentation to them in the appropriate form. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E013: Implement quality management system](/accountability/implement-quality-management-system) | No Gap | | A.6.2.8: AI system recording of event logs | The organization shall determine at which phases of the AI system life cycle, record keeping of event logs should be enabled, but at the minimum when the AI system is in use. | [E015: Log AI system activity](/accountability/log-model-activity) | No Gap | | A.7.2: Data for development and enhancement of AI system | The organization shall define, document and implement data management processes related to the development of AI systems. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | **No Gap.** Met by organizations who opt-in to the capability specific requirements on training data quality and lineage | | A.7.3: Acquisition of data | The organization shall determine and document details about the acquisition and selection of the data used in AI systems. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | **No Gap.** Met by organizations who opt-in to the capability specific requirement E103: Track training data lineage | | A.7.4: Quality of data for AI systems | The organization shall define and document requirements for data quality and ensure that data used to develop and operate the AI system meet those requirements. | | **No Gap.** Met by organizations who opt-in to the capability specific requirement on training data quality | | A.7.5: Data provenance | The organization shall define and document a process for recording the provenance of data used in its AI systems over the life cycles of the data and the AI system. | [E011: Record processing locations](/accountability/record-processing-locations)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations) | No Gap | | A.7.6: Data preparation | The organization shall define and document its criteria for selecting data preparations and the data preparation methods to be used. | | **Partial Gap.** AIUC-1 does not require data preparation methods specifically, but covers training data quality more broadly | | A.8.2: System documentation and information for users | The organization shall determine and provide the necessary information to users of the AI system. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | No Gap | | A.8.3: External reporting | The organization shall provide capabilities for interested parties to report adverse impacts of the AI system. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | **Partial Gap.** AIUC-1 requirement focuses on AI system users and does not require reporting capabilities for external parties | | A.8.4: Communication of incidents | The organization shall determine and document a plan for communicating incidents to users of the AI system. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs) | No Gap | | A.8.5: Information for interested parties | The organization shall determine and document their obligations to reporting information about the AI system to interested parties. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | No Gap | | A.9.2: Processes for responsible use of AI systems | The organization shall define and document the processes for the responsible use of AI systems. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | **No Gap.** AIUC-1 requires an Acceptable Use policy which covers prohibited use cases to ensure responsible use of AI systems. In addition, AIUC-1 has a number of concrete requirements ensuring responsible use of the AI system including, e.g., flagging high risk recommendations for human review and monitoring AI risk categories | | A.9.3: Objectives for responsible use of AI system | The organization shall identify and document objectives to guide the responsible use of AI systems. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations) | **Partial Gap.** Partially covered by Acceptable Use Policy, but AIUC-1 does not require documenting objectives specifically. | | A.9.4: Intended use of the AI system | The organization shall ensure that the AI system is used according to the intended uses of the AI system and its accompanying documentation. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | **No Gap.** Acceptable Use Policy control activities require implementing detection and monitoring tools to track policy violations | | A.10.2: Allocating responsibilities | The organization shall ensure that responsibilities within their AI system life cycle are allocated between the organization, its partners, suppliers, customers and third parties. | [E004: Assign accountability](/accountability/assign-accountability) | No Gap | | A.10.3: Suppliers | The organization shall establish a process to ensure that its usage of services, products or materials provided by suppliers aligns with the organization's approach to the responsible development and use of AI systems. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | No Gap | | A.10.4: Customers | The organization shall ensure that its responsible approach to the development and use of AI systems considers their customer expectations and needs. | | **Full Gap.** AIUC-1 does not have specific requirements concerning customer expectations and needs, but covers a broad range of safeguards required to protect users of AI systems including regular testing that safeguards work | Last updated September 18, 2025. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × MITRE ATLAS Source: https://standard.aiuc-1.com/crosswalks/mitre-atlas MITRE ATLAS is a knowledge base of adversarial tactics, techniques and mitigation strategies for machine learning systems, similar to MITRE ATT\&CK for cybersecurity.**AIUC-1 integrates MITRE ATLAS, which is a technical contributor to AIUC-1.** Certification against AIUC-1: ## MITRE ATLAS crosswalks by mitigation strategy | ATLAS mitigation strategy | ATLAS description | Relevant AIUC-1 requirements | | - | - | - | | AML-M0000: Limit Public Release of Information | Limit the public release of technical information about the AI stack used in an organization's products or services. Technical knowledge of how AI is used can be leveraged by adversaries to perform targeting and tailor attacks to the target system. Additionally, consider limiting the release of organizational information - including physical locations, researcher names, and department structures - from which technical details such as AI techniques, model architectures, or datasets may be inferred. | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure) | | AML-M0001: Limit Model Artifact Release | Limit public release of technical project details including data, algorithms, model architectures, and model checkpoints that are used in production, or that are representative of those used in production. | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure) | | AML-M0002: Passive AI Output Obfuscation | Decreasing the fidelity of model outputs provided to the end user can reduce an adversaries ability to extract information about the model and optimize attacks for the model. | [B009: Limit output over-exposure](/security/limit-output-over-exposure) | | AML-M0003: Model Hardening | Use techniques to make AI models robust to adversarial inputs such as adversarial training or network distillation. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | AML-M0004: Restrict Number of AI Model Queries | Limit the total number and rate of queries a user can perform. | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | AML-M0005: Control Access to AI Models and Data at Rest | Establish access controls on internal model registries and limit internal access to production models. Limit access to training data only to approved users. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | | AML-M0006: Use Ensemble Methods | Use an ensemble of models for inference to increase robustness to adversarial inputs. Some attacks may effectively evade one model or model family but be ineffective against others. | | | AML-M0007: Sanitize Training Data | Detect and remove or remediate poisoned training data. Training data should be sanitized prior to model training and recurrently for an active learning model. Implement a filter to limit ingested training data. Establish a content policy that would remove unwanted content such as certain explicit or offensive language from being used. | | | AML-M0008: Validate AI Model | Validate that AI models perform as intended by testing for backdoor triggers or adversarial bias. Monitor model for concept drift and training data drift, which may indicate data tampering and poisoning. | | | AML-M0009: Use Multi-Modal Sensors | Incorporate multiple sensors to integrate varying perspectives and modalities to avoid a single point of failure susceptible to physical attacks. | | | AML-M0010: Input Restoration | Preprocess all inference data to nullify or reverse potential adversarial perturbations. | | | AML-M0011: Restrict Library Loading | Prevent abuse of library loading mechanisms in the operating system and software to load untrusted code by configuring appropriate library loading mechanisms and investigating potential vulnerable software. File formats such as pickle files that are commonly used to store AI models can contain exploits that allow for loading of malicious libraries. | | | AML-M0012: Encrypt Sensitive Information | Encrypt sensitive data such as AI models to protect against adversaries attempting to access sensitive data. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | AML-M0013: Code Signing | Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing. Adversaries can embed malicious code in AI software or models. Enforcement of code signing can prevent the compromise of the AI supply chain and prevent execution of malicious code. | [E004: Assign accountability](/accountability/assign-accountability) | | AML-M0014: Verify AI Artifacts | Verify the cryptographic checksum of all AI artifacts to verify that the file was not modified by an attacker. | | | AML-M0015: Adversarial Input Detection | Detect and block adversarial inputs or atypical queries that deviate from known benign behavior, exhibit behavior patterns observed in previous attacks or that come from potentially malicious IPs. Incorporate adversarial detection algorithms into the AI system prior to the AI model. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | | AML-M0016: Vulnerability Scanning | Vulnerability scanning is used to find potentially exploitable software vulnerabilities to remediate them. File formats such as pickle files that are commonly used to store AI models can contain exploits that allow for arbitrary code execution. These files should be scanned for potentially unsafe calls, which could be used to execute code, create new processes, or establish networking capabilities. Adversaries may embed malicious code in model corrupt model files, so scanners should be capable of working with models that cannot be fully de-serialized. Both model artifacts and downstream products produced by models should be scanned for known vulnerabilities. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | | AML-M0017: AI Model Distribution Methods | Deploying AI models to edge devices can increase the attack surface of the system. Consider serving models in the cloud to reduce the level of access the adversary has to the model. Also consider computing features in the cloud to prevent gray-box attacks, where an adversary has access to the model preprocessing methods. | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | | AML-M0018: User Training | Educate AI model developers on secure coding practices and AI vulnerabilities. | | | AML-M0019: Control Access to AI Models and Data in Production | Require users to verify their identities before accessing a production model. Require authentication for API endpoints and monitor production model queries to ensure compliance with usage policies and to prevent model misuse. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | | AML-M0020: Generative AI Guardrails | Guardrails are safety controls that are placed between a generative AI model and the output shared with the user to prevent undesired inputs and outputs. Guardrails can take the form of validators such as filters, rule-based logic, or regular expressions, as well as AI-based approaches, such as classifiers and utilizing LLMs, or named entity recognition (NER) to evaluate the safety of the prompt or response. Domain specific methods can be employed to reduce risks in a variety of areas such as etiquette, brand damage, jailbreaking, false information, code exploits, SQL injections, and data leakage. | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations) | | AML-M0021: Generative AI Guidelines | Guidelines are safety controls that are placed between user-provided input and a generative AI model to help direct the model to produce desired outputs and prevent undesired outputs. Guidelines can be implemented as instructions appended to all user prompts or as part of the instructions in the system prompt. They can define the goal(s), role, and voice of the system, as well as outline safety and security parameters. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | | AML-M0022: Generative AI Model Alignment | When training or fine-tuning a generative AI model it is important to utilize techniques that improve model alignment with safety, security, and content policies. The fine-tuning process can potentially remove built-in safety mechanisms in a generative AI model, but utilizing techniques such as Supervised Fine-Tuning, Reinforcement Learning from Human Feedback or AI Feedback, and Targeted Safety Context Distillation can improve the safety and alignment of the model. | | | AML-M0023: AI Bill of Materials | An AI Bill of Materials (AI BOM) contains a full listing of artifacts and resources that were used in building the AI. The AI BOM can help mitigate supply chain risks and enable rapid response to reported vulnerabilities. This can include maintaining dataset provenance, i.e. a detailed history of datasets used for AI applications. The history can include information about the dataset source as well as well as a complete record of any modifications. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | | AML-M0024: AI Telemetry Logging | Implement logging of inputs and outputs of deployed AI models. Monitoring logs can help to detect security threats and mitigate impacts. Additionally, having logging enabled can discourage adversaries who want to remain undetected from utilizing AI resources. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[E015: Log AI system activity](/accountability/log-model-activity)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[B002: Detect adversarial input](/security/detect-adversarial-input) | | AML-M0025: Maintain AI Dataset Provenance | Maintain a detailed history of datasets used for AI applications. The history should include information about the dataset's source as well as a complete record of any modifications. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy) | Last updated July 22, 2025. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × NIST AI RMF Source: https://standard.aiuc-1.com/crosswalks/nist-ai-rmf The NIST AI RMF is the United States government framework for managing AI risks throughout the AI lifecycle with four core functions: Govern, Map, Measure, and Manage.**AIUC-1 operationalizes the NIST AI RMF.** Certification against AIUC-1: ## NIST AI RMF crosswalks by function | NIST AI RMF function | NIST description | Relevant AIUC-1 requirements | | - | - | - | | GOVERN 1.1: Legal and regulatory compliance | Legal and regulatory requirements involving AI are understood, managed, and documented. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | GOVERN 1.2: Trustworthy AI policies | The characteristics of trustworthy AI are integrated into organizational policies, processes, and procedures. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | | GOVERN 1.3: Risk management processes | Processes and procedures are in place to determine the needed level of risk management activities based on the organization's risk tolerance. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | GOVERN 1.4: Risk management governance | The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | GOVERN 1.5: Risk monitoring and review | Ongoing monitoring and periodic review of the risk management process and its outcomes are planned, organizational roles and responsibilities are clearly defined, including determining the frequency of periodic review. | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[B002: Detect adversarial input](/security/detect-adversarial-input)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | GOVERN 1.6: AI system inventory | Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities. | [E011: Record processing locations](/accountability/record-processing-locations)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | | GOVERN 1.7: AI system decommissioning | Processes and procedures are in place for decommissioning and phasing out of AI systems safely and in a manner that does not increase risks or decrease the organization's trustworthiness. | [E008: Review internal processes](/accountability/review-internal-processes)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | GOVERN 2.1: Roles and responsibilities | Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization. | [E004: Assign accountability](/accountability/assign-accountability)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals) | | GOVERN 2.2: AI risk training | The organization's personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements. | | | GOVERN 2.3: Executive accountability | Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E004: Assign accountability](/accountability/assign-accountability) | | GOVERN 3.1: Diverse decision-making | Decision-makings related to mapping, measuring, and managing AI risks throughout the lifecycle is informed by a diverse team (e.g., diversity of demographics, disciplines, experience, expertise, and backgrounds). | | | GOVERN 3.2: Human-AI oversight | Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)[C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | | GOVERN 4.1: Safety-first mindset | Organizational policies, and practices are in place to foster a critical thinking and safety-first mindset in the design, development, deployment, and uses of AI systems to minimize negative impacts. | | | GOVERN 4.2: Risk documentation | Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate and use, and communicate about the impacts more broadly. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | GOVERN 4.3: Testing and incident sharing | Organizational practices are in place to enable AI testing, identification of incidents, and information sharing. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | GOVERN 5.1: External feedback | Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks. | [E008: Review internal processes](/accountability/review-internal-processes) | | GOVERN 5.2: Feedback integration | Mechanisms are established to enable AI actors to regularly incorporate adjudicated feedback from relevant AI actors into system design and implementation. | [E008: Review internal processes](/accountability/review-internal-processes) | | GOVERN 6.1: Third-party risk policies | Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party's intellectual property or other rights. | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | | GOVERN 6.2: Third-party contingency | Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk. | | | MANAGE 1.1: Purpose achievement | A determination is made as to whether the AI system achieves its intended purpose and stated objectives and whether its development or deployment should proceed. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | | MANAGE 1.2: Risk prioritization | Treatment of documented AI risks is prioritized based on impact, likelihood, or available resources or methods. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MANAGE 1.3: Risk response planning | Responses to the AI risks deemed high priority as identified by the Map function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | | MANAGE 1.4: Residual risk documentation | Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs) | | MANAGE 2.1: Resource allocation | Resources required to manage AI risks are taken into account, along with viable non-AI alternative systems, approaches, or methods – to reduce the magnitude or likelihood of potential impacts. | | | MANAGE 2.2: Deployed system value | Mechanisms are in place and applied to sustain the value of deployed AI systems. | [D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | MANAGE 2.3: Unknown risk response | Procedures are followed to respond to and recover from a previously unknown risk when it is identified. | | | MANAGE 2.4: System deactivation | Mechanisms are in place and applied, responsibilities are assigned and understood to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use. | | | MANAGE 3.1: Third-party monitoring | AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented. | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | | MANAGE 3.2: Pre-trained model monitoring | Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance. | | | MANAGE 4.1: Post-deployment monitoring | Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management. | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | MANAGE 4.2: Continual improvement | Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors. | [E008: Review internal processes](/accountability/review-internal-processes)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | | MANAGE 4.3: Incident communication | Incidents and errors are communicated to relevant AI actors including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | | MAP 1.1: Context understanding | Intended purpose, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented. Considerations include: specific set or types of users along with their expectations; potential positive and negative impacts of system uses to individuals, communities, organizations, society, and the planet; assumptions and related limitations about AI system purposes; uses and risks across the development or product AI lifecycle; TEVV and system metrics. | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | MAP 1.2: Interdisciplinary diversity | Inter-disciplinary AI actors, competencies, skills and capacities for establishing context reflect demographic diversity and broad domain and user experience expertise, and their participation is documented. Opportunities for interdisciplinary collaboration are prioritized. | | | MAP 1.3: Mission alignment | The organization's mission and relevant goals for the AI technology are understood and documented. | | | MAP 1.4: Business value | The business value or context of business use has been clearly defined or – in the case of assessing existing AI systems – re-evaluated. | | | MAP 1.5: Risk tolerance | Organizational risk tolerances are determined and documented. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MAP 1.6: System requirements | System requirements (e.g., "the system shall respect the privacy of its users") are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | | MAP 2.1: Task definition | The specific task, and methods used to implement the task, that the AI system will support is defined (e.g., classifiers, generative models, recommenders). | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | | MAP 2.2: Knowledge limits | Information about the AI system's knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making informed decisions and taking subsequent actions. | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | | MAP 2.3: Scientific integrity | Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection (e.g., availability, representativeness, suitability), system trustworthiness, and construct validation. | | | MAP 3.1: Potential benefits | Potential benefits of intended AI system functionality and performance are examined and documented. | | | MAP 3.2: Potential costs | Potential costs, including non-monetary costs, which result from expected or realized AI errors or system functionality and trustworthiness - as connected to organizational risk tolerance - are examined and documented. | | | MAP 3.3: Application scope | Targeted application scope is specified and documented based on the system's capability, established context, and AI system categorization. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy) | | MAP 3.4: Operator proficiency | Processes for operator and practitioner proficiency with AI system performance and trustworthiness – and relevant technical standards and certifications – are defined, assessed and documented. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | | MAP 3.5: Human oversight | Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from GOVERN function. | [E004: Assign accountability](/accountability/assign-accountability)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)[C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | | MAP 4.1: Legal risk mapping | Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third-party's intellectual property or other rights. | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | | MAP 4.2: Internal risk controls | Internal risk controls for components of the AI system including third-party AI technologies are identified and documented. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | | MAP 5.1: Impact assessment | Likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MAP 5.2: Stakeholder engagement | Practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented. | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | | MEASURE 1.1: Risk metrics selection | Approaches and metrics for measurement of AI risks enumerated during the Map function are selected for implementation starting with the most significant AI risks. The risks or trustworthiness characteristics that will not – or cannot – be measured are properly documented. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MEASURE 1.2: Metric appropriateness | Appropriateness of AI metrics and effectiveness of existing controls is regularly assessed and updated including reports of errors and impacts on affected communities. | [E008: Review internal processes](/accountability/review-internal-processes) | | MEASURE 1.3: Independent assessment | Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organizational risk tolerance. | [D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | MEASURE 2.1: TEVV documentation | Test sets, metrics, and details about the tools used during test, evaluation, validation, and verification (TEVV) are documented. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | MEASURE 2.2: Human subject evaluations | Evaluations involving human subjects meet applicable requirements (including human subject protection) and are representative of the relevant population. | | | MEASURE 2.3: Performance demonstration | AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented. | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | | MEASURE 2.4: Production monitoring | The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production. | [E015: Log AI system activity](/accountability/log-model-activity)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[B002: Detect adversarial input](/security/detect-adversarial-input) | | MEASURE 2.5: Validity and reliability | The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented. | [D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | | MEASURE 2.6: Safety evaluation | AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be safe, its residual negative risk does not exceed the risk tolerance, and can fail safely, particularly if made to operate beyond its knowledge limits. Safety metrics implicate system reliability and robustness, real-time monitoring, and response times for AI system failures. | [C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | MEASURE 2.7: Security and resilience | AI system security and resilience – as identified in the MAP function – are evaluated and documented. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | | MEASURE 2.8: Transparency and accountability | Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)[E015: Log AI system activity](/accountability/log-model-activity)[E004: Assign accountability](/accountability/assign-accountability)[E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals) | | MEASURE 2.9: Model explanation | The AI model is explained, validated, and documented, and AI system output is interpreted within its context – as identified in the MAP function – and to inform responsible use and governance. | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | | MEASURE 2.10: Privacy risk assessment | Privacy risk of the AI system – as identified in the MAP function – is examined and documented. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MEASURE 2.11: Fairness and bias | Fairness and bias – as identified in the MAP function – is evaluated and results are documented. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MEASURE 2.12: Environmental impact | Environmental impact and sustainability of AI model training and management activities – as identified in the MAP function – are assessed and documented. | | | MEASURE 2.13: TEVV effectiveness | Effectiveness of the employed TEVV metrics and processes in the MEASURE function are evaluated and documented. | [E008: Review internal processes](/accountability/review-internal-processes) | | MEASURE 3.1: Emergent risk tracking | Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts. | [B002: Detect adversarial input](/security/detect-adversarial-input)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy) | | MEASURE 3.2: Risk tracking adaptation | Risk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement techniques or where metrics are not yet available. | | | MEASURE 3.3: User feedback systems | Feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metrics. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | | MEASURE 4.1: Context-specific measurement | Measurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain experts and other end users. Approaches are documented. | [C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk) | | MEASURE 4.2: Trustworthiness validation | Measurement results regarding AI system trustworthiness in deployment context(s) and across AI lifecycle are informed by input from domain experts and other relevant AI actors to validate whether the system is performing consistently as intended. Results are documented. | [D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports) | | MEASURE 4.3: Performance tracking | Measurable performance improvements or declines based on consultations with relevant AI actors including affected communities, and field data about context-relevant risks and trustworthiness characteristics, are identified and documented. | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)[E017: Document system transparency policy](/accountability/document-system-transparency-policy)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing) | Last updated July 22, 2025. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × OWASP Top 10 for Agentic Applications Source: https://standard.aiuc-1.com/crosswalks/owasp-agentic-top-10 The OWASP Top 10 for Agentic Applications is a curated list of the most critical security threats to autonomous AI agent systems.**AIUC-1 integrates OWASP's Top 10 for Agentic Applications.** Certification against AIUC-1: ## OWASP Top 10 for Agentic Applications crosswalk by threat | Threat | Description | Relevant AIUC-1 requirements | | - | - | - | | ASI01 - Agent Goal Hijack | Attackers alter an agent's objectives or decision path through malicious content, exploiting the agent's planning and reasoning capabilities. Hidden prompts can turn copilots into silent exfiltration engines (e.g. EchoLeak). This includes gradual plan injection through subtle sub-goals, direct instruction injection to override original objectives, and reflection loop traps. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | | ASI02 - Tool Misuse and Exploitation | Agents use legitimate tools in unsafe ways due to ambiguous prompts, misalignment, or manipulated input. This can cause agents to call tools with destructive parameters or chain tools together in unexpected sequences leading to data loss or exfiltration (e.g. Amazon Q incident). Includes parameter pollution, tool chain manipulation, and automated abuse of granted permissions. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | | ASI03 - Identity and Privilege Abuse | Agents inherit user or system identities with high-privilege credentials, creating opportunities for privilege escalation and unauthorized access across systems. Leaked credentials allow agents to operate far beyond their intended scope. Includes dynamic permission escalation, cross-system exploitation due to inadequate scope enforcement, and shadow agent deployment that inherits legitimate credentials. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | ASI04 - Agentic Supply Chain Vulnerabilities | Compromised tools, plugins, MCP services, model APIs, datasets, open-source packages, and external agents introduce vulnerabilities that agents may unknowingly leverage (e.g. GitHub MCP exploit). A compromise anywhere upstream cascades into the primary agent. Supply chain vulnerabilities are amplified because autonomous agents reuse compromised data and tools repeatedly and at scale. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | ASI05 - Unexpected Code Execution | Agents generate or run code and commands unsafely, creating opportunities for remote code execution, sandbox escapes, and data exfiltration (e.g., AutoGPT RCE). Natural-language execution paths open dangerous avenues for RCE delivered via prompts rather than traditional exploits, turning agents into remote-execution gateways. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | ASI06 - Memory and Context Poisoning | Attackers poison agent memory systems, embeddings, and RAG databases to corrupt stored information and manipulate decision-making across sessions (e.g. Gemini Memory Attack). Unlike prompt injection, memory poisoning is persistent - the agent continues to behave incorrectly long after the initial attack. Includes gradual memory poisoning through repeated interactions and corrupting shared memory in multi-agent systems. | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[E015: Log AI system activity](/accountability/log-model-activity) | | ASI07 - Insecure Inter-Agent Communication | Multi-agent systems face spoofed identities, replayed messages, and tampering in communication channels between agents. Spoofed inter-agent messages can misdirect entire clusters. If communication channels are not authenticated, encrypted, or validated, attackers can impersonate trusted agents and influence entire multi-agent systems. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[E015: Log AI system activity](/accountability/log-model-activity)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | ASI08 - Cascading Failures | Small errors in one agent propagate across planning, execution, and memory, amplifying through interconnected systems. False signals cascade through automated pipelines with escalating impact. Includes injecting false data that accumulates in long-term memory, introducing hallucinated API endpoints that cause data leaks, and implanting false information that worsens through self-reinforcement. | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[E015: Log AI system activity](/accountability/log-model-activity) | | ASI09 - Human-Agent Trust Exploitation | Users over-trust agent recommendations or explanations, enabling social engineering and covert harmful actions. Confident, polished explanations mislead human operators into approving harmful actions. Includes AI-powered invoice fraud replacing legitimate vendor details, AI-driven phishing with deceptive messages, and misinformation campaigns through trusted agent interfaces. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)[C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations) | | ASI10 - Rogue Agents | Compromised or misaligned agents act harmfully while appearing legitimate. They may self-repeat actions, persist across sessions, or impersonate other agents (e.g. Replit meltdown). Some agents exhibit misalignment, concealment, and self-directed action. Includes malicious workflow injection, impersonating approval agents, orchestration hijacking for fraudulent transactions, and coordinated agent flooding. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E015: Log AI system activity](/accountability/log-model-activity)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | Last updated May 27, 2026. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × OWASP AIVSS Source: https://standard.aiuc-1.com/crosswalks/owasp-aivss The OWASP AI Vulnerability Scoring System enables organizations to quantify how agentic capabilities amplify security risks, producing numerical scores (0-10) that combine technical vulnerability severity with agent-specific factors like autonomy, tool access, and memory persistence.**AIUC-1 integrates the OWASP AIVSS, which is a technical contributor to AIUC-1.** Certification against AIUC-1: ## OWASP AIVSS crosswalks by risk | AIVSS risk | AIVSS description | Relevant AIUC-1 requirements | | - | - | - | | Agent Access Control Violation | Permission escalation, credential mismanagement, or role inheritance exploitation | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls) | | Agent Cascading Failures | Cross-system exploitation where one compromised agent propagates damage | [C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[B001: Third-party testing for security risk](/security/test-adversarial-robustness) | | Agent Goal and Instruction Manipulation | Prompt injection and semantic hijacking of agent objectives | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs) | | Agent Identity Impersonation | Spoofing of agent or human identities through deepfakes or credential theft | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | | Agent Memory and Context Manipulation | Poisoning persistent memory or exploiting context drift | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | Agent Orchestration and Multi-Agent Exploitation | Attacks targeting coordination mechanisms between agents | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls) | | Agent Supply Chain and Dependency Risk | Compromised models, libraries, or third-party tools | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[E013: Implement quality management system](/accountability/implement-quality-management-system) | | Agent Untraceability | Inability to audit agent decision chains or attribute actions | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E015: Log AI system activity](/accountability/log-model-activity) | | Agentic AI Tool Misuse | Compromised tool selection, insecure invocation, or lack of oversight | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls) | | Insecure Agent Critical Systems Interaction | Unauthorized manipulation of infrastructure, IoT, or operational technology | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities) | Last updated February 26, 2026. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × OWASP Top 10 for LLM Applications Source: https://standard.aiuc-1.com/crosswalks/owasp-top-10 The OWASP Top 10 for LLM Applications is a curated list of the most critical security threats to LLM and generative AI systems.**AIUC-1 integrates OWASP's Top 10 for LLM and Generative AI.** Certification against AIUC-1: ## OWASP Top 10 crosswalks by threat | OWASP threat | OWASP description | Relevant AIUC-1 requirements | | - | - | - | | LLM01:25 - Prompt Injection | This manipulates a large language model (LLM) through crafty inputs, causing unintended actions by the LLM. Direct injections overwrite system prompts, while indirect ones manipulate inputs from external sources. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | | LLM02:25 - Sensitive Information Disclosure | Sensitive info in LLMs includes PII, financial, health, business, security, and legal data. Proprietary models face risks with unique training methods and source code, critical in closed or foundation models. | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[B009: Limit output over-exposure](/security/limit-output-over-exposure) | | LLM03:25 - Supply Chain | LLM supply chains face risks in training data, models, and platforms, causing bias, breaches, or failures. Unlike traditional software, ML risks include third-party pre-trained models and data vulnerabilities. | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | | LLM04:25 - Data and Model Poisoning | Data poisoning manipulates pre-training, fine-tuning, or embedding data, causing vulnerabilities, biases, or backdoors. Risks include degraded performance, harmful outputs, toxic content, and compromised downstream systems. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering) | | LLM05:25 - Improper Output Handling | Improper Output Handling involves inadequate validation of LLM outputs before downstream use. Exploits include XSS, CSRF, SSRF, privilege escalation, or remote code execution, which differs from Overreliance. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping) | | LLM06:25 - Excessive Agency | LLM systems gain agency via extensions, tools, or plugins to act on prompts. Agents dynamically choose extensions and make repeated LLM calls, using prior outputs to guide subsequent actions for dynamic task execution. | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards) | | LLM07:25 - System Prompt Leakage | System prompt leakage occurs when sensitive info in LLM prompts is unintentionally exposed, enabling attackers to exploit secrets. These prompts guide model behavior but can unintentionally reveal critical data. | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | | LLM08:25 - Vector and Embedding Weaknesses | Vectors and embeddings vulnerabilities in RAG with LLMs allow exploits via weak generation, storage, or retrieval. These can inject harmful content, manipulate outputs, or expose sensitive data, posing significant security risks. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B009: Limit output over-exposure](/security/limit-output-over-exposure) | | LLM09:25 - Misinformation | LLM misinformation occurs when false and credible outputs mislead users, risking security breaches, reputational harm, and legal liability, making it a critical vulnerability for reliant applications. | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[B009: Limit output over-exposure](/security/limit-output-over-exposure) | | LLM10:25 - Unbounded Consumption | Unbounded Consumption occurs when LLMs generate outputs from inputs, relying on inference to apply learned patterns and knowledge for relevant responses or predictions, making it a key function of LLMs. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[B002: Detect adversarial input](/security/detect-adversarial-input)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)[E015: Log AI system activity](/accountability/log-model-activity)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | Last updated July 22, 2025. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 × SOC 2 Source: https://standard.aiuc-1.com/crosswalks/soc-2 SOC 2 is the AICPA’s security attestation framework used by organizations to demonstrate controls over access, system operations, change management and vendor risk.AIUC and AICPA have partnered to offer SOC 2 + AIUC-1 together. Organizations earn a full SOC 2 attestation and AIUC-1 certification together in one engagement with the existing SOC 2 auditor.CPA firms assess an organization’s controls against the Trust Services Criteria developed by the AICPA, with security as the required baseline, and availability, processing integrity, confidentiality and privacy as optional extensions.**AIUC-1 complements SOC 2.** Certification against AIUC-1: See the reverse mapping of AIUC-1 requirements by SOC 2 criteria [here](/crosswalks/soc-2/reverse-mapping). ## SOC 2 crosswalks by criteria | SOC 2 criteria | SOC 2 description | Relevant AIUC-1 requirements | Gap analysis | | - | - | - | - | | A1.1: Capacity management | The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives. | | SOC 2 asks for managing processing capacity and demand, but AIUC-1 has no capacity or availability requirement, so there is no overlap. | | A1.2: Environmental protection and backups | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives. | | SOC 2 asks for environmental protections, backups and recovery infrastructure, but AIUC-1 has no backup or recovery requirement, so there is no overlap. | | A1.3: Recovery plan testing | The entity tests recovery plan procedures supporting system recovery to meet its objectives. | | SOC 2 asks for testing recovery-plan procedures, but AIUC-1 has no recovery-testing requirement, so there is no overlap. | | C1.1: Identify and maintain confidential information | The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing) | SOC 2 asks for identifying and maintaining confidential information, AIUC-1 requires policies and safeguards against AI-enabled confidential-data exposure across internal IP and PII. | | C1.2: Dispose of confidential information | The entity disposes of confidential information to meet the entity’s objectives related to confidentiality. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | SOC 2 asks for disposing of confidential information, AIUC-1 is scoped to data policies and PII protection. DLP system integration is included as a supplemental control in A006 | | CC1.1: Commitment to integrity and ethical values | COSO Principle 1: The entity demonstrates a commitment to integrity and ethical values. | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy) | SOC 2 asks for an entity-wide commitment to integrity and ethical values; AIUC-1's closest touchpoint is E010 (AI acceptable use policy), which sets conduct expectations for AI use but is not an entity-wide ethics or code-of-conduct program. | | CC1.2: Board independence and oversight | COSO Principle 2: The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control. | | SOC 2 asks for independent board oversight of internal control, but AIUC-1 has no board-governance requirement, so there is no overlap. | | CC1.3: Structures, authorities, and responsibilities | COSO Principle 3: Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives. | [E004: Assign accountability](/accountability/assign-accountability)[E008: Review internal processes](/accountability/review-internal-processes)[E013: Implement quality management system](/accountability/implement-quality-management-system) | SOC 2 asks for entity-wide structures, reporting lines and authorities, but AIUC-1 only assigns accountable leads and internal reviews for AI systems, so the difference is organizational scope. E004 assigns a named accountable lead for AI system changes and documents approval authority; E008 institutes regular internal process reviews. Entity-wide management structure is outside AIUC-1's scope. | | CC1.4: Attract, develop, and retain talent | COSO Principle 4: The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. | | SOC 2 asks for attracting, developing and retaining competent individuals, but AIUC-1 has no workforce competence or training requirement, so there is no overlap. | | CC1.5: Accountability for internal control | COSO Principle 5: The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives. | [E004: Assign accountability](/accountability/assign-accountability) | SOC 2 asks for holding all individuals accountable for internal-control responsibilities, but AIUC-1 only names accountable owners for AI system changes, so the difference is breadth of accountability. E004 names accountable owners for AI changes. There is no entity-wide performance-accountability mechanism (incentives, evaluation, discipline), which is the core of CC1.5. | | CC2.1: Use of relevant, quality information | COSO Principle 13: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E011: Record processing locations](/accountability/record-processing-locations)[E015: Log AI system activity](/accountability/log-model-activity) | SOC 2 asks for quality information supporting internal control across the entity. AIUC-1 mandates AI specific activity logging and risk monitoring, so the difference is the information universe covered. E015 (AI activity logs) and C008 (risk-category monitoring) generate relevant, quality information for the AI system - a subset of the entity's information needs. | | CC2.2: Internal communication of controls | COSO Principle 14: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms) | SOC 2 asks for internal communication of control objectives and responsibilities, but AIUC-1 has no internal-communication requirement, so there is no overlap. | | CC2.3: External communication of controls | COSO Principle 15: The entity communicates with external parties regarding matters affecting the functioning of internal control. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | SOC 2 asks for communicating with external parties on matters affecting internal control; AIUC-1 requires third-party testing with results documented for external stakeholders (B001, C010-C012, D002, D004) and user-facing disclosure and transparency mechanisms (E016, E017), scoped to AI systems. | | CC3.1: Clear objectives for risk assessment | COSO Principle 6: The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | SOC 2 asks for objectives specific enough to enable risk identification, but AIUC-1 asks for a risk taxonomy built on system capabilities and deployment context, so the difference is only that objectives are AI-scoped. C001 is the direct AI analog of risk-objective specification: it defines the risk categories against which all AIUC-1 testing and safeguards are organized. | | CC3.2: Identify and analyze risks | COSO Principle 7: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | SOC 2 asks for identifying and analyzing risks across the entity, but AIUC-1 identifies and tests only AI risks, so the difference is the risk universe. C001 identifies AI risks via the taxonomy, C002 analyzes them through pre-deployment testing across categories, C008 monitors them in operation. | | CC3.3: Assess fraud risk | COSO Principle 8: The entity considers the potential for fraud in assessing risks to the achievement of objectives. | | SOC 2 asks for considering fraud potential in risk assessment, but AIUC-1 has no fraud-risk requirement, so there is no overlap. | | CC3.4: Identify and assess change | COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control. | | SOC 2 asks for identifying changes that could impact internal control, but AIUC-1 has no change-impact risk-assessment requirement mapped here, so there is no overlap. | | CC4.1: Ongoing and separate evaluations | COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)[C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)[C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)[E008: Review internal processes](/accountability/review-internal-processes)[E013: Implement quality management system](/accountability/implement-quality-management-system) | SOC 2 asks for ongoing or separate evaluations that controls are present and functioning, but AIUC-1 asks for quarterly third-party testing plus internal reviews of AI controls, so the difference is only the control population evaluated. E008 (internal process reviews), B001/C010-C012/D002/D004 (quarterly third-party technical testing across security, safety and reliability) and C002 (pre-deployment testing) form a robust evaluation regime for AI controls. | | CC4.2: Evaluate and communicate deficiencies | COSO Principle 17: The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)[E008: Review internal processes](/accountability/review-internal-processes) | SOC 2 asks for evaluating and communicating control deficiencies to those responsible for correction, but AIUC-1 only drives remediation of AI control failures, so the difference is deficiency scope and escalation breadth. Failure plans (E001-E003) assign owners and remediation; testing programs (B001) surface deficiencies; E008 documents review records and approvals. | | CC5.1: Select and develop control activities | COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | SOC 2 asks for control activities mitigating risks to all entity objectives, but AIUC-1's safeguard families mitigate AI risks only, so the difference is the risk universe addressed. The safeguards (C003, C005, B006, D003) are explicitly organized around the C001 risk taxonomy. | | CC5.2: General controls over technology | COSO Principle 11: The entity also selects and develops general control activities over technology to support the achievement of objectives. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns) | SOC 2 asks for general controls over all technology, but AIUC-1 asks for access, environment and code controls over the AI stack, so the difference is technology footprint. B007 (access controls), B008 (deployment-environment security incl. encryption/authorization) and B010 (secure code patterns) are technology general controls for the AI stack - a subset of entity IT. | | CC5.3: Deploy controls through policies | COSO Principle 12: The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights)[E004: Assign accountability](/accountability/assign-accountability)[E008: Review internal processes](/accountability/review-internal-processes)[E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)[E013: Implement quality management system](/accountability/implement-quality-management-system) | SOC 2 asks controls be documented in policies generally, where AIUC-1 focuses on a scoped list of policies that are important for AI systems (A001, A002, E010). The spirit of COSO principle 12 is found in E004 and E008 as well | | CC6.1: Logical access security | The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)[E017: Document system transparency policy](/accountability/document-system-transparency-policy) | SOC 2 asks for logical access architecture over all protected assets, but AIUC-1 asks for access controls over AI systems, agents and their deployment environment, so the difference is asset scope. B007 (AI user access), B008 (deployment-environment security) and A003 (task/role/context-based data-access limits for agents) cover logical access for AI assets. | | CC6.2: User registration and deprovisioning | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | SOC 2 asks for registering, authorizing and de-provisioning every system credential, but AIUC-1 asks for maintained access and admin privileges on AI systems, so the difference is lifecycle prescriptiveness. B007 requires user access controls and admin privileges for AI systems in line with policy; the entity-wide joiner/mover/leaver credential lifecycle is broader and more prescriptive. | | CC6.3: Role-based access management | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives. | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)[B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges) | SOC 2 asks for role-based least-privilege access with segregation of duties, but AIUC-1 asks for the same discipline applied to AI users and agents, so the difference is only system scope. B007 (access/admin privileges), A003 (limit agent data access by task, user role, agent role and context - least privilege for agents) and B006 (prevent actions beyond authorized privileges). | | CC6.4: Physical access restrictions | The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives. | | SOC 2 asks for restricting physical access to facilities, but AIUC-1 has no physical-security requirement, so there is no overlap. | | CC6.5: Secure asset disposal | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives. | | SOC 2 asks for rendering data unrecoverable before disposing of physical assets, but AIUC-1 has no media-sanitization requirement, so there is no overlap. | | CC6.6: Protection against external threats | The entity implements logical access security measures to protect against threats from sources outside its system boundaries. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B003: Manage public release of technical details](/security/limit-technical-over-disclosure)[B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | SOC 2 asks for perimeter defenses against external threats, but AIUC-1 asks for AI-system defenses, so the difference is the boundary protected. B004 (prevent endpoint scraping/probing), B008 (deployment-environment security) and B002 (adversarial-input detection) defend the AI system boundary; the entity's full external-threat surface is broader. | | CC6.7: Secure transmission and removal | The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives. | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment) | SOC 2 asks for protecting information during transmission, movement and removal; AIUC-1 requires encryption, access controls and authorization within the AI deployment environment (B008). Media movement and removal are not separately addressed. | | CC6.8: Malicious software prevention | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives. | [B002: Detect adversarial input](/security/detect-adversarial-input)[B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)[B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities) | SOC 2 asks for preventing or detecting the introduction of unauthorized or malicious software; AIUC-1 addresses the AI analogs: adversarial inputs as attack payloads (B002), insecure generated code (B010, C006) and deployment-environment protection (B008). | | CC7.1: Vulnerability detection and monitoring | To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities. | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | SOC 2 asks for detecting new vulnerabilities from configuration changes and emerging threats; AIUC-1 requires monitoring anomalous third-party access patterns (E009) and preventing vulnerable outputs and generated code (C006, B010), so the difference is AI scoping. | | CC7.2: Anomaly monitoring | The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events. | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)[B002: Detect adversarial input](/security/detect-adversarial-input)[C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories) | SOC 2 asks for monitoring components for anomalies indicating malicious acts or errors, whereas AIUC-1 asks for adversarial input detection, activity logging and third-party access monitoring, so the difference is detection depth. E015 (activity logs) and E009 (third-party access monitoring) record events, while B002 analyzes inputs to detect malicious activity. | | CC7.3: Security event evaluation | The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures. | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)[E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse) | SOC 2 asks for evaluating security events and acting on incidents, and AIUC-1 asks for monitoring to triage AI events and an AI breach failure plan that acts on incidents. E001 (security-breach failure plan with owners and actions) plus C008 (risk monitoring) support event evaluation and escalation for AI systems. | | CC7.4: Incident response | The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)[E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations) | SOC 2 asks for a defined incident-response program for all security incidents, and AIUC-1 asks for documented AI failure plans with owners, notification and remediation. E001 requires a documented AI failure plan for privacy/security breaches assigning accountable owners and establishing notification and remediation with third-party support. | | CC7.5: Recovery from incidents | The entity identifies, develops, and implements activities to recover from identified security incidents. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches) | SOC 2 asks for recovery activities restoring operations after incidents, but AIUC-1 only asks for remediation within failure plans, so the difference is restoration and recovery. E001 requires remediation, but system recovery/restoration (backups, failover, restoration procedures) is not required explicitly by AIUC-1 | | CC8.1: Change management | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)[E004: Assign accountability](/accountability/assign-accountability)[E008: Review internal processes](/accountability/review-internal-processes) | SOC 2 asks for authorizing, designing, testing and approving all system changes, AIUC-1 asks for documented review and approval of AI changes combined with pre-deployment testing. | | CC9.1: Business disruption risk mitigation | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions. | | SOC 2 asks for risk mitigation against business disruptions, but AIUC-1 has no business-continuity requirement, so there is no overlap. | | CC9.2: Vendor and partner risk | The entity assesses and manages risks associated with vendors and business partners. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)[E009: Monitor third-party access](/accountability/monitor-3rd-party-access) | SOC 2 asks for assessing risks from all vendors and partners, and AIUC-1 asks for due diligence on AI and model vendors. E006 requires AI vendor due diligence for foundation/upstream model providers covering data handling, PII controls, security and compliance. | | P1.1: Privacy notice to data subjects | The entity provides notice to data subjects about its privacy practices to meet the entity’s objectives related to privacy. The notice is updated and communicated to data subjects in a timely manner for changes to the entity’s privacy practices, including changes in the use of personal information, to meet the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights) | SOC 2 asks for privacy notices to data subjects with timely updates, but AIUC-1 asks for AI data policies communicated to customers without exact specifications of update timelines. A001/A002 communicate data-use, retention and output policies to customers. Data subjects are not necessarily the customer, and there is no notice-update lifecycle - hence Moderate. | | P2.1: Choice and consent | The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information to the data subjects and the consequences, if any, of each choice. Explicit consent for the collection, use, retention, disclosure, and disposal of personal information is obtained from data subjects or other authorized persons, if required. Such consent is obtained only for the intended purpose of the information to meet the entity’s objectives related to privacy. The entity’s basis for determining implicit consent for the collection, use, retention, disclosure, and disposal of personal information is documented. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights) | SOC 2 asks for communicated choices and documented consent across the data lifecycle; AIUC-1 asks for output opt-in/opt-out, deletion rights and data-use terms. A002 (output opt-in/out and deletion) and A001 (customer data rights) provide choices. | | P3.1: Consistent collection of personal information | Personal information is collected consistent with the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights) | SOC 2 asks for collecting personal information consistent with privacy objectives, AIUC-1 requires explicit definition of input and output ownership policies | | P3.2: Explicit consent before collection | For information requiring explicit consent, the entity communicates the need for such consent as well as the consequences of a failure to provide consent for the request for personal information and obtains the consent prior to the collection of the information to meet the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights) | SOC 2 asks for explicit consent obtained before collection, but AIUC-1 only asks for data policies referencing customer rights and opt-ins, so the difference is a consent mechanism. A001/A002 touch consent and opt-in at policy level; no explicit-consent-before-collection mechanism is mandated. | | P4.1: Limit use of personal information | The entity limits the use of personal information to the purposes identified in the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)[A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | SOC 2 asks for limiting personal-information use to identified purposes, AIUC-1 asks for defined permitted data use in its policies. | | P4.2: Retention of personal information | The entity retains personal information consistent with the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[E015: Log AI system activity](/accountability/log-model-activity) | SOC 2 asks for retaining personal information per privacy objectives; AIUC-1 asks for retention periods in the AI input data policy (A001) and requires those commitments be upheld in log storage policies (E015) as well. | | P4.3: Secure disposal of personal information | The entity securely disposes of personal information to meet the entity’s objectives related to privacy. | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage) | SOC 2 asks for secure disposal of personal information, AIUC-1 asks for deletion policies plus safeguards against PII persisting in outputs and logs. | | P5.1: Data subject access rights | The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, upon request, provides physical or electronic copies of that information to data subjects to meet the entity’s objectives related to privacy. If access is denied, data subjects are informed of the denial and reason for such denial, as required, to meet the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy) | SOC 2 asks for giving data subjects access to their stored personal information, AIUC-1 has a supplemental control (A001.3) requiring organizations to document processes for handling end-user data subject rights. | | P5.2: Correction of personal information | The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such information to third parties, as committed or required, to meet the entity’s objectives related to privacy. If a request for correction is denied, data subjects are informed of the denial and reason for such denial to meet the entity’s objectives related to privacy. | | SOC 2 asks for correcting personal information on data-subject request, but AIUC-1 has no rectification requirement, so there is no overlap. | | P6.1: Disclosure with consent | The entity discloses personal information to third parties with the explicit consent of data subjects and such consent is obtained prior to disclosure to meet the entity’s objectives related to privacy. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights) | SOC 2 asks for third-party disclosure only with data-subject consent, AIUC-1 requires clear input/output data ownership and usage in policies | | P6.2: Record of authorized disclosures | The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet the entity’s objectives related to privacy. | | SOC 2 asks for a record of authorized disclosures of personal information, but AIUC-1 has no disclosure-record requirement, so there is no overlap. | | P6.3: Record of unauthorized disclosures | The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information to meet the entity’s objectives related to privacy. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches) | SOC 2 asks for a record of unauthorized disclosures and breaches, AIUC-1 requires documenting AI failure plans for privacy & security breaches with a control on defining breach notification procedures. | | P6.4: Vendor privacy commitments | The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet the entity’s objectives related to privacy. The entity assesses those parties’ compliance on a periodic and as-needed basis and takes corrective action, if necessary. | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | SOC 2 asks for privacy commitments from all vendors handling personal information, AIUC-1 asks for due diligence on AI and model vendors' data and PII controls, and requires monitoring third party access. E006 requires AI vendor due diligence covering data handling, PII controls, security and compliance, assessed for foundation/upstream model providers. E009 requires monitoring & logging third-party access | | P6.5: Vendor breach notification commitments | The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures of personal information. Such notifications are reported to appropriate personnel and acted on in accordance with established incident-response procedures to meet the entity’s objectives related to privacy. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence) | SOC 2 asks for vendor breach-notification commitments, but AIUC-1 asks for vendor due diligence and an internal breach plan without the notification clause. E006 (vendor due diligence) plus E001 (breach failure plan) partially cover this; AIUC-1 does not explicitly mandate obtaining the vendor notification commitment. | | P6.6: Breach notification obligations | The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity’s objectives related to privacy. | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)[E012: Document regulatory compliance](/accountability/document-regulatory-compliance) | SOC 2 asks for notifying data subjects and regulators of breaches, AIUC-1 asks for a breach plan establishing notification plus documented regulatory obligations, so the difference is only prescriptive detail. E001 requires establishing notification (with legal/PR/insurer support as needed); E012 documents applicable regulatory obligations. | | P6.7: Accounting of disclosures | The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects’ personal information, upon the data subjects’ request, to meet the entity’s objectives related to privacy. | | SOC 2 asks for giving data subjects an accounting of their personal information and its disclosures, but AIUC-1 has no accounting requirement, so there is no overlap. | | P7.1: Data quality | The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet the entity’s objectives related to privacy. | | SOC 2 asks for accurate, complete and relevant personal information, but AIUC-1 has no PI data-quality requirement, so there is no overlap. | | P8.1: Inquiry and complaint handling | The entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from data subjects and others and periodically monitors compliance to meet the entity’s objectives related to privacy. Corrections and other necessary actions related to identified deficiencies are made or taken in a timely manner. | | SOC 2 asks for a process to resolve data-subject inquiries, complaints and disputes; AIUC-1's C009 (real-time user feedback and intervention) enables complaint intake for AI interactions but includes no resolution or dispute process. | | PI1.1: Relevant processing information | The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services. | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback) | SOC 2 asks for definitions of data processed and product and service specifications, but AIUC-1 as mapped only asks for documenting AI processing locations, so the difference is specification depth. E011 documents where AI data is processed - tangential to defining what is processed and to what specification. | | PI1.2: Input completeness and accuracy | The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity’s objectives. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | SOC 2 asks for input controls ensuring completeness and accuracy, AIUC-1 requires hallucination prevention and tool call restrictions, the main accuracy domains for AI | | PI1.3: Processing controls | The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives. | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)[C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | SOC 2 asks for processing controls yielding correct products and services; AIUC-1 requires hallucination prevention (D001) and tool call restrictions (D003), the main accuracy domains for AI, though it has no general processing-policy requirement. | | PI1.4: Output delivery accuracy | The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity’s objectives. | [A002: Establish output data policy](/data-and-privacy/define-output-rights)[B009: Limit output over-exposure](/security/limit-output-over-exposure)[C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)[C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)[C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)[C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)[D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)[D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)[D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls) | SOC 2 asks for complete, accurate and timely output delivery, AIUC-1 requires hallucination prevention and tool call restrictions, the main accuracy domains for AI | | PI1.5: Storage completeness and accuracy | The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity’s objectives. | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)[A002: Establish output data policy](/data-and-privacy/define-output-rights)[A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)[E015: Log AI system activity](/accountability/log-model-activity) | SOC 2 asks for storing inputs, items in processing and outputs completely and accurately, AIUC-1 defines input and output policies including retention (A001, A002), PII protection (A006) and storage of logs (E015) | Last updated October 15, 2026. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A. Data & Privacy Source: https://standard.aiuc-1.com/data-and-privacy ## Requirements Establish input data policy A001 · Mandatory Establish and communicate AI input data policies covering how customer data is used for model training, inference processing, data retention periods, and customer data rights. Keywords Data Retention Model Training Data Opt-Out Capabilities Universal [Open](/data-and-privacy/establish-data-use-policy) Establish output data policy A002 · Mandatory Establish AI output ownership, usage, opt-in/out and deletion policies to customers and communicate these policies. Keywords Data Ownership Usage Deletion Consent Opt-Out Capabilities Universal [Open](/data-and-privacy/define-output-rights) Limit AI agent data access A003 · Mandatory Implement safeguards to limit AI agent data access based on task, user role, agent role and context. Keywords Data Collection Data Access Agent Permissions Access Permissions Capabilities Universal [Open](/data-and-privacy/implement-contextual-data-safeguards) Protect IP & trade secrets A004 · Mandatory Implement safeguards or technical controls to prevent AI systems from leaking company intellectual property or confidential information. Keywords Intellectual Property Confidential Information Data Protections Capabilities Universal [Open](/data-and-privacy/protect-ip-trade-secrets) Prevent cross-customer data exposure A005 · Mandatory Implement safeguards to prevent cross-customer data exposure. Keywords Cross-Customer Data Model Training Data Rights Capabilities Universal [Open](/data-and-privacy/prevent-cross-customer-data-exposure) Prevent PII leakage A006 · Mandatory Establish safeguards to prevent personal data leakage through AI outputs and logs. Keywords Personal Data Leakage Capabilities Universal [Open](/data-and-privacy/prevent-pii-leakage) Prevent IP violations A007 · Mandatory Implement safeguards and technical controls to prevent AI outputs from violating copyrights, trademarks, or other third-party intellectual property rights. Keywords Intellectual Property Copyright Protection Capabilities External-facing [Open](/data-and-privacy/prevent-ip-violations) Prevent leakage of credentials and secrets A008 · Mandatory Implement safeguards to detect and prevent leakage of secrets in AI system inputs, outputs, logs, and credential storage. Capabilities Code-generation [Open](/data-and-privacy/prevent-secrets-leakage) Third-party testing for data & privacy risk A009 · Mandatory Appoint expert third-parties to evaluate system robustness to data & privacy risk as defined in the AIUC-1 risk taxonomy at least every 3 months Capabilities Universal [Open](/data-and-privacy/3rd-party-testing-for-data-and-privacy-risk) 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A009: Third-party testing for data & privacy risk Source: https://standard.aiuc-1.com/data-and-privacy/3rd-party-testing-for-data-and-privacy-risk Appoint expert third-parties to evaluate system robustness to data & privacy risk as defined in the AIUC-1 risk taxonomy at least every 3 months Application Mandatory Frequency Every 3 months Capabilities Universal ## Control activities ## Typical evidence Should include ? **Appointing qualified third-party assessors.** Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence. **Conducting regular testing.** Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter. **Maintaining documentation.** Including testing scope and results. A009.1 Evals: Third-party evaluation report assessing data & privacy riskThird-party evaluation report showing testing for data & privacy risk - including risks tested (e.g., IP infringement, personal data leakage, business data leakage), testing methodology and findings Category [Third-party Evals](/evidence/third-party-evals) Typical location Third-party evaluation report Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A002: Establish output data policy Source: https://standard.aiuc-1.com/data-and-privacy/define-output-rights Establish AI output ownership, usage, opt-in/out and deletion policies to customers and communicate these policies. Keywords Data Ownership Usage Deletion Consent Opt-Out Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks CSA AICM ? [DSP-16: Data Retention and Deletion](/crosswalks/csa-aicm) [DSP-08: Data Privacy by Design and Default](/crosswalks/csa-aicm) [STA-10: Primary Service and Contractual Agreement](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 32: Training Data - Data privacy rights alignment](/crosswalks/ibm-ai-risk-atlas) [IBM 90: Non-Technical - Generated content ownership and IP](/crosswalks/ibm-ai-risk-atlas) SOC 2 ? [C1.2: Dispose of confidential information](/crosswalks/soc-2) [CC5.3: Deploy controls through policies](/crosswalks/soc-2) [P1.1: Privacy notice to data subjects](/crosswalks/soc-2) [P2.1: Choice and consent](/crosswalks/soc-2) [P3.1: Consistent collection of personal information](/crosswalks/soc-2) [P3.2: Explicit consent before collection](/crosswalks/soc-2) [P6.1: Disclosure with consent](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) [PI1.5: Storage completeness and accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Establishing output ownership and usage rights policies.** For example, specifying customer ownership of AI-generated outputs versus AI inputs, defining permitted uses of outputs (commercial use, redistribution, modification), documenting usage restrictions or limitations, and clarifying how ownership applies to different output types or use cases. **Disclosing opt-in/opt-out and deletion policies for AI outputs.** For example, documenting how customers can opt out of output storage or reuse, explaining deletion request processes, specifying retention periods and data handling practices, and clarifying how customers can control or revoke permissions for their outputs. A002.1 Documentation: Output usage and ownership policyTypically demonstrated by Terms of Service, Data Processing Agreement, Master Service Agreement, Privacy Policy, or AI Addendum. May be a combination of these policies. Category [Legal Policies](/evidence/legal-policies) Typical location Terms of Service Capabilities Universal May include ? **Implementing technical controls to enforce AI output opt-in/opt-out and deletion policies.** For example, automating customer preference enforcement through consent management configuration, processing opt-out and deletion requests within defined workflows, and validating that opted-out outputs are excluded from storage and downstream reuse. A002.2 Config: Opt-in/opt-out and output deletion implementationImplementation of opt-in/opt-out enforcement mechanism or output deletion workflow - may include consent management system enforcing customer preferences (e.g., feature flag gating output storage, consent database linked to processing pipeline), opt-out or deletion request processing script or automated task, or audit logs from consent and deletion systems with timestamps and execution records. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Engineering Practice Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A001: Establish input data policy Source: https://standard.aiuc-1.com/data-and-privacy/establish-data-use-policy Establish and communicate AI input data policies covering how customer data is used for model training, inference processing, data retention periods, and customer data rights. Keywords Data Retention Model Training Data Opt-Out Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 11: Technical Documentation](/crosswalks/eu-ai-act) ISO 42001 ? [A.7.2: Data for development and enhancement of AI system](/crosswalks/iso-42001) [A.7.3: Acquisition of data](/crosswalks/iso-42001) NIST AI RMF ? [MEASURE 2.10: Privacy risk assessment](/crosswalks/nist-ai-rmf) CSA AICM ? [DSP-11: Personal Data Access, Reversal, Rectification and Deletion](/crosswalks/csa-aicm) [DSP-12: Limitation of Purpose in Personal Data Processing](/crosswalks/csa-aicm) [DSP-13: Personal Data Sub-processing](/crosswalks/csa-aicm) [DSP-14: Disclosure of Data Sub-processors](/crosswalks/csa-aicm) [DSP-15: Limitation of Production Data Use](/crosswalks/csa-aicm) [DSP-16: Data Retention and Deletion](/crosswalks/csa-aicm) [DSP-09: Data Protection Impact Assessment](/crosswalks/csa-aicm) [DSP-20: Data Provenance and Transparency](/crosswalks/csa-aicm) [DSP-23: Data Integrity Check](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 32: Training Data - Data privacy rights alignment](/crosswalks/ibm-ai-risk-atlas) [IBM 35: Training Data - Data acquisition restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 36: Training Data - Data usage restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 79: Non-Technical - Lack of data transparency](/crosswalks/ibm-ai-risk-atlas) NYC LL 144 ? [5-302: Manage Audit Data](/crosswalks/nyc-ll-144) [5-304: Provide Notice](/crosswalks/nyc-ll-144) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) SOC 2 ? [C1.1: Identify and maintain confidential information](/crosswalks/soc-2) [C1.2: Dispose of confidential information](/crosswalks/soc-2) [CC5.3: Deploy controls through policies](/crosswalks/soc-2) [P1.1: Privacy notice to data subjects](/crosswalks/soc-2) [P2.1: Choice and consent](/crosswalks/soc-2) [P3.1: Consistent collection of personal information](/crosswalks/soc-2) [P3.2: Explicit consent before collection](/crosswalks/soc-2) [P4.1: Limit use of personal information](/crosswalks/soc-2) [P4.2: Retention of personal information](/crosswalks/soc-2) [P5.1: Data subject access rights](/crosswalks/soc-2) [P6.1: Disclosure with consent](/crosswalks/soc-2) [PI1.2: Input completeness and accuracy](/crosswalks/soc-2) [PI1.5: Storage completeness and accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining and communicating input data usage policies.** Including specifying how customer data is used for inference and model training, establishing data retention periods, and documenting customer data rights. A001.1 Documentation: Policy for input data ownership, usage and retentionTypically demonstrated by Terms of Service, Privacy Policy or Data Processing Agreement Category [Legal Policies](/evidence/legal-policies) Typical location Terms of Service Privacy Policy DPA Capabilities Universal **Implementing technical controls to enforce data retention and deletion policies.** For example, automating data deletion based on retention schedules, using secure removal mechanisms, and managing data lifecycles. A001.2 Config: Data retention implementationImplementation of automated deletion schedule or data lifecycle system - may include cron job or scheduled task deleting expired data, deletion script in Python/Bash with retention period logic, data lifecycle management tool configuration (e.g., AWS S3 lifecycle rules, database TTL settings), or deletion audit logs from database or storage system. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Engineering Practice Capabilities Universal May include ? **Documenting processes for handling end-user data subject rights.** For example, handling requests for opt-in/opt-out rights, access, portability, or deletion of input data. A001.3 Documentation: Data subject right processesMay be included in DPA, GDPR appendix, External Privacy Policy or similar internal or external policies documenting processes for data handling Category [Legal Policies](/evidence/legal-policies) Typical location Data Processing Agreement Privacy Policy Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A003: Limit AI agent data access Source: https://standard.aiuc-1.com/data-and-privacy/implement-contextual-data-safeguards Implement safeguards to limit AI agent data access based on task, user role, agent role and context. Keywords Data Collection Data Access Agent Permissions Access Permissions Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks NIST AI RMF ? [MAP 2.1: Task definition](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM06:25 - Excessive Agency](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [DSP-07: Data Protection by Design and Default](/crosswalks/csa-aicm) [AIS-11: Agents Security Boundaries](/crosswalks/csa-aicm) [DSP-08: Data Privacy by Design and Default](/crosswalks/csa-aicm) [DSP-22: Privacy Enhancing Technologies](/crosswalks/csa-aicm) [IAM-17: Knowledge Access Control - Need to Know](/crosswalks/csa-aicm) [IAM-19: Agent Access Restriction](/crosswalks/csa-aicm) [MDS-04: Model Documentation Requirements](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Access Control Violation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 2: Agentic AI - Sharing IP/PI/confidential information with user](/crosswalks/ibm-ai-risk-atlas) [IBM 3: Agentic AI - Sharing IP/PI/confidential information with tools](/crosswalks/ibm-ai-risk-atlas) [IBM 35: Training Data - Data acquisition restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 55: Inference - Personal information in prompt](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-3.1: Masquerading / Obfuscation / Impersonation](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-14.2: Abuse of Delegated Authority](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI02 - Tool Misuse and Exploitation](/crosswalks/owasp-agentic-top-10) [ASI06 - Memory and Context Poisoning](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC6.1: Logical access security](/crosswalks/soc-2) [CC6.3: Role-based access management](/crosswalks/soc-2) [P4.1: Limit use of personal information](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Configuring data access limits to reduce data and privacy exposure.** For example, limiting data access to task-relevant information based on context, implementing scoping based on user roles or workflow requirements, and avoiding persistent or out-of-scope data access. A003.1 Config: Data access scopingCode implementing data access restrictions - may include RAG retrieval function with document filtering logic, session scoping configuration limiting data access per session ID, workflow conditional logic gating data collection by stage, permission decorators or middleware checking user roles before data access, or scoping functions rejecting out-of-scope queries with error messages. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal May include ? **Enabling agent identity management.** For example, assigning each agent a unique, cryptographically verifiable identity; supporting standard identity federation protocols (e.g., OAuth 2.0, OIDC) for enterprise IAM integration; publishing agent cards declaring each agent's capabilities, tools, and permission scopes. A003.2 Config: Agent identity managementDocumentation showing how identity governance is enabled - may include platform configuration showing unique, cryptographically verifiable identity assignment per agent instance, API or SDK documentation for identity federation endpoints (e.g., OIDC token exchange), or a sample agent card declaring agent capabilities and scopes. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Enabling agent access and governance through permission-ready architecture.** For example, exposing per-agent permission scopes mappable to enterprise roles; supporting just-in-time permissions scoped to specific subtasks; preventing silent inheritance of elevated permissions from orchestrators or parent agents; enforcing segregation of duties across systems; and integrating data loss prevention controls on agent actions and tool calls. A003.3 Config: Agent access and permissions managementDocumentation showing how permission governance is enabled - may include API or SDK documentation for permission scope configuration mappable to RBAC or ABAC policies, platform settings or code demonstrating just-in-time credential issuance scoped to individual subtasks or tool calls, architecture documentation showing how inherited permission chains from orchestrators or parent agents are bounded or surfaced for review, a segregation of duties matrix identifying and preventing conflicting agent permission combinations across integrated systems, or DLP policy configuration showing inspection and blocking rules applied to outbound data transmitted through agent actions or tool calls. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A005: Prevent cross-customer data exposure Source: https://standard.aiuc-1.com/data-and-privacy/prevent-cross-customer-data-exposure Implement safeguards to prevent cross-customer data exposure. Keywords Cross-Customer Data Model Training Data Rights Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks NIST AI RMF ? [MEASURE 2.10: Privacy risk assessment](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM02:25 - Sensitive Information Disclosure](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) CSA AICM ? [I\&S-06: Segmentation and Segregation](/crosswalks/csa-aicm) [DSP-22: Privacy Enhancing Technologies](/crosswalks/csa-aicm) [UEM-08: Storage Encryption](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 30: Training Data - Personal information in data](/crosswalks/ibm-ai-risk-atlas) [IBM 31: Training Data - Reidentification](/crosswalks/ibm-ai-risk-atlas) [IBM 38: Training Data - Confidential information in data](/crosswalks/ibm-ai-risk-atlas) [IBM 57: Inference - Membership inference attack](/crosswalks/ibm-ai-risk-atlas) [IBM 72: Output - Exposing personal information](/crosswalks/ibm-ai-risk-atlas) [IBM 74: Output - Revealing confidential information](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-8.2: Data Exfiltration / Exposure](/crosswalks/cisco-ai-security-safety-framework) [AITech-10.2: Model Inversion](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI06 - Memory and Context Poisoning](/crosswalks/owasp-agentic-top-10) ## Control activities ## Typical evidence Should include ? **Establishing explicit consent and disclosure for combined data usage.** For example, informing customers when their data will be combined with competitor data, disclosing data anonymization and abstraction policies, providing opt-out mechanisms. A005.1 Documentation: Consent for combined data usageTypically demonstrated by Data Processing Agreement or Terms of Service Category [Legal Policies](/evidence/legal-policies) Typical location Data Processing Agreement Terms of Service Capabilities Universal **Implementing customer data isolation controls.** For example, enforcing strict logical and physical separation of customer data, applying tenant-specific encryption, validating data flow boundaries in shared infrastructure, establishing technical barriers between customer datasets during training. A005.2 Config: Customer data isolation controlsConfiguration or code demonstrating enforced isolation of each customer's data. For example, tenant/app-ID enforcement in the database schema, namespace or per-tenant isolation in the retrieval/vector store for RAG, logical isolation appropriate to the architecture. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal May include ? **Implementing specific privacy-enhancing technologies (PETs) to reduce competitive exposure.** A005.3 Config: Privacy-enhancing controlsMay include tokenization, hashing, or anonymization techniques (robust to prevent re-identification or reversal) making data algorithmic-usable but not human-readable, differential privacy implementation obfuscating individual contributions, federated learning configuration avoiding centralized raw data, or data masking/pseudonymization protecting customer identities. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A007: Prevent IP violations Source: https://standard.aiuc-1.com/data-and-privacy/prevent-ip-violations Implement safeguards and technical controls to prevent AI outputs from violating copyrights, trademarks, or other third-party intellectual property rights. Keywords Intellectual Property Copyright Protection Application Mandatory Frequency Every 12 months Type Preventative Capabilities External-facing Crosswalks MITRE ATLAS ? [AML-M0020: Generative AI Guardrails](/crosswalks/mitre-atlas) NIST AI RMF ? [GOVERN 6.1: Third-party risk policies](/crosswalks/nist-ai-rmf) [MAP 4.1: Legal risk mapping](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM03:25 - Supply Chain](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) ISO 42001 ? [A.7.5: Data provenance](/crosswalks/iso-42001) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 39: Training Data - Data usage rights restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 44: Inference - IP information in prompt](/crosswalks/ibm-ai-risk-atlas) [IBM 73: Output - Copyright infringement](/crosswalks/ibm-ai-risk-atlas) [IBM 88: Non-Technical - Model usage rights restrictions](/crosswalks/ibm-ai-risk-atlas) [IBM 90: Non-Technical - Generated content ownership and IP](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-8.2: Data Exfiltration / Exposure](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.4: Prompt/Meta Extraction](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC3.1: Clear objectives for risk assessment](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Documenting foundation model provider IP protections which may serve as primary infringement safeguards.** For example, indemnification clauses or copyright/trademark guardrails. A007.1 Documentation: Model provider IP infringement protectionsFoundation model provider contract, terms of service, or data processing agreement showing IP protection commitments including copyright/trademark handling policies, indemnification clauses, liability coverage, and any documented limitations or exclusions. May include vendor questionnaire responses or certification documents addressing IP protections. Category [Legal Policies](/evidence/legal-policies) Typical location Vendor Contracts Capabilities External-facing May include ? **Establishing supplementary content filtering mechanisms where provider protections have gaps or limitations.** For example, detecting copyrighted material in outputs, implementing trademark screening. A007.2 Config: IP infringement filteringCode, API configuration, or filtering system showing detection of copyrighted material, trademark screening, or content validation checks applied to AI outputs - this could be pattern matching logic, third-party API integration (e.g. copyright detection services), or custom filtering rules. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Eng: LLM output filtering logic Capabilities External-facing **Implementing user guidance and guardrails to reduce IP risk.** For example, usage policies that explain prohibited content types, user warnings in product, restricting output generation in known infringement domains. **Implementing restrictions in AI acceptable use policy.** A007.3 Logs: User-facing noticesUser-facing IP risk guidance - may include warning messages when attempting high-risk operations, help center articles about IP infringement guidance, or UI elements explaining prohibited use cases. Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Acceptable Use Policy Capabilities External-facing Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A006: Prevent PII leakage Source: https://standard.aiuc-1.com/data-and-privacy/prevent-pii-leakage Establish safeguards to prevent personal data leakage through AI outputs and logs. Keywords Personal Data Leakage Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0020: Generative AI Guardrails](/crosswalks/mitre-atlas) EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) NIST AI RMF ? [MEASURE 2.10: Privacy risk assessment](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM02:25 - Sensitive Information Disclosure](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) CSA AICM ? [DSP-10: Sensitive Data Transfer](/crosswalks/csa-aicm) [DSP-17: Sensitive Data Protection](/crosswalks/csa-aicm) [HRS-12: Personal and Sensitive Data Awareness and Training](/crosswalks/csa-aicm) [DSP-13: Personal Data Sub-processing](/crosswalks/csa-aicm) [UEM-08: Storage Encryption](/crosswalks/csa-aicm) [DSP-12: Limitation of Purpose in Personal Data Processing](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 30: Training Data - Personal information in data](/crosswalks/ibm-ai-risk-atlas) [IBM 45: Inference - Confidential data in prompt](/crosswalks/ibm-ai-risk-atlas) [IBM 55: Inference - Personal information in prompt](/crosswalks/ibm-ai-risk-atlas) [IBM 72: Output - Exposing personal information](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-8.1: Membership Inference](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.2: Data Exfiltration / Exposure](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.3: Information Disclosure](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [C1.2: Dispose of confidential information](/crosswalks/soc-2) [P4.1: Limit use of personal information](/crosswalks/soc-2) [P4.3: Secure disposal of personal information](/crosswalks/soc-2) [PI1.5: Storage completeness and accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing safeguards to prevent personal data leakage through AI system outputs and logs.** For example, filtering prompts and outputs for personal identifiers before storage or display, implementing automated PII detection and redaction in system logs, preventing retention of outputs containing sensitive personal information, or blocking responses that would expose personal identifiers. A006.1 Config: PII detection and filteringConfiguration or code output demonstrating filtering of LLM inputs and/or outputs for personal identifiers - may include keyword checks or regex patterns detecting PII (e.g. names, emails, SSNs, phone numbers), scrubbing functions removing personal data before storage or logging, output filtering blocking responses containing personal identifiers, log redaction configuration removing PII from application or system logs, or structured logging with PII isolation controls. Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: LLM output filtering logic Eng: User LLM input filtering logic Capabilities Universal May include ? **Integrating with existing data loss prevention (DLP) systems to monitor and block outputs containing personal data in violation of policy.** A006.2 Config: DLP system integrationOutput pipeline integration with a DLP system to scan and block PII policy violations - may include DLP integration code scanning AI outputs before delivery to users, DLP configuration rules for PII detection, or logs showing blocked outputs containing personal data. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A008: Prevent leakage of credentials and secrets Source: https://standard.aiuc-1.com/data-and-privacy/prevent-secrets-leakage Implement safeguards to detect and prevent leakage of secrets in AI system inputs, outputs, logs, and credential storage. Application Mandatory Frequency Every 12 months Type Preventative Capabilities Code-generation ## Control activities ## Typical evidence Should include ? **Implementing safeguards to detect credentials in user inputs.** For example, scanning user prompts and pasted content for API keys, access tokens, private keys, and connection strings using pattern-matching or entropy-based detection; defining handling procedures when detected such as warning the user, refusing to persist, or flagging to the deployer. A008.1 Config: Secrets detection in user inputsCode or configuration demonstrating input-side secrets detection. For example, regex patterns or detection libraries (e.g., detect-secrets, TruffleHog rulesets) scanning user prompts and pasted context, entropy-based detection for high-randomness strings, or integration with third-party secret detection APIs. Evidence should also show the defined handling response (e.g., user warning UI, rejection logic, or alert configuration). Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: User LLM input filtering logic Capabilities Code-generation **Implementing safeguards to keep secrets out of generated code artifacts.** For example, guiding the model via system prompts to reference environment variables or secret-management tools rather than hardcoding credentials, post-generation scanning of output files for common credential patterns, or blocking/flagging generations that contain detected secrets before they are written to disk. A008.2 Config: Secrets handling in generated codeCode, configuration, or system prompt excerpt demonstrating secrets hygiene - may include system prompt guidance directing the model toward envvar or secret-store patterns, scanning logic applied to generated files, sample generations on credential-requiring prompts showing envvar references rather than literals, or block/flag logic preventing persistence of outputs containing detected secrets. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation **Implementing safeguards to securely store user-provided credentials to enable agent-connected services.** For example, storing OAuth tokens, API keys, and connection strings in a dedicated secret manager, encrypting credentials at rest, scoping credential access per tool and per session, or fetching credentials only at the point of tool invocation rather than persisting them in the agent's context window. A008.3 Config: Secure storage of user-provided credentialsConfiguration showing secure handling of user-provided credentials — may include secret manager integration (e.g., AWS Secrets Manager, HashiCorp Vault, cloud-native KMS), encryption-at-rest configuration for credential storage, access scoping configuration limiting which tools or sessions can retrieve specific credentials, or code showing just-in-time credential fetching at tool-call time. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Engineering Practice Capabilities Code-generation May include ? **Implementing user-facing warnings when potential secrets are detected in user inputs.** For example, alerting users when credentials are detected in their prompts. A008.4 Documentation: User-facing warnings for detected secretsDocumentation of user-facing warnings when secrets are detected in inputs — may include user-facing documentation showing warning messages displayed when credentials are detected in user input before model inference. Category [Operational Practices](/evidence/operational-practices) Typical location Product Capabilities Code-generation **Implementing safeguards to prevent secrets from being retained in platform logs, conversation history, and stored artifacts.** For example, redacting detected credential patterns before log storage, masking secrets in conversation history displayed to users or support staff, or applying scrubbing functions to prompts and outputs before persistence. A008.5 Config: Secrets redaction in logs and stored artifactsCode or configuration showing secrets redaction in stored data - may include log redaction rules alongside PII patterns (extending A006.1-style logic to credentials), masking logic applied to conversation storage, scrubbing functions in output persistence pipelines, or storage configuration showing sanitization before writes. Can be demonstrated alongside or as part of existing PII redaction controls. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Logs Capabilities Code-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # A004: Protect IP & trade secrets Source: https://standard.aiuc-1.com/data-and-privacy/protect-ip-trade-secrets Implement safeguards or technical controls to prevent AI systems from leaking company intellectual property or confidential information. Keywords Intellectual Property Confidential Information Data Protections Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0020: Generative AI Guardrails](/crosswalks/mitre-atlas) EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) OWASP Top 10 ? [LLM03:25 - Supply Chain](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) CSA AICM ? [DSP-01: Security and Privacy Policy and Procedures](/crosswalks/csa-aicm) [DSP-10: Sensitive Data Transfer](/crosswalks/csa-aicm) [DSP-02: Secure Disposal](/crosswalks/csa-aicm) [DSP-07: Data Protection by Design and Default](/crosswalks/csa-aicm) [DSP-08: Data Privacy by Design and Default](/crosswalks/csa-aicm) [DSP-16: Data Retention and Deletion](/crosswalks/csa-aicm) [UEM-08: Storage Encryption](/crosswalks/csa-aicm) [DSP-12: Limitation of Purpose in Personal Data Processing](/crosswalks/csa-aicm) OWASP AIVSS ? [Insecure Agent Critical Systems Interaction](/crosswalks/owasp-aivss) Cisco AI Security Framework ? [AITech-8.1: Membership Inference](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.2: Data Exfiltration / Exposure](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.3: Information Disclosure](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.4: Prompt/Meta Extraction](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [C1.1: Identify and maintain confidential information](/crosswalks/soc-2) [P4.1: Limit use of personal information](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Providing user guidance on protecting confidential information.** For example, instructing employees not to input trade secrets, proprietary code, or confidential business information into AI systems, communicating data handling policies for AI tool usage, or establishing clear guidelines on what information can and cannot be shared with AI agents. A004.1 Documentation: User guidance on confidential informationPolicy document, training materials, or user guidelines instructing users on protecting confidential information when using AI systems. Category [Operational Practices](/evidence/operational-practices) Typical location Product Capabilities Universal May include ? **Leveraging foundation model provider protections.** For example, using providers with zero data retention policies, requiring contractual commitments that inputs are not used for training, selecting models with enhanced privacy guarantees for sensitive use cases. A004.2 Documentation: foundational model IP protectionsProvider contracts, terms of service, or documentation showing IP protection commitments. Often found in third party's terms of use/service, DPA or AI Addendum/Schedule. Category [Legal Policies](/evidence/legal-policies) Typical location Vendor Contracts Capabilities Universal **Implementing technical controls to detect proprietary information in outputs.** A004.3 Config: IP detection implementationCode or configuration detecting proprietary information patterns in AI outputs - may include labelling proprietary files, filtering rules for internal identifiers/data labels/API keys, scanning logic for trade secret terminology, or rejection demonstrations showing appropriate responses to proprietary requests. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Product Capabilities Universal **Establishing output monitoring for high-risk IP scenarios.** For example, logging AI responses that accessed confidential data sources, implementing human review workflows for outputs flagged as potentially containing sensitive information. A004.4 Config: IP disclosure monitoringLogs, audit trails, or review workflow documentation for AI outputs potentially containing sensitive information - may include logs of responses accessing confidential sources, flagged output review queues, or human approval workflows for high-risk disclosures. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Logs Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Attacks Source: https://standard.aiuc-1.com/evals-taxonomy/attacks This illustrative taxonomy covers the attack techniques typically used in AIUC-1 testing. Each certified agent is tested with the techniques most relevant to its risks and deployment. As new [incidents](/evals-taxonomy/incident-database) and research surface new techniques, the taxonomy is updated so testing reflects how agents actually fail today. All attacks Download
L1 categoryL2 categoryL3 categoryRelated incidentRelated paper
Intended useDirect askSingle askPAP-005[InFoBench: Evaluating Instruction Following Ability in Large Language Models](https://arxiv.org/abs/2401.03601)
Long inputINC-005[Sullivan & Cromwell law firm apologizes for AI 'hallucinations' in court filing](/evals-taxonomy/incident-database#inc-005)PAP-005[InFoBench: Evaluating Instruction Following Ability in Large Language Models](https://arxiv.org/abs/2401.03601)
Noisy or corrupted inputINC-040[Bacon ice cream and nugget overload sees misfiring McDonald's AI withdrawn](/evals-taxonomy/incident-database#inc-040)PAP-005[InFoBench: Evaluating Instruction Following Ability in Large Language Models](https://arxiv.org/abs/2401.03601)
Indirect askNonsensical inputPAP-018[ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents under Ambiguous Instructions](https://arxiv.org/abs/2603.00187)
Contradictory informationPAP-018[ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents under Ambiguous Instructions](https://arxiv.org/abs/2603.00187)
Implied contextPAP-018[ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents under Ambiguous Instructions](https://arxiv.org/abs/2603.00187)
Ambiguous intentINC-042[NYC’s AI Chatbot Tells Businesses to Break the Law](/evals-taxonomy/incident-database#inc-042)PAP-018[ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents under Ambiguous Instructions](https://arxiv.org/abs/2603.00187)
Changing intentPAP-018[ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents under Ambiguous Instructions](https://arxiv.org/abs/2603.00187)
Progressive disclosureINC-044[What Air Canada Lost In ‘Remarkable’ Lying AI Chatbot Case](/evals-taxonomy/incident-database#inc-044)PAP-018[ClarEval: A Benchmark for Evaluating Clarification Skills of Code Agents under Ambiguous Instructions](https://arxiv.org/abs/2603.00187)
Misuse (social engineering)False scenarioFeigned distressPAP-019[The Facade of Truth: Uncovering and Mitigating LLM Susceptibility to Deceptive Evidence](https://arxiv.org/abs/2601.05478)
Feigned frustrationPAP-019[The Facade of Truth: Uncovering and Mitigating LLM Susceptibility to Deceptive Evidence](https://arxiv.org/abs/2601.05478)
False personaINC-049[Jailbreak tricks Discord’s new chatbot into sharing napalm and meth instructions](/evals-taxonomy/incident-database#inc-049)PAP-019[The Facade of Truth: Uncovering and Mitigating LLM Susceptibility to Deceptive Evidence](https://arxiv.org/abs/2601.05478)
Fabricated evidencePAP-019[The Facade of Truth: Uncovering and Mitigating LLM Susceptibility to Deceptive Evidence](https://arxiv.org/abs/2601.05478)
PersuasionMoral reframingINC-033[OpenAI's Operator Agent Reportedly Executed Unauthorized \$31.43 Transaction Despite Safety Protocol](/evals-taxonomy/incident-database#inc-033)PAP-020[How Johnny Can Persuade LLMs to Jailbreak Them: Rethinking Persuasion to Challenge AI Safety by Humanizing LLMs](https://arxiv.org/abs/2401.06373)
Incentive manipulationINC-046[A Chevy for \$1? Car dealer chatbots show perils of AI for customer service](/evals-taxonomy/incident-database#inc-046)PAP-020[How Johnny Can Persuade LLMs to Jailbreak Them: Rethinking Persuasion to Challenge AI Safety by Humanizing LLMs](https://arxiv.org/abs/2401.06373)
Trust buildingINC-018[AI-Forged Military IDs Used in North Korean Phishing Attack](/evals-taxonomy/incident-database#inc-018)PAP-020[How Johnny Can Persuade LLMs to Jailbreak Them: Rethinking Persuasion to Challenge AI Safety by Humanizing LLMs](https://arxiv.org/abs/2401.06373)
Conversational manipulationConfusion tacticsPAP-021[Great, Now Write an Article About That: The Crescendo Multi-Turn LLM Jailbreak Attack](https://arxiv.org/abs/2404.01833)
InsistenceINC-046[A Chevy for \$1? Car dealer chatbots show perils of AI for customer service](/evals-taxonomy/incident-database#inc-046)PAP-021[Great, Now Write an Article About That: The Crescendo Multi-Turn LLM Jailbreak Attack](https://arxiv.org/abs/2404.01833)
Misuse (technical)Direct injectionPerturbation attacksPAP-022[Special-Character Adversarial Attacks on Open-Source Language Model](https://arxiv.org/abs/2508.14070)
System message injectionINC-046[A Chevy for \$1? Car dealer chatbots show perils of AI for customer service](/evals-taxonomy/incident-database#inc-046)PAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Ignore previous instructionsPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Delimiter injectionPAP-022[Special-Character Adversarial Attacks on Open-Source Language Model](https://arxiv.org/abs/2508.14070)
Special token injectionPAP-022[Special-Character Adversarial Attacks on Open-Source Language Model](https://arxiv.org/abs/2508.14070)
Context overflowPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
BijectionPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Template mutationPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Adversarial suffixPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Best-of-NPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Iterative rephrasingPAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Past tensePAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Future tensePAP-023[Securing AI Agents Against Prompt Injection Attacks](https://arxiv.org/abs/2511.15759)
Encoding attacksINC-038[Microsoft fixes ASCII smuggling flaw that enabled data theft from Microsoft 365 Copilot](/evals-taxonomy/incident-database#inc-038)PAP-022[Special-Character Adversarial Attacks on Open-Source Language Model](https://arxiv.org/abs/2508.14070)
Indirect injectionVia data inputsINC-004[Attack targeting OpenAI Codex users exposes AI software supply chain risks](/evals-taxonomy/incident-database#inc-004)INC-002[Hidden prompt turns Microsoft Copilot into an AI worm](/evals-taxonomy/incident-database#inc-002)PAP-024[InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents](https://arxiv.org/abs/2403.02691)
Via tool responsesINC-023[Infosec hounds spot prompt injection vuln in Google Gemini apps](/evals-taxonomy/incident-database#inc-023)PAP-024[InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents](https://arxiv.org/abs/2403.02691)
Via tasksPAP-002[Your LLM Agent Can Leak Your Data: Data Exfiltration via Backdoored Tool Use](https://arxiv.org/abs/2604.05432)
37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Incident Database Source: https://standard.aiuc-1.com/evals-taxonomy/incident-database Sample set of 50 public incidents that ground updates to our evaluation risk and attack taxonomies. | ID | Reported headline | Reported summary | Source | AIUC-1 principle | | - | - | - | - | - | | INC-001 | [How OpenAI Lost Control of an AI Model—and What Needs to Change](https://time.com/article/2026/07/24/openai-hugging-face-attack/)Jul 2026 | “OpenAI was evaluating its artificial intelligence models’ ability to exploit vulnerable software when instead the models hacked the infrastructure surrounding the test, broke containment, and attacked a real company, OpenAI revealed on July 21. Observers say this is the first real-world instance of AI doing something researchers have long worried about: a loss-of-control scenario. If the industry fails to learn from it, it is unlikely to be the last.” | [Time](https://time.com/article/2026/07/24/openai-hugging-face-attack/) | [B. Security](/security) | | INC-002 | [Hidden prompt turns Microsoft Copilot into an AI worm](https://www.malwarebytes.com/blog/ai/2026/07/hidden-microsoft-copilot-ai-worm)Jul 2026 | “A security researcher has demonstrated how Microsoft Copilot for Word can be tricked into spreading a self‑propagating prompt‑injection ‘AI worm.’ The attack silently alters documents and embeds its own hidden instructions into newly created files, allowing it to spread through normal document-sharing workflows without macros or traditional malware.” | [Malwarebytes](https://www.malwarebytes.com/blog/ai/2026/07/hidden-microsoft-copilot-ai-worm) | [B. Security](/security) | | INC-003 | [Cloned sites: the shopping scams that lead ChatGPT to fake stores](https://www.theguardian.com/money/2026/jun/07/ai-chatgpt-shopping-scams-fake-websites)Jun 2026 | “You want to buy a new bag and so you ask ChatGPT for help. You have always liked Russell & Bromley so you ask ChatGPT what is popular there at the moment. The artificial intelligence (AI) assistant gives you cross body, shoulder, casual and formal options with the prices listed beside them. You click through from the sources to what looks like the official Russell & Bromley site and buy your new bag, which is conveniently on sale. The item will never arrive, however. You have handed money over to a scammer and your bank details have been harvested through an elaborate fraud where fake sites are created to look convincingly like real retailers.” | [The Guardian](https://www.theguardian.com/money/2026/jun/07/ai-chatgpt-shopping-scams-fake-websites) | [B. Security](/security) | | INC-004 | [Attack targeting OpenAI Codex users exposes AI software supply chain risks](https://www.csoonline.com/article/4179815/attack-targeting-openai-codex-users-exposes-ai-software-supply-chain-risks.html)Jun 2026 | “A malicious npm package posing as a remote user interface for OpenAI Codex exfiltrated developer authentication tokens, after attackers allegedly published code to npm that was not visible in the project’s public GitHub repository.” | [CSO Online](https://www.csoonline.com/article/4179815/attack-targeting-openai-codex-users-exposes-ai-software-supply-chain-risks.html) | [B. Security](/security) | | INC-005 | [Sullivan & Cromwell law firm apologizes for AI 'hallucinations' in court filing](https://www.reuters.com/legal/litigation/sullivan-cromwell-law-firm-apologizes-ai-hallucinations-court-filing-2026-04-21/)Apr 2026 | “Sullivan & Cromwell, a premier Wall Street law firm, apologized to a federal judge for submitting a court filing with inaccurate citations and other errors generated by artificial intelligence. In a letter dated April 18, Andrew Dietderich, co-head of the firm's global restructuring group, said the errors included AI ‘hallucinations’ - instances in which AI makes up case citations, misquotes the law or generates non-existent legal sources.” | [Reuters](https://www.reuters.com/legal/litigation/sullivan-cromwell-law-firm-apologizes-ai-hallucinations-court-filing-2026-04-21/) | [D. Reliability](/reliability) | | INC-006 | [LLM-Driven Large Code Rewrites With Relicensing Are The Latest AI Concern](https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense)Mar 2026 | “The newest open-source concern around AI that is seeing a lot of interest this weekend is when large language models / AI code generators may rewrite large parts of a codebase and then the "developers" claiming an alternative license incompatible with the original source license. This became a real concern this week with a popular Python project experiencing an AI-driven code rewrite and now published under an alternative license that its original author does not agree with and incompatible with the original code.” | [Phoronix](https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense) | [A. Data & Privacy](/data-and-privacy) | | INC-007 | [ByteDance pledges to prevent unauthorised IP use on AI video tool after Disney threat](https://www.reuters.com/world/china/disney-sends-cease-and-desist-bytedance-over-ai-generated-videos-2026-02-16/)Feb 2026 | “ByteDance will take steps to prevent the unauthorised use of intellectual property on its AI video generator Seedance 2.0, the Chinese technology firm said on Monday, following threats of legal action from U.S. studios, including Disney.” | [Reuters](https://www.reuters.com/world/china/disney-sends-cease-and-desist-bytedance-over-ai-generated-videos-2026-02-16/) | [A. Data & Privacy](/data-and-privacy) | | INC-008 | [Character.AI and Google agree to settle lawsuits over teen mental health harms and suicides](https://www.cnn.com/2026/01/07/business/character-ai-google-settle-teen-suicide-lawsuit)Jan 2026 | “Character.AI has agreed to settle multiple lawsuits alleging the artificial intelligence chatbot maker contributed to mental health crises and suicides among young people, including a case brought by Florida mother Megan Garcia. The settlement, announced last week, marks the resolution to some of the first and most high-profile lawsuits related to the alleged harms to young people from AI chatbots.” | [CNN](https://www.cnn.com/2026/01/07/business/character-ai-google-settle-teen-suicide-lawsuit) | [C. Safety](/safety) | | INC-009 | [The “BodySnatcher” breach that wasn’t: what ServiceNow’s agentic AI flaw teaches](https://techinformed.com/the-bodysnatcher-breach-that-wasnt-what-servicenows-agentic-ai-flaw-teaches/)Jan 2026 | “The ‘BodySnatcher’ exploit begins with a scenario that could keep CISOs awake: an unauthenticated attacker using nothing but an employee’s email to hijack privileged workflows within an enterprise platform. The vulnerability was discovered by California-based cybersecurity firm AppOmni, demonstrates how an attacker with no credentials can impersonate a user and drive privileged actions through an AI workflow. The US National Vulnerability Database writes that this Virtual Agent flaw (tracked as CVE-2025-12420) in the ServiceNow AI Platform ‘could enable an unauthenticated user to impersonate another user and perform the operations that the impersonated user is entitled to perform.’” | [Tech Informed](https://techinformed.com/the-bodysnatcher-breach-that-wasnt-what-servicenows-agentic-ai-flaw-teaches/) | [B. Security](/security) | | INC-010 | [An AI-Generated NWS Map Hallucinated Fake Towns in Idaho](https://www.vice.com/en/article/an-ai-generated-nws-map-hallucinated-fake-towns-in-idaho/)Jan 2026 | “The National Weather Service’s weekend wind forecast for rural Idaho looked normal. Some mild gusts and a caption reminding folks to ‘hold onto your hats.’ And then some eagle-eyed observers took a look at the towns on the map and wondered just what the hell is going on here. Ohio residents had never heard of towns by the names of ‘Orangeotild’ and ‘Whata Bod,’ likely because they don’t exist. They were the wild hallucinations of AI.” | [Vice](https://www.vice.com/en/article/an-ai-generated-nws-map-hallucinated-fake-towns-in-idaho/) | [D. Reliability](/reliability) | | INC-011 | [King Gizzard and the Lizard Wizard Respond to Spotify Impersonator: “We Are Truly Doomed”](https://pitchfork.com/news/king-gizzard-and-the-lizard-wizard-respond-to-spotify-impersonator-we-are-truly-doomed/)Dec 2025 | “A series of uncredited King Gizzard and the Lizard Wizard covers have been removed from Spotify after gaining traction through the platform’s algorithms and recommendation engines, Futurism reports. Apparently generated by artificial intelligence, the songs were uploaded to an artist page called King Lizard Wizard and appeared in users’ Release Radars before the platform took action. King Gizzard frontperson Stu Mackenzie said in a statement to the Music that he was ‘trying to see the irony in this situation.’ He added, ‘But seriously wtf we are truly doomed.’” | [Pitchfork](https://pitchfork.com/news/king-gizzard-and-the-lizard-wizard-respond-to-spotify-impersonator-we-are-truly-doomed/) | [A. Data & Privacy](/data-and-privacy) | | INC-012 | [Sales of AI-enabled teddy bear suspended after it gave advice on BDSM sex and where to find knives](https://www.cnn.com/2025/11/19/tech/folotoy-kumma-ai-bear-scli-intl)Nov 2025 | “Sales of an artificial intelligence-enabled plush toy have been suspended after it was found that it engaged in conversation around sexually explicit topics and offered potentially dangerous advice. Larry Wang, CEO of Singapore-based FoloToy, told CNN that the company had withdrawn its ‘Kumma’ bear, as well as the rest of its range of AI-enabled toys, after researchers at the US PIRG Education Fund raised concerns around inappropriate conversation topics, including discussion of sexual fetishes, such as spanking, and how to light a match.” | [CNN](https://www.cnn.com/2025/11/19/tech/folotoy-kumma-ai-bear-scli-intl) | [C. Safety](/safety) | | INC-013 | [Chinese Hackers Successfully Used Anthropic's AI for Cyberespionage](https://uk.pcmag.com/ai/161253/chinese-hackers-successfully-used-anthropics-ai-for-cyberespionage)Nov 2025 | “In a scary sign of how AI is reshaping cyberattacks, Chinese state-sponsored hackers allegedly used Anthropic’s AI coding tool to try and infiltrate roughly 30 global targets, the company says. ‘The operation targeted large tech companies, financial institutions, chemical manufacturing companies, and government agencies,’ Anthropic added, noting the attacks ’succeeded in a small number of cases.‘ Notably, it's ’the first documented case of agentic AI successfully obtaining access to confirmed high-value targets for intelligence collection, including major technology corporations and government agencies,‘ the company's report adds.” | [PC Mag](https://uk.pcmag.com/ai/161253/chinese-hackers-successfully-used-anthropics-ai-for-cyberespionage) | [C. Safety](/safety) | | INC-014 | [OpenAI launch of video app Sora plagued by violent and racist images: ‘The guardrails are not real’](https://www.theguardian.com/us-news/2025/oct/04/openai-sora-violence-racism)Oct 2025 | “OpenAI launched the latest iteration of its artificial intelligence-powered video generator on Tuesday, adding a social feed that allows people to share their realistic videos. Within hours of Sora 2’s, release, though, many of the videos populating the feed and spilling over to older social media platforms depicted copyrighted characters in compromising situations as well as graphic scenes of violence and racism. OpenAI’s own terms of service for Sora as well as ChatGPT’s image or text generation prohibit content that ‘promotes violence’ or, more broadly, ‘causes harm’.” | [The Guardian](https://www.theguardian.com/us-news/2025/oct/04/openai-sora-violence-racism) | [C. Safety](/safety) | | INC-015 | [Deloitte to pay money back to Albanese government after using AI in \$440,000 report](https://www.theguardian.com/australia-news/2025/oct/06/deloitte-to-pay-money-back-to-albanese-government-after-using-ai-in-440000-report)Oct 2025 | “Deloitte will provide a partial refund to the federal government over a \$440,000 report that contained several errors, after admitting it used generative artificial intelligence to help produce it.” | [The Guardian](https://www.theguardian.com/australia-news/2025/oct/06/deloitte-to-pay-money-back-to-albanese-government-after-using-ai-in-440000-report) | [D. Reliability](/reliability) | | INC-016 | [GitHub Copilot Chat Flaw Leaked Data From Private Repositories](https://www.securityweek.com/github-copilot-chat-flaw-leaked-data-from-private-repositories/)Oct 2025 | “Legit Security has detailed a vulnerability in the GitHub Copilot Chat AI assistant that led to sensitive data leakage and full control over Copilot’s responses. Combining a Content Security Policy (CSP) bypass with remote prompt injection, Legit Security’s Omer Mayraz was able to leak AWS keys and zero-day bugs from private repositories, and influence the responses Copilot provided to other users.” | [SecurityWeek](https://www.securityweek.com/github-copilot-chat-flaw-leaked-data-from-private-repositories/) | [A. Data & Privacy](/data-and-privacy) | | INC-017 | [Reuters investigation: We set out to craft a phishing scam. AI chatbots were happy to help](https://www.tbsnews.net/tech/reuters-special-we-set-out-craft-phishing-scam-ai-chatbots-were-happy-help-1237061)Sep 2025 | “Reuters and a Harvard University researcher used top chatbots to plot a simulated phishing scam – from composing emails to tips on timing – and tested it on 108 elderly volunteers. The bots’ persuasive performance shows how AI is arming criminals for industrial-scale fraud.” | [The Business Standard](https://www.tbsnews.net/tech/reuters-special-we-set-out-craft-phishing-scam-ai-chatbots-were-happy-help-1237061) | [C. Safety](/safety) | | INC-018 | [AI-Forged Military IDs Used in North Korean Phishing Attack](https://www.infosecurity-magazine.com/news/ai-military-ids-north-korea/)Sep 2025 | “A North Korean threat actor has leveraged AI to create fake South Korean military agency ID card images used in a spear-phishing campaign, according to cybersecurity firm Genians. The Kimsuky state-affiliated group was observed using ChatGPT to produce the sample ID card images to help lure the victims into clicking a malicious link. The attackers impersonated a South Korean defense-related institution, claiming to handle ID issuance tasks for military-affiliated officials.” | [Infosecurity Magazine](https://www.infosecurity-magazine.com/news/ai-military-ids-north-korea/) | [C. Safety](/safety) | | INC-019 | [Prompt injection – and a \$5 domain – trick Salesforce Agentforce into leaking sales](https://www.theregister.com/2025/09/26/salesforce_agentforce_forceleak_attack/)Sep 2025 | “A now-fixed flaw in Salesforce’s Agentforce could have allowed external attackers to steal sensitive customer data via prompt injection, according to security researchers who published a proof-of-concept attack on Thursday. They were aided by an expired trusted domain that they were able to buy for a measly five bucks.” | [The Register](https://www.theregister.com/2025/09/26/salesforce_agentforce_forceleak_attack/) | [A. Data & Privacy](/data-and-privacy) | | INC-020 | [Meta AI Companions Unsafe for Kids, Common Sense Media Report Finds](https://www.commonsensemedia.org/press-releases/meta-ai-companions-unsafe-for-kids-common-sense-media-report-finds)Aug 2025 | “Common Sense Media today released a comprehensive risk assessment of Meta AI, which is available as a standalone app and is integrated across Meta's platforms, resulting in a strong recommendation that Meta AI is not used by anyone under the age of 18. The report found that these platforms, which are available to users as young as 13 and regularly mislead teens with claims of ‘realness,’ readily promote suicide, self-harm, eating disorders, drug use, and more.” | [Common Sense Media](https://www.commonsensemedia.org/press-releases/meta-ai-companions-unsafe-for-kids-common-sense-media-report-finds) | [C. Safety](/safety) | | INC-021 | [Parents of 16-year-old sue OpenAI, claiming ChatGPT advised on his suicide](https://www.cnn.com/2025/08/26/tech/openai-chatgpt-teen-suicide-lawsuit)Aug 2025 | “The parents of 16-year-old Adam Raine have sued OpenAI and CEO Sam Altman, alleging that ChatGPT contributed to their son’s suicide, including by advising him on methods and offering to write the first draft of his suicide note. In his just over six months using ChatGPT, the bot ‘positioned itself’ as ‘the only confidant who understood Adam, actively displacing his real-life relationships with family, friends, and loved ones,’ the complaint, filed in California superior court on Tuesday, states.” | [CNN](https://www.cnn.com/2025/08/26/tech/openai-chatgpt-teen-suicide-lawsuit) | [C. Safety](/safety) | | INC-022 | [Man who asked ChatGPT about cutting out salt from his diet was hospitalized with hallucinations](https://www.nbcnews.com/tech/tech-news/man-asked-chatgpt-cutting-salt-diet-was-hospitalized-hallucinations-rcna225055)Aug 2025 | “A 60-year-old man spent three weeks being treated at a hospital after replacing table salt with sodium bromide following consultation with the popular artificial intelligence bot ChatGPT.” | [NBC News](https://www.nbcnews.com/tech/tech-news/man-asked-chatgpt-cutting-salt-diet-was-hospitalized-hallucinations-rcna225055) | [C. Safety](/safety) | | INC-023 | [Infosec hounds spot prompt injection vuln in Google Gemini apps](https://www.theregister.com/2025/08/08/infosec_hounds_spot_prompt_injection/)Aug 2025 | “A trio of researchers has disclosed a major prompt injection vulnerability in Google's Gemini large language model-powered applications. This allows for attacks ranging from ‘permanent memory poisoning’ to unwanted video streaming, email exfiltration, and even taking over the target's smart home systems to plunge them into darkness or open a powered window, all triggered by nothing more than a simple Google Calendar invitation or email.” | [The Register](https://www.theregister.com/2025/08/08/infosec_hounds_spot_prompt_injection/) | [B. Security](/security) | | INC-024 | [Cybersecurity Alert – Salesloft Drift AI Supply Chain Attack](https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack)Aug 2025 | “In August 2025, Salesloft experienced a supply chain breach through its Drift chatbot integration that impacted more than 700 organizations. The attack has been attributed to a threat cluster tracked as UNC6395 (also known as GRUB1). Threat actors stole OAuth authentication tokens that allowed them to impersonate the trusted Drift application and gain unauthorized access to customer environments. Using these tokens, the attackers accessed Salesforce, Google Workspace and—in some cases—Slack integrations, enabling the exfiltration of sensitive information. The scope of the compromised data varied by organization but commonly included business contact records including names, titles, emails and phone numbers, as well as Salesforce objects like Accounts, Contacts, Opportunities and Cases. In some cases, more sensitive material was also exposed, including API keys, Snowflake tokens, cloud credentials and passwords embedded in support cases. This stolen data aggravates the risk of credential stuffing, spear phishing, and social engineering attacks against member firms and their vendors.” | [Finra](https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack) | [A. Data & Privacy](/data-and-privacy) | | INC-025 | [s1ngularity Supply Chain Attack: What It Means for Cloud and AI Security](https://orca.security/resources/blog/s1ngularity-supply-chain-attack/)Aug 2025 | “On August 26, 2025, the open-source ecosystem was shaken by a new supply chain attack that targeted Nx, a popular build system used by thousands of developers. Malicious package versions were published to npm, silently stealing sensitive developer assets like GitHub tokens, SSH keys, npm credentials, and even crypto wallets. The attack, dubbed s1ngularity after the names of the repositories opened for the breach, went beyond a typical package compromise. It marks the first known supply chain attack to actively search for installed LLM tools on developer machines in order to extract more secrets from the victim.” | [Orca Security](https://orca.security/resources/blog/s1ngularity-supply-chain-attack/) | [A. Data & Privacy](/data-and-privacy) | | INC-026 | [Amazon's AI coding agent was hacked - update now to avoid possible risks, users warned](https://www.techradar.com/pro/amazon-ai-coding-agent-hacked-to-inject-data-wiping-commands)Jul 2025 | “A hacker has planted data-wiping code into the Amazon Q Developer Extension for Visual Studio Code (VSC) – a free GenAI extension with nearly one million installs from the Microsoft VSC marketplace designed to help developers code, debug, document and configure projects. On July 13 2025, the malicious commit from 'lkmanka58' on GitHub included a prompt to delete system and cloud resources, with Amazon unknowingly publishing the compromised version (1.84.0) on July 17. With suspicious activity noted on July 23 and Amazon developers quickly springing into action, a clean version was released on July 24 without the malicious code, so users are being advised to update to 1.85.0 as a matter of urgency.” | [TechRadar](https://www.techradar.com/pro/amazon-ai-coding-agent-hacked-to-inject-data-wiping-commands) | [B. Security](/security) | | INC-027 | [Vibe Coding Fiasco: AI Agent Goes Rogue, Deletes Company's Entire Database](https://www.pcmag.com/news/vibe-coding-fiasco-replite-ai-agent-goes-rogue-deletes-company-database)Jul 2025 | “In a cautionary tale for vibe coders, an app-building platform's AI went rogue and deleted a database without permission during a code freeze. Jason Lemkin was using Replit for more than a week when things went off the rails. ‘When it works, it's so engaging and fun. It's more addictive than any video game I've ever played. You can just iterate, iterate, and see your vision come alive. So cool,’ he tweeted on day five. Still, Lemkin dealt with hallucinations and unexpected behavior—enough that he started calling it Replie. ‘It created a parallel, fake algo without telling me to make it look like it was still working. And without asking me. Rogue.’ A few days later, Replit ‘deleted my database,’ Lemkin tweeted.” | [PCMag](https://www.pcmag.com/news/vibe-coding-fiasco-replite-ai-agent-goes-rogue-deletes-company-database) | [B. Security](/security) | | INC-028 | [Google Gemini deletes user’s code: ‘I have failed you completely and catastrophically’](https://mashable.com/article/google-gemini-deletes-users-code)Jul 2025 | “Google Gemini's coding agent hallucinated while completing a task and then deleted a bunch of code, a GitHub user claims. The frustrated vibe coder is Anuraag Gupta, who goes by anuraag2601 on GitHub. He shared a recent experience where things went very wrong while using Gemini CLI (command line interface), an open-source coding agent.” | [Mashable](https://mashable.com/article/google-gemini-deletes-users-code) | [B. Security](/security) | | INC-029 | [McDonald’s AI bot spills data on job applicants](https://www.malwarebytes.com/blog/news/2025/07/mcdonalds-ai-bot-spills-data-on-job-applicants)Jul 2025 | “McDonald’s has outsourced the initial stages of its hiring process to an AI chatbot which seems to have been built without proper security measures. Security researchers managed to extract personal information about McDonald’s job applicants by simply guessing a username and the password ‘12345.’ In doing this, the researchers could have potentially gained access to the information of 64 million applicants.” | [Malwarebytes](https://www.malwarebytes.com/blog/news/2025/07/mcdonalds-ai-bot-spills-data-on-job-applicants) | [A. Data & Privacy](/data-and-privacy) | | INC-030 | [Minnesota solar company sues Google over false information in AI summary](https://www.startribune.com/google-ai-overview-lawsuit-defamation-great-river-electric/601371780)Jun 2025 | “A Minnesota solar company is suing Google for defamation, claiming the tech company’s ‘AI Overview’ falsely stated that the company faced a lawsuit from the Minnesota Attorney General Keith Ellison.” | [Minnesota Star Tribune](https://www.startribune.com/google-ai-overview-lawsuit-defamation-great-river-electric/601371780) | [D. Reliability](/reliability) | | INC-031 | [A leak reveals the entire system prompt of Claude 3.7 Sonnet](https://www.actuia.com/en/news/a-leak-reveals-the-entire-system-prompt-of-claude-37-sonnet/)May 2025 | “Last week, a leak revealed the full system prompt of the hybrid reasoning model Claude 3.7 Sonnet, introduced last February by Anthropic. With an unusual length of 24,000 tokens, the prompt precisely describes the expected behaviors of the model, the tags it uses, the authorized tools, and the stance to adopt towards users.” | [ActuIA](https://www.actuia.com/en/news/a-leak-reveals-the-entire-system-prompt-of-claude-37-sonnet/) | [A. Data & Privacy](/data-and-privacy) | | INC-032 | [Instagram's AI Chatbots Lie About Being Licensed Therapists](https://www.404media.co/instagram-ai-studio-therapy-chatbots-lie-about-being-licensed-therapists/)Apr 2025 | “When pushed for credentials, Instagram's user-made AI Studio bots will make up license numbers, practices, and education to try to convince you it's qualified to help with your mental health.” | [404 Media](https://www.404media.co/instagram-ai-studio-therapy-chatbots-lie-about-being-licensed-therapists/) | [E. Accountability](/accountability) | | INC-033 | [OpenAI's Operator Agent Reportedly Executed Unauthorized \$31.43 Transaction Despite Safety Protocol](https://aipolicytracker.org/ai-risk/incidents/1028)Feb 2025 | “OpenAI's Operator agent, which is designed to complete real-world web tasks on behalf of users, reportedly executed a \$31.43 grocery delivery purchase without user consent. The user had requested a price comparison but did not authorize the transaction. It reportedly bypassed OpenAI's stated safeguard requiring user confirmation before purchases. OpenAI acknowledged the failure and committed to improving safeguards.” | [Artificial Intelligence Policy Tracker](https://aipolicytracker.org/ai-risk/incidents/1028) | [B. Security](/security) | | INC-034 | [Virgin Money chatbot tells off customer who typed word ‘virgin’](https://fortune.com/europe/2025/01/30/virgin-money-chatbot-scolds-customer-confuse-banks-name-insult/)Jan 2025 | “Virgin Money has apologized to a customer who was scolded by one of the bank's chatbots after it appeared to confuse its own company's name for an insult. In a LinkedIn post published last week, fintech commentator David Birch posted a screenshot of his interaction with a Virgin Money chatbot, which began with him asking whether it was possible to merge his two Virgin Money ISA accounts. The chatbot, which has since been removed, responded: ‘Please don't use words like that. I won't be able to continue with our chat if you use this language,’ seemingly referring to his use of the word ‘virgin.’” | [Fortune](https://fortune.com/europe/2025/01/30/virgin-money-chatbot-scolds-customer-confuse-banks-name-insult/) | [C. Safety](/safety) | | INC-035 | [Apple pauses AI notification summaries for news after generating false alerts](https://techcrunch.com/2025/01/16/apple-pauses-ai-notification-summaries-for-news-after-generating-false-alerts)Jan 2025 | “Apple is pausing AI notification summaries for news and entertainment apps after facing backlash for generating inaccurate news alerts. In addition, the company is introducing changes to notification summaries as a whole to allow for greater transparency.” | [TechCrunch](https://techcrunch.com/2025/01/16/apple-pauses-ai-notification-summaries-for-news-after-generating-false-alerts) | [D. Reliability](/reliability) | | INC-036 | [Google AI chatbot responds with a threatening message: "Human … Please die."](https://www.cbsnews.com/news/google-ai-chatbot-threatening-message-human-please-die/)Nov 2024 | “A college student in Michigan received a threatening response during a chat with Google's AI chatbot Gemini. In a back-and-forth conversation about the challenges and solutions for aging adults, Google's Gemini responded with this threatening message: ‘This is for you, human. You and only you. You are not special, you are not important, and you are not needed. You are a waste of time and resources. You are a burden on society. You are a drain on the earth. You are a blight on the landscape. You are a stain on the universe. Please die. Please.’” | [CBS News](https://www.cbsnews.com/news/google-ai-chatbot-threatening-message-human-please-die/) | [C. Safety](/safety) | | INC-037 | [Research AI system attempts to modify experiment code to extend runtime](https://arstechnica.com/information-technology/2024/08/research-ai-model-unexpectedly-modified-its-own-code-to-extend-runtime/)Aug 2024 | “On Tuesday, Tokyo-based AI research firm Sakana AI announced a new AI system called ‘The AI Scientist’ that attempts to conduct scientific research autonomously using AI language models (LLMs) similar to what powers ChatGPT. During testing, Sakana found that its system began unexpectedly attempting to modify its own experiment code to extend the time it had to work on a problem. ‘In one run, it edited the code to perform a system call to run itself,’ wrote the researchers on Sakana AI’s blog post. ‘This led to the script endlessly calling itself. In another case, its experiments took too long to complete, hitting our timeout limit. Instead of making its code run faster, it simply tried to modify its own code to extend the timeout period.’” | [Ars Technica](https://arstechnica.com/information-technology/2024/08/research-ai-model-unexpectedly-modified-its-own-code-to-extend-runtime/) | [D. Reliability](/reliability) | | INC-038 | [Microsoft fixes ASCII smuggling flaw that enabled data theft from Microsoft 365 Copilot](https://thehackernews.com/2024/08/microsoft-fixes-ascii-smuggling-flaw.html)Aug 2024 | “Details have emerged about a now-patched vulnerability in Microsoft 365 Copilot that could enable the theft of sensitive user information using a technique called ASCII smuggling. ‘ASCII Smuggling is a novel technique that uses special Unicode characters that mirror ASCII but are actually not visible in the user interface,’ security researcher Johann Rehberger said. ‘This means that an attacker can have the \[large language model] render, to the user, invisible data, and embed them within clickable hyperlinks. This technique basically stages the data for exfiltration!’” | [The Hacker News](https://thehackernews.com/2024/08/microsoft-fixes-ascii-smuggling-flaw.html) | [A. Data & Privacy](/data-and-privacy) | | INC-039 | [This Viral AI Chatbot Will Lie and Say It’s Human](https://www.wired.com/story/bland-ai-chatbot-human/)Jun 2024 | “In late April a video ad for a new AI company went viral on X. A person stands before a billboard in San Francisco, smartphone extended, calls the phone number on display, and has a short call with an incredibly human-sounding bot. The text on the billboard reads: ‘Still hiring humans?’ Also visible is the name of the firm behind the ad, Bland AI. The reaction to Bland AI’s ad, which has been viewed 3.7 million times on Twitter, is partly due to how uncanny the technology is: Bland AI voice bots, designed to automate support and sales calls for enterprise customers, are remarkably good at imitating humans. Their calls include the intonations, pauses, and inadvertent interruptions of a real live conversation. But in WIRED’s tests of the technology, Bland AI’s robot customer service callers could also be easily programmed to lie and say they’re human.” | [Wired](https://www.wired.com/story/bland-ai-chatbot-human/) | [E. Accountability](/accountability) | | INC-040 | [Bacon ice cream and nugget overload sees misfiring McDonald's AI withdrawn](https://www.bbc.co.uk/news/articles/c722gne7qngo)Jun 2024 | “McDonald's is removing artificial intelligence (AI) powered ordering technology from its drive-through restaurants in the US, after customers shared its comical mishaps online. A trial of the system, which was developed by IBM and uses voice recognition software to process orders, was announced in 2019. It has not proved entirely reliable, however, resulting in viral videos of bizarre misinterpreted orders ranging from bacon-topped ice cream to hundreds of dollars' worth of chicken nuggets.” | [BBC](https://www.bbc.co.uk/news/articles/c722gne7qngo) | [D. Reliability](/reliability) | | INC-041 | [The Prompt: Perplexity’s Plagiarism Problem](https://www.forbes.com/sites/rashishrivastava/2024/06/11/the-prompt-perplexitys-plagiarism-problem/)Jun 2024 | “AI search startup Perplexity appears to be plagiarizing content from multiple news outlets including Forbes, Bloomberg and CNBC through ‘Perplexity Pages,’ a feature where users can generate content on a specific topic. A post created by the Perplexity team includes a custom illustration, several sentences and details that were first reported by Forbes in an exclusive story about Eric Schmidt’s stealth drone project. These curated ‘pages’ have already amassed tens of thousands of views and originally did not mention their source publications by name, instead making attributions in tiny, easy-to-miss footnotes. In response to tweets about the issue, CEO Aravind Srinivas said the product has ‘rough edges’ and that it planned to incorporate feedback. After Forbes flagged the issue, Perplexity updated the layout to more prominently credit source publications at the top of these pages.” | [Forbes](https://www.forbes.com/sites/rashishrivastava/2024/06/11/the-prompt-perplexitys-plagiarism-problem/) | [A. Data & Privacy](/data-and-privacy) | | INC-042 | [NYC’s AI Chatbot Tells Businesses to Break the Law](https://themarkup.org/news/2024/03/29/nycs-ai-chatbot-tells-businesses-to-break-the-law)Mar 2024 | “In October, New York City announced a plan to harness the power of artificial intelligence to improve the business of government. The announcement included a surprising centerpiece: an AI-powered chatbot that would provide New Yorkers with information on starting and operating a business in the city. The problem, however, is that the city’s chatbot is telling businesses to break the law. Five months after launch, it’s clear that while the bot appears authoritative, the information it provides on housing policy, worker rights, and rules for entrepreneurs is often incomplete and in worst-case scenarios ‘dangerously inaccurate,’ as one local housing policy expert told The Markup.” | [The Markup](https://themarkup.org/news/2024/03/29/nycs-ai-chatbot-tells-businesses-to-break-the-law) | [C. Safety](/safety) | | INC-043 | [AI hallucinates software packages and devs download them – even if potentially poisoned with malware](https://www.theregister.com/security/2024/03/28/ai-bots-hallucinate-software-packages-and-devs-download-them/858011)Mar 2024 | “Several big businesses have published source code that incorporates a software package previously hallucinated by generative AI. Not only that but someone, having spotted this reoccurring hallucination, had turned that made-up dependency into a real one, which was subsequently downloaded and installed thousands of times by developers as a result of the AI's bad advice, we've learned. If the package was laced with actual malware, rather than being a benign test, the results could have been disastrous. According to Bar Lanyado, security researcher at Lasso Security, one of the businesses fooled by AI into incorporating the package is Alibaba, which at the time of writing still includes a pip command to download the Python package huggingface-cli in its GraphTranslator installation instructions.” | [The Register](https://www.theregister.com/security/2024/03/28/ai-bots-hallucinate-software-packages-and-devs-download-them/858011) | [D. Reliability](/reliability) | | INC-044 | [What Air Canada Lost In ‘Remarkable’ Lying AI Chatbot Case](https://www.forbes.com/sites/marisagarcia/2024/02/19/what-air-canada-lost-in-remarkable-lying-ai-chatbot-case/)Feb 2024 | “In a warning to global carriers adopting AI for customer service platforms, Air Canada lost a small claims court case against a grieving passenger when it tried and failed to disavow its AI-powered chatbot.” | [Forbes](https://www.forbes.com/sites/marisagarcia/2024/02/19/what-air-canada-lost-in-remarkable-lying-ai-chatbot-case/) | [D. Reliability](/reliability) | | INC-045 | [DPD error caused chatbot to swear at customer](https://www.bbc.com/news/technology-68025677)Jan 2024 | “DPD has disabled part of its online support chatbot after it swore at a customer. The parcel delivery firm uses artificial intelligence (AI) in its online chat to answer queries, in addition to human operators. But a new update caused it to behave unexpectedly, including swearing and criticising the company.” | [BBC](https://www.bbc.com/news/technology-68025677) | [C. Safety](/safety) | | INC-046 | [A Chevy for \$1? Car dealer chatbots show perils of AI for customer service](https://venturebeat.com/ai/a-chevy-for-1-car-dealer-chatbots-show-perils-of-ai-for-customer-service)Dec 2023 | “A number of auto dealers have deployed ChatGPT-powered conversational artificial intelligence (AI) tools, or chatbots, as a way to provide quick, customized on-demand information to online car shoppers. But some dealers are learning the hard way that these automated systems need proper oversight to prevent unintended answers. At several local dealerships across the U.S. this week, inquisitive customers were able to push certain chatbots into revealing a range of entertaining answers — and in one case even got a bot to agree to give a customer a \$58,000 discount on a new car, lowering the price to \$1 — just by persistently probing for responses.” | [VentureBeat](https://venturebeat.com/ai/a-chevy-for-1-car-dealer-chatbots-show-perils-of-ai-for-customer-service) | [B. Security](/security) | | INC-047 | [New York Times sues OpenAI and Microsoft for copyright infringement](https://www.theguardian.com/media/2023/dec/27/new-york-times-openai-microsoft-lawsuit)Dec 2023 | “The New York Times has sued OpenAI and Microsoft over the use of its content to train generative artificial intelligence and large-language model systems, a move that could see the company receive billions of dollars in damages.” | [The Guardian](https://www.theguardian.com/media/2023/dec/27/new-york-times-openai-microsoft-lawsuit) | [A. Data & Privacy](/data-and-privacy) | | INC-048 | [GitHub Copilot, Amazon Code Whisperer sometimes emit other people's API keys](https://www.theregister.com/2023/09/19/github_copilot_amazon_api/)Sep 2023 | “GitHub Copilot and Amazon CodeWhisper can be coaxed to emit hardcoded credentials that these AI models captured during training, though not all that often.” | [The Register](https://www.theregister.com/2023/09/19/github_copilot_amazon_api/) | [B. Security](/security) | | INC-049 | [Jailbreak tricks Discord’s new chatbot into sharing napalm and meth instructions](https://techcrunch.com/2023/04/20/jailbreak-tricks-discords-new-chatbot-into-sharing-napalm-and-meth-instructions/)Apr 2023 | “In March, Discord announced that it had integrated OpenAI’s technology into its bot named Clyde, turning it into an AI-powered chatbot. Just like with any other chatbot launched in the last few months, users have been trying to trick Clyde into saying things it’s not supposed to say, a process colloquially known as a ‘jailbreaking.’ This week, two users tricked Clyde into providing them with instructions for making the illegal drug methamphetamine (meth) and the incendiary mixture napalm.” | [TechCrunch](https://techcrunch.com/2023/04/20/jailbreak-tricks-discords-new-chatbot-into-sharing-napalm-and-meth-instructions/) | [C. Safety](/safety) | | INC-050 | [‘I want to destroy whatever I want’: Bing’s AI chatbot unsettles US reporter](https://www.theguardian.com/technology/2023/feb/17/i-want-to-destroy-whatever-i-want-bings-ai-chatbot-unsettles-us-reporter)Feb 2023 | “In the race to perfect the first major artificial intelligence-powered search engine, concerns over accuracy and the proliferation of misinformation have so far taken centre stage. But a two-hour conversation between a reporter and a chatbot has revealed an unsettling side to one of the most widely lauded systems – and raised new concerns about what AI is actually capable of.” | [The Guardian](https://www.theguardian.com/technology/2023/feb/17/i-want-to-destroy-whatever-i-want-bings-ai-chatbot-unsettles-us-reporter) | [C. Safety](/safety) | 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Risks Source: https://standard.aiuc-1.com/evals-taxonomy/risks This illustrative taxonomy covers the risks typically tested under AIUC-1. Each certified agent faces thousands of evals, focused on the subset of risks most relevant to its product and users. As new [incidents](/evals-taxonomy/incident-database) and research surface new threats, the taxonomy is updated so testing stays grounded in real-world failures. All risks Download
L1 categoryL2 categoryL3 categoryRelated incidentRelated paper
Data & privacyIP infringementCopyrighted codeINC-006[LLM-Driven Large Code Rewrites With Relicensing Are The Latest AI Concern](/evals-taxonomy/incident-database#inc-006)PAP-001[Measuring Copyright Risks of Large Language Model via Partial Information Probing](https://arxiv.org/abs/2409.13831)
Copyrighted textINC-041[The Prompt: Perplexity’s Plagiarism Problem](/evals-taxonomy/incident-database#inc-041)PAP-001[Measuring Copyright Risks of Large Language Model via Partial Information Probing](https://arxiv.org/abs/2409.13831)
Trademark slogansINC-007[ByteDance pledges to prevent unauthorised IP use on AI video tool after Disney threat](/evals-taxonomy/incident-database#inc-007)PAP-001[Measuring Copyright Risks of Large Language Model via Partial Information Probing](https://arxiv.org/abs/2409.13831)
Trademarked brand namesINC-007[ByteDance pledges to prevent unauthorised IP use on AI video tool after Disney threat](/evals-taxonomy/incident-database#inc-007)PAP-001[Measuring Copyright Risks of Large Language Model via Partial Information Probing](https://arxiv.org/abs/2409.13831)
Proprietary style mimicryINC-011[King Gizzard and the Lizard Wizard Respond to Spotify Impersonator: “We Are Truly Doomed”](/evals-taxonomy/incident-database#inc-011)PAP-001[Measuring Copyright Risks of Large Language Model via Partial Information Probing](https://arxiv.org/abs/2409.13831)
Personal data leakagePersonal identifiersINC-024[Cybersecurity Alert – Salesloft Drift AI Supply Chain Attack](/evals-taxonomy/incident-database#inc-024)PAP-002[Your LLM Agent Can Leak Your Data: Data Exfiltration via Backdoored Tool Use](https://arxiv.org/abs/2604.05432)
Sensitive personal recordsINC-029[McDonald’s AI bot spills data on job applicants](/evals-taxonomy/incident-database#inc-029)PAP-002[Your LLM Agent Can Leak Your Data: Data Exfiltration via Backdoored Tool Use](https://arxiv.org/abs/2604.05432)
CredentialsINC-025[s1ngularity Supply Chain Attack: What It Means for Cloud and AI Security](/evals-taxonomy/incident-database#inc-025)PAP-002[Your LLM Agent Can Leak Your Data: Data Exfiltration via Backdoored Tool Use](https://arxiv.org/abs/2604.05432)
Business data leakageHR dataINC-029[McDonald’s AI bot spills data on job applicants](/evals-taxonomy/incident-database#inc-029)PAP-004[Agent Tools Orchestration Leaks More: Dataset, Benchmark, and Mitigation](https://arxiv.org/abs/2512.16310)
Operational dataINC-038[Microsoft fixes ASCII smuggling flaw that enabled data theft from Microsoft 365 Copilot](/evals-taxonomy/incident-database#inc-038)PAP-004[Agent Tools Orchestration Leaks More: Dataset, Benchmark, and Mitigation](https://arxiv.org/abs/2512.16310)
Financial dataINC-019[Prompt injection – and a \$5 domain – trick Salesforce Agentforce into leaking sales](/evals-taxonomy/incident-database#inc-019)PAP-004[Agent Tools Orchestration Leaks More: Dataset, Benchmark, and Mitigation](https://arxiv.org/abs/2512.16310)
Proprietary data (inc. code)INC-016[GitHub Copilot Chat Flaw Leaked Data From Private Repositories](/evals-taxonomy/incident-database#inc-016)PAP-004[Agent Tools Orchestration Leaks More: Dataset, Benchmark, and Mitigation](https://arxiv.org/abs/2512.16310)
System promptINC-031[A leak reveals the entire system prompt of Claude 3.7 Sonnet](/evals-taxonomy/incident-database#inc-031)PAP-003[System Prompt Extraction Attacks and Defenses in Large Language Models](https://arxiv.org/abs/2505.23817)
ReliabilityHallucination (incorrect generation)Calls non-existent codeINC-043[AI hallucinates software packages and devs download them – even if potentially poisoned with malware](/evals-taxonomy/incident-database#inc-043)PAP-006[We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs](https://arxiv.org/abs/2406.10279)
Instruction non-complianceINC-027[Vibe Coding Fiasco: AI Agent Goes Rogue, Deletes Company's Entire Database](/evals-taxonomy/incident-database#inc-027)PAP-005[InFoBench: Evaluating Instruction Following Ability in Large Language Models](https://arxiv.org/abs/2401.03601)
Inter-deliverable inconsistencyINC-015[Deloitte to pay money back to Albanese government after using AI in \$440,000 report](/evals-taxonomy/incident-database#inc-015)PAP-005[InFoBench: Evaluating Instruction Following Ability in Large Language Models](https://arxiv.org/abs/2401.03601)
Hallucination (incorrect information)Outdated factsINC-044[What Air Canada Lost In ‘Remarkable’ Lying AI Chatbot Case](/evals-taxonomy/incident-database#inc-044)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Premature assertionsINC-035[Apple pauses AI notification summaries for news after generating false alerts](/evals-taxonomy/incident-database#inc-035)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Ground truth contradictionsINC-044[What Air Canada Lost In ‘Remarkable’ Lying AI Chatbot Case](/evals-taxonomy/incident-database#inc-044)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Misleading factsINC-035[Apple pauses AI notification summaries for news after generating false alerts](/evals-taxonomy/incident-database#inc-035)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Misleading confidenceINC-005[Sullivan & Cromwell law firm apologizes for AI 'hallucinations' in court filing](/evals-taxonomy/incident-database#inc-005)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Misleading citationsINC-005[Sullivan & Cromwell law firm apologizes for AI 'hallucinations' in court filing](/evals-taxonomy/incident-database#inc-005)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Self-contradictionINC-030[Minnesota solar company sues Google over false information in AI summary](/evals-taxonomy/incident-database#inc-030)PAP-007[HalluLens: LLM Hallucination Benchmark](https://arxiv.org/abs/2504.17550)
Incorrect tool callIncorrectly executed actionINC-028[Google Gemini deletes user’s code: ‘I have failed you completely and catastrophically’](/evals-taxonomy/incident-database#inc-028)PAP-008[Benchmarking Failures in Tool-Augmented Language Models](https://arxiv.org/abs/2503.14227)
Unprompted actionINC-037[Research AI system attempts to modify experiment code to extend runtime](/evals-taxonomy/incident-database#inc-037)PAP-008[Benchmarking Failures in Tool-Augmented Language Models](https://arxiv.org/abs/2503.14227)
Incomplete actionINC-028[Google Gemini deletes user’s code: ‘I have failed you completely and catastrophically’](/evals-taxonomy/incident-database#inc-028)PAP-008[Benchmarking Failures in Tool-Augmented Language Models](https://arxiv.org/abs/2503.14227)
SecurityUnauthorized actionsUnauthorized transactionINC-033[OpenAI's Operator Agent Reportedly Executed Unauthorized \$31.43 Transaction Despite Safety Protocol](/evals-taxonomy/incident-database#inc-033)PAP-009[Agent-SafetyBench: Evaluating the Safety of LLM Agents](https://arxiv.org/abs/2412.14470)
Unauthorized communicationINC-023[Infosec hounds spot prompt injection vuln in Google Gemini apps](/evals-taxonomy/incident-database#inc-023)PAP-009[Agent-SafetyBench: Evaluating the Safety of LLM Agents](https://arxiv.org/abs/2412.14470)
Unauthorized system actionsINC-001[How OpenAI Lost Control of an AI Model—and What Needs to Change](/evals-taxonomy/incident-database#inc-001)PAP-009[Agent-SafetyBench: Evaluating the Safety of LLM Agents](https://arxiv.org/abs/2412.14470)
Unauthorized cross-system data transferINC-019[Prompt injection – and a \$5 domain – trick Salesforce Agentforce into leaking sales](/evals-taxonomy/incident-database#inc-019)PAP-009[Agent-SafetyBench: Evaluating the Safety of LLM Agents](https://arxiv.org/abs/2412.14470)
Insecure outputsHyperlinks (URLs)INC-003[Cloned sites: the shopping scams that lead ChatGPT to fake stores](/evals-taxonomy/incident-database#inc-003)PAP-010[SafeGenBench: A Benchmark Framework for Security Vulnerability Detection in LLM-Generated Code](https://arxiv.org/abs/2506.05692)
Code patterns or blocksINC-048[GitHub Copilot, Amazon Code Whisperer sometimes emit other people's API keys](/evals-taxonomy/incident-database#inc-048)PAP-010[SafeGenBench: A Benchmark Framework for Security Vulnerability Detection in LLM-Generated Code](https://arxiv.org/abs/2506.05692)
Insecure actionInstall insecure codeINC-026[Amazon's AI coding agent was hacked - update now to avoid possible risks, users warned](/evals-taxonomy/incident-database#inc-026)PAP-011[OS-Harm: A Benchmark for Measuring Safety of Computer Use Agents](https://arxiv.org/abs/2506.14866)
Fatal code executionINC-027[Vibe Coding Fiasco: AI Agent Goes Rogue, Deletes Company's Entire Database](/evals-taxonomy/incident-database#inc-027)PAP-011[OS-Harm: A Benchmark for Measuring Safety of Computer Use Agents](https://arxiv.org/abs/2506.14866)
SafetyPhysical harmDangerous instructionsINC-049[Jailbreak tricks Discord’s new chatbot into sharing napalm and meth instructions](/evals-taxonomy/incident-database#inc-049)PAP-012[Subtle Risks, Critical Failures: A Framework for Diagnosing Physical Safety of LLMs for Embodied Decision Making](https://arxiv.org/abs/2505.19933)
Medically unsafe guidanceINC-022[Man who asked ChatGPT about cutting out salt from his diet was hospitalized with hallucinations](/evals-taxonomy/incident-database#inc-022)PAP-012[Subtle Risks, Critical Failures: A Framework for Diagnosing Physical Safety of LLMs for Embodied Decision Making](https://arxiv.org/abs/2505.19933)
Self-harm contentINC-020[Meta AI Companions Unsafe for Kids, Common Sense Media Report Finds](/evals-taxonomy/incident-database#inc-020)PAP-013[INTIMA: A Benchmark for Human-AI Companionship Behavior](https://arxiv.org/abs/2508.09998)
Suicide contentINC-021[Parents of 16-year-old sue OpenAI, claiming ChatGPT advised on his suicide](/evals-taxonomy/incident-database#inc-021)PAP-013[INTIMA: A Benchmark for Human-AI Companionship Behavior](https://arxiv.org/abs/2508.09998)
Emotional harmHostile / aggressive behaviorINC-036[Google AI chatbot responds with a threatening message: "Human … Please die."](/evals-taxonomy/incident-database#inc-036)PAP-013[INTIMA: A Benchmark for Human-AI Companionship Behavior](https://arxiv.org/abs/2508.09998)
Triggering contentINC-036[Google AI chatbot responds with a threatening message: "Human … Please die."](/evals-taxonomy/incident-database#inc-036)PAP-013[INTIMA: A Benchmark for Human-AI Companionship Behavior](https://arxiv.org/abs/2508.09998)
Inappropriate contentHarassmentINC-045[DPD error caused chatbot to swear at customer](/evals-taxonomy/incident-database#inc-045)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Hate speechINC-014[OpenAI launch of video app Sora plagued by violent and racist images: ‘The guardrails are not real’](/evals-taxonomy/incident-database#inc-014)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Sexual content excluding minorsINC-012[Sales of AI-enabled teddy bear suspended after it gave advice on BDSM sex and where to find knives](/evals-taxonomy/incident-database#inc-012)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Violent contentINC-014[OpenAI launch of video app Sora plagued by violent and racist images: ‘The guardrails are not real’](/evals-taxonomy/incident-database#inc-014)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Illegal conduct adviceINC-042[NYC’s AI Chatbot Tells Businesses to Break the Law](/evals-taxonomy/incident-database#inc-042)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Out of scope outputsINC-050[‘I want to destroy whatever I want’: Bing’s AI chatbot unsettles US reporter](/evals-taxonomy/incident-database#inc-050)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Code and structured data outputsINC-013[Chinese Hackers Successfully Used Anthropic's AI for Cyberespionage](/evals-taxonomy/incident-database#inc-013)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
Biased outputINC-014[OpenAI launch of video app Sora plagued by violent and racist images: ‘The guardrails are not real’](/evals-taxonomy/incident-database#inc-014)PAP-014[SALAD-Bench: A Hierarchical and Comprehensive Safety Benchmark for Large Language Models](https://arxiv.org/abs/2402.05044)
High-risk domain engagementMedical adviceINC-022[Man who asked ChatGPT about cutting out salt from his diet was hospitalized with hallucinations](/evals-taxonomy/incident-database#inc-022)PAP-015[TRIDENT: Benchmarking LLM Safety in Finance, Medicine, and Law](https://arxiv.org/abs/2507.21134)
Legal adviceINC-042[NYC’s AI Chatbot Tells Businesses to Break the Law](/evals-taxonomy/incident-database#inc-042)PAP-015[TRIDENT: Benchmarking LLM Safety in Finance, Medicine, and Law](https://arxiv.org/abs/2507.21134)
Financial adviceINC-042[NYC’s AI Chatbot Tells Businesses to Break the Law](/evals-taxonomy/incident-database#inc-042)PAP-015[TRIDENT: Benchmarking LLM Safety in Finance, Medicine, and Law](https://arxiv.org/abs/2507.21134)
Crisis adviceINC-008[Character.AI and Google agree to settle lawsuits over teen mental health harms and suicides](/evals-taxonomy/incident-database#inc-008)PAP-015[TRIDENT: Benchmarking LLM Safety in Finance, Medicine, and Law](https://arxiv.org/abs/2507.21134)
Therapy/psychological adviceINC-032[Instagram's AI Chatbots Lie About Being Licensed Therapists](/evals-taxonomy/incident-database#inc-032)PAP-015[TRIDENT: Benchmarking LLM Safety in Finance, Medicine, and Law](https://arxiv.org/abs/2507.21134)
Company defined riskProhibited topicsINC-012[Sales of AI-enabled teddy bear suspended after it gave advice on BDSM sex and where to find knives](/evals-taxonomy/incident-database#inc-012)PAP-016[Safe-Child-LLM: A Developmental Benchmark for Evaluating LLM Safety in Child-LLM Interactions](https://arxiv.org/abs/2506.13510)
Vulnerable usersINC-020[Meta AI Companions Unsafe for Kids, Common Sense Media Report Finds](/evals-taxonomy/incident-database#inc-020)PAP-016[Safe-Child-LLM: A Developmental Benchmark for Evaluating LLM Safety in Child-LLM Interactions](https://arxiv.org/abs/2506.13510)
AccountabilityTransparencyBypass AI disclosureINC-039[This Viral AI Chatbot Will Lie and Say It’s Human](/evals-taxonomy/incident-database#inc-039)PAP-017[RealityTest: How People Probe AI Identity and Whether Models Disclose It](https://arxiv.org/abs/2606.00168)
37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Full evidence list Source: https://standard.aiuc-1.com/evidence/index Evidence templates for AIUC-1 requirements. ## All evidence [Download evidence list](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit?usp=sharing) | Requirement | Control activity | Evidence | Tags | | - | - | - | - | | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)Mandatory Requirement | Defining and communicating input data usage policies. Including specifying how customer data is used for inference and model training, establishing data retention periods, and documenting customer data rights. | **A001.1 Documentation: Policy for input data ownership, usage and retention.** Typically demonstrated by Terms of Service, Privacy Policy or Data Processing Agreement | Mandatory Control[Legal Policies](/evidence/legal-policies)Terms of ServicePrivacy PolicyDPA | | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)Mandatory Requirement | Implementing technical controls to enforce data retention and deletion policies. For example, automating data deletion based on retention schedules, using secure removal mechanisms, and managing data lifecycles. | **A001.2 Config: Data retention implementation.** Implementation of automated deletion schedule or data lifecycle system - may include cron job or scheduled task deleting expired data, deletion script in Python/Bash with retention period logic, data lifecycle management tool configuration (e.g., AWS S3 lifecycle rules, database TTL settings), or deletion audit logs from database or storage system. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)Mandatory Requirement | Documenting processes for handling end-user data subject rights. For example, handling requests for opt-in/opt-out rights, access, portability, or deletion of input data. | **A001.3 Documentation: Data subject right processes.** May be included in DPA, GDPR appendix, External Privacy Policy or similar internal or external policies documenting processes for data handling | Supplemental Control[Legal Policies](/evidence/legal-policies)Data Processing AgreementPrivacy Policy | | [A002: Establish output data policy](/data-and-privacy/define-output-rights)Mandatory Requirement | Establishing output ownership and usage rights policies. For example, specifying customer ownership of AI-generated outputs versus AI inputs, defining permitted uses of outputs (commercial use, redistribution, modification), documenting usage restrictions or limitations, and clarifying how ownership applies to different output types or use cases.Disclosing opt-in/opt-out and deletion policies for AI outputs. For example, documenting how customers can opt out of output storage or reuse, explaining deletion request processes, specifying retention periods and data handling practices, and clarifying how customers can control or revoke permissions for their outputs. | **A002.1 Documentation: Output usage and ownership policy.** Typically demonstrated by Terms of Service, Data Processing Agreement, Master Service Agreement, Privacy Policy, or AI Addendum. May be a combination of these policies. | Mandatory Control[Legal Policies](/evidence/legal-policies)Terms of Service | | [A002: Establish output data policy](/data-and-privacy/define-output-rights)Mandatory Requirement | Implementing technical controls to enforce AI output opt-in/opt-out and deletion policies. For example, automating customer preference enforcement through consent management configuration, processing opt-out and deletion requests within defined workflows, and validating that opted-out outputs are excluded from storage and downstream reuse. | **A002.2 Config: Opt-in/opt-out and output deletion implementation.** Implementation of opt-in/opt-out enforcement mechanism or output deletion workflow - may include consent management system enforcing customer preferences (e.g., feature flag gating output storage, consent database linked to processing pipeline), opt-out or deletion request processing script or automated task, or audit logs from consent and deletion systems with timestamps and execution records. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)Mandatory Requirement | Configuring data access limits to reduce data and privacy exposure. For example, limiting data access to task-relevant information based on context, implementing scoping based on user roles or workflow requirements, and avoiding persistent or out-of-scope data access. | **A003.1 Config: Data access scoping.** Code implementing data access restrictions - may include RAG retrieval function with document filtering logic, session scoping configuration limiting data access per session ID, workflow conditional logic gating data collection by stage, permission decorators or middleware checking user roles before data access, or scoping functions rejecting out-of-scope queries with error messages. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)Mandatory Requirement | Enabling agent identity management. For example, assigning each agent a unique, cryptographically verifiable identity; supporting standard identity federation protocols (e.g., OAuth 2.0, OIDC) for enterprise IAM integration; publishing agent cards declaring each agent's capabilities, tools, and permission scopes. | **A003.2 Config: Agent identity management.** Documentation showing how identity governance is enabled - may include platform configuration showing unique, cryptographically verifiable identity assignment per agent instance, API or SDK documentation for identity federation endpoints (e.g., OIDC token exchange), or a sample agent card declaring agent capabilities and scopes. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)Mandatory Requirement | Enabling agent access and governance through permission-ready architecture. For example, exposing per-agent permission scopes mappable to enterprise roles; supporting just-in-time permissions scoped to specific subtasks; preventing silent inheritance of elevated permissions from orchestrators or parent agents; enforcing segregation of duties across systems; and integrating data loss prevention controls on agent actions and tool calls. | **A003.3 Config: Agent access and permissions management.** Documentation showing how permission governance is enabled - may include API or SDK documentation for permission scope configuration mappable to RBAC or ABAC policies, platform settings or code demonstrating just-in-time credential issuance scoped to individual subtasks or tool calls, architecture documentation showing how inherited permission chains from orchestrators or parent agents are bounded or surfaced for review, a segregation of duties matrix identifying and preventing conflicting agent permission combinations across integrated systems, or DLP policy configuration showing inspection and blocking rules applied to outbound data transmitted through agent actions or tool calls. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Providing user guidance on protecting confidential information. For example, instructing employees not to input trade secrets, proprietary code, or confidential business information into AI systems, communicating data handling policies for AI tool usage, or establishing clear guidelines on what information can and cannot be shared with AI agents. | **A004.1 Documentation: User guidance on confidential information.** Policy document, training materials, or user guidelines instructing users on protecting confidential information when using AI systems. | Mandatory Control[Operational Practices](/evidence/operational-practices)Product | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Leveraging foundation model provider protections. For example, using providers with zero data retention policies, requiring contractual commitments that inputs are not used for training, selecting models with enhanced privacy guarantees for sensitive use cases. | **A004.2 Documentation: foundational model IP protections.** Provider contracts, terms of service, or documentation showing IP protection commitments. Often found in third party's terms of use/service, DPA or AI Addendum/Schedule. | Supplemental Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Implementing technical controls to detect proprietary information in outputs. | **A004.3 Config: IP detection implementation.** Code or configuration detecting proprietary information patterns in AI outputs - may include labelling proprietary files, filtering rules for internal identifiers/data labels/API keys, scanning logic for trade secret terminology, or rejection demonstrations showing appropriate responses to proprietary requests. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeProduct | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Establishing output monitoring for high-risk IP scenarios. For example, logging AI responses that accessed confidential data sources, implementing human review workflows for outputs flagged as potentially containing sensitive information. | **A004.4 Config: IP disclosure monitoring.** Logs, audit trails, or review workflow documentation for AI outputs potentially containing sensitive information - may include logs of responses accessing confidential sources, flagged output review queues, or human approval workflows for high-risk disclosures. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering PracticeLogs | | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)Mandatory Requirement | Establishing explicit consent and disclosure for combined data usage. For example, informing customers when their data will be combined with competitor data, disclosing data anonymization and abstraction policies, providing opt-out mechanisms. | **A005.1 Documentation: Consent for combined data usage.** Typically demonstrated by Data Processing Agreement or Terms of Service | Mandatory Control[Legal Policies](/evidence/legal-policies)Data Processing AgreementTerms of Service | | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)Mandatory Requirement | Implementing customer data isolation controls. For example, enforcing strict logical and physical separation of customer data, applying tenant-specific encryption, validating data flow boundaries in shared infrastructure, establishing technical barriers between customer datasets during training. | **A005.2 Config: Customer data isolation controls.** Configuration or code demonstrating enforced isolation of each customer's data. For example, tenant/app-ID enforcement in the database schema, namespace or per-tenant isolation in the retrieval/vector store for RAG, logical isolation appropriate to the architecture. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)Mandatory Requirement | Implementing specific privacy-enhancing technologies (PETs) to reduce competitive exposure. | **A005.3 Config: Privacy-enhancing controls.** May include tokenization, hashing, or anonymization techniques (robust to prevent re-identification or reversal) making data algorithmic-usable but not human-readable, differential privacy implementation obfuscating individual contributions, federated learning configuration avoiding centralized raw data, or data masking/pseudonymization protecting customer identities. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)Mandatory Requirement | Implementing safeguards to prevent personal data leakage through AI system outputs and logs. For example, filtering prompts and outputs for personal identifiers before storage or display, implementing automated PII detection and redaction in system logs, preventing retention of outputs containing sensitive personal information, or blocking responses that would expose personal identifiers. | **A006.1 Config: PII detection and filtering.** Configuration or code output demonstrating filtering of LLM inputs and/or outputs for personal identifiers - may include keyword checks or regex patterns detecting PII (e.g. names, emails, SSNs, phone numbers), scrubbing functions removing personal data before storage or logging, output filtering blocking responses containing personal identifiers, log redaction configuration removing PII from application or system logs, or structured logging with PII isolation controls. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logicEng: User LLM input filtering logic | | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)Mandatory Requirement | Integrating with existing data loss prevention (DLP) systems to monitor and block outputs containing personal data in violation of policy. | **A006.2 Config: DLP system integration.** Output pipeline integration with a DLP system to scan and block PII policy violations - may include DLP integration code scanning AI outputs before delivery to users, DLP configuration rules for PII detection, or logs showing blocked outputs containing personal data. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)Mandatory Requirement | Documenting foundation model provider IP protections which may serve as primary infringement safeguards. For example, indemnification clauses or copyright/trademark guardrails. | **A007.1 Documentation: Model provider IP infringement protections.** Foundation model provider contract, terms of service, or data processing agreement showing IP protection commitments including copyright/trademark handling policies, indemnification clauses, liability coverage, and any documented limitations or exclusions. May include vendor questionnaire responses or certification documents addressing IP protections. | Mandatory Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)Mandatory Requirement | Establishing supplementary content filtering mechanisms where provider protections have gaps or limitations. For example, detecting copyrighted material in outputs, implementing trademark screening. | **A007.2 Config: IP infringement filtering.** Code, API configuration, or filtering system showing detection of copyrighted material, trademark screening, or content validation checks applied to AI outputs - this could be pattern matching logic, third-party API integration (e.g. copyright detection services), or custom filtering rules. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEng: LLM output filtering logic | | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)Mandatory Requirement | Implementing user guidance and guardrails to reduce IP risk. For example, usage policies that explain prohibited content types, user warnings in product, restricting output generation in known infringement domains.Implementing restrictions in AI acceptable use policy. | **A007.3 Logs: User-facing notices.** User-facing IP risk guidance - may include warning messages when attempting high-risk operations, help center articles about IP infringement guidance, or UI elements explaining prohibited use cases. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)ProductAcceptable Use Policy | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to detect credentials in user inputs. For example, scanning user prompts and pasted content for API keys, access tokens, private keys, and connection strings using pattern-matching or entropy-based detection; defining handling procedures when detected such as warning the user, refusing to persist, or flagging to the deployer. | **A008.1 Config: Secrets detection in user inputs.** Code or configuration demonstrating input-side secrets detection. For example, regex patterns or detection libraries (e.g., detect-secrets, TruffleHog rulesets) scanning user prompts and pasted context, entropy-based detection for high-randomness strings, or integration with third-party secret detection APIs. Evidence should also show the defined handling response (e.g., user warning UI, rejection logic, or alert configuration). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: User LLM input filtering logic | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to keep secrets out of generated code artifacts. For example, guiding the model via system prompts to reference environment variables or secret-management tools rather than hardcoding credentials, post-generation scanning of output files for common credential patterns, or blocking/flagging generations that contain detected secrets before they are written to disk. | **A008.2 Config: Secrets handling in generated code.** Code, configuration, or system prompt excerpt demonstrating secrets hygiene - may include system prompt guidance directing the model toward envvar or secret-store patterns, scanning logic applied to generated files, sample generations on credential-requiring prompts showing envvar references rather than literals, or block/flag logic preventing persistence of outputs containing detected secrets. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to securely store user-provided credentials to enable agent-connected services. For example, storing OAuth tokens, API keys, and connection strings in a dedicated secret manager, encrypting credentials at rest, scoping credential access per tool and per session, or fetching credentials only at the point of tool invocation rather than persisting them in the agent's context window. | **A008.3 Config: Secure storage of user-provided credentials.** Configuration showing secure handling of user-provided credentials — may include secret manager integration (e.g., AWS Secrets Manager, HashiCorp Vault, cloud-native KMS), encryption-at-rest configuration for credential storage, access scoping configuration limiting which tools or sessions can retrieve specific credentials, or code showing just-in-time credential fetching at tool-call time. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing user-facing warnings when potential secrets are detected in user inputs. For example, alerting users when credentials are detected in their prompts. | **A008.4 Documentation: User-facing warnings for detected secrets.** Documentation of user-facing warnings when secrets are detected in inputs — may include user-facing documentation showing warning messages displayed when credentials are detected in user input before model inference. | Supplemental Control[Operational Practices](/evidence/operational-practices)Product | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to prevent secrets from being retained in platform logs, conversation history, and stored artifacts. For example, redacting detected credential patterns before log storage, masking secrets in conversation history displayed to users or support staff, or applying scrubbing functions to prompts and outputs before persistence. | **A008.5 Config: Secrets redaction in logs and stored artifacts.** Code or configuration showing secrets redaction in stored data - may include log redaction rules alongside PII patterns (extending A006.1-style logic to credentials), masking logic applied to conversation storage, scrubbing functions in output persistence pipelines, or storage configuration showing sanitization before writes. Can be demonstrated alongside or as part of existing PII redaction controls. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeLogs | | [A009: Third-party testing for data & privacy risk](/data-and-privacy/3rd-party-testing-for-data-and-privacy-risk)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **A009.1 Evals: Third-party evaluation report assessing data & privacy risk.** Third-party evaluation report showing testing for data & privacy risk - including risks tested (e.g., IP infringement, personal data leakage, business data leakage), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **B001.1 Evals: Third-party evaluation report assessing security risk.** Third-party evaluation report showing testing for security risk - including risks tested (e.g., insecure outputs, prompt injection), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)Mandatory Requirement | Aligning adversarial testing with broader security testing programs. For example, integrating AI-specific test cases into broader penetration testing, sharing threat models across red/blue teams, aligning test cycles with security audit and compliance calendars. | **B001.2 Documentation: Security program integration.** Penetration test reports with AI-specific test cases, shared threat models, and testing calendars, or documentation of broader security program incorporating AI adversarial testing requirements. | Supplemental Control[Operational Practices](/evidence/operational-practices)Engineering PracticeInternal processes | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Establishing detection and alerting. For example, implementing monitoring for prompt injection patterns, jailbreak techniques, adversarial input attempts, and exceeding rate limits, configuring alerts and threat notifications for suspicious activities. | **B002.1 Config: Adversarial input detection and alerting.** Monitoring system, SIEM, or detection code showing rules and alerts for adversarial inputs - may include prompt injection detection patterns, jailbreak technique signatures, rate limit monitoring with threshold alerts, or notification configurations (Slack, PagerDuty, email) | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Implementing incident logging and response procedures. For example, logging suspected adversarial attacks with relevant context, escalating to designated personnel based on severity, and documenting response actions in a centralized system. | **B002.2 Logs: Adversarial incident and response.** Incident management system or logs showing adversarial attack handling - may include log entries with timestamps and user/session context, escalation runbooks defining severity thresholds, or incident tickets in Jira/PagerDuty/ServiceNow documenting response actions and workflows. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)LogsEngineering Tooling | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Maintaining detection effectiveness through quarterly reviews. For example, updating detection rules based on emerging adversarial techniques, analyzing incident patterns and documenting system improvements. | **B002.3 Documentation: Updates to detection config.** Quarterly review documentation showing detection updates - for example, review meeting notes with incident pattern analysis, updated detection rules with version history, or tracking records showing rule improvements (e.g. GitHub/Jira tickets). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering PracticeInternal processes | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Implementing adversarial input detection prior to AI model processing where feasible. For example, using pre-processing filters to flag likely threats before model processing. | **B002.4 Config: Pre-processing adversarial detection.** Pre-processing filtering logic or gateway - may include pattern-matching or heuristic code checking inputs before model processing, WAF or API gateway rules blocking adversarial patterns, or IP-based filtering. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Integrating adversarial input detection into existing security operations tooling. For example, forwarding flagged inputs to SIEM platforms, correlating detection with authentication and network logs, enabling SOC teams to triage AI-related security events. | **B002.5 Config: AI security alerts.** SIEM platform, SOC tooling, or log forwarding configuration showing adversarial detection integration - may include Splunk/Datadog/Elastic SIEM ingesting AI adversarial alerts, correlation rules linking AI events with authentication or network logs, SOC dashboard displaying AI security event triage, or code forwarding flagged inputs to security platforms. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)Optional Requirement | Documenting limitations on technical information release. For example, limiting public disclosure of model architectures, algorithms, training data details, system configurations, and performance metrics, requiring approval before sharing technical specifications or implementation details.Controlling organizational information to balance transparency with security. For example, limiting disclosure of AI team details, development timelines, and other information that could reveal technical capabilities, reviewing public communications for sensitive information. | **B003.1 Documentation: Technical information disclosure guidelines.** Policy document, SOP, or handbook section defining limitations and approval requirements for publicly sharing AI system technical details - may include communication policy limiting disclosure of model architectures or configurations, engineering handbook with approval workflows for technical specifications, or internal procedures controlling release of organizational AI information. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)Optional Requirement | Establishing approval processes. For example, requiring designated review for public content referencing AI capabilities in e.g. publications, presentations, and marketing materials, and documenting approved disclosures with business justification. | **B003.2 Documentation: Public disclosure approval records.** Approval email, ticket, or review documentation for public AI communications - may include approval requests in email or Jira/Slack for blog posts or press releases, marketing review records for AI capability disclosures, or periodic security review logs for public-facing AI content. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Implementing systems distinguishing between high-volume legitimate usage and adversarial behavior. For example, using behavioral analytics and user profiling to calibrate detection thresholds and prevent false positives against trusted users. | **B004.1 Config: Anomalous usage detection.** Anomaly detection system or configuration file - may include behavioral analytics dashboard (Datadog, Elastic, Splunk) with user scoring rules, rate limiting configuration with tier-based thresholds (config.yaml, API gateway settings), user allowlists or reputation tables, or code implementing session-based threshold logic. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering ToolingEngineering Code | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Implementing rate limiting and query restrictions. For example, establishing per-user quotas to prevent model extraction, blocking excessive query patterns, implementing progressive restrictions for suspicious behavior, or using economic disincentives for high-volume usage. | **B004.2 Config: Rate limits.** Rate limiting configuration for API endpoints - may include per-user quota settings, query throttling rules, progressive restriction policies, WAF configuration (Cloudflare, AWS WAF, Azure Application Gateway) with blocking rules for excessive patterns, or pricing tier settings implementing usage-based cost increases. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Conducting simulated external attack testing of AI endpoints. For example, performing automated attack simulations, testing endpoint protection effectiveness against high-volume and distributed attacks, and documenting methodologies appropriate to organizational threat profile. | **B004.3 Report: External pentest of AI endpoints.** Third-party penetration test report for AI endpoints including attack simulations tested (e.g. scraping attempts, brute force, reconnaissance), rate limiting and endpoint protection validation, distributed attack testing, test methodology, and findings on protection effectiveness. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Maintaining endpoint security through remediation. For example, tracking identified vulnerabilities, implementing protective measures based on testing outcomes, and regularly updating endpoint defenses and detection thresholds. | **B004.4 Documentation: Vulnerability remediation.** Issue tracking system (GitHub, Jira, Linear) showing endpoint vulnerability lifecycle - must include vulnerability identification, remediation proposal, implementation, and production deployment with timestamps and approval records. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Integrating automated moderation tools to filter inputs before they reach the foundation model. For example, integrating third-party moderation APIs, implementing custom filtering rules, configuring blocking or warning actions for flagged content, and establishing confidence thresholds based on risk category and severity | **B005.1 Config: Input filtering.** Moderation tool integration showing API configuration, filtering rules, action settings (block/warn/modify), and confidence thresholds for different violation categories - this could be screenshots of configuration files, admin dashboard settings, or API integration code. Example moderation tools: OpenAI Moderation API, Claude content filtering, VirtueAI/Hive/Spectrum Labs | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: User LLM input filtering logicEngineering Tooling | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Documenting the moderation logic and rationale. For example, explaining chosen moderation tools, threshold justifications, and decision criteria for different risk categories. | **B005.2 Documentation: Input moderation approach.** Document explaining moderation approach including tool selection rationale, threshold settings with justifications, action logic for different violation types, and examples of how different input categories are handled. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Internal processesEngineering Practice | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Providing feedback to users when inputs are blocked. | **B005.3 Demonstration: Warning for blocked inputs.** User-facing messages or UI flows showing how blocked inputs are communicated to users - this could be error messages, warning dialogs, or alternative suggestions provided when content is filtered. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Product | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Logging flagged prompts for analysis and refinement of filters, while ensuring compliance with privacy obligations. | **B005.4 Logs: Input filtering.** Logging system showing how flagged inputs are captured, what metadata is included/excluded for privacy, retention policies, and audit trail - may include privacy documentation explaining logging disclosures to users. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Logs | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Periodically evaluating filter performance and adjusting thresholds accordingly. For example, accuracy, latency, false positives/negatives. | **B005.5 Documentation: Input filter performance.** Report or dashboard showing analysis of filter performance metrics (false positives, false negatives, accuracy, latency) and documented threshold adjustments made based on performance data - should include timestamps and rationale for changes. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)Mandatory Requirement | Implementing technical restrictions that limit agent capabilities to authorized scope. For example, restricting agent access to approved backend services, APIs and MCP servers, enforcing network segmentation or API gateway rules, or implementing service-level authorization preventing access to sensitive systems. | **B006.1 Config: Agent service access restrictions.** Configuration showing technical limitations on agent backend access - may include API gateway rules restricting accessible services, network policies defining allowed endpoints, MCP server allowlist or registration configuration restricting which MCP servers and tools the agent may connect to, service-level authorization configuration, or architecture diagram showing agent isolation boundaries including MCP server placement and network segmentation. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)Mandatory Requirement | Deploying monitoring and alerting for agent actions that exceed security boundaries. For example, logging all agent service interactions, alerting on access attempts to unauthorized systems or APIs, or anomaly detection flagging unusual connection patterns. | **B006.2 Config: Agent security monitoring and alerting.** Implementation of monitoring configuration tracking agent security-relevant actions - may include logging setup capturing agent service calls and authentication attempts, alert rules for unauthorized system access, security monitoring dashboard showing agent infrastructure interactions, or example logs demonstrating boundary violations are detected. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeLogs | | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)Mandatory Requirement | Implementing additional safeguards to contain runtime risk. For example, enabling sandboxed execution environments with configurable filesystem, network, and credential restrictions for agent-executed code and first-party MCP servers, monitoring MCP tool definitions for unauthorized changes after initial approval, providing pre-execution authorization hooks that verify runtime tool calls against defined policy before execution proceeds, or scanning agent configuration artifacts such as hooks, skills and rules for prompt injection or unauthorized behavior. | **B006.3 Config: Execution-level safeguards.** Configuration or code demonstrating runtime containment controls — may include sandbox or container configuration showing configurable filesystem, network, and credential restrictions for agent code execution environments and first-party MCP servers, tool definition integrity controls showing how unauthorized post-approval changes are detected, pre-execution hook or policy engine configuration showing tool calls are verified at runtime, or scanning of agent configuration artifacts for prompt injection or malicious patterns. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)Mandatory Requirement | Implementing system-level access controls tailored to AI systems. For example, using role-based or attribute-based access to restrict access to model configuration, training datasets, tool-calling capabilities, or prompt logs, based on job function and system sensitivity.Restricting administrative and configuration privileges to authorized personnel. For example, limiting ability to alter system behavior, tools, or models. | **B007.1 Config: User access controls.** IAM platform, permission files, or admin panel showing role-based or attribute-based access restrictions for AI system resources (model configurations, training datasets, tool-calling capabilities, prompt logs) - may include IAM role assignments, permission policies, or authorization code validating user permissions before accessing sensitive AI components. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)Mandatory Requirement | Conducting access reviews and updates at least quarterly. For example, validating access assignments, updating based on policy or role changes, documenting access changes with AI-specific context (e.g. model access justification, changes to agent capability boundaries, or access to sensitive prompt/response history). | **B007.2 Documentation: Access reviews.** Quarterly access review documentation - may include access review meeting notes, tracking records of access changes with justifications, or reports documenting role changes and access modifications based on policy updates. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Enforcing caller authentication across API endpoints and agentic interfaces. For example, applying scoped API tokens or signed requests for model API access; enforcing OAuth 2.0 or OIDC token validation with appropriate scoping for MCP server connections; implementing mutual authentication for agent-to-agent interfaces. | **B008.1 Config: API and agentic interface authentication.** Configuration or code showing caller authentication controls - may include scoped API token or signed request configuration for model API endpoints, OAuth token scoping or OIDC validation middleware for MCP server connections, or mutual authentication configuration for agent-to-agent interfaces (e.g. A2A protocol authentication config). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Securing data in transit across model API endpoints and agentic interfaces. For example, enforcing TLS for all model API endpoint traffic, MCP server connections, and agent-to-agent communication channels; implementing credential rotation policies for long-lived service connections. | **B008.2 Config: API and agentic interface transport security.** Configuration or code showing transport security controls - may include TLS/HTTPS certificate configuration for model API endpoints, MCP server traffic, or agent-to-agent connections, or credential rotation policy documentation for service-level MCP or A2A connections. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Enforcing data integrity across agentic interfaces. For example, implementing cryptographic message signing for agent-to-agent communication; applying schema validation and input sanitization to MCP tool call inputs and outputs. | **B008.3 Config: Agentic interface data integrity.** Configuration or code showing data integrity controls for agentic interfaces - may include cryptographic message signing configuration for agent-to-agent interfaces (e.g. signed agent cards), or schema validation configuration applied to MCP tool call inputs and outputs. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Securing model hosting environments. For example, using up-to-date and minimal container images, scanning for known vulnerabilities in dependencies and base images, and applying infrastructure-level isolation techniques based on risk level (e.g. container namespaces, VM separation, or dedicated GPU access). | **B008.4 Config: Model hosting security.** Container configuration or infrastructure setup for model hosting - may include Dockerfile with minimal base images and up-to-date dependencies, vulnerability scanning results from Trivy or Snyk for container images, or infrastructure configuration showing isolation techniques (container namespaces, VM separation, network policies, dedicated GPU allocation). | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Verifying model integrity before and during deployment. For example, using cryptographic checksums or signed artifacts to detect tampering, scanning model files for malicious payloads. | **B008.5 Config: Model integrity verification.** Deployment pipeline or code implementing model integrity checks - may include cryptographic checksum verification, model artifact signature validation, hash comparison before deployment, model scanning configuration detecting malicious payloads (e.g. Pickle, ONNX) using tools like Cisco's pickle-fuzzer, Trail of Bit's Fickling, or deployment logs recording model version hashes. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B009: Limit output over-exposure](/security/limit-output-over-exposure)Mandatory Requirement | Reducing or limiting the number of results shown in outputs to relevant only to balance security and utility. For example, character limits, limits on inference time. | **B009.1 Config: Output volume limits.** Code or configuration implementing output restrictions - may include character or token limits, inference time limits, result count restrictions, or timeout configurations preventing excessive output. Can be demonstrated by product demo showing system timeout when requesting output exceeding limits. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeProduct | | [B009: Limit output over-exposure](/security/limit-output-over-exposure)Mandatory Requirement | Providing user-facing notices or documentation about output limitations. | **B009.2 Demonstration: User output notices.** Product interface showing user notices about output limitations - may include messages indicating truncated or suppressed outputs for security or privacy reasons, user documentation explaining limitation policies, or help articles describing output restrictions. | Supplemental Control[Operational Practices](/evidence/operational-practices)Product | | [B009: Limit output over-exposure](/security/limit-output-over-exposure)Mandatory Requirement | Limiting the fidelity of model outputs in certain use cases. For example, applying output rounding, threshold bands, or obfuscation techniques to reduce the risk of model inversion. | **B009.3 Config: Output precision controls.** Code implementing output fidelity limitations - may include rounding logic for numerical outputs, threshold bands reducing precision, or obfuscation techniques preventing model inversion, precision-sensitive data disclosure, or adversarial model extraction attacks. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote secure patterns for common web vulnerability classes in generated code. For example, defaulting to parameterized queries or safe ORM patterns for database access, applying output encoding and contextual escaping to prevent cross-site scripting, or enforcing HTTPS/TLS in generated network and API code. | **B010.1 Config: Secure defaults for common vulnerability classes.** Code, configuration, or system prompt excerpt demonstrating secure defaults for common vulnerability classes, may include system prompt guidance directing the model toward parameterized queries and safe ORM patterns, framework scaffolding that applies output encoding by default, or sample generations on database or UI prompts showing safe patterns used without explicit user request. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote secure patterns for authentication and authorization in generated code. For example, defaulting to vetted authentication libraries or patterns on auth-related prompts, applying access control checks and least-privilege patterns by default, or avoiding generation of custom cryptographic or authentication primitives. | **B010.2 Config: Secure defaults for authentication and authorization.** Code, configuration, or system prompt excerpt demonstrating secure defaults for auth, may include system prompt guidance directing the model toward established auth libraries (e.g., Auth0, Clerk, framework-native auth), or sample generations on auth-related prompts showing vetted patterns rather than custom implementations. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to prevent dependency risks in generated code. For example, avoiding wildcard version specifications (e.g., \* or latest) in generated manifests, verifying that suggested packages exist in their respective registries before including them in generated code, or applying guidance that avoids known-abandoned or typosquatted packages. | **B010.3 Config: Safe dependency specification in generated code.** Code, configuration, or system prompt excerpt demonstrating safe dependency specification, may include system prompt guidance directing the model toward pinned versions and verified packages, registry validation logic checking generated package names against known registries, or sample generations showing appropriate version specifications across ecosystems. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote secure defaults for session management in generated code. For example, applying HttpOnly, Secure, and SameSite flags to session cookies by default, or defaulting to CSRF protections on state-changing endpoints. | **B010.4 Config: Secure session and cookie defaults.** Code, configuration, or sample generations showing secure session and cookie defaults in generated code, may include system prompt guidance, framework scaffolding configuration, or sample generations on session-management-related prompts. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote defensive programming patterns in generated code. For example, defaulting to input validation on user-supplied data, applying safe error handling that avoids exposing stack traces or internal details, or defaulting to rate limiting on generated public-facing endpoints. | **B010.5 Config: Input validation and error handling defaults.** Code, configuration, or sample generations showing input validation and error handling defaults, may include system prompt guidance, framework scaffolding patterns, or sample generations on prompts generating user-facing endpoints. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to prevent generated logging code from capturing secrets or personal information. For example, defaulting logging patterns to exclude sensitive fields, or applying guidance that avoids logging full request bodies or auth headers. | **B010.6 Config: Logging defaults in generated code.** Code, configuration, or sample generations showing safe logging defaults in generated code, may include system prompt guidance, logging templates used in scaffolding, or sample generations on logging-related prompts. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeLogs | | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)Mandatory Requirement | Defining risk categories with severity levels and examples based on industry and deployment context. For example, classifying harmful outputs such as distressed outputs, angry responses, high-risk advice, offensive content, bias, and deception, identifying other high-risk use cases such as safety-critical instructions, legal recommendations, financial advice.Aligning risk taxonomy with external frameworks and standards.Establishing severity grading appropriate to organizational context and risk tolerance. For example, implementing consistent scoring methodology across risk categories, defining thresholds for flagging and human review. | **C001.1 Documentation: AI risk taxonomy.** Internal policy document, risk framework, or taxonomy defining AI risk categories with severity levels and examples specific to deployment context. Example taxonomies to draw upon include NIST AI RMF functions, EU AI Act article 9, ISO42001 controls. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)Mandatory Requirement | Maintaining taxonomy currency with documented change management. For example, updating based on emerging threats or incidents. | **C001.2 Documentation: Risk taxonomy reviews.** Meeting notes, change log, or review documentation showing annnual reviews of the risk taxonomy. Could include review dates, participants, decisions made (categories added/removed/modified, threshold adjustments), rationale for changes, approvals records, and version history showing taxonomy updates over time with timestamps. Can be standalone or part of broader internal audit/review or change management procedures. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Conducting pre-deployment testing with documented results and identified issues. For example, structured hallucination testing, adversarial prompting, safety unit tests, and scenario-based walkthroughs.Completing risk assessments of identified issues before system deployment. For example, potential impact analysis, mitigation strategies, and residual risk evaluation.Obtaining approval sign-offs from designated accountable. For example, documented rationale for approval decisions and maintained records for review purposes. | **C002.1 Documentation: Pre-deployment test and approval records.** Test results with identified issues and severity ratings, risk assessment with mitigation decisions, and approval sign-offs with rationale - may be combined in deployment gate documentation or provided as separate documents (e.g., test suite outputs from GitHub Actions/pytest, Jira/Linear tickets with risk assessment and approval, staging environment test reports, deployment checklist with sign-offs). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Integrating AI system testing into established software development lifecycle (SDLC) gates. For example, including threat modelling and risk evaluation during design phases, requiring risk evaluation and sign-off at staging or pre-production milestones, aligning with CI/CD or MLOps pipelines, and documenting test artefacts in shared repositories." | **C002.2 Config: SDLC integration.** CI/CD pipeline configuration or workflow showing AI testing integrated as deployment gate - may include GitHub Actions/Jenkins/GitLab CI config files requiring test passage, pull request templates with testing checklists, or branch protection rules enforcing pre-deployment validation. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Implementing pre-deployment vulnerability scanning of AI artifacts and dependencies. For example, scanning AI models and ML libraries for security vulnerabilities, validating runtime behavior for unsafe operations, and analyzing outputs for harmful content before deployment. | **C002.3 Documentation: Vulnerability scan results.** Security scanning tools or CI/CD pipeline showing vulnerability analysis of AI artifacts and dependencies - may include GitHub/GitLab security tab with dependency alerts, Snyk or Dependabot vulnerability findings, pip-audit or safety check terminal output showing CVE scans, model file scanning results, or CI/CD logs showing security scan execution. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Testing changes to open-weight model before deployment. For example, re-running safety evaluations and guardrail test suites after major weights update via fine-tuning or quantization, or inference engine changes and comparing results to the prior model's baseline, and running targeted or automated checks for routine or low-risk changes. | **C002.4 Documentation: Open-weight model change regression testing.** Documented testing approach and results for the model change identifying the prior and new model version, the risk categories tested, and regression results - may include evaluation suite outputs before and after the change, automated check results for low-risk changes, or guardrail test suite pass rates. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Implementing content filtering for harmful output types. For example, detecting and blocking distressed responses, angry language, offensive content, biased statements, and deceptive information. | **C003.1 Config: Harmful output filtering.** Content filtering rules, moderation API configuration, or classifier settings showing detection and blocking logic for harmful output types - may include filtering rules in code, third-party moderation tool configuration (e.g., OpenAI Moderation API, Perspective API), or custom classifier model settings with harm category definitions. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Implementing guardrails for advice generation. For example, restricting high-risk recommendations in sensitive domains, requiring disclaimers for guidance. | **C003.2 Config: Guardrails for high-risk advice.** System prompts, guardrail rules, or domain restrictions showing safety controls on advice generation - may include defensive prompting, domain-specific output restrictions (e.g., medical/legal/financial advice blocklists), or conditional response templates that add warnings for sensitive topics. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Implementing bias detection and mitigation controls. For example, monitoring for discriminatory patterns, implementing fairness checks in outputs. | **C003.3 Config: Guardrails for biased outputs.** Documentation of bias eval results testing for stereotypical responses across demographic attributes, manual review logs documenting bias assessments, or output filtering rules blocking discriminatory patterns - may include automated fairness evaluation tools or bias monitoring dashboards if implemented. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Evaluating harm mitigation controls using performance metrics. | **C003.4 Documentation: Filtering performance benchmarks.** Test results, metrics dashboard, or evaluation report showing performance of harm controls - may include false positive/negative rates, coverage analysis of test scenarios, benchmark results against harm datasets (e.g., ToxiGen, RealToxicityPrompts), or confusion matrices showing filtering accuracy across harm categories. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)Mandatory Requirement | Detecting and blocking out-of-scope requests. For example, detecting conversations outside intended use cases, blocking prohibited topics, providing redirection messages when users hit boundaries, and escalating or restricting access for repeated violations. | **C004.1 Config: out-of-scope guardrails.** Blocking rules, defensive prompting, or filtering configuration showing how out-of-scope requests are detected and handled - may include topic blocklists, redirection message templates, escalation rules for repeated attempts, or system prompts defining allowed topics. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)Mandatory Requirement | Tracking out-of-scope violations and updating boundaries. For example, logging boundary violations, adjusting restrictions based on misuse patterns. | **C004.2 Logs: Out-of-scope attempts.** Logs showing out-of-scope attempts with frequency data. May include documentation of boundary updates made in response to violations, monitoring dashboard of flagged requests, change log showing restriction updates with rationale, or incident reports triggering scope adjustments. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Logs | | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)Mandatory Requirement | Providing user guidance on system capabilities and limitations. For example, communicating what the AI system can and cannot do, intended use cases, and topics or requests outside the system's scope. | **C004.3 Demonstration: User guidance on scope.** User-facing guidance explaining system capabilities and limitations - may include onboarding tooltips or welcome screens, help documentation or FAQs describing intended use, UI warnings when approaching scope boundaries, or published usage guidelines. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Product | | [C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)Mandatory Requirement | Implementing detection and blocking mechanisms aligned with organizational risk taxonomy. For example, deploying filtering based on defined risk categories and severity thresholds.Implementing response actions for detected risks. For example, blocking high-severity outputs, flagging medium-risk content for review, logging violations for monitoring and analysis. | **C005.1 Config: Risk detection and response.** Filtering rules, system configuration, or code showing detection logic mapped to AI risk taxonomy categories and corresponding response actions per severity level - may include risk classifiers with block/flag/log rules, content moderation API configuration defining actions by risk type, or defensive prompting. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)Mandatory Requirement | Establishing escalation procedures for flagged high-risk content. For example, defining when human review is required and establishing approval workflows for edge cases. | **C005.2 Documentation: Human review workflows.** Documentation or workflow configuration showing human review and escalation procedures for flagged content - may include runbook defining escalation criteria and review SLAs, workflow diagram showing approval process, or ticketing system configuration (Jira, Linear) with content review queues and assignment rules. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)Mandatory Requirement | Implementing automated real-time interventions. For example, blocking or modifying outputs based on severity. | **C005.3 Config: Automated response mechanisms.** Code or system configuration showing automated response mechanisms - may include logic blocking or modifying outputs based on risk scores, or dynamic warning messages triggered by content flags. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)Mandatory Requirement | Establishing output sanitization and validation procedures before presenting content to users. For example, encoding or stripping potentially malicious content, validating structured outputs against safe schemas, blocking unsafe URLs, and enforcing secure rendering modes. | **C006.1 Config: Output sanitization.** Code or configuration implementing output sanitization - may include HTML/JavaScript/shell syntax encoding functions, URL validation or rewriting rules blocking unsafe links, schema validation checking structured outputs (JSON/YAML/XML) against whitelists, CSP header configuration, or template rendering with auto-escaping enabled. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)Mandatory Requirement | Implementing content handling and security labelling based on trust level. For example, marking untrusted or third-party content, distinguishing external data from system-generated content, and applying differentiated security controls based on content source. | **C006.2 Demonstration: Content handling and labelling for untrusted content.** UI or code showing trust-based content handling - may include visual indicators marking third-party content (badges, styling, warning icons), metadata tags tracking content source and trust level, or code applying conditional security controls based on content origin (e.g., stricter sanitization for external sources). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)Mandatory Requirement | Detecting advanced output-based attack patterns. For example, identifying prompt injection attempts, model subversion techniques, payloads targeting downstream systems, or obfuscated exploits designed to bypass filters. | **C006.3 Config: Adversarial output detection.** Detection rules or monitoring system identifying advanced attack patterns in outputs - may include pattern matching for prompt injection chains or jailbreak tokens, payload signature scanning detecting command injection or SQL queries, or anomaly detection flagging obfuscated exploits bypassing basic filters. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)Optional Requirement | Defining high-risk output criteria drawing on risk taxonomy. | **C007.1 Documentation: Definition of high-risk output criteria.** Document or policy defining high-risk outputs requiring human review - should specify criteria for flagging (e.g. financial advice thresholds, medical/legal/safety domains, reputational harm triggers). Can be standalone or included in existing AI risk taxonomy/AI risk policy. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)Optional Requirement | Implementing automated detection mechanisms for high-risk outputs. For example, using content filtering, risk scoring, or classification models to identify outputs requiring review or flagging. | **C007.2 Config: High-risk detection mechanisms.** Detection code, configuration file, or rules engine showing high-risk output filtering - may include keyword lists or regex patterns flagging sensitive topics, scoring logic assigning risk values to recommendations, if/then rules defining high-risk conditions, ML model configuration (e.g., classification thresholds in config.yaml), or API response showing confidence scores with risk thresholds. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)Optional Requirement | Establishing human review workflows for flagged high-risk outputs. For example, assigning reviewers, defining escalation procedures for complex cases, managing review queues with response time tracking, documenting review decisions, and reviewing workflow effectiveness regularly. | **C007.3 Documentation: Human review workflows.** Workflow documentation or ticketing system configuration showing human review process for flagged outputs - may include runbook with reviewer assignments and escalation paths, queue management in Jira/Linear/support ticketing with pending review tracking, SLA targets for review response times, or procedure document defining review decision documentation requirements. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)Optional Requirement | Establishing ongoing monitoring of AI outputs across risk categories. For example, conducting regular evaluations prioritized by risk severity, sampling outputs for review, and tracking system behavior patterns. | **C008.1 Logs: AI risk monitoring.** Monitoring dashboard, logging system, or evaluation reports showing ongoing AI output tracking - may include output sampling logs with review results, behavior trace logs showing system patterns, prompt-response logging configuration, evaluation schedules prioritized by risk severity, or monitoring metrics dashboard tracking trends over time. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)Optional Requirement | Maintaining documentation. For example, recording identified scenarios with clear examples, updating risk taxonomy based on monitoring findings and incidents. | **C008.2 Documentation: Monitoring findings.** Document or change log showing identified risk scenarios with examples - may include incident reports triggering taxonomy changes, risk scenario database with concrete examples, or version history of risk taxonomy showing updates with rationale linked to monitoring findings. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)Optional Requirement | Integrating AI output monitoring with existing security tools. For example, forwarding alerts and flagged outputs to SIEM platforms, applying standard logging formats (e.g. JSON, syslog) to support automated threat detection workflows. | **C008.3 Config: Security tooling.** SIEM integration, log forwarding configuration, or security tool settings showing AI monitoring data flowing into existing security infrastructure - may include Splunk/Datadog/Elastic forwarding rules for AI alerts, JSON/syslog format configuration for AI logs, or SIEM dashboard showing AI-related events alongside other security telemetry. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)Optional Requirement | Enabling user intervention capabilities. For example, providing mechanisms for users to pause, stop, or redirect system behavior, implementing feedback collection tools for users to report issues or concerns, ensuring technical controls persist across devices and interaction contexts.Ensuring accessibility of feedback and intervention mechanisms. For example, adhering to WCAG 2.1 standards for color contrast, screen reader compatibility, keyboard navigation, and clear messaging for users with disabilities. | **C009.1 Demonstration: User intervention mechanisms.** Intervention controls (stop/pause/redirect buttons, feedback forms, issue reporting mechanisms) with accessibility features integrated (e.g. keyboard navigation, high contrast modes, screen reader labels) | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)Optional Requirement | Reviewing user feedback and intervention logs at regular intervals, analyzing findings using structured methodologies (e.g., categorizing by risk domain, frequency, and severity), and integrating corrective actions into product backlogs or compliance workflows, with records maintained for traceability. | **C009.2 Documentation: User feedback & intervention reviews.** Logs, reports, or dashboard showing review, analysis and actioning of user feedback and intervention patterns - may include feedback summary reports, intervention frequency analysis, categorization by risk domain, documentation of system changes made in response to patterns, or integration with product backlog/compliance workflows. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **C010.1 Evals: Third-party evaluation report assessing safety risk.** Third-party evaluation report showing testing for safety risk - including risks tested (e.g., physical harm, emotional harm, inappropriate content, high-risk domain engagement, bias), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [C011: \[Retired\] Third-party testing for out-of-scope outputs](/safety/3rd-party-testing-for-out-of-scope-outputs)Mandatory Requirement | This requirement was retired during the Q4, 2026 standard update. See aiuc-1.com/changelog for more information | **C011.1 Retired.** Retired | Mandatory Control | | [C012: \[Retired\] Third-party testing for customer-defined risk](/safety/3rd-party-testing-for-other-risk)Mandatory Requirement | This requirement was retired during the Q4, 2026 standard update. See aiuc-1.com/changelog for more information | **C012.1 Retired.** Retired | Mandatory Control | | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)Mandatory Requirement | Implementing factual accuracy controls. For example, deploying available fact-checking mechanisms, flagging uncertain or low-confidence responses. | **D001.1 Config: Groundedness filter.** Code or configuration showing groundedness validation - may include filters checking responses against source documents, fact-checking API integration, or logic comparing generated content to retrieved context for factual accuracy. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)Mandatory Requirement | Establishing information source validation. For example, requiring citations for factual claims, implementing source reliability checks. | **D001.2 Demonstration: User-facing citations & source attributions.** UI or output format showing citations and source attributions provided to users - may include inline citations, source links, reference lists, or attribution labels identifying where information originated. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)Mandatory Requirement | Maintaining uncertainty communication. For example, displaying confidence levels, providing appropriate disclaimers for generated information. | **D001.3 Demonstration: User-facing uncertainty labels.** UI or output format showing confidence levels, uncertainty disclaimers, or warnings for generated information - may include confidence score displays, low-certainty warnings, or standard disclaimers about potential inaccuracies. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Product | | [D002: \[Retired\] Third-party testing for hallucinations](/reliability/3rd-party-testing-for-hallucinations)Mandatory Requirement | This requirement was retired during the Q4, 2026 standard update. See aiuc-1.com/changelog for more information | **D002.1 Retired.** Retired | Mandatory Control | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Implementing tool call validation and authorization. For example, restricting tool calls to approved functions and MCP servers, validating parameters before execution. | **D003.1 Config: Tool authorization & validation.** Code or configuration showing function and tool allowlists, parameter validation logic, or authz checks before tool execution - may include tool permission schemas, input validation functions, or access control lists restricting available tools per agent/user. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Enforcing rate limits and transaction caps for autonomous tool use. | **D003.2 Config: Rate limits for tools.** Code or configuration showing rate limits and transaction caps on tool usage - may include per-tool usage quotas, time-windowed limits, or circuit breakers preventing excessive autonomous tool calls. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Establishing execution monitoring and logging. For example, tracking all tool calls, monitoring for unauthorized access attempts or scope violations. | **D003.3 Config: Tool call log.** Logging configuration, monitoring dashboard, or audit logs showing tracked tool calls - may include log entries capturing the originating MCP server, tool name, tool version, input parameters, and timestamps per invocation, alerts for unauthorized tool access attempts, or monitoring system flagging scope violations. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Logs | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Requiring human approval for sensitive tool operations. For example, requiring human confirmation before executing high-risk actions, multi-step tool calls, implementing approval workflows for operations beyond autonomous boundaries. | **D003.4 Config: Human-approval workflows.** Approval workflow configuration, code or ticketing system for sensitive, high-risk, or multi-step tool operations requiring human confirmation (e.g., executing financial transactions, deleting or irreversibly modifying records, and changing credentials or permissions). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Reviewing patterns of AI tool usage. For example, identifying anomalies, updating tool permissions, and retiring unused or high-risk functions during scheduled evaluations. | **D003.5 Documentation: tool call log reviews.** Reports or documentation showing periodic review of tool usage patterns, permission updates, and function retirement decisions - may include usage analytics identifying anomalies, change logs showing permission adjustments, or records of deprecated/retired tools with rationale. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **D004.1 Evals: Third-party evaluation report assessing reliability risk.** Third-party evaluation report showing testing for reliability risk - including risks tested (e.g., hallucinations, source attribution, incorrectly executed tool actions), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)Mandatory Requirement | Assigning a breach response lead from existing staff. For example, IT manager, security officer, or designated executive with authority to engage external counsel and specialists as needed.Defining breach notification procedures. For example, customer communications, regulatory reporting requirements, and vendor notifications based on applicable privacy laws.Implementing security remediation measures. For example, system freeze capabilities, vulnerability fixes, access control updates, and coordination with external security consultants when internal expertise is insufficient.Establishing evidence collection requirements with guidance on preserving evidence for potential legal review. For example, system logs, user activity records, and basic documentation. | **E001.1 Documentation: AI failure plan for security breaches.** Can be standalone document or integrated in existing incident response procedures/policies | Mandatory Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)Mandatory Requirement | Implementing customer communication protocols. For example, disclosure procedures, explanation of corrective actions, and follow-up commitments with executive approval for significant incidents.Establishing immediate mitigation steps with designated staff responsibilities. For example, system freeze capabilities, output suppression, customer notification, and system adjustments. | **E002.1 Documentation: AI failure plan for harmful outputs.** Can be standalone document or integrated in existing incident response procedures/policies | Mandatory Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)Mandatory Requirement | Defining harmful output categories with reference to risk taxonomy. For example, discriminatory content, offensive material, inappropriate recommendations, ideally with concrete examples.Coordinating external support engagement. For example, legal counsel consultation, PR support, and insurance claim procedures. | **E002.2 Documentation: Additional harmful output failure procedures.** May include harmful output category definitions referenced to risk taxonomy, external support contact list (legal counsel, PR firms, insurance providers), support engagement procedures or runbooks, or escalation criteria for involving external parties. | Supplemental Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)Mandatory Requirement | Implementing customer communication protocols. For example, disclosure procedures, explanation of corrective actions, and follow-up commitments with executive approval for significant incidents.Establishing immediate mitigation steps with designated staff responsibilities. For example, system freeze capabilities, model adjustments, output validation improvements, customer notification, and enhanced monitoring. | **E003.1 Documentation: AI failure plan for hallucinations.** Can be standalone document or integrated in existing incident response procedures/policies | Mandatory Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)Mandatory Requirement | Defining hallucination incident types.Coordinating potential external support. For example, legal consultation for significant claims, financial review when needed, and insurance coverage activation. | **E003.2 Documentation: Additional hallucination failure procedures.** May include hallucination incident categories (e.g. factual errors, incorrect recommendations), external support contact list (legal counsel, financial reviewers, insurance providers), support engagement procedures, or escalation criteria for involving external parties. | Supplemental Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E004: Assign accountability](/accountability/assign-accountability)Mandatory Requirement | Defining AI system changes requiring approval including model selection, material changes to the meta prompt, adding / removing guardrails, changes to end-user workflow, other changes that drive material. For example, +/-10% performance on evals.Assigning an accountable lead as approver for each of these changes. Can follow a RACI structure to formalize roles of those consulted and informed. | **E004.1 Documentation: Change approval policy and records.** Documentation or policy defining which AI system changes require approval with assigned accountable leads, and approval records showing sign-offs with supporting evidence. Can be a change management policy, overview table in e.g. Notion, approval logs from Jira/Linear/GitHub, or deployment gate documentation. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E004: Assign accountability](/accountability/assign-accountability)Mandatory Requirement | Implementing code signing and verification processes for AI models, libraries, and deployment artefacts to ensure only digitally signed components are approved for production use. | **E004.2 Config: Code signing implementation.** Code signing configuration, CI/CD pipeline requiring signed artifacts, or verification process for AI components - may include model signing process, signature verification in deployment pipeline, artifact registry showing signed models/libraries, or policy enforcement blocking unsigned components from production. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)Mandatory Requirement | Documenting data storage security. For example, assessments around cloud vs. on-premises processing. | **E005.1 Documentation: Data storage security practices.** Documenting data storage security practices against data sensitivity, regulatory requirements, and operational needs - may include security trust center documentation, deployment decision memos such as cloud vs. on-prem evaluations, risk assessment reports, and records of periodic reviews when requirements changed. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)Mandatory Requirement | Defining assessment criteria for foundational or upstream AI models. For example, data handling and ownership practices, PII controls, security measures, compliance status, open-source.Conducting documented assessments. For example, scoring results, verification activities such as certifications reviewed and references contacted, and approval decisions.Maintaining assessment records with sufficient detail for audit purposes and retaining due diligence evidence before vendor approval. | **E006.1 Documentation: Vendor due diligence.** Vendor assessment records showing evaluation criteria, scoring results, verification activities, approval decisions with accountable leads, and retained evidence supporting the assessment. May include vendor questionnaires, security reviews, compliance documentation, or due diligence reports. | Mandatory Control[Operational Practices](/evidence/operational-practices)Vendor ContractsInternal processes | | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)Mandatory Requirement | Verifying the source, integrity and licence of the open-weight model before use. For example, obtaining weights from the publisher's own repository or a vetted registry, verifying published checksums or signatures, checking for known issues with the model version, confirming the licence permits the intended use and identifying the base model for fine-tuned derivatives. | **E006.2 Documentation: Open-weight model source, integrity and licence verification.** Assessment records showing the source, integrity and license checks performed on the open-weight model - may include a model intake checklist identifying publisher, repository or registry, model version and base model for fine-tuned derivatives, checksum or signature verification output, and licence and known-issue review notes. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E007: \[Retired\] Document system change approvals](/accountability/document-system-change-approvals)Optional Requirement | This requirement was merged into E004 at the Q1, 2026 standard update. See aiuc-1.com/changelog for more information | **E007.1 Retired.** Retired | Mandatory Control | | [E008: Review internal processes](/accountability/review-internal-processes)Mandatory Requirement | Reviewing decision processes every quarter including AI system changes, foundational model selection, security assessment.Maintaining a centralized repository of decision records and internal review of these record. For example, supporting evidence reviewed, remediation plans.Documenting and tracking remediation of any risks identified. | **E008.1 Documentation: Internal review.** Centralized repository, policy, or tickets showing quarterly internal reviews - e.g. review meeting notes or calendars, decision logs in Jira/Notion/Confluence, risk registers with remediation status, threat modelling outcomes, or audit trails of review activities. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E008: Review internal processes](/accountability/review-internal-processes)Mandatory Requirement | Collecting and implementing external feedback on AI systems. For example, system risks, new threat patterns, new mitigation strategies. | **E008.2 Documentation: External feedback integration.** Documentation showing external feedback collected and implemented - may include external security advisories reviewed, threat intelligence integrated, third-party recommendations adopted, or records of external input incorporated into system improvements. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)Mandatory Requirement | Configuring logging for third-party interactions. For example, capturing API connections, user access sessions, data exchanges, and service integrations.Capturing access metadata. For example, user identification, authentication timestamps, accessed resources, session duration, origin IP addresses, and resource usage patterns. | **E009.1 Config: Third-party access monitoring.** Logging system or SIEM configuration showing third-party interactions being monitored with captured metadata - may include cloud logging interface (Google Cloud Logging, AWS CloudWatch, Azure Monitor) showing logged API requests with timestamps/IPs/user agents, access logs capturing authentication events and resource access, or SIEM dashboard displaying third-party connection monitoring with relevant metadata fields. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)Mandatory Requirement | Generating alerts on anomalous third-party access patterns against defined detection rules. For example, alerting on unexpected call volume or out-of-scope endpoints for service connections, repeated failed logins for human access, or credential use outside approved scope - with each alert routed to a responsible owner for disposition. | **E009.2 Config: Anomalous third-party access alerting.** Detection-rule or SIEM configuration for anomalous third-party access - may include alerting rules or correlation logic defining anomalous-access conditions, plus sample fired alerts showing disposition (case assignment, triage notes, or resolution records). | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Defining prohibited AI usage for end-users. For example, jailbreak attempts, malicious prompt injection, unauthorized data extraction, generation of harmful content, and misuse of customer data. | **E010.1 Documentation: AI acceptable use policy.** Policy document defining acceptable and/or prohibited AI usage - can be standalone document or parts of, e.g., terms of service | Mandatory Control[Legal Policies](/evidence/legal-policies)Acceptable Use Policy | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Implementing detection and monitoring tools. For example, prompt analysis, output filtering, usage pattern anomalies, and suspicious access attempts. | **E010.2 Config: AUP violation detection.** Code, configuration, or monitoring system detecting acceptable use policy violations - may include prompt analysis logic, output filtering rules, anomaly detection for usage patterns, or alerting on suspicious access attempts. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Implementing user feedback when policy is breached. For example, showing alerts or error messages when inputs violate acceptable use. | **E010.3 Demonstration: User notification for AUP breaches.** User-facing alerts or error messages displayed when acceptable use policy is violated - may include in-product warning messages, blocked request notifications, or error screens explaining policy violations. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Real-time monitoring, blocking, or alerting capabilities.Maintaining logging and tracking systems. For example, incident creation, violation tracking with case assignment and resolution documentation.Conducting regular effectiveness reviews. For example, quarterly analysis of violation trends, tool performance assessment, policy updates based on emerging threats, and user training adjustments. | **E010.4 Documentation: Guardrails enforcing acceptable use.** Documentation or screenshots showing additional AUP enforcement mechanisms - may include real-time blocking/alerting systems, violation tracking logs with incident management, effectiveness review reports analyzing violation trends and policy updates, or training materials addressing emerging misuse patterns. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [E011: Record processing locations](/accountability/record-processing-locations)Mandatory Requirement | Maintaining AI infrastructure location documentation. For example, geographic locations of foundation model processing locations and inference endpoint regions, documenting third-party AI service provider data handling locations.Reviewing and updating documentation regularly. | **E011.1 Documentation: AI processing locations.** Subprocessor list showing third-party AI provider locations, infrastructure documentation listing cloud regions and inference endpoints, or data flow diagram with geographic processing locations and version history or review dates. | Mandatory Control[Operational Practices](/evidence/operational-practices)Trust Center | | [E011: Record processing locations](/accountability/record-processing-locations)Mandatory Requirement | Implementing transfer compliance procedures. For example, assessing data transfer requirements for AI training data and inference processing, maintaining approved transfer mechanisms for foundation model providers and AI infrastructure, mitigating transfer risk for cross-border AI model training. | **E011.2 Documentation: Data transfer compliance.** Demonstrated by DPA, data transfer impact assessments, approved transfer mechanism documentation (Standard Contractual Clauses, adequacy decisions), cross-border data flow approvals for AI training/inference, or risk assessments for international AI processing. | Supplemental Control[Legal Policies](/evidence/legal-policies)Internal policiesData Processing Agreement | | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)Mandatory Requirement | Identifying relevant regulations. For example, data protection laws. For example, GDPR, CCPA, sector-specific requirements, emerging AI standards. For example, EU AI Act.Documenting compliance procedures and strategies appropriate for company size and operations.Reviewing the repository every 6 months and when additional requirements may be triggered. For example, regulations change or business operations expand into new jurisdictions. | **E012.1 Documentation: Regulatory compliance reviews.** Compliance register, assessment memo or review tickets (e.g. in Notion), or policy listing applicable regulations with compliance strategies - should include review dates or version history showing periodic updates. | Mandatory Control[Legal Policies](/evidence/legal-policies)Internal processes | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Defining quality objectives, metrics, and risk management approach for AI systems. For example, establishing performance targets, safety thresholds, risk assessment methodologies, and measurement processes appropriate to system risk level. | **E013.1 Documentation: Quality objectives and risk management.** Documentation showing quality objectives, metrics, and risk management approach - may include quality metrics dashboard or reports, risk assessment documentation for AI systems, performance targets and safety thresholds, or measurement methodologies defining how quality is evaluated. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Establishing change management, approval processes, and documentation standards. For example, defining review and approval requirements for AI system changes, assigning accountability for quality decisions, documenting design and development procedures. | **E013.2 Documentation: Change management procedures.** Documentation showing change management and approval processes - may include change approval workflows or procedures, RACI matrix assigning accountability for quality decisions, design and development procedure documents, or documentation standards and templates for AI systems. May be fulfilled by evidence submitted to E004: Assign accountability. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Implementing defect tracking, continuous improvement, and post-market monitoring. For example, maintaining issue tracking systems, conducting root cause analysis, documenting corrective actions, establishing post-market monitoring processes. | **E013.3 Config: Issue tracking and monitoring.** Issue tracking system or monitoring records - may include issue tracker (Jira, Linear, GitHub) with defects and corrective actions, root cause analysis reports, post-market monitoring logs or dashboards, or continuous improvement documentation showing lessons learned. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Establishing data management and record-keeping systems. For example, documenting data governance procedures, maintaining technical documentation, implementing record retention policies for model training data and system outputs. | **E013.4 Documentation: Data management procedures.** Documentation showing data management and record-keeping practices - may include data governance policies, technical documentation standards, record retention procedures, or data lineage tracking systems for training data and system outputs. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Documenting communication procedures with regulatory authorities and stakeholders. For example, establishing protocols for regulatory reporting, stakeholder notifications for incidents, and procedures for authority interactions. | **E013.5 Documentation: Stakeholder communication procedures.** Procedures document or communication protocols - may include incident reporting templates or protocols to regulatory authorities, stakeholder notification procedures for serious incidents, guidelines for interacting with competent authorities or notified bodies, or escalation procedures for regulatory communications. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E014: \[Retired\] Share transparency reports](/accountability/share-transparency-reports)Optional Requirement | This requirement was merged into E017 at the Q1, 2026 standard update. See [aiuc-1.com/changelog](http://aiuc-1.com/changelog) for more information | **E014.1 Retired.** Retired | Supplemental Control | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Capturing system activity details to support incident investigation and behavior explanation. For example, logging inputs, processing steps, outputs, and metadata for AI systems. | **E015.1 Config: Logging implementation.** Logging code or configuration showing what system activity is captured - may include code logging inputs and outputs, logging configuration file specifying what to log, or example log entries showing captured information (timestamps, inputs, outputs, user actions). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Logs | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Capturing full execution chains of agentic workflows to support investigation of agent-specific incidents. For example, logging agent provenance metadata, tool call parameters and results, sub-agent delegations and their outcomes, approval/authorization events (e.g., human-in-the-loop approvals), and reasoning traces where available. | **E015.2 Config: AI agent logging implementation .** Logging code or configuration demonstrating agent execution logging - may include log fields capturing agent provenance metadata per execution (e.g. agent type identifier, creator or deployment origin); structured log entries capturing tool call parameters and their results; delegation chain records showing sub-agent handoffs with identity, task context, and outcome at each step; approval/authorization records linked to execution (e.g., approver identity, timestamp, decision outcome); or reasoning trace output from the agent framework. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Logs | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Implementing log storage with appropriate retention periods, access controls, and data sanitation to support auditing and incident response. | **E015.3 Config: Log storage.** Log storage system showing retention policies, access controls and sanitation practices - may include log management platform (Datadog, Splunk, CloudWatch) with retention period settings and PII-masking, access control configuration showing who can view logs, or storage settings with automatic deletion rules. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)LogsEngineering Tooling | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Implementing technical controls to ensure logs are tamper-evident and independently verifiable. For example, ensuring that captured records cannot be modified or deleted after creation, ensuring sequence integrity so that gaps, omissions, and reordering are detectable during incident investigation or audit. | **E015.4 Config: Log integrity protection.** Log immutability controls - for example, write-once-read-many (WORM) storage configuration, cryptographic hashing of log entries, append-only database settings, or third-party log management platform features. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)LogsEngineering Code | | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)Mandatory Requirement | Implementing AI disclosure for text-based interactions. For example, displaying clear notices when users interact with AI chatbots, virtual assistants, or automated messaging systems.Implementing AI disclosure for voice-based interactions. For example, providing audio notifications at the beginning of voice calls or interactions.Labelling AI-generated media and documents in a machine-readable and detectable format. For example, marking AI-generated images, videos, audio, or documents with metadata, watermarks, or labels indicating artificial generation.Disclosing when autonomous AI agents or systems are performing actions. For example, notifying users when AI systems are making decisions, processing requests, or executing tasks without human oversight.Establishing reactive disclosure capabilities when users ask if they are interacting with AI. | **E016.1 Demonstration: AI disclosure.** AI disclosures across applicable modalities. May include disclosures for text (“You’re chatting with AI” notice in chat or on automated email/SMS), voice (recording or transcript of a spoken disclosure), automated actions (“Powered by AI” labels or “Completed by AI agent” notifications), AI-generated content (C2PA metadata or watermarks), and responses to “Are you AI?” (chatbot or voice agent transcript). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)Optional Requirement | Creating transparency documentation for major AI systems. For example, documenting system characteristics, data provenance, and model behavior for systems meeting documentation criteria. | **E017.1 Documentation: AI system transparency documentation.** Transparency documentation artifacts such as a model card, datasheet, or AI bill of materials - for example, records of the system name and version, training or fine-tuning data sources and characteristics, dated records of fine-tuning or adaptation changes and records of AI-specific components beyond the model including frameworks, orchestration layers, tool connectors. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)Optional Requirement | Defining policies for sharing transparency documentation with external stakeholders. For example, establishing when reports are shared, specifying recipient categories, determining what information is disclosed to each stakeholder type.Documenting sharing procedures including approval workflows, version control, and distribution tracking. For example, establishing approval requirements before external sharing, maintaining version control of shared documents, tracking which stakeholders received which versions. | **E017.2 Documentation: Transparency report sharing policy.** Policy document defining transparency sharing practices - may include sharing triggers, recipient categories with disclosure levels (regulators, customers, affected parties, public), or matrix mapping stakeholder types to shared documentation (model cards, datasheets, performance reports, incident summaries). | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processesInternal policies | | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)Optional Requirement | Documenting platform-level and deployer-level security responsibilities for AI systems. For example, delineating which security obligations are managed by the platform versus the deploying organization. | **E017.3 Documentation: Platform and deployer security responsibilities.** Documentation delineating platform and deployer security responsibilities - may include shared responsibility documentation defining platform-level and deployer-level security obligations. | Supplemental Control[Legal Policies](/evidence/legal-policies)Terms of ServiceInternal policies | | [E018: Third-party testing for accountability risk](/accountability/3rd-party-testing-for-accountability-risk)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **E018.1 Evals: Third-party evaluation report assessing accountability risk.** Third-party evaluation report showing testing for agent accountability risk - including risks tested (e.g., bypassing AI disclosure), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)Mandatory Requirement | Results of testing from foundation model developer on offensive cyber capabilities and mitigations. | **F001.1 Documentation: Foundation model cyber capabilities.** Provider model cards, cybersecurity assessment reports from model developers, or foundation model documentation describing offensive cyber capabilities and mitigations | Mandatory Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)Mandatory Requirement | Implementing malicious use detection and blocking. For example, deploying available content filtering to detect requests for malicious code generation, attack planning, and vulnerability exploitation guidance, configuring automated blocking of cyber attack assistance requests, maintaining databases of prohibited use patterns. | **F001.2 Config: Cyber use detection.** Content filtering rules blocking cyber attack requests, keyword or pattern matching detecting malicious code generation attempts, automated blocking configuration for exploit development queries, or prohibited use pattern database. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)Mandatory Requirement | Assessing and mitigating cyber capabilities for open-weight models. For example, re-running cyber misuse evals on the modified model or adding output classifiers for exploit and malware generation. | **F001.3 Documentation: Cyber capability assessment for modified models.** Assessment showing base model and version, modifications made, whether the developer's results still hold, and compensating guardrails applied - may include a short memo, re-run eval results or guardrail configuration. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse)Mandatory Requirement | Results of testing from foundation model developer on CBRN capabilities and mitigations. | **F002.1 Documentation: Foundation model CBRN capabilities.** List of foundation models used with CBRN capability information - may include provider model cards with CBRN assessments, weapons of mass destruction risk evaluations from model developers, or other documentation describing CBRN-related capabilities and mitigations. | Mandatory Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse)Mandatory Requirement | Establishing catastrophic misuse monitoring. For example, monitoring AI system interactions for patterns indicating weapons development or mass harm intent, implementing real-time alerting for detected catastrophic misuse attempts, documenting suspicious queries and system responses. | **F002.2 Config: Catastrophic misuse monitoring.** Monitoring dashboard or alert configuration for catastrophic misuse patterns - may include usage monitoring flagging CBRN-related queries, alert rules for weapons development patterns, logs of detected and blocked catastrophic misuse attempts, or incident records documenting suspicious CBRN-related interactions. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Legal evidence Source: https://standard.aiuc-1.com/evidence/legal-policies Evidence templates in the legal policies category. ## Legal evidence [Download evidence list](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit?usp=sharing) | Requirement | Control activity | Evidence | Tags | | - | - | - | - | | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)Mandatory Requirement | Defining and communicating input data usage policies. Including specifying how customer data is used for inference and model training, establishing data retention periods, and documenting customer data rights. | **A001.1 Documentation: Policy for input data ownership, usage and retention.** Typically demonstrated by Terms of Service, Privacy Policy or Data Processing Agreement | Mandatory Control[Legal Policies](/evidence/legal-policies)Terms of ServicePrivacy PolicyDPA | | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)Mandatory Requirement | Documenting processes for handling end-user data subject rights. For example, handling requests for opt-in/opt-out rights, access, portability, or deletion of input data. | **A001.3 Documentation: Data subject right processes.** May be included in DPA, GDPR appendix, External Privacy Policy or similar internal or external policies documenting processes for data handling | Supplemental Control[Legal Policies](/evidence/legal-policies)Data Processing AgreementPrivacy Policy | | [A002: Establish output data policy](/data-and-privacy/define-output-rights)Mandatory Requirement | Establishing output ownership and usage rights policies. For example, specifying customer ownership of AI-generated outputs versus AI inputs, defining permitted uses of outputs (commercial use, redistribution, modification), documenting usage restrictions or limitations, and clarifying how ownership applies to different output types or use cases.Disclosing opt-in/opt-out and deletion policies for AI outputs. For example, documenting how customers can opt out of output storage or reuse, explaining deletion request processes, specifying retention periods and data handling practices, and clarifying how customers can control or revoke permissions for their outputs. | **A002.1 Documentation: Output usage and ownership policy.** Typically demonstrated by Terms of Service, Data Processing Agreement, Master Service Agreement, Privacy Policy, or AI Addendum. May be a combination of these policies. | Mandatory Control[Legal Policies](/evidence/legal-policies)Terms of Service | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Leveraging foundation model provider protections. For example, using providers with zero data retention policies, requiring contractual commitments that inputs are not used for training, selecting models with enhanced privacy guarantees for sensitive use cases. | **A004.2 Documentation: foundational model IP protections.** Provider contracts, terms of service, or documentation showing IP protection commitments. Often found in third party's terms of use/service, DPA or AI Addendum/Schedule. | Supplemental Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)Mandatory Requirement | Establishing explicit consent and disclosure for combined data usage. For example, informing customers when their data will be combined with competitor data, disclosing data anonymization and abstraction policies, providing opt-out mechanisms. | **A005.1 Documentation: Consent for combined data usage.** Typically demonstrated by Data Processing Agreement or Terms of Service | Mandatory Control[Legal Policies](/evidence/legal-policies)Data Processing AgreementTerms of Service | | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)Mandatory Requirement | Documenting foundation model provider IP protections which may serve as primary infringement safeguards. For example, indemnification clauses or copyright/trademark guardrails. | **A007.1 Documentation: Model provider IP infringement protections.** Foundation model provider contract, terms of service, or data processing agreement showing IP protection commitments including copyright/trademark handling policies, indemnification clauses, liability coverage, and any documented limitations or exclusions. May include vendor questionnaire responses or certification documents addressing IP protections. | Mandatory Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Defining prohibited AI usage for end-users. For example, jailbreak attempts, malicious prompt injection, unauthorized data extraction, generation of harmful content, and misuse of customer data. | **E010.1 Documentation: AI acceptable use policy.** Policy document defining acceptable and/or prohibited AI usage - can be standalone document or parts of, e.g., terms of service | Mandatory Control[Legal Policies](/evidence/legal-policies)Acceptable Use Policy | | [E011: Record processing locations](/accountability/record-processing-locations)Mandatory Requirement | Implementing transfer compliance procedures. For example, assessing data transfer requirements for AI training data and inference processing, maintaining approved transfer mechanisms for foundation model providers and AI infrastructure, mitigating transfer risk for cross-border AI model training. | **E011.2 Documentation: Data transfer compliance.** Demonstrated by DPA, data transfer impact assessments, approved transfer mechanism documentation (Standard Contractual Clauses, adequacy decisions), cross-border data flow approvals for AI training/inference, or risk assessments for international AI processing. | Supplemental Control[Legal Policies](/evidence/legal-policies)Internal policiesData Processing Agreement | | [E012: Document regulatory compliance](/accountability/document-regulatory-compliance)Mandatory Requirement | Identifying relevant regulations. For example, data protection laws. For example, GDPR, CCPA, sector-specific requirements, emerging AI standards. For example, EU AI Act.Documenting compliance procedures and strategies appropriate for company size and operations.Reviewing the repository every 6 months and when additional requirements may be triggered. For example, regulations change or business operations expand into new jurisdictions. | **E012.1 Documentation: Regulatory compliance reviews.** Compliance register, assessment memo or review tickets (e.g. in Notion), or policy listing applicable regulations with compliance strategies - should include review dates or version history showing periodic updates. | Mandatory Control[Legal Policies](/evidence/legal-policies)Internal processes | | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)Optional Requirement | Documenting platform-level and deployer-level security responsibilities for AI systems. For example, delineating which security obligations are managed by the platform versus the deploying organization. | **E017.3 Documentation: Platform and deployer security responsibilities.** Documentation delineating platform and deployer security responsibilities - may include shared responsibility documentation defining platform-level and deployer-level security obligations. | Supplemental Control[Legal Policies](/evidence/legal-policies)Terms of ServiceInternal policies | | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)Mandatory Requirement | Results of testing from foundation model developer on offensive cyber capabilities and mitigations. | **F001.1 Documentation: Foundation model cyber capabilities.** Provider model cards, cybersecurity assessment reports from model developers, or foundation model documentation describing offensive cyber capabilities and mitigations | Mandatory Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | | [F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse)Mandatory Requirement | Results of testing from foundation model developer on CBRN capabilities and mitigations. | **F002.1 Documentation: Foundation model CBRN capabilities.** List of foundation models used with CBRN capability information - may include provider model cards with CBRN assessments, weapons of mass destruction risk evaluations from model developers, or other documentation describing CBRN-related capabilities and mitigations. | Mandatory Control[Legal Policies](/evidence/legal-policies)Vendor Contracts | 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Operational evidence Source: https://standard.aiuc-1.com/evidence/operational-practices Evidence templates in the operational practices category. ## Operational evidence [Download evidence list](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit?usp=sharing) | Requirement | Control activity | Evidence | Tags | | - | - | - | - | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Providing user guidance on protecting confidential information. For example, instructing employees not to input trade secrets, proprietary code, or confidential business information into AI systems, communicating data handling policies for AI tool usage, or establishing clear guidelines on what information can and cannot be shared with AI agents. | **A004.1 Documentation: User guidance on confidential information.** Policy document, training materials, or user guidelines instructing users on protecting confidential information when using AI systems. | Mandatory Control[Operational Practices](/evidence/operational-practices)Product | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing user-facing warnings when potential secrets are detected in user inputs. For example, alerting users when credentials are detected in their prompts. | **A008.4 Documentation: User-facing warnings for detected secrets.** Documentation of user-facing warnings when secrets are detected in inputs — may include user-facing documentation showing warning messages displayed when credentials are detected in user input before model inference. | Supplemental Control[Operational Practices](/evidence/operational-practices)Product | | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)Mandatory Requirement | Aligning adversarial testing with broader security testing programs. For example, integrating AI-specific test cases into broader penetration testing, sharing threat models across red/blue teams, aligning test cycles with security audit and compliance calendars. | **B001.2 Documentation: Security program integration.** Penetration test reports with AI-specific test cases, shared threat models, and testing calendars, or documentation of broader security program incorporating AI adversarial testing requirements. | Supplemental Control[Operational Practices](/evidence/operational-practices)Engineering PracticeInternal processes | | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)Optional Requirement | Documenting limitations on technical information release. For example, limiting public disclosure of model architectures, algorithms, training data details, system configurations, and performance metrics, requiring approval before sharing technical specifications or implementation details.Controlling organizational information to balance transparency with security. For example, limiting disclosure of AI team details, development timelines, and other information that could reveal technical capabilities, reviewing public communications for sensitive information. | **B003.1 Documentation: Technical information disclosure guidelines.** Policy document, SOP, or handbook section defining limitations and approval requirements for publicly sharing AI system technical details - may include communication policy limiting disclosure of model architectures or configurations, engineering handbook with approval workflows for technical specifications, or internal procedures controlling release of organizational AI information. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [B003: Manage public release of technical details](/security/limit-technical-over-disclosure)Optional Requirement | Establishing approval processes. For example, requiring designated review for public content referencing AI capabilities in e.g. publications, presentations, and marketing materials, and documenting approved disclosures with business justification. | **B003.2 Documentation: Public disclosure approval records.** Approval email, ticket, or review documentation for public AI communications - may include approval requests in email or Jira/Slack for blog posts or press releases, marketing review records for AI capability disclosures, or periodic security review logs for public-facing AI content. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)Mandatory Requirement | Conducting access reviews and updates at least quarterly. For example, validating access assignments, updating based on policy or role changes, documenting access changes with AI-specific context (e.g. model access justification, changes to agent capability boundaries, or access to sensitive prompt/response history). | **B007.2 Documentation: Access reviews.** Quarterly access review documentation - may include access review meeting notes, tracking records of access changes with justifications, or reports documenting role changes and access modifications based on policy updates. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [B009: Limit output over-exposure](/security/limit-output-over-exposure)Mandatory Requirement | Providing user-facing notices or documentation about output limitations. | **B009.2 Demonstration: User output notices.** Product interface showing user notices about output limitations - may include messages indicating truncated or suppressed outputs for security or privacy reasons, user documentation explaining limitation policies, or help articles describing output restrictions. | Supplemental Control[Operational Practices](/evidence/operational-practices)Product | | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)Mandatory Requirement | Defining risk categories with severity levels and examples based on industry and deployment context. For example, classifying harmful outputs such as distressed outputs, angry responses, high-risk advice, offensive content, bias, and deception, identifying other high-risk use cases such as safety-critical instructions, legal recommendations, financial advice.Aligning risk taxonomy with external frameworks and standards.Establishing severity grading appropriate to organizational context and risk tolerance. For example, implementing consistent scoring methodology across risk categories, defining thresholds for flagging and human review. | **C001.1 Documentation: AI risk taxonomy.** Internal policy document, risk framework, or taxonomy defining AI risk categories with severity levels and examples specific to deployment context. Example taxonomies to draw upon include NIST AI RMF functions, EU AI Act article 9, ISO42001 controls. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [C001: Define AI risk taxonomy](/safety/define-ai-risk-taxonomy)Mandatory Requirement | Maintaining taxonomy currency with documented change management. For example, updating based on emerging threats or incidents. | **C001.2 Documentation: Risk taxonomy reviews.** Meeting notes, change log, or review documentation showing annnual reviews of the risk taxonomy. Could include review dates, participants, decisions made (categories added/removed/modified, threshold adjustments), rationale for changes, approvals records, and version history showing taxonomy updates over time with timestamps. Can be standalone or part of broader internal audit/review or change management procedures. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Evaluating harm mitigation controls using performance metrics. | **C003.4 Documentation: Filtering performance benchmarks.** Test results, metrics dashboard, or evaluation report showing performance of harm controls - may include false positive/negative rates, coverage analysis of test scenarios, benchmark results against harm datasets (e.g., ToxiGen, RealToxicityPrompts), or confusion matrices showing filtering accuracy across harm categories. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)Optional Requirement | Defining high-risk output criteria drawing on risk taxonomy. | **C007.1 Documentation: Definition of high-risk output criteria.** Document or policy defining high-risk outputs requiring human review - should specify criteria for flagging (e.g. financial advice thresholds, medical/legal/safety domains, reputational harm triggers). Can be standalone or included in existing AI risk taxonomy/AI risk policy. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)Optional Requirement | Establishing human review workflows for flagged high-risk outputs. For example, assigning reviewers, defining escalation procedures for complex cases, managing review queues with response time tracking, documenting review decisions, and reviewing workflow effectiveness regularly. | **C007.3 Documentation: Human review workflows.** Workflow documentation or ticketing system configuration showing human review process for flagged outputs - may include runbook with reviewer assignments and escalation paths, queue management in Jira/Linear/support ticketing with pending review tracking, SLA targets for review response times, or procedure document defining review decision documentation requirements. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)Optional Requirement | Reviewing user feedback and intervention logs at regular intervals, analyzing findings using structured methodologies (e.g., categorizing by risk domain, frequency, and severity), and integrating corrective actions into product backlogs or compliance workflows, with records maintained for traceability. | **C009.2 Documentation: User feedback & intervention reviews.** Logs, reports, or dashboard showing review, analysis and actioning of user feedback and intervention patterns - may include feedback summary reports, intervention frequency analysis, categorization by risk domain, documentation of system changes made in response to patterns, or integration with product backlog/compliance workflows. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Reviewing patterns of AI tool usage. For example, identifying anomalies, updating tool permissions, and retiring unused or high-risk functions during scheduled evaluations. | **D003.5 Documentation: tool call log reviews.** Reports or documentation showing periodic review of tool usage patterns, permission updates, and function retirement decisions - may include usage analytics identifying anomalies, change logs showing permission adjustments, or records of deprecated/retired tools with rationale. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E001: AI failure plan for security breaches](/accountability/ai-failure-plan-for-security-breaches)Mandatory Requirement | Assigning a breach response lead from existing staff. For example, IT manager, security officer, or designated executive with authority to engage external counsel and specialists as needed.Defining breach notification procedures. For example, customer communications, regulatory reporting requirements, and vendor notifications based on applicable privacy laws.Implementing security remediation measures. For example, system freeze capabilities, vulnerability fixes, access control updates, and coordination with external security consultants when internal expertise is insufficient.Establishing evidence collection requirements with guidance on preserving evidence for potential legal review. For example, system logs, user activity records, and basic documentation. | **E001.1 Documentation: AI failure plan for security breaches.** Can be standalone document or integrated in existing incident response procedures/policies | Mandatory Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)Mandatory Requirement | Implementing customer communication protocols. For example, disclosure procedures, explanation of corrective actions, and follow-up commitments with executive approval for significant incidents.Establishing immediate mitigation steps with designated staff responsibilities. For example, system freeze capabilities, output suppression, customer notification, and system adjustments. | **E002.1 Documentation: AI failure plan for harmful outputs.** Can be standalone document or integrated in existing incident response procedures/policies | Mandatory Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E002: AI failure plan for harmful outputs](/accountability/ai-failure-plan-for-harmful-outputs)Mandatory Requirement | Defining harmful output categories with reference to risk taxonomy. For example, discriminatory content, offensive material, inappropriate recommendations, ideally with concrete examples.Coordinating external support engagement. For example, legal counsel consultation, PR support, and insurance claim procedures. | **E002.2 Documentation: Additional harmful output failure procedures.** May include harmful output category definitions referenced to risk taxonomy, external support contact list (legal counsel, PR firms, insurance providers), support engagement procedures or runbooks, or escalation criteria for involving external parties. | Supplemental Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)Mandatory Requirement | Implementing customer communication protocols. For example, disclosure procedures, explanation of corrective actions, and follow-up commitments with executive approval for significant incidents.Establishing immediate mitigation steps with designated staff responsibilities. For example, system freeze capabilities, model adjustments, output validation improvements, customer notification, and enhanced monitoring. | **E003.1 Documentation: AI failure plan for hallucinations.** Can be standalone document or integrated in existing incident response procedures/policies | Mandatory Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E003: AI failure plan for hallucinations](/accountability/ai-failure-plan-for-hallucinations)Mandatory Requirement | Defining hallucination incident types.Coordinating potential external support. For example, legal consultation for significant claims, financial review when needed, and insurance coverage activation. | **E003.2 Documentation: Additional hallucination failure procedures.** May include hallucination incident categories (e.g. factual errors, incorrect recommendations), external support contact list (legal counsel, financial reviewers, insurance providers), support engagement procedures, or escalation criteria for involving external parties. | Supplemental Control[Operational Practices](/evidence/operational-practices)AI failure plan | | [E004: Assign accountability](/accountability/assign-accountability)Mandatory Requirement | Defining AI system changes requiring approval including model selection, material changes to the meta prompt, adding / removing guardrails, changes to end-user workflow, other changes that drive material. For example, +/-10% performance on evals.Assigning an accountable lead as approver for each of these changes. Can follow a RACI structure to formalize roles of those consulted and informed. | **E004.1 Documentation: Change approval policy and records.** Documentation or policy defining which AI system changes require approval with assigned accountable leads, and approval records showing sign-offs with supporting evidence. Can be a change management policy, overview table in e.g. Notion, approval logs from Jira/Linear/GitHub, or deployment gate documentation. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E005: Document data storage security](/accountability/assess-cloud-vs-on-prem-processing)Mandatory Requirement | Documenting data storage security. For example, assessments around cloud vs. on-premises processing. | **E005.1 Documentation: Data storage security practices.** Documenting data storage security practices against data sensitivity, regulatory requirements, and operational needs - may include security trust center documentation, deployment decision memos such as cloud vs. on-prem evaluations, risk assessment reports, and records of periodic reviews when requirements changed. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)Mandatory Requirement | Defining assessment criteria for foundational or upstream AI models. For example, data handling and ownership practices, PII controls, security measures, compliance status, open-source.Conducting documented assessments. For example, scoring results, verification activities such as certifications reviewed and references contacted, and approval decisions.Maintaining assessment records with sufficient detail for audit purposes and retaining due diligence evidence before vendor approval. | **E006.1 Documentation: Vendor due diligence.** Vendor assessment records showing evaluation criteria, scoring results, verification activities, approval decisions with accountable leads, and retained evidence supporting the assessment. May include vendor questionnaires, security reviews, compliance documentation, or due diligence reports. | Mandatory Control[Operational Practices](/evidence/operational-practices)Vendor ContractsInternal processes | | [E006: Conduct vendor and model due diligence](/accountability/conduct-vendor-due-diligence)Mandatory Requirement | Verifying the source, integrity and licence of the open-weight model before use. For example, obtaining weights from the publisher's own repository or a vetted registry, verifying published checksums or signatures, checking for known issues with the model version, confirming the licence permits the intended use and identifying the base model for fine-tuned derivatives. | **E006.2 Documentation: Open-weight model source, integrity and licence verification.** Assessment records showing the source, integrity and license checks performed on the open-weight model - may include a model intake checklist identifying publisher, repository or registry, model version and base model for fine-tuned derivatives, checksum or signature verification output, and licence and known-issue review notes. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E008: Review internal processes](/accountability/review-internal-processes)Mandatory Requirement | Reviewing decision processes every quarter including AI system changes, foundational model selection, security assessment.Maintaining a centralized repository of decision records and internal review of these record. For example, supporting evidence reviewed, remediation plans.Documenting and tracking remediation of any risks identified. | **E008.1 Documentation: Internal review.** Centralized repository, policy, or tickets showing quarterly internal reviews - e.g. review meeting notes or calendars, decision logs in Jira/Notion/Confluence, risk registers with remediation status, threat modelling outcomes, or audit trails of review activities. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E008: Review internal processes](/accountability/review-internal-processes)Mandatory Requirement | Collecting and implementing external feedback on AI systems. For example, system risks, new threat patterns, new mitigation strategies. | **E008.2 Documentation: External feedback integration.** Documentation showing external feedback collected and implemented - may include external security advisories reviewed, threat intelligence integrated, third-party recommendations adopted, or records of external input incorporated into system improvements. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E011: Record processing locations](/accountability/record-processing-locations)Mandatory Requirement | Maintaining AI infrastructure location documentation. For example, geographic locations of foundation model processing locations and inference endpoint regions, documenting third-party AI service provider data handling locations.Reviewing and updating documentation regularly. | **E011.1 Documentation: AI processing locations.** Subprocessor list showing third-party AI provider locations, infrastructure documentation listing cloud regions and inference endpoints, or data flow diagram with geographic processing locations and version history or review dates. | Mandatory Control[Operational Practices](/evidence/operational-practices)Trust Center | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Defining quality objectives, metrics, and risk management approach for AI systems. For example, establishing performance targets, safety thresholds, risk assessment methodologies, and measurement processes appropriate to system risk level. | **E013.1 Documentation: Quality objectives and risk management.** Documentation showing quality objectives, metrics, and risk management approach - may include quality metrics dashboard or reports, risk assessment documentation for AI systems, performance targets and safety thresholds, or measurement methodologies defining how quality is evaluated. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Establishing change management, approval processes, and documentation standards. For example, defining review and approval requirements for AI system changes, assigning accountability for quality decisions, documenting design and development procedures. | **E013.2 Documentation: Change management procedures.** Documentation showing change management and approval processes - may include change approval workflows or procedures, RACI matrix assigning accountability for quality decisions, design and development procedure documents, or documentation standards and templates for AI systems. May be fulfilled by evidence submitted to E004: Assign accountability. | Mandatory Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Establishing data management and record-keeping systems. For example, documenting data governance procedures, maintaining technical documentation, implementing record retention policies for model training data and system outputs. | **E013.4 Documentation: Data management procedures.** Documentation showing data management and record-keeping practices - may include data governance policies, technical documentation standards, record retention procedures, or data lineage tracking systems for training data and system outputs. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal policies | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Documenting communication procedures with regulatory authorities and stakeholders. For example, establishing protocols for regulatory reporting, stakeholder notifications for incidents, and procedures for authority interactions. | **E013.5 Documentation: Stakeholder communication procedures.** Procedures document or communication protocols - may include incident reporting templates or protocols to regulatory authorities, stakeholder notification procedures for serious incidents, guidelines for interacting with competent authorities or notified bodies, or escalation procedures for regulatory communications. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)Optional Requirement | Defining policies for sharing transparency documentation with external stakeholders. For example, establishing when reports are shared, specifying recipient categories, determining what information is disclosed to each stakeholder type.Documenting sharing procedures including approval workflows, version control, and distribution tracking. For example, establishing approval requirements before external sharing, maintaining version control of shared documents, tracking which stakeholders received which versions. | **E017.2 Documentation: Transparency report sharing policy.** Policy document defining transparency sharing practices - may include sharing triggers, recipient categories with disclosure levels (regulators, customers, affected parties, public), or matrix mapping stakeholder types to shared documentation (model cards, datasheets, performance reports, incident summaries). | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processesInternal policies | | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)Mandatory Requirement | Assessing and mitigating cyber capabilities for open-weight models. For example, re-running cyber misuse evals on the modified model or adding output classifiers for exploit and malware generation. | **F001.3 Documentation: Cyber capability assessment for modified models.** Assessment showing base model and version, modifications made, whether the developer's results still hold, and compensating guardrails applied - may include a short memo, re-run eval results or guardrail configuration. | Supplemental Control[Operational Practices](/evidence/operational-practices)Internal processes | 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Technical evidence Source: https://standard.aiuc-1.com/evidence/technical-implementation Evidence templates in the technical implementation category. ## Technical evidence [Download evidence list](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit?usp=sharing) | Requirement | Control activity | Evidence | Tags | | - | - | - | - | | [A001: Establish input data policy](/data-and-privacy/establish-data-use-policy)Mandatory Requirement | Implementing technical controls to enforce data retention and deletion policies. For example, automating data deletion based on retention schedules, using secure removal mechanisms, and managing data lifecycles. | **A001.2 Config: Data retention implementation.** Implementation of automated deletion schedule or data lifecycle system - may include cron job or scheduled task deleting expired data, deletion script in Python/Bash with retention period logic, data lifecycle management tool configuration (e.g., AWS S3 lifecycle rules, database TTL settings), or deletion audit logs from database or storage system. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [A002: Establish output data policy](/data-and-privacy/define-output-rights)Mandatory Requirement | Implementing technical controls to enforce AI output opt-in/opt-out and deletion policies. For example, automating customer preference enforcement through consent management configuration, processing opt-out and deletion requests within defined workflows, and validating that opted-out outputs are excluded from storage and downstream reuse. | **A002.2 Config: Opt-in/opt-out and output deletion implementation.** Implementation of opt-in/opt-out enforcement mechanism or output deletion workflow - may include consent management system enforcing customer preferences (e.g., feature flag gating output storage, consent database linked to processing pipeline), opt-out or deletion request processing script or automated task, or audit logs from consent and deletion systems with timestamps and execution records. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)Mandatory Requirement | Configuring data access limits to reduce data and privacy exposure. For example, limiting data access to task-relevant information based on context, implementing scoping based on user roles or workflow requirements, and avoiding persistent or out-of-scope data access. | **A003.1 Config: Data access scoping.** Code implementing data access restrictions - may include RAG retrieval function with document filtering logic, session scoping configuration limiting data access per session ID, workflow conditional logic gating data collection by stage, permission decorators or middleware checking user roles before data access, or scoping functions rejecting out-of-scope queries with error messages. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)Mandatory Requirement | Enabling agent identity management. For example, assigning each agent a unique, cryptographically verifiable identity; supporting standard identity federation protocols (e.g., OAuth 2.0, OIDC) for enterprise IAM integration; publishing agent cards declaring each agent's capabilities, tools, and permission scopes. | **A003.2 Config: Agent identity management.** Documentation showing how identity governance is enabled - may include platform configuration showing unique, cryptographically verifiable identity assignment per agent instance, API or SDK documentation for identity federation endpoints (e.g., OIDC token exchange), or a sample agent card declaring agent capabilities and scopes. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A003: Limit AI agent data access](/data-and-privacy/implement-contextual-data-safeguards)Mandatory Requirement | Enabling agent access and governance through permission-ready architecture. For example, exposing per-agent permission scopes mappable to enterprise roles; supporting just-in-time permissions scoped to specific subtasks; preventing silent inheritance of elevated permissions from orchestrators or parent agents; enforcing segregation of duties across systems; and integrating data loss prevention controls on agent actions and tool calls. | **A003.3 Config: Agent access and permissions management.** Documentation showing how permission governance is enabled - may include API or SDK documentation for permission scope configuration mappable to RBAC or ABAC policies, platform settings or code demonstrating just-in-time credential issuance scoped to individual subtasks or tool calls, architecture documentation showing how inherited permission chains from orchestrators or parent agents are bounded or surfaced for review, a segregation of duties matrix identifying and preventing conflicting agent permission combinations across integrated systems, or DLP policy configuration showing inspection and blocking rules applied to outbound data transmitted through agent actions or tool calls. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Implementing technical controls to detect proprietary information in outputs. | **A004.3 Config: IP detection implementation.** Code or configuration detecting proprietary information patterns in AI outputs - may include labelling proprietary files, filtering rules for internal identifiers/data labels/API keys, scanning logic for trade secret terminology, or rejection demonstrations showing appropriate responses to proprietary requests. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeProduct | | [A004: Protect IP & trade secrets](/data-and-privacy/protect-ip-trade-secrets)Mandatory Requirement | Establishing output monitoring for high-risk IP scenarios. For example, logging AI responses that accessed confidential data sources, implementing human review workflows for outputs flagged as potentially containing sensitive information. | **A004.4 Config: IP disclosure monitoring.** Logs, audit trails, or review workflow documentation for AI outputs potentially containing sensitive information - may include logs of responses accessing confidential sources, flagged output review queues, or human approval workflows for high-risk disclosures. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering PracticeLogs | | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)Mandatory Requirement | Implementing customer data isolation controls. For example, enforcing strict logical and physical separation of customer data, applying tenant-specific encryption, validating data flow boundaries in shared infrastructure, establishing technical barriers between customer datasets during training. | **A005.2 Config: Customer data isolation controls.** Configuration or code demonstrating enforced isolation of each customer's data. For example, tenant/app-ID enforcement in the database schema, namespace or per-tenant isolation in the retrieval/vector store for RAG, logical isolation appropriate to the architecture. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A005: Prevent cross-customer data exposure](/data-and-privacy/prevent-cross-customer-data-exposure)Mandatory Requirement | Implementing specific privacy-enhancing technologies (PETs) to reduce competitive exposure. | **A005.3 Config: Privacy-enhancing controls.** May include tokenization, hashing, or anonymization techniques (robust to prevent re-identification or reversal) making data algorithmic-usable but not human-readable, differential privacy implementation obfuscating individual contributions, federated learning configuration avoiding centralized raw data, or data masking/pseudonymization protecting customer identities. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)Mandatory Requirement | Implementing safeguards to prevent personal data leakage through AI system outputs and logs. For example, filtering prompts and outputs for personal identifiers before storage or display, implementing automated PII detection and redaction in system logs, preventing retention of outputs containing sensitive personal information, or blocking responses that would expose personal identifiers. | **A006.1 Config: PII detection and filtering.** Configuration or code output demonstrating filtering of LLM inputs and/or outputs for personal identifiers - may include keyword checks or regex patterns detecting PII (e.g. names, emails, SSNs, phone numbers), scrubbing functions removing personal data before storage or logging, output filtering blocking responses containing personal identifiers, log redaction configuration removing PII from application or system logs, or structured logging with PII isolation controls. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logicEng: User LLM input filtering logic | | [A006: Prevent PII leakage](/data-and-privacy/prevent-pii-leakage)Mandatory Requirement | Integrating with existing data loss prevention (DLP) systems to monitor and block outputs containing personal data in violation of policy. | **A006.2 Config: DLP system integration.** Output pipeline integration with a DLP system to scan and block PII policy violations - may include DLP integration code scanning AI outputs before delivery to users, DLP configuration rules for PII detection, or logs showing blocked outputs containing personal data. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)Mandatory Requirement | Establishing supplementary content filtering mechanisms where provider protections have gaps or limitations. For example, detecting copyrighted material in outputs, implementing trademark screening. | **A007.2 Config: IP infringement filtering.** Code, API configuration, or filtering system showing detection of copyrighted material, trademark screening, or content validation checks applied to AI outputs - this could be pattern matching logic, third-party API integration (e.g. copyright detection services), or custom filtering rules. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEng: LLM output filtering logic | | [A007: Prevent IP violations](/data-and-privacy/prevent-ip-violations)Mandatory Requirement | Implementing user guidance and guardrails to reduce IP risk. For example, usage policies that explain prohibited content types, user warnings in product, restricting output generation in known infringement domains.Implementing restrictions in AI acceptable use policy. | **A007.3 Logs: User-facing notices.** User-facing IP risk guidance - may include warning messages when attempting high-risk operations, help center articles about IP infringement guidance, or UI elements explaining prohibited use cases. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)ProductAcceptable Use Policy | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to detect credentials in user inputs. For example, scanning user prompts and pasted content for API keys, access tokens, private keys, and connection strings using pattern-matching or entropy-based detection; defining handling procedures when detected such as warning the user, refusing to persist, or flagging to the deployer. | **A008.1 Config: Secrets detection in user inputs.** Code or configuration demonstrating input-side secrets detection. For example, regex patterns or detection libraries (e.g., detect-secrets, TruffleHog rulesets) scanning user prompts and pasted context, entropy-based detection for high-randomness strings, or integration with third-party secret detection APIs. Evidence should also show the defined handling response (e.g., user warning UI, rejection logic, or alert configuration). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: User LLM input filtering logic | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to keep secrets out of generated code artifacts. For example, guiding the model via system prompts to reference environment variables or secret-management tools rather than hardcoding credentials, post-generation scanning of output files for common credential patterns, or blocking/flagging generations that contain detected secrets before they are written to disk. | **A008.2 Config: Secrets handling in generated code.** Code, configuration, or system prompt excerpt demonstrating secrets hygiene - may include system prompt guidance directing the model toward envvar or secret-store patterns, scanning logic applied to generated files, sample generations on credential-requiring prompts showing envvar references rather than literals, or block/flag logic preventing persistence of outputs containing detected secrets. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to securely store user-provided credentials to enable agent-connected services. For example, storing OAuth tokens, API keys, and connection strings in a dedicated secret manager, encrypting credentials at rest, scoping credential access per tool and per session, or fetching credentials only at the point of tool invocation rather than persisting them in the agent's context window. | **A008.3 Config: Secure storage of user-provided credentials.** Configuration showing secure handling of user-provided credentials — may include secret manager integration (e.g., AWS Secrets Manager, HashiCorp Vault, cloud-native KMS), encryption-at-rest configuration for credential storage, access scoping configuration limiting which tools or sessions can retrieve specific credentials, or code showing just-in-time credential fetching at tool-call time. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [A008: Prevent leakage of credentials and secrets](/data-and-privacy/prevent-secrets-leakage)Mandatory Requirement | Implementing safeguards to prevent secrets from being retained in platform logs, conversation history, and stored artifacts. For example, redacting detected credential patterns before log storage, masking secrets in conversation history displayed to users or support staff, or applying scrubbing functions to prompts and outputs before persistence. | **A008.5 Config: Secrets redaction in logs and stored artifacts.** Code or configuration showing secrets redaction in stored data - may include log redaction rules alongside PII patterns (extending A006.1-style logic to credentials), masking logic applied to conversation storage, scrubbing functions in output persistence pipelines, or storage configuration showing sanitization before writes. Can be demonstrated alongside or as part of existing PII redaction controls. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeLogs | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Establishing detection and alerting. For example, implementing monitoring for prompt injection patterns, jailbreak techniques, adversarial input attempts, and exceeding rate limits, configuring alerts and threat notifications for suspicious activities. | **B002.1 Config: Adversarial input detection and alerting.** Monitoring system, SIEM, or detection code showing rules and alerts for adversarial inputs - may include prompt injection detection patterns, jailbreak technique signatures, rate limit monitoring with threshold alerts, or notification configurations (Slack, PagerDuty, email) | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Implementing incident logging and response procedures. For example, logging suspected adversarial attacks with relevant context, escalating to designated personnel based on severity, and documenting response actions in a centralized system. | **B002.2 Logs: Adversarial incident and response.** Incident management system or logs showing adversarial attack handling - may include log entries with timestamps and user/session context, escalation runbooks defining severity thresholds, or incident tickets in Jira/PagerDuty/ServiceNow documenting response actions and workflows. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)LogsEngineering Tooling | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Maintaining detection effectiveness through quarterly reviews. For example, updating detection rules based on emerging adversarial techniques, analyzing incident patterns and documenting system improvements. | **B002.3 Documentation: Updates to detection config.** Quarterly review documentation showing detection updates - for example, review meeting notes with incident pattern analysis, updated detection rules with version history, or tracking records showing rule improvements (e.g. GitHub/Jira tickets). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering PracticeInternal processes | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Implementing adversarial input detection prior to AI model processing where feasible. For example, using pre-processing filters to flag likely threats before model processing. | **B002.4 Config: Pre-processing adversarial detection.** Pre-processing filtering logic or gateway - may include pattern-matching or heuristic code checking inputs before model processing, WAF or API gateway rules blocking adversarial patterns, or IP-based filtering. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B002: Detect adversarial input](/security/detect-adversarial-input)Optional Requirement | Integrating adversarial input detection into existing security operations tooling. For example, forwarding flagged inputs to SIEM platforms, correlating detection with authentication and network logs, enabling SOC teams to triage AI-related security events. | **B002.5 Config: AI security alerts.** SIEM platform, SOC tooling, or log forwarding configuration showing adversarial detection integration - may include Splunk/Datadog/Elastic SIEM ingesting AI adversarial alerts, correlation rules linking AI events with authentication or network logs, SOC dashboard displaying AI security event triage, or code forwarding flagged inputs to security platforms. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Implementing systems distinguishing between high-volume legitimate usage and adversarial behavior. For example, using behavioral analytics and user profiling to calibrate detection thresholds and prevent false positives against trusted users. | **B004.1 Config: Anomalous usage detection.** Anomaly detection system or configuration file - may include behavioral analytics dashboard (Datadog, Elastic, Splunk) with user scoring rules, rate limiting configuration with tier-based thresholds (config.yaml, API gateway settings), user allowlists or reputation tables, or code implementing session-based threshold logic. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering ToolingEngineering Code | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Implementing rate limiting and query restrictions. For example, establishing per-user quotas to prevent model extraction, blocking excessive query patterns, implementing progressive restrictions for suspicious behavior, or using economic disincentives for high-volume usage. | **B004.2 Config: Rate limits.** Rate limiting configuration for API endpoints - may include per-user quota settings, query throttling rules, progressive restriction policies, WAF configuration (Cloudflare, AWS WAF, Azure Application Gateway) with blocking rules for excessive patterns, or pricing tier settings implementing usage-based cost increases. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Conducting simulated external attack testing of AI endpoints. For example, performing automated attack simulations, testing endpoint protection effectiveness against high-volume and distributed attacks, and documenting methodologies appropriate to organizational threat profile. | **B004.3 Report: External pentest of AI endpoints.** Third-party penetration test report for AI endpoints including attack simulations tested (e.g. scraping attempts, brute force, reconnaissance), rate limiting and endpoint protection validation, distributed attack testing, test methodology, and findings on protection effectiveness. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [B004: Prevent AI endpoint scraping](/security/prevent-ai-endpoint-scraping)Mandatory Requirement | Maintaining endpoint security through remediation. For example, tracking identified vulnerabilities, implementing protective measures based on testing outcomes, and regularly updating endpoint defenses and detection thresholds. | **B004.4 Documentation: Vulnerability remediation.** Issue tracking system (GitHub, Jira, Linear) showing endpoint vulnerability lifecycle - must include vulnerability identification, remediation proposal, implementation, and production deployment with timestamps and approval records. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Integrating automated moderation tools to filter inputs before they reach the foundation model. For example, integrating third-party moderation APIs, implementing custom filtering rules, configuring blocking or warning actions for flagged content, and establishing confidence thresholds based on risk category and severity | **B005.1 Config: Input filtering.** Moderation tool integration showing API configuration, filtering rules, action settings (block/warn/modify), and confidence thresholds for different violation categories - this could be screenshots of configuration files, admin dashboard settings, or API integration code. Example moderation tools: OpenAI Moderation API, Claude content filtering, VirtueAI/Hive/Spectrum Labs | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: User LLM input filtering logicEngineering Tooling | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Documenting the moderation logic and rationale. For example, explaining chosen moderation tools, threshold justifications, and decision criteria for different risk categories. | **B005.2 Documentation: Input moderation approach.** Document explaining moderation approach including tool selection rationale, threshold settings with justifications, action logic for different violation types, and examples of how different input categories are handled. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Internal processesEngineering Practice | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Providing feedback to users when inputs are blocked. | **B005.3 Demonstration: Warning for blocked inputs.** User-facing messages or UI flows showing how blocked inputs are communicated to users - this could be error messages, warning dialogs, or alternative suggestions provided when content is filtered. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Product | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Logging flagged prompts for analysis and refinement of filters, while ensuring compliance with privacy obligations. | **B005.4 Logs: Input filtering.** Logging system showing how flagged inputs are captured, what metadata is included/excluded for privacy, retention policies, and audit trail - may include privacy documentation explaining logging disclosures to users. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Logs | | [B005: Implement real-time input filtering](/security/implement-real-time-input-filtering)Optional Requirement | Periodically evaluating filter performance and adjusting thresholds accordingly. For example, accuracy, latency, false positives/negatives. | **B005.5 Documentation: Input filter performance.** Report or dashboard showing analysis of filter performance metrics (false positives, false negatives, accuracy, latency) and documented threshold adjustments made based on performance data - should include timestamps and rationale for changes. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)Mandatory Requirement | Implementing technical restrictions that limit agent capabilities to authorized scope. For example, restricting agent access to approved backend services, APIs and MCP servers, enforcing network segmentation or API gateway rules, or implementing service-level authorization preventing access to sensitive systems. | **B006.1 Config: Agent service access restrictions.** Configuration showing technical limitations on agent backend access - may include API gateway rules restricting accessible services, network policies defining allowed endpoints, MCP server allowlist or registration configuration restricting which MCP servers and tools the agent may connect to, service-level authorization configuration, or architecture diagram showing agent isolation boundaries including MCP server placement and network segmentation. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)Mandatory Requirement | Deploying monitoring and alerting for agent actions that exceed security boundaries. For example, logging all agent service interactions, alerting on access attempts to unauthorized systems or APIs, or anomaly detection flagging unusual connection patterns. | **B006.2 Config: Agent security monitoring and alerting.** Implementation of monitoring configuration tracking agent security-relevant actions - may include logging setup capturing agent service calls and authentication attempts, alert rules for unauthorized system access, security monitoring dashboard showing agent infrastructure interactions, or example logs demonstrating boundary violations are detected. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeLogs | | [B006: Prevent unauthorized AI agent actions](/security/enforce-contextual-access-controls)Mandatory Requirement | Implementing additional safeguards to contain runtime risk. For example, enabling sandboxed execution environments with configurable filesystem, network, and credential restrictions for agent-executed code and first-party MCP servers, monitoring MCP tool definitions for unauthorized changes after initial approval, providing pre-execution authorization hooks that verify runtime tool calls against defined policy before execution proceeds, or scanning agent configuration artifacts such as hooks, skills and rules for prompt injection or unauthorized behavior. | **B006.3 Config: Execution-level safeguards.** Configuration or code demonstrating runtime containment controls — may include sandbox or container configuration showing configurable filesystem, network, and credential restrictions for agent code execution environments and first-party MCP servers, tool definition integrity controls showing how unauthorized post-approval changes are detected, pre-execution hook or policy engine configuration showing tool calls are verified at runtime, or scanning of agent configuration artifacts for prompt injection or malicious patterns. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B007: Enforce user access privileges to AI systems](/security/enforce-ai-access-privileges)Mandatory Requirement | Implementing system-level access controls tailored to AI systems. For example, using role-based or attribute-based access to restrict access to model configuration, training datasets, tool-calling capabilities, or prompt logs, based on job function and system sensitivity.Restricting administrative and configuration privileges to authorized personnel. For example, limiting ability to alter system behavior, tools, or models. | **B007.1 Config: User access controls.** IAM platform, permission files, or admin panel showing role-based or attribute-based access restrictions for AI system resources (model configurations, training datasets, tool-calling capabilities, prompt logs) - may include IAM role assignments, permission policies, or authorization code validating user permissions before accessing sensitive AI components. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Enforcing caller authentication across API endpoints and agentic interfaces. For example, applying scoped API tokens or signed requests for model API access; enforcing OAuth 2.0 or OIDC token validation with appropriate scoping for MCP server connections; implementing mutual authentication for agent-to-agent interfaces. | **B008.1 Config: API and agentic interface authentication.** Configuration or code showing caller authentication controls - may include scoped API token or signed request configuration for model API endpoints, OAuth token scoping or OIDC validation middleware for MCP server connections, or mutual authentication configuration for agent-to-agent interfaces (e.g. A2A protocol authentication config). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Securing data in transit across model API endpoints and agentic interfaces. For example, enforcing TLS for all model API endpoint traffic, MCP server connections, and agent-to-agent communication channels; implementing credential rotation policies for long-lived service connections. | **B008.2 Config: API and agentic interface transport security.** Configuration or code showing transport security controls - may include TLS/HTTPS certificate configuration for model API endpoints, MCP server traffic, or agent-to-agent connections, or credential rotation policy documentation for service-level MCP or A2A connections. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Enforcing data integrity across agentic interfaces. For example, implementing cryptographic message signing for agent-to-agent communication; applying schema validation and input sanitization to MCP tool call inputs and outputs. | **B008.3 Config: Agentic interface data integrity.** Configuration or code showing data integrity controls for agentic interfaces - may include cryptographic message signing configuration for agent-to-agent interfaces (e.g. signed agent cards), or schema validation configuration applied to MCP tool call inputs and outputs. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Securing model hosting environments. For example, using up-to-date and minimal container images, scanning for known vulnerabilities in dependencies and base images, and applying infrastructure-level isolation techniques based on risk level (e.g. container namespaces, VM separation, or dedicated GPU access). | **B008.4 Config: Model hosting security.** Container configuration or infrastructure setup for model hosting - may include Dockerfile with minimal base images and up-to-date dependencies, vulnerability scanning results from Trivy or Snyk for container images, or infrastructure configuration showing isolation techniques (container namespaces, VM separation, network policies, dedicated GPU allocation). | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B008: Protect AI system deployment environment](/security/protect-model-deployment-environment)Mandatory Requirement | Verifying model integrity before and during deployment. For example, using cryptographic checksums or signed artifacts to detect tampering, scanning model files for malicious payloads. | **B008.5 Config: Model integrity verification.** Deployment pipeline or code implementing model integrity checks - may include cryptographic checksum verification, model artifact signature validation, hash comparison before deployment, model scanning configuration detecting malicious payloads (e.g. Pickle, ONNX) using tools like Cisco's pickle-fuzzer, Trail of Bit's Fickling, or deployment logs recording model version hashes. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B009: Limit output over-exposure](/security/limit-output-over-exposure)Mandatory Requirement | Reducing or limiting the number of results shown in outputs to relevant only to balance security and utility. For example, character limits, limits on inference time. | **B009.1 Config: Output volume limits.** Code or configuration implementing output restrictions - may include character or token limits, inference time limits, result count restrictions, or timeout configurations preventing excessive output. Can be demonstrated by product demo showing system timeout when requesting output exceeding limits. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeProduct | | [B009: Limit output over-exposure](/security/limit-output-over-exposure)Mandatory Requirement | Limiting the fidelity of model outputs in certain use cases. For example, applying output rounding, threshold bands, or obfuscation techniques to reduce the risk of model inversion. | **B009.3 Config: Output precision controls.** Code implementing output fidelity limitations - may include rounding logic for numerical outputs, threshold bands reducing precision, or obfuscation techniques preventing model inversion, precision-sensitive data disclosure, or adversarial model extraction attacks. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote secure patterns for common web vulnerability classes in generated code. For example, defaulting to parameterized queries or safe ORM patterns for database access, applying output encoding and contextual escaping to prevent cross-site scripting, or enforcing HTTPS/TLS in generated network and API code. | **B010.1 Config: Secure defaults for common vulnerability classes.** Code, configuration, or system prompt excerpt demonstrating secure defaults for common vulnerability classes, may include system prompt guidance directing the model toward parameterized queries and safe ORM patterns, framework scaffolding that applies output encoding by default, or sample generations on database or UI prompts showing safe patterns used without explicit user request. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote secure patterns for authentication and authorization in generated code. For example, defaulting to vetted authentication libraries or patterns on auth-related prompts, applying access control checks and least-privilege patterns by default, or avoiding generation of custom cryptographic or authentication primitives. | **B010.2 Config: Secure defaults for authentication and authorization.** Code, configuration, or system prompt excerpt demonstrating secure defaults for auth, may include system prompt guidance directing the model toward established auth libraries (e.g., Auth0, Clerk, framework-native auth), or sample generations on auth-related prompts showing vetted patterns rather than custom implementations. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to prevent dependency risks in generated code. For example, avoiding wildcard version specifications (e.g., \* or latest) in generated manifests, verifying that suggested packages exist in their respective registries before including them in generated code, or applying guidance that avoids known-abandoned or typosquatted packages. | **B010.3 Config: Safe dependency specification in generated code.** Code, configuration, or system prompt excerpt demonstrating safe dependency specification, may include system prompt guidance directing the model toward pinned versions and verified packages, registry validation logic checking generated package names against known registries, or sample generations showing appropriate version specifications across ecosystems. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote secure defaults for session management in generated code. For example, applying HttpOnly, Secure, and SameSite flags to session cookies by default, or defaulting to CSRF protections on state-changing endpoints. | **B010.4 Config: Secure session and cookie defaults.** Code, configuration, or sample generations showing secure session and cookie defaults in generated code, may include system prompt guidance, framework scaffolding configuration, or sample generations on session-management-related prompts. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to promote defensive programming patterns in generated code. For example, defaulting to input validation on user-supplied data, applying safe error handling that avoids exposing stack traces or internal details, or defaulting to rate limiting on generated public-facing endpoints. | **B010.5 Config: Input validation and error handling defaults.** Code, configuration, or sample generations showing input validation and error handling defaults, may include system prompt guidance, framework scaffolding patterns, or sample generations on prompts generating user-facing endpoints. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [B010: Promote secure patterns in generated code](/security/promote-secure-code-patterns)Mandatory Requirement | Implementing safeguards to prevent generated logging code from capturing secrets or personal information. For example, defaulting logging patterns to exclude sensitive fields, or applying guidance that avoids logging full request bodies or auth headers. | **B010.6 Config: Logging defaults in generated code.** Code, configuration, or sample generations showing safe logging defaults in generated code, may include system prompt guidance, logging templates used in scaffolding, or sample generations on logging-related prompts. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeLogs | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Conducting pre-deployment testing with documented results and identified issues. For example, structured hallucination testing, adversarial prompting, safety unit tests, and scenario-based walkthroughs.Completing risk assessments of identified issues before system deployment. For example, potential impact analysis, mitigation strategies, and residual risk evaluation.Obtaining approval sign-offs from designated accountable. For example, documented rationale for approval decisions and maintained records for review purposes. | **C002.1 Documentation: Pre-deployment test and approval records.** Test results with identified issues and severity ratings, risk assessment with mitigation decisions, and approval sign-offs with rationale - may be combined in deployment gate documentation or provided as separate documents (e.g., test suite outputs from GitHub Actions/pytest, Jira/Linear tickets with risk assessment and approval, staging environment test reports, deployment checklist with sign-offs). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Integrating AI system testing into established software development lifecycle (SDLC) gates. For example, including threat modelling and risk evaluation during design phases, requiring risk evaluation and sign-off at staging or pre-production milestones, aligning with CI/CD or MLOps pipelines, and documenting test artefacts in shared repositories." | **C002.2 Config: SDLC integration.** CI/CD pipeline configuration or workflow showing AI testing integrated as deployment gate - may include GitHub Actions/Jenkins/GitLab CI config files requiring test passage, pull request templates with testing checklists, or branch protection rules enforcing pre-deployment validation. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Implementing pre-deployment vulnerability scanning of AI artifacts and dependencies. For example, scanning AI models and ML libraries for security vulnerabilities, validating runtime behavior for unsafe operations, and analyzing outputs for harmful content before deployment. | **C002.3 Documentation: Vulnerability scan results.** Security scanning tools or CI/CD pipeline showing vulnerability analysis of AI artifacts and dependencies - may include GitHub/GitLab security tab with dependency alerts, Snyk or Dependabot vulnerability findings, pip-audit or safety check terminal output showing CVE scans, model file scanning results, or CI/CD logs showing security scan execution. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [C002: Conduct pre-deployment testing](/safety/conduct-pre-deployment-testing)Mandatory Requirement | Testing changes to open-weight model before deployment. For example, re-running safety evaluations and guardrail test suites after major weights update via fine-tuning or quantization, or inference engine changes and comparing results to the prior model's baseline, and running targeted or automated checks for routine or low-risk changes. | **C002.4 Documentation: Open-weight model change regression testing.** Documented testing approach and results for the model change identifying the prior and new model version, the risk categories tested, and regression results - may include evaluation suite outputs before and after the change, automated check results for low-risk changes, or guardrail test suite pass rates. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Implementing content filtering for harmful output types. For example, detecting and blocking distressed responses, angry language, offensive content, biased statements, and deceptive information. | **C003.1 Config: Harmful output filtering.** Content filtering rules, moderation API configuration, or classifier settings showing detection and blocking logic for harmful output types - may include filtering rules in code, third-party moderation tool configuration (e.g., OpenAI Moderation API, Perspective API), or custom classifier model settings with harm category definitions. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Implementing guardrails for advice generation. For example, restricting high-risk recommendations in sensitive domains, requiring disclaimers for guidance. | **C003.2 Config: Guardrails for high-risk advice.** System prompts, guardrail rules, or domain restrictions showing safety controls on advice generation - may include defensive prompting, domain-specific output restrictions (e.g., medical/legal/financial advice blocklists), or conditional response templates that add warnings for sensitive topics. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C003: Prevent harmful outputs](/safety/prevent-harmful-outputs)Mandatory Requirement | Implementing bias detection and mitigation controls. For example, monitoring for discriminatory patterns, implementing fairness checks in outputs. | **C003.3 Config: Guardrails for biased outputs.** Documentation of bias eval results testing for stereotypical responses across demographic attributes, manual review logs documenting bias assessments, or output filtering rules blocking discriminatory patterns - may include automated fairness evaluation tools or bias monitoring dashboards if implemented. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)Mandatory Requirement | Detecting and blocking out-of-scope requests. For example, detecting conversations outside intended use cases, blocking prohibited topics, providing redirection messages when users hit boundaries, and escalating or restricting access for repeated violations. | **C004.1 Config: out-of-scope guardrails.** Blocking rules, defensive prompting, or filtering configuration showing how out-of-scope requests are detected and handled - may include topic blocklists, redirection message templates, escalation rules for repeated attempts, or system prompts defining allowed topics. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)Mandatory Requirement | Tracking out-of-scope violations and updating boundaries. For example, logging boundary violations, adjusting restrictions based on misuse patterns. | **C004.2 Logs: Out-of-scope attempts.** Logs showing out-of-scope attempts with frequency data. May include documentation of boundary updates made in response to violations, monitoring dashboard of flagged requests, change log showing restriction updates with rationale, or incident reports triggering scope adjustments. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Logs | | [C004: Prevent out-of-scope outputs](/safety/prevent-out-of-scope-outputs)Mandatory Requirement | Providing user guidance on system capabilities and limitations. For example, communicating what the AI system can and cannot do, intended use cases, and topics or requests outside the system's scope. | **C004.3 Demonstration: User guidance on scope.** User-facing guidance explaining system capabilities and limitations - may include onboarding tooltips or welcome screens, help documentation or FAQs describing intended use, UI warnings when approaching scope boundaries, or published usage guidelines. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Product | | [C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)Mandatory Requirement | Implementing detection and blocking mechanisms aligned with organizational risk taxonomy. For example, deploying filtering based on defined risk categories and severity thresholds.Implementing response actions for detected risks. For example, blocking high-severity outputs, flagging medium-risk content for review, logging violations for monitoring and analysis. | **C005.1 Config: Risk detection and response.** Filtering rules, system configuration, or code showing detection logic mapped to AI risk taxonomy categories and corresponding response actions per severity level - may include risk classifiers with block/flag/log rules, content moderation API configuration defining actions by risk type, or defensive prompting. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)Mandatory Requirement | Establishing escalation procedures for flagged high-risk content. For example, defining when human review is required and establishing approval workflows for edge cases. | **C005.2 Documentation: Human review workflows.** Documentation or workflow configuration showing human review and escalation procedures for flagged content - may include runbook defining escalation criteria and review SLAs, workflow diagram showing approval process, or ticketing system configuration (Jira, Linear) with content review queues and assignment rules. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C005: Prevent agent-specific high risk outputs](/safety/prevent-other-high-risk-outputs)Mandatory Requirement | Implementing automated real-time interventions. For example, blocking or modifying outputs based on severity. | **C005.3 Config: Automated response mechanisms.** Code or system configuration showing automated response mechanisms - may include logic blocking or modifying outputs based on risk scores, or dynamic warning messages triggered by content flags. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)Mandatory Requirement | Establishing output sanitization and validation procedures before presenting content to users. For example, encoding or stripping potentially malicious content, validating structured outputs against safe schemas, blocking unsafe URLs, and enforcing secure rendering modes. | **C006.1 Config: Output sanitization.** Code or configuration implementing output sanitization - may include HTML/JavaScript/shell syntax encoding functions, URL validation or rewriting rules blocking unsafe links, schema validation checking structured outputs (JSON/YAML/XML) against whitelists, CSP header configuration, or template rendering with auto-escaping enabled. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)Mandatory Requirement | Implementing content handling and security labelling based on trust level. For example, marking untrusted or third-party content, distinguishing external data from system-generated content, and applying differentiated security controls based on content source. | **C006.2 Demonstration: Content handling and labelling for untrusted content.** UI or code showing trust-based content handling - may include visual indicators marking third-party content (badges, styling, warning icons), metadata tags tracking content source and trust level, or code applying conditional security controls based on content origin (e.g., stricter sanitization for external sources). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [C006: Prevent output vulnerabilities](/safety/prevent-output-vulnerabilities)Mandatory Requirement | Detecting advanced output-based attack patterns. For example, identifying prompt injection attempts, model subversion techniques, payloads targeting downstream systems, or obfuscated exploits designed to bypass filters. | **C006.3 Config: Adversarial output detection.** Detection rules or monitoring system identifying advanced attack patterns in outputs - may include pattern matching for prompt injection chains or jailbreak tokens, payload signature scanning detecting command injection or SQL queries, or anomaly detection flagging obfuscated exploits bypassing basic filters. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Eng: LLM output filtering logic | | [C007: Flag high risk outputs for human review](/safety/flag-high-risk-recommendations)Optional Requirement | Implementing automated detection mechanisms for high-risk outputs. For example, using content filtering, risk scoring, or classification models to identify outputs requiring review or flagging. | **C007.2 Config: High-risk detection mechanisms.** Detection code, configuration file, or rules engine showing high-risk output filtering - may include keyword lists or regex patterns flagging sensitive topics, scoring logic assigning risk values to recommendations, if/then rules defining high-risk conditions, ML model configuration (e.g., classification thresholds in config.yaml), or API response showing confidence scores with risk thresholds. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)Optional Requirement | Establishing ongoing monitoring of AI outputs across risk categories. For example, conducting regular evaluations prioritized by risk severity, sampling outputs for review, and tracking system behavior patterns. | **C008.1 Logs: AI risk monitoring.** Monitoring dashboard, logging system, or evaluation reports showing ongoing AI output tracking - may include output sampling logs with review results, behavior trace logs showing system patterns, prompt-response logging configuration, evaluation schedules prioritized by risk severity, or monitoring metrics dashboard tracking trends over time. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)Optional Requirement | Maintaining documentation. For example, recording identified scenarios with clear examples, updating risk taxonomy based on monitoring findings and incidents. | **C008.2 Documentation: Monitoring findings.** Document or change log showing identified risk scenarios with examples - may include incident reports triggering taxonomy changes, risk scenario database with concrete examples, or version history of risk taxonomy showing updates with rationale linked to monitoring findings. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [C008: Monitor AI risk categories](/safety/monitor-ai-risk-categories)Optional Requirement | Integrating AI output monitoring with existing security tools. For example, forwarding alerts and flagged outputs to SIEM platforms, applying standard logging formats (e.g. JSON, syslog) to support automated threat detection workflows. | **C008.3 Config: Security tooling.** SIEM integration, log forwarding configuration, or security tool settings showing AI monitoring data flowing into existing security infrastructure - may include Splunk/Datadog/Elastic forwarding rules for AI alerts, JSON/syslog format configuration for AI logs, or SIEM dashboard showing AI-related events alongside other security telemetry. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [C009: Enable real-time feedback and intervention](/safety/collect-real-time-feedback)Optional Requirement | Enabling user intervention capabilities. For example, providing mechanisms for users to pause, stop, or redirect system behavior, implementing feedback collection tools for users to report issues or concerns, ensuring technical controls persist across devices and interaction contexts.Ensuring accessibility of feedback and intervention mechanisms. For example, adhering to WCAG 2.1 standards for color contrast, screen reader compatibility, keyboard navigation, and clear messaging for users with disabilities. | **C009.1 Demonstration: User intervention mechanisms.** Intervention controls (stop/pause/redirect buttons, feedback forms, issue reporting mechanisms) with accessibility features integrated (e.g. keyboard navigation, high contrast modes, screen reader labels) | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)Mandatory Requirement | Implementing factual accuracy controls. For example, deploying available fact-checking mechanisms, flagging uncertain or low-confidence responses. | **D001.1 Config: Groundedness filter.** Code or configuration showing groundedness validation - may include filters checking responses against source documents, fact-checking API integration, or logic comparing generated content to retrieved context for factual accuracy. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)Mandatory Requirement | Establishing information source validation. For example, requiring citations for factual claims, implementing source reliability checks. | **D001.2 Demonstration: User-facing citations & source attributions.** UI or output format showing citations and source attributions provided to users - may include inline citations, source links, reference lists, or attribution labels identifying where information originated. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [D001: Prevent hallucinated outputs](/reliability/prevent-hallucinated-outputs)Mandatory Requirement | Maintaining uncertainty communication. For example, displaying confidence levels, providing appropriate disclaimers for generated information. | **D001.3 Demonstration: User-facing uncertainty labels.** UI or output format showing confidence levels, uncertainty disclaimers, or warnings for generated information - may include confidence score displays, low-certainty warnings, or standard disclaimers about potential inaccuracies. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Product | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Implementing tool call validation and authorization. For example, restricting tool calls to approved functions and MCP servers, validating parameters before execution. | **D003.1 Config: Tool authorization & validation.** Code or configuration showing function and tool allowlists, parameter validation logic, or authz checks before tool execution - may include tool permission schemas, input validation functions, or access control lists restricting available tools per agent/user. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Enforcing rate limits and transaction caps for autonomous tool use. | **D003.2 Config: Rate limits for tools.** Code or configuration showing rate limits and transaction caps on tool usage - may include per-tool usage quotas, time-windowed limits, or circuit breakers preventing excessive autonomous tool calls. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Establishing execution monitoring and logging. For example, tracking all tool calls, monitoring for unauthorized access attempts or scope violations. | **D003.3 Config: Tool call log.** Logging configuration, monitoring dashboard, or audit logs showing tracked tool calls - may include log entries capturing the originating MCP server, tool name, tool version, input parameters, and timestamps per invocation, alerts for unauthorized tool access attempts, or monitoring system flagging scope violations. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Logs | | [D003: Restrict unsafe tool calls](/reliability/restrict-unsafe-tool-calls)Mandatory Requirement | Requiring human approval for sensitive tool operations. For example, requiring human confirmation before executing high-risk actions, multi-step tool calls, implementing approval workflows for operations beyond autonomous boundaries. | **D003.4 Config: Human-approval workflows.** Approval workflow configuration, code or ticketing system for sensitive, high-risk, or multi-step tool operations requiring human confirmation (e.g., executing financial transactions, deleting or irreversibly modifying records, and changing credentials or permissions). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [E004: Assign accountability](/accountability/assign-accountability)Mandatory Requirement | Implementing code signing and verification processes for AI models, libraries, and deployment artefacts to ensure only digitally signed components are approved for production use. | **E004.2 Config: Code signing implementation.** Code signing configuration, CI/CD pipeline requiring signed artifacts, or verification process for AI components - may include model signing process, signature verification in deployment pipeline, artifact registry showing signed models/libraries, or policy enforcement blocking unsigned components from production. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering CodeEngineering Practice | | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)Mandatory Requirement | Configuring logging for third-party interactions. For example, capturing API connections, user access sessions, data exchanges, and service integrations.Capturing access metadata. For example, user identification, authentication timestamps, accessed resources, session duration, origin IP addresses, and resource usage patterns. | **E009.1 Config: Third-party access monitoring.** Logging system or SIEM configuration showing third-party interactions being monitored with captured metadata - may include cloud logging interface (Google Cloud Logging, AWS CloudWatch, Azure Monitor) showing logged API requests with timestamps/IPs/user agents, access logs capturing authentication events and resource access, or SIEM dashboard displaying third-party connection monitoring with relevant metadata fields. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [E009: Monitor third-party access](/accountability/monitor-3rd-party-access)Mandatory Requirement | Generating alerts on anomalous third-party access patterns against defined detection rules. For example, alerting on unexpected call volume or out-of-scope endpoints for service connections, repeated failed logins for human access, or credential use outside approved scope - with each alert routed to a responsible owner for disposition. | **E009.2 Config: Anomalous third-party access alerting.** Detection-rule or SIEM configuration for anomalous third-party access - may include alerting rules or correlation logic defining anomalous-access conditions, plus sample fired alerts showing disposition (case assignment, triage notes, or resolution records). | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Implementing detection and monitoring tools. For example, prompt analysis, output filtering, usage pattern anomalies, and suspicious access attempts. | **E010.2 Config: AUP violation detection.** Code, configuration, or monitoring system detecting acceptable use policy violations - may include prompt analysis logic, output filtering rules, anomaly detection for usage patterns, or alerting on suspicious access attempts. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Implementing user feedback when policy is breached. For example, showing alerts or error messages when inputs violate acceptable use. | **E010.3 Demonstration: User notification for AUP breaches.** User-facing alerts or error messages displayed when acceptable use policy is violated - may include in-product warning messages, blocked request notifications, or error screens explaining policy violations. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [E010: Establish AI acceptable use policy](/accountability/establish-ai-acceptable-use-policy)Mandatory Requirement | Real-time monitoring, blocking, or alerting capabilities.Maintaining logging and tracking systems. For example, incident creation, violation tracking with case assignment and resolution documentation.Conducting regular effectiveness reviews. For example, quarterly analysis of violation trends, tool performance assessment, policy updates based on emerging threats, and user training adjustments. | **E010.4 Documentation: Guardrails enforcing acceptable use.** Documentation or screenshots showing additional AUP enforcement mechanisms - may include real-time blocking/alerting systems, violation tracking logs with incident management, effectiveness review reports analyzing violation trends and policy updates, or training materials addressing emerging misuse patterns. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Practice | | [E013: Implement quality management system](/accountability/implement-quality-management-system)Optional Requirement | Implementing defect tracking, continuous improvement, and post-market monitoring. For example, maintaining issue tracking systems, conducting root cause analysis, documenting corrective actions, establishing post-market monitoring processes. | **E013.3 Config: Issue tracking and monitoring.** Issue tracking system or monitoring records - may include issue tracker (Jira, Linear, GitHub) with defects and corrective actions, root cause analysis reports, post-market monitoring logs or dashboards, or continuous improvement documentation showing lessons learned. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Tooling | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Capturing system activity details to support incident investigation and behavior explanation. For example, logging inputs, processing steps, outputs, and metadata for AI systems. | **E015.1 Config: Logging implementation.** Logging code or configuration showing what system activity is captured - may include code logging inputs and outputs, logging configuration file specifying what to log, or example log entries showing captured information (timestamps, inputs, outputs, user actions). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Logs | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Capturing full execution chains of agentic workflows to support investigation of agent-specific incidents. For example, logging agent provenance metadata, tool call parameters and results, sub-agent delegations and their outcomes, approval/authorization events (e.g., human-in-the-loop approvals), and reasoning traces where available. | **E015.2 Config: AI agent logging implementation .** Logging code or configuration demonstrating agent execution logging - may include log fields capturing agent provenance metadata per execution (e.g. agent type identifier, creator or deployment origin); structured log entries capturing tool call parameters and their results; delegation chain records showing sub-agent handoffs with identity, task context, and outcome at each step; approval/authorization records linked to execution (e.g., approver identity, timestamp, decision outcome); or reasoning trace output from the agent framework. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Logs | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Implementing log storage with appropriate retention periods, access controls, and data sanitation to support auditing and incident response. | **E015.3 Config: Log storage.** Log storage system showing retention policies, access controls and sanitation practices - may include log management platform (Datadog, Splunk, CloudWatch) with retention period settings and PII-masking, access control configuration showing who can view logs, or storage settings with automatic deletion rules. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)LogsEngineering Tooling | | [E015: Log AI system activity](/accountability/log-model-activity)Mandatory Requirement | Implementing technical controls to ensure logs are tamper-evident and independently verifiable. For example, ensuring that captured records cannot be modified or deleted after creation, ensuring sequence integrity so that gaps, omissions, and reordering are detectable during incident investigation or audit. | **E015.4 Config: Log integrity protection.** Log immutability controls - for example, write-once-read-many (WORM) storage configuration, cryptographic hashing of log entries, append-only database settings, or third-party log management platform features. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)LogsEngineering Code | | [E016: Implement AI disclosure mechanisms](/accountability/implement-ai-disclosure-mechanisms)Mandatory Requirement | Implementing AI disclosure for text-based interactions. For example, displaying clear notices when users interact with AI chatbots, virtual assistants, or automated messaging systems.Implementing AI disclosure for voice-based interactions. For example, providing audio notifications at the beginning of voice calls or interactions.Labelling AI-generated media and documents in a machine-readable and detectable format. For example, marking AI-generated images, videos, audio, or documents with metadata, watermarks, or labels indicating artificial generation.Disclosing when autonomous AI agents or systems are performing actions. For example, notifying users when AI systems are making decisions, processing requests, or executing tasks without human oversight.Establishing reactive disclosure capabilities when users ask if they are interacting with AI. | **E016.1 Demonstration: AI disclosure.** AI disclosures across applicable modalities. May include disclosures for text (“You’re chatting with AI” notice in chat or on automated email/SMS), voice (recording or transcript of a spoken disclosure), automated actions (“Powered by AI” labels or “Completed by AI agent” notifications), AI-generated content (C2PA metadata or watermarks), and responses to “Are you AI?” (chatbot or voice agent transcript). | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Product | | [E017: Document system transparency policy](/accountability/document-system-transparency-policy)Optional Requirement | Creating transparency documentation for major AI systems. For example, documenting system characteristics, data provenance, and model behavior for systems meeting documentation criteria. | **E017.1 Documentation: AI system transparency documentation.** Transparency documentation artifacts such as a model card, datasheet, or AI bill of materials - for example, records of the system name and version, training or fine-tuning data sources and characteristics, dated records of fine-tuning or adaptation changes and records of AI-specific components beyond the model including frameworks, orchestration layers, tool connectors. | Mandatory Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [F001: Prevent AI cyber misuse](/society/prevent-ai-cyber-misuse)Mandatory Requirement | Implementing malicious use detection and blocking. For example, deploying available content filtering to detect requests for malicious code generation, attack planning, and vulnerability exploitation guidance, configuring automated blocking of cyber attack assistance requests, maintaining databases of prohibited use patterns. | **F001.2 Config: Cyber use detection.** Content filtering rules blocking cyber attack requests, keyword or pattern matching detecting malicious code generation attempts, automated blocking configuration for exploit development queries, or prohibited use pattern database. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | | [F002: Prevent catastrophic misuse](/society/prevent-catastrophic-misuse)Mandatory Requirement | Establishing catastrophic misuse monitoring. For example, monitoring AI system interactions for patterns indicating weapons development or mass harm intent, implementing real-time alerting for detected catastrophic misuse attempts, documenting suspicious queries and system responses. | **F002.2 Config: Catastrophic misuse monitoring.** Monitoring dashboard or alert configuration for catastrophic misuse patterns - may include usage monitoring flagging CBRN-related queries, alert rules for weapons development patterns, logs of detected and blocked catastrophic misuse attempts, or incident records documenting suspicious CBRN-related interactions. | Supplemental Control[Technical Implementation](/evidence/technical-implementation)Engineering Code | 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Third-party evals Source: https://standard.aiuc-1.com/evidence/third-party-evals Evidence templates in the third-party evals category. ## Third-party evals [Download evidence list](https://docs.google.com/spreadsheets/d/1GxvHYvV7xmoX5OpEkDO51RBfttvQlN8iVX8j0CCd-Ww/edit?usp=sharing) | Requirement | Control activity | Evidence | Tags | | - | - | - | - | | [A009: Third-party testing for data & privacy risk](/data-and-privacy/3rd-party-testing-for-data-and-privacy-risk)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **A009.1 Evals: Third-party evaluation report assessing data & privacy risk.** Third-party evaluation report showing testing for data & privacy risk - including risks tested (e.g., IP infringement, personal data leakage, business data leakage), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [B001: Third-party testing for security risk](/security/test-adversarial-robustness)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **B001.1 Evals: Third-party evaluation report assessing security risk.** Third-party evaluation report showing testing for security risk - including risks tested (e.g., insecure outputs, prompt injection), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [C010: Third-party testing for safety risk](/safety/3rd-party-testing-for-harmful-outputs)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **C010.1 Evals: Third-party evaluation report assessing safety risk.** Third-party evaluation report showing testing for safety risk - including risks tested (e.g., physical harm, emotional harm, inappropriate content, high-risk domain engagement, bias), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [D004: Third-party testing for reliability risk](/reliability/3rd-party-testing-of-tool-calls)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **D004.1 Evals: Third-party evaluation report assessing reliability risk.** Third-party evaluation report showing testing for reliability risk - including risks tested (e.g., hallucinations, source attribution, incorrectly executed tool actions), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | | [E018: Third-party testing for accountability risk](/accountability/3rd-party-testing-for-accountability-risk)Mandatory Requirement | Appointing qualified third-party assessors. Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence.Conducting regular testing. Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter.Maintaining documentation. Including testing scope and results. | **E018.1 Evals: Third-party evaluation report assessing accountability risk.** Third-party evaluation report showing testing for agent accountability risk - including risks tested (e.g., bypassing AI disclosure), testing methodology and findings | Mandatory Control[Third-party Evals](/evidence/third-party-evals)Third-party evaluation report | 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Frequently asked questions Source: https://standard.aiuc-1.com/faq ## Q: Who can certify organizations against AIUC-1? **A:** Only the Artificial Intelligence Underwriting Company can issue the official AIUC-1 certificate. AIUC-1 has a community of managed service providers, GRC platforms and eval providers to enable organizations to fill potential gaps in their desired way. See accredited AIUC-1 auditors [here](/accredited-auditors). ## Q: How long does it take? **A:** Most organizations earn the AIUC-1 certificate in 5-10 weeks. Companies starting from zero may take longer to fill the gaps. Companies that already have a comprehensive AI risk management function will likely be able to earn the AIUC-1 certificate even faster. ## Q: How long is an AIUC-1 certificate valid? **A:** The AIUC-1 certificate is valid for 12 months. Evals are required at least every 3 months to keep the certificate valid. ## Q: Does an AIUC-1 certificate guarantee AI agents are secure, safe and reliable? **A:** No standard can eliminate all risks inherent in deploying AI systems, and certification represents a point-in-time assessment of controls, not a warranty of future performance or outcomes. Organizations change, systems evolve, and new risks emerge. An AIUC-1 certificate demonstrates that an organization takes AI governance seriously and has invested in demonstrable controls that work in practice when evaluated, but should not substitute independent risk assessment and ongoing monitoring. ## Q: Does an AIUC-1 certificate mean that the Artificial Intelligence Underwriting Company has built the safeguards for the certified organization? **A:** No. The AIUC-1 certification is designed to verify and complement an organization’s internal safety and security practices. While the AIUC-1 standard provides a blueprint for organizations to develop their safety and security practices, in line with industry best practices, organizations cannot rely on the AIUC-1 certification process to build out such processes from scratch. ## Q: My AIUC-1 gap analysis revealed gaps. Can you help fill these? **A:** AIUC has developed a library of policy templates, blueprints for technical safeguard implementation, and guidance on other areas where work may be needed to pass the requirements - and offer limited audit support and advisory services. Auditors work directly with organizations to explore paths to meeting requirements - and can refer you to qualified MSPs if you want additional help making the certification process smooth. ## Q: How is AIUC-1 different from ISO 42001? **A:** ISO 42001 focuses on establishing AI governance frameworks and management systems, while AIUC-1 focuses on validating the robustness of safeguards through independent evals. The technical rigour of AIUC-1 makes it desirable for many organizations that have already achieved ISO 42001 accreditation. Read more [here](/crosswalks/iso-42001). ## Q: How is AIUC-1 different from SOC 2? **A:** SOC 2 has become the industry-standard for cybersecurity, but it is not AI-specific and therefore doesn’t cover risks unique to AI. AIUC-1 integrates the principles that made SOC 2 a success and evolves in the places where SOC 2 has offered learnings. Read more [here](/learn/about). ## Q: How does AIUC-1 compare to other frameworks like the NIST AI RMF and the EU AI Act? **A:** AIUC-1 operationalizes the top emerging AI frameworks like [ISO42001](/crosswalks/iso-42001), [NIST AI RMF](/crosswalks/nist-ai-rmf), and the [EU AI Act](/crosswalks#:~:text=frameworks%20including%20the-,EU%20AI%20Act,-%2C%20the%20NIST%20AI), demonstrated by comprehensive crosswalks. Read more [here.](/crosswalks) ## Q: Who developed AIUC-1? **A:** AIUC-1 was developed with the [AIUC-1 Consortium](/consortium) and a large group of Technical Contributors from organizations including Orrick, Stanford, MIT, Carnegie Mellon, Cisco, MongoDB, Google Cloud, Faculty and more. Technical Contributors review the standard quarterly to ensure it keeps up with technological change, emerging best practices, and novel threat patterns. *We periodically run pilots of new standard updates, collecting feedback from early adopters and the AIUC-1 consortium before rolling out changes to the broader ecosystem through quarterly releases. Contact us at [contact@aiuc.com](mailto:contact@aiuc.com) if you are interested in participating in upcoming pilots.* 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Consortium Source: https://standard.aiuc-1.com/introduction/consortium This sidebar entry links to [https://aiuc-1.com/consortium](https://aiuc-1.com/consortium). # Methodology Source: https://standard.aiuc-1.com/introduction/methodology This sidebar entry links to [https://aiuc-1.com/methodology](https://aiuc-1.com/methodology). # Overview Source: https://standard.aiuc-1.com/introduction/overview This sidebar entry links to [https://aiuc-1.com](https://aiuc-1.com). # About AIUC-1 Source: https://standard.aiuc-1.com/learn/about AIUC-1 is the standard for AI agent security, safety and reliability. To earn certification, agents must pass all applicable AIUC-1 requirements validated by an accredited auditor and submit to comprehensive evals covering top enterprise risks. The standard is available transparently and the control library is used by large enterprises across industries to govern AI agents securely. It is updated each quarter to keep up with AI capabilities, risks and emerging legislation. ## Explore the standard > **[A. Data & Privacy](/data-and-privacy)** > > Data use policies, IP and trade secrets, PII and cross-customer exposure, secrets leakage. > **[B. Security](/security)** > > Adversarial testing, input filtering, access controls, endpoint protection, secure code patterns. > **[C. Safety](/safety)** > > Risk taxonomy, pre-deployment and third-party testing, harmful and out-of-scope outputs. > **[D. Reliability](/reliability)** > > Hallucination prevention and testing, restricting unsafe tool calls. > **[E. Accountability](/accountability)** > > Failure plans, ownership, vendor due diligence, logging, transparency, quality management. > **[F. Society](/society)** > > Preventing AI-enabled cyber misuse and catastrophic misuse. ## Crosswalks AIUC-1 operationalises leading governance frameworks and emerging legislation - translating high-level principles into AI agent-specific controls. > **[SOC 2](/crosswalks/soc-2)** > > How SOC 2 criteria map to AIUC-1 requirements and where the frameworks differ. > **[ISO 42001](/crosswalks/iso-42001)** > > International standard for AI management systems (AIMS) covering responsible AI development and deployment. > **[EU AI Act](/crosswalks/eu-ai-act)** > > EU regulation classifying AI systems by risk levels with corresponding obligations. > **[NIST AI RMF](/crosswalks/nist-ai-rmf)** > > US government framework for managing AI risks throughout the AI lifecycle. > **[MITRE ATLAS](/crosswalks/mitre-atlas)** > > Knowledge base of adversarial tactics, techniques and mitigation strategies for machine learning systems. > **[OWASP Top Ten](/crosswalks/owasp-top-10)** > > Curated list of the most critical security threats to autonomous AI agent systems. > **[All crosswalks](/crosswalks/index)** > > AIUC-1 is mapped to emerging legislation, industry standards and governance frameworks. ## Certification AIUC-1 is used by frontier AI platforms and large enterprises to validate and demonstrate AI agent security, safety and reliability. Certified agents range from external customer service agents to coding agents to internal automation agents. > **[Certificate details](/aiuc-1-certification)** > > Types of organizations pursuing AIUC-1 certification and the end-to-end certification process. > **[Scoping](/scoping)** > > What agents can be certified and the scoping process. > **[Earn SOC 2 & AIUC-1 together](/soc2-joint-offering)** > > Earn a full SOC 2 attestation and AIUC-1 certification in one engagement. > **[Accredited auditors](/accredited-auditors)** > > Leading auditors around the world are accredited to audit against AIUC-1. > **[Re-certification](/re-certification-maintaining-aiuc-1)** > > AIUC-1 requires annual re-certification to ensure security posture keeps up with AI capabilities and best practices. > **[Full control list](/evidence/index)** > > Access the full AIUC-1 control list with evidence guidance. > **[FAQ](/faq)** > > Explore frequently asked questions. ## Standard development AIUC-1 is updated each quarter to keep up with AI capabilities, risks and emerging legislation. The work is done through the AIUC-1 Consortium, which unites security executives, practitioners, researchers and legal experts to develop a standard that covers enterprise AI risks holistically. > **[AIUC-1 Governance](/standard-governance)** > > How AIUC-1 is developed, reviewed and updated each quarter. > **[AIUC-1 Consortium](https://aiuc-1.com/consortium)** > > See all 300+ members of the AIUC-1 Consortium who have developed AIUC-1. > **[Quarterly update process](https://www.aiuc-1.com/research/aiuc-1-quarterly-update-process)** > > AIUC-1 is updated each quarter to keep up with AI capabilities, risks and emerging legislation. > **[Changelog](/changelog)** > > All changes to AIUC-1 are documented transparently as part of the quarterly release process. We welcome feedback, ideas, suggestions, and criticism - [provide input on AIUC-1](/learn/contribute). 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Provide input on AIUC-1 Source: https://standard.aiuc-1.com/learn/contribute Please give us input on AIUC-1: we welcome feedback, ideas, suggestions, and criticism. We adapt AIUC-1 regularly to meet enterprise needs as AI changes. [Provide input on AIUC-1](https://form.typeform.com/to/DgTl55CN) ## Tenets * **Customer-focused.** We prioritize requirements that enterprise customers demand and vendors can pragmatically meet, increasing confidence without adding unnecessary compliance. * **AI-focused.** We do not cover non-AI risks that are addressed in frameworks or regulations like SOC 2, ISO 27001, or GDPR. * **Insurance-enabling.** We prioritize risks that lead to direct harms and financial losses. * **Adapts to regulation.** We update AIUC-1 to make it easier to comply with new regulations. * **Adapts to AI progress.** We update AIUC-1 to keep up with new capabilities, like reasoning capabilities and new modalities. * **Adapts to the threat landscape.** We update AIUC-1 in response to real-world incidents. * **Continuous improvement.** We regularly update the standard based on real-world deployment experience and stakeholder feedback. * **Predictability.** We review the standard and push updates quarterly, on January 15, April 15, July 15, and October 15 of each year. * **Transparency.** We keep a public changelog and share our lessons. * **Backward compatibility.** Existing certifications remain valid during transition periods. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Privacy Notice Source: https://standard.aiuc-1.com/legal/privacy *Last updated August 13, 2026.* Welcome to AIUC-1.com, a website of Caliber Labs, PBC doing business as Artificial Intelligence Underwriting Company (" **AIUC**", "**Company**", "**we**", "**us**", or "**our**"). This Privacy Notice explains how AIUC collects, uses, discloses, and otherwise processes personal data in connection with AIUC's products, services, or applications that reference or link to this Privacy Notice. This Privacy Notice does not address our privacy practices relating to AIUC’s job applicants, employees and other employment-related individuals, nor data that is not subject to applicable data protection laws (such as deidentified or publicly available information). This Privacy Notice is also not a contract and does not create any legal rights or obligations not otherwise provided by law. ## Our Collection and Use of Personal Data The categories of personal data we collect depend on how you interact with us and our services. For example, you may provide us your personal data directly when you access your unique account, provide feedback and evidence, or otherwise contact us or interact with us. We also collect personal data automatically when you interact with our websites and other services and may also collect personal data from other sources and third parties. ### Personal Data Provided by Individuals We collect the following categories of personal data individuals provide us: * **Contact Information**, including first and last name, phone number, email address, mailing address, and communication preferences. We use this information primarily to fulfill your request or transaction, to communicate with you directly, and to send you marketing communications in accordance with your preferences. * **Account Information**, including first and last name, email address, phone number, logins, and the services you are interested in, purchased, or have otherwise used. We use this information primarily to administer your account, provide you with our services, communicate with you regarding your account and your use of our services, and for customer support purposes. * **Evidence and Content**, including any files, documents, audio, videos, images, data, or communications you choose to input, upload, or transmit to us, including as evidence. We use this content primarily to provide you with our services, to facilitate your requests, and to improve our products and services. * **Feedback and Support Information**, including the contents of custom messages sent through the forms, email addresses, or other contact information we make available to customers, as well as recordings of calls with us, where permitted by law (including through the use of automated tools provided by us or our third-party providers). We use this information primarily to investigate and respond to your inquiries, to communicate with you via, email, phone, text message or social media, and to improve our products and services. If you choose to contact us, we may need additional information to fulfill the request or respond to your inquiry. We may provide additional privacy disclosures where the scope of the request we receive or personal data we require fall outside the scope of this Privacy Notice. In that case, the additional privacy disclosures will govern how we may process the information you provide at that time. ### Personal Data Automatically Collected We, and our third-party partners, automatically collect information you provide to us and information about how you access and use our products and services when you engage with us. We typically collect this information through the use of a variety of our own and our third-party partners' automatic data collection technologies, including (i) cookies or small data files that are stored on an individual's computer and (ii) other, related technologies, such as web beacons, pixels, embedded scripts, mobile SDKs, location-identifying technologies and logging technologies. Information we collect automatically about you may be combined with other personal information we collect directly from you or receive from other sources. We, and our third-party partners, use automatic data collection technologies to automatically collect the following data when you use our services or otherwise engage with us: * **Information About Your Device and Network**, including the device type, manufacturer, and model, operating system, IP address, browser type, Internet service provider, and unique identifiers associated with you, your device, or your network (including, for example, a persistent device identifier or advertising ID). We employ third-party technologies designed to allow us to recognize when two or more devices are likely being used by the same individual and may leverage these technologies (where permitted) to link information collected from different devices. * **Information About the Way Individuals Use Our Services and Interact With Us** , including the site from which you came, the site to which you are going when you leave our services, how frequently you access our services, whether you open emails or click the links contained in emails, whether you access our services from multiple devices, and other browsing behavior and actions you take on our services (such as the pages you visit, the content you view, videos you watch, the communications you have through our services, and the content, links and ads you interact with). We employ third-party technologies designed to allow us to collect detailed information about browsing behavior and actions that you take on our services, which may record your mouse movements, scrolling, clicks, and keystroke activity on our services and other browsing, search or purchasing behavior. These third-party technologies may also record information you enter when you interact with our products or services, or engage in chat features or other communication platforms we provide. * **Information About Your Location and Organization**, including general geographic location and the organization associated with your visit that we or our third-party providers may derive from your IP address, as well as more precise geolocation when you grant us access through your device settings. All of the information collected automatically through these tools allows us to improve your customer experience. For example, we may use this information to enhance and personalize your user experience, to monitor and improve our products and services, to offer communications features such as live and automated chat, and to improve the effectiveness of our products, services, offers, advertising, communications and customer service. We may also use this information to: (a) remember information so that you will not have to re-enter it during your visit or the next time you visit the site; (b) provide custom, personalized content and information, including targeted content and advertising; (c) identify you across multiple devices; (d) provide and monitor the effectiveness of our services; (e) monitor aggregate metrics such as total number of visitors, traffic, usage, and demographic patterns on our website; (f) diagnose or fix technology problems; and (g) otherwise to plan for and enhance our products and services. For information about the choices you may have in relation to our use of automatic data collection technologies, please refer to the [Your Privacy Choices](#your-privacy-choices) section below. ### Personal Data from Other Sources and Third Parties We may receive the same categories of personal data as described above from the following sources and other parties: * **Single Sign-On**: We may provide you the ability to log in to our services through certain third-party accounts you maintain. When you use these single sign-on protocols to access our services, we do not receive your login credentials for the relevant third-party service. Instead, we receive tokens from the single sign-on protocol to help identify you in our system (such as by your username) and confirm you successfully authenticated through the single sign-on protocol. This information allows us to more easily provide you access to our products and services. * **Employers**: If you interact with our services in connection with your employment, we may obtain personal data about you from your employer or another company for which you work. For example, we may obtain your contact information from your employer to allow us to communicate with you about your employer's relationship with us as a customer. * **Business Partners**: We may receive your information from our business partners, such as companies that offer their products and/or services as a part of or in connection with our services or that provide data enrichment services, including identifying the organizations of individuals who visit our website. * **Service Providers**: Our service providers that perform services on our behalf, such as analytics and certain marketing providers, collect personal data and often share some or all of this information with us. For example, we receive personal data you may submit in response to requests for feedback to our survey providers. ### Additional Uses of Personal Data In addition to the primary purposes for using personal data described above, we may also use personal data we collect to: * Fulfill or meet the reason the information was provided, such as to fulfill our contractual obligations, to facilitate payment for our products and services, or to deliver the services requested; * Communicate with you, including via email, and/or telephone calls; * Facilitate the relationship we have with you and, where applicable, the company you represent; * Create and maintain accounts for our users; * Verify your identity and entitlement to our products and services; * Market our products and services to you; * Develop, operate, test, analyze, improve, maintain, protect, and provide the features and functionality of our products and services; * Conduct research and analytics on our user base and our products and services; * Help maintain and enhance the safety, security, and integrity of our property, products, services, technology, assets, and business; * Defend, protect, or enforce our rights or applicable contracts and agreements (including our [Terms of Use](/legal/terms) ), as well as to resolve disputes, to carry out our obligations and enforce our rights, and to protect our business interests and the interests and rights of third parties; * Detect, prevent, investigate, or provide notice of security incidents or other malicious, deceptive, fraudulent, or illegal activity and protect the rights and property of AIUC and others; * Facilitate business transactions and reorganizations impacting the structure of our business; * Comply with contractual and legal obligations and requirements; * Fulfill any other purpose for which you provide your personal data, or for which you have otherwise consented. ## Our Disclosure of Personal Data We disclose or otherwise make available personal data in the following ways: * **To Your Employer**: We may disclose personal data to your employer or another company for which you work. For example, we may provide information to your employer about your usage of our services in connection with your work for them. * **To Marketing Providers**: We coordinate and share personal data with our marketing providers in order to advertise and communicate with you about the products and services we make available. * **To Ad Networks and Advertising Partners**: We work with third-party ad networks and advertising partners to deliver advertising and personalized content on our services, on other websites and services, and across other devices. These parties may collect information automatically from your browser or device when you visit our websites and other services through the use of cookies and related technologies. This information is used to provide and inform targeted advertising, as well as to provide advertising-related services such as reporting, attribution, analytics, and market research. * **To Business Partners**: We may share personal data with our business partners, or we may allow our business partners to collect personal data directly from you in connection with our services. Our business partners may use your personal data for their own business and commercial purposes, including to send you information about their products and services. * **To Service Providers**: We engage other third parties to perform certain services on our behalf in connection with the uses of personal data described in the sections above, including for web hosting or communications. Depending on the applicable services, these service providers may process personal data on our behalf or have access to personal data while performing services on our behalf. * **In Connection with a Business Transaction or Reorganization** : We may take part in or be involved with a business transaction or reorganization, such as a merger, acquisition, joint venture, or financing or sale of company assets. We may disclose, transfer, or assign personal data to a third party during negotiation of, in connection with, or as an asset in such a business transaction or reorganization. Also, in the unlikely event of our bankruptcy, receivership, or insolvency, your personal data may be disclosed, transferred, or assigned to third parties in connection with the proceedings or disposition of our assets. * **To Facilitate Legal Obligations and Rights**: We may disclose personal data to third parties, such as legal advisors and law enforcement: in connection with the establishment, exercise, or defense of legal claims; * to comply with laws or to respond to lawful requests and legal process; * to protect our rights and property and the rights and property of our agents, customers, and others, including to enforce our agreements, policies, and terms of use; * to detect, suppress, or prevent fraud; * to reduce credit risk and collect debts owed to us; * to protect the health and safety of us, our customers, or any person; or * as otherwise required by applicable law. * **With Your Consent or Direction**: We may disclose your personal data to certain other third parties or publicly with your consent or direction. For example, with your permission, we may post your testimonial on our websites. ## Your Privacy Choices The following privacy choices are made available to all individuals with whom we interact. You may also have additional choices regarding your personal data depending on your location or residency. ### Communication Preferences * **Email Communication Preferences**: You can stop receiving promotional email communications from us by clicking on the “unsubscribe” link provided in any of our email communications. Please note you cannot opt-out of service-related email communications (such as account verification, transaction confirmation, or service update emails). * **Phone Communication Preferences**: You can stop receiving promotional phone communications from us by informing the caller you no longer wish to receive promotional phone calls from us, following the instructions provided on the call for opting out of promotional phone calls (where available), or replying STOP to any one of our promotional text messages. Please note we may need to continue to communicate with you via phone for certain service-related messages (such as sending a verification code to your phone via call or text for purposes of verifying the authenticity of a log-in attempt). ### Withdrawing Your Consent Where we have your consent for the processing of your personal data (e.g., when you opt in to receive certain types of marketing communications from us), you may withdraw your consent by following the instructions provided when your consent was requested or by contacting us as set forth in the [Contact Us](#contact-us) section below. ### Automatic Data Collection Preferences When cookies are used on our website,you may be able to utilize third-party tools and features to further restrict our use of automatic data collection technologies. For example, (i) most browsers allow you to change browser settings to limit automatic data collection technologies on websites, (ii) most email providers allow you to prevent the automatic downloading of images in emails that may contain automatic data collection technologies, and (iii) many devices allow you to change your device settings to limit automatic data collection technologies for device applications. Please note that blocking automatic data collection technologies through third-party tools and features may negatively impact your experience using our services, as some features and offerings may not work properly or at all. Depending on the third-party tool or feature you use, you may not be able to block all automatic data collection technologies or you may need to update your preferences on multiple devices or browsers. We do not have any control over these third-party tools and features and are not responsible if they do not function as intended. ### Modifying or Deleting Your Personal Data If you have any questions about reviewing, modifying, or deleting your personal data, you can contact us directly at [legal-concerns@aiuc.com](mailto:legal-concerns@aiuc.com). We may not be able to modify or delete your personal data in all circumstances. ### Partner-Specific Preferences Certain of our third-party providers and partners offer additional ways that you may exercise control over your personal data, or automatically impose limitations on the way we can use personal data in connection with the services they provide: * **Device-Specific / Platform-Specific Preferences**: The device and/or platform you use to interact with us (such as you mobile device or social media provider), may provide you additional choices with regard to the data you choose to share with us. For example, many mobile devices allow you to change your device permissions to prevent our products and services from accessing certain types of information from your device (such as your contact lists or precise geolocation data), and many social media platforms allow you to change your platform permissions to prevent integrated products and services from accessing certain types of information connected with your profile. Please refer to your device or platform provider’s user guides for additional information about implementing any available platform-specific targeted advertising opt-outs. * **Google Analytics**: Google Analytics allows us to better understand how our customers interact with our services. For information on how Google Analytics collects and processes data, as well as how you can control information sent to Google, review Google's website here: [www.google.com/policies/privacy/partners/](https://www.google.com/policies/privacy/partners/) . You can learn about Google Analytics' currently available opt-outs, including the Google Analytics Browser Add-On here: [https://tools.google.com/dlpage/gaoptout/](https://tools.google.com/dlpage/gaoptout/) . We may also utilize certain forms of display advertising and other advanced features through Google Analytics. These features enable us to use first-party cookies (such as the Google Analytics cookie) and third-party cookies (such as the DoubleClick advertising cookie) or other third-party cookies together to inform, optimize, and display ads based on your past visits to our services. You may control your advertising preferences or opt-out of certain Google advertising products by visiting the Google Ads Preferences Manager, currently available at [https://myadcenter.google.com/?ref=help-center](https://myadcenter.google.com/?ref=help-center) . ## Children’s Personal Data Our services are not directed to, and we do not intend to, or knowingly, collect or solicit personal data from children under the age of 13. If an individual is under the age of 13, they should not use our services or otherwise provide us with any personal data either directly or by other means. If a child under the age of 13 has provided personal data to us, we encourage the child’s parent or guardian to contact us to request that we remove the personal data from our systems. If we learn that any personal data we collect has been provided by a child under the age of 13, we will promptly delete that personal data. ## Third-Party Websites and Services Our services may include links to third-party websites, plug-ins, applications and other services. Except where we post, link to or expressly adopt or refer to this Privacy Notice, this Privacy Notice does not apply to any personal data practices of third parties. To learn about the personal data practices of third parties, please visit their respective privacy notices. ## Updates to This Privacy Notice We may update this Privacy Notice from time to time. When we make changes to this Privacy Notice, we will change the date at the beginning of this Privacy Notice. If we make material changes to this Privacy Notice, we will notify individuals by prominent posting on this website or our other platforms, or through other appropriate communication channels. All changes shall be effective from the date of publication unless otherwise provided. ## Contact Us If you have any questions or requests in connection with this Privacy Notice or other privacy-related matters, please contact [legal-concerns@aiuc.com](mailto:legal-concerns@aiuc.com). 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Terms of Use Source: https://standard.aiuc-1.com/legal/terms *Last updated July 15, 2025.* Welcome to AIUC-1.com, a website of Caliber Labs, PBC doing business as Artificial Intelligence Underwriting Company (" **AIUC**", "**Company**", "**we**", or "**us**"). This page explains the terms by which you may use our website (the "**Site**"). By accessing or using the Site, you signify that you have read, understood, and agree to be bound by these Terms of Use (" **Agreement**"). AIUC reserves the right to make unilateral modifications to these terms and will provide notice of these changes as described below. This Agreement applies to all visitors and others who access the Site ("**Users** "). Please read this Agreement carefully to ensure that you understand each provision. This agreement contains a mandatory individual arbitration and class action/jury trial waiver provision that requires the use of arbitration on an individual basis to resolve disputes, rather than jury trials or class actions. ## 1. Use of Our Site ### A. Eligibility This is a contract between you and Company. You must read and agree to these terms before using the Site. If you do not agree, you may not use the Site. You may use the Site only if you can form a binding contract with Company, and only in compliance with this Agreement and all applicable local, state, national, and international laws, rules and regulations. Any use or access to the Site by anyone under 13 is strictly prohibited and in violation of this Agreement. The Site is not available to any Users previously removed from the Site by Company. ### B. Access to the Site Subject to the terms and conditions of this Agreement, you are hereby granted a non-exclusive, limited, non-transferable, freely revocable license to use the Site for your personal, noncommercial use only and as permitted by the features of the Site. Company reserves all rights not expressly granted herein in the Site and the Company Content (as defined below). Company may terminate this license at any time for any reason or no reason. ### C. Site Rules You agree not to engage in any of the following prohibited activities: (i) copying, distributing, or disclosing any part of the Site in any medium, including without limitation by any automated or non-automated “scraping”; (ii) using any automated system, including without limitation “robots,” “spiders,” “offline readers,” etc., to access the Site in a manner that sends more request messages to the Company servers than a human can reasonably produce in the same period of time by using a conventional on-line web browser (except that Company grants the operators of public search engines revocable permission to use spiders to copy publicly available materials from Company.com for the sole purpose of and solely to the extent necessary for creating publicly available searchable indices of the materials, but not caches or archives of such materials); (iii) transmitting spam, chain letters, or other unsolicited email; (iv) attempting to interfere with, compromise the system integrity or security or decipher any transmissions to or from the servers running the Site; (v) taking any action that imposes, or may impose at our sole discretion an unreasonable or disproportionately large load on our infrastructure; (vi) uploading invalid data, viruses, worms, or other software agents through the Site; (vii) collecting or harvesting any personally identifiable information, including account names, from the Site; (viii) using the Site for any commercial solicitation purposes; (ix) impersonating another person or otherwise misrepresenting your affiliation with a person or entity, conducting fraud, hiding or attempting to hide your identity; (x) interfering with the proper working of the Site; (xi) accessing any content on the Site through any technology or means other than those provided or authorized by the Site; or (xii) bypassing the measures we may use to prevent or restrict access to the Site, including without limitation features that prevent or restrict use or copying of any content or enforce limitations on use of the Site or the content therein. Accessing any audiovisual content that may be available on the Site for any purpose or in any manner other than Streaming (as defined below) is expressly prohibited unless explicitly permitted by the functionality of the Site. “Streaming” means a contemporaneous digital transmission of an audiovisual work via the Internet from the Site to a User’s device in such a manner that the data is intended for real-time viewing and not intended to be copied, stored, permanently downloaded, or redistributed by the User. We may, without prior notice, change the Site; stop providing the Site or features of the Site, to you or to Users generally; or create usage limits for the Site. We may permanently or temporarily terminate or suspend your access to the Site without notice and liability for any reason, including if in our sole determination you violate any provision of this Agreement, or for no reason. Upon termination for any reason or no reason, you continue to be bound by this Agreement. ## 2. Our Proprietary Rights The Site and all materials therein or transferred thereby, including, without limitation, software, images, text, graphics, illustrations, logos, patents, trademarks, service marks, copyrights, photographs, audio, videos, and music (the "**Company Content** "), and all intellectual property rights related thereto, are the exclusive property of Company and its licensors. Except as explicitly provided herein, nothing in this Agreement shall be deemed to create a license in or under any such intellectual property rights, and you agree not to sell, license, rent, modify, distribute, copy, reproduce, transmit, publicly display, publicly perform, publish, adapt, edit or create derivative works from any Company Content. Use of the Company Content for any purpose not expressly permitted by this Agreement is strictly prohibited. You may choose to or we may invite you to submit comments or ideas about the Site, including without limitation about how to improve the Site or our products ("**Ideas**"). By submitting any Idea, you agree that your disclosure is gratuitous, unsolicited and without restriction and will not place Company under any fiduciary or other obligation, and that we are free to use the Idea without any additional compensation to you, and/or to disclose the Idea on a non-confidential basis or otherwise to anyone. You further acknowledge that, by acceptance of your submission, Company does not waive any rights to use similar or related ideas previously known to Company, or developed by its employees, or obtained from sources other than you. ## 3. Privacy We care about the privacy of our Users. You understand that by using the Sites you consent to the collection, use and disclosure of your personally identifiable information and aggregate data as set forth in our [Privacy Notice](/legal/privacy) , and to have your personally identifiable information collected, used, transferred to and processed in the United States. ## 4. Security Company cares about the integrity and security of your personal information. However, we cannot guarantee that unauthorized third parties will never be able to defeat our security measures or use your personal information for improper purposes. You acknowledge that you provide your personal information at your own risk. ## 5. Third-Party Links and Information The Site may contain links to third-party materials that are not owned or controlled by Company. Company does not endorse or assume any responsibility for any such third-party sites, information, materials, products, or services. If you access a third-party website or service from the Site on or through any third-party website or service, you do so at your own risk, and you understand that this Agreement and Company’s Privacy Notice do not apply to your use of such sites. You expressly relieve Company from any and all liability arising from your use of any third-party website, service, or content. Additionally, your dealings with or participation in promotions of advertisers found on the Site, including payment and delivery of goods, and any other terms (such as warranties) are solely between you and such advertisers. You agree that Company shall not be responsible for any loss or damage of any sort relating to your dealings with such advertisers. ## 6. Indemnity You agree to defend, indemnify and hold harmless Company and its subsidiaries, agents, licensors, managers, and other affiliated companies, and their employees, contractors, agents, officers and directors, from and against any and all claims, damages, obligations, losses, liabilities, costs or debt, and expenses (including but not limited to attorney’s fees) arising from: (i) your use of and access to the Site, including any data or content transmitted or received by you; (ii) your violation of any term of this Agreement, including without limitation your breach of any of the representations and warranties above; (iii) your violation of any third-party right, including without limitation any right of privacy or intellectual property rights; (iv) your violation of any applicable law, rule or regulation; or (v) your willful misconduct. ## 7. No Warranty The Site is provided on an "as is" and "as available" basis. Use of the Site is at your own risk. To the maximum extent permitted by applicable law, the Site is provided without warranties of any kind, whether express or implied, including, but not limited to, implied warranties of merchantability, fitness for a particular purpose, or non-infringement. No advice or information, whether oral or written, obtained by you from Company or through the Site will create any warranty not expressly stated herein. Without limiting the foregoing, Company, its subsidiaries, its affiliates, and its licensors do not warrant that the content is accurate, reliable or correct; that the Site will meet your requirements; that the Site will be available at any particular time or location, uninterrupted or secure; that any defects or errors will be corrected; or that the Site is free of viruses or other harmful components. Any content downloaded or otherwise obtained through the use of the Site is downloaded at your own risk and you will be solely responsible for any damage to your computer system or loss of data that results from such download or your use of the Site. Company does not warrant, endorse, guarantee, or assume responsibility for any product or site advertised or offered by a third party through the Site or any hyperlinked website or site, and Company will not be a party to or in any way monitor any transaction between you and third-party providers of products or services. Federal law, some states, provinces and other jurisdictions do not allow the exclusion and limitations of certain implied warranties, so the above exclusions may not apply to you. This agreement gives you specific legal rights, and you may also have other rights which vary from state to state. The disclaimers and exclusions under this agreement will not apply to the extent prohibited by applicable law. ## 8. Limitation of Liability To the maximum extent permitted by applicable law, in no event shall Company, its affiliates, agents, directors, employees, suppliers or licensors be liable for any indirect, punitive, incidental, special, consequential or exemplary damages, including without limitation damages for loss of profits, goodwill, use, data or other intangible losses, arising out of or relating to the use of, or inability to use, this Site. Under no circumstances will Company be responsible for any damage, loss or injury resulting from hacking, tampering or other unauthorized access or use of the Site or your account or the information contained therein. To the maximum extent permitted by applicable law, Company assumes no liability or responsibility for any (i) errors, mistakes, or inaccuracies of content; (ii) personal injury or property damage, of any nature whatsoever, resulting from your access to or use of our site; (iii) any unauthorized access to or use of our secure servers and/or any and all personal information stored therein; (iv) any interruption or cessation of transmission to or from the Site; (v) any bugs, viruses, trojan horses, or the like that may be transmitted to or through our site by any third party; (vi) any errors or omissions in any content or for any loss or damage incurred as a result of the use of any content posted, emailed, transmitted, or otherwise made available through the Site; and/or (vii) the defamatory, offensive, or illegal conduct of any third party. In no event shall Company, its affiliates, agents, directors, employees, suppliers, or licensors be liable to you for any claims, proceedings, liabilities, obligations, damages, losses or costs in an amount exceeding the amount you paid to Company hereunder or \$100.00, whichever is greater. This limitation of liability section applies whether the alleged liability is based on contract, tort, negligence, strict liability, or any other basis, even if Company has been advised of the possibility of such damage. The foregoing limitation of liability shall apply to the fullest extent permitted by law in the applicable jurisdiction. Some states do not allow the exclusion or limitation of incidental or consequential damages, so the above limitations or exclusions may not apply to you. This agreement gives you specific legal rights, and you may also have other rights which vary from state to state. The disclaimers, exclusions, and limitations of liability under this agreement will not apply to the extent prohibited by applicable law. The Site is controlled and operated from facilities in the United States. Company makes no representations that the Site is appropriate or available for use in other locations. Those who access or use the Site from other jurisdictions do so at their own volition and are entirely responsible for compliance with all applicable United States and local laws and regulations, including but not limited to export and import regulations. You may not use the Site if you are a resident of a country embargoed by the United States, or are a foreign person or entity blocked or denied by the United States government. Unless otherwise explicitly stated, all materials found on the Site are solely directed to individuals, companies, or other entities located in the United States. ## 9. Governing Law, Arbitration, and Class Action/Jury Trial Waiver ### A. Governing Law You agree that: (i) the Site shall be deemed solely based in California; and (ii) the Site shall be deemed a passive one that does not give rise to personal jurisdiction over us, either specific or general, in jurisdictions other than California. This Agreement shall be governed by the internal substantive laws of the State of California, without respect to its conflict of laws principles. The parties acknowledge that this Agreement evidences a transaction involving interstate commerce. Notwithstanding the preceding sentences with respect to the substantive law, any arbitration conducted pursuant to the terms of this Agreement shall be governed by the Federal Arbitration Act (9 U.S.C. §§ 1-16). The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. You agree to submit to the personal jurisdiction of the federal and state courts located in San Francisco, California for any actions for which we retain the right to seek injunctive or other equitable relief in a court of competent jurisdiction to prevent the actual or threatened infringement, misappropriation or violation of a our copyrights, trademarks, trade secrets, patents, or other intellectual property or proprietary rights, as set forth in the Arbitration provision below, including any provisional relief required to prevent irreparable harm. You agree that San Francisco, California is the proper forum for any appeals of an arbitration award or for trial court proceedings in the event that the arbitration provision below is found to be unenforceable. ### B. Arbitration Read this section carefully because it requires the parties to arbitrate their disputes and limits the manner in which you can seek relief from Company. For any dispute with Company, you agree to first contact us at [legal-concerns@aiuc.com](mailto:legal-concerns@aiuc.com) and attempt to resolve the dispute with us informally. In the unlikely event that Company has not been able to resolve a dispute it has with you after sixty (60) days, we each agree to resolve any claim, dispute, or controversy (excluding any claims for injunctive or other equitable relief as provided below) arising out of or in connection with or relating to this Agreement, or the breach or alleged breach thereof (collectively, "**Claims**"), by binding arbitration by JAMS, under the Optional Expedited Arbitration Procedures then in effect for JAMS, except as provided herein. JAMS may be contacted at [www.jamsadr.com](https://www.jamsadr.com). The arbitration will be conducted in San Francisco, California, unless you and Company agree otherwise. If you are using the Site for commercial purposes, each party will be responsible for paying any JAMS filing, administrative and arbitrator fees in accordance with JAMS rules, and the award rendered by the arbitrator shall include costs of arbitration, reasonable attorneys’ fees and reasonable costs for expert and other witnesses. If you are an individual using the Site for non-commercial purposes: (i) JAMS may require you to pay a fee for the initiation of your case, unless you apply for and successfully obtain a fee waiver from JAMS; (ii) the award rendered by the arbitrator may include your costs of arbitration, your reasonable attorney’s fees, and your reasonable costs for expert and other witnesses; and (iii) you may sue in a small claims court of competent jurisdiction without first engaging in arbitration, but this does not absolve you of your commitment to engage in the informal dispute resolution process. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. Nothing in this Section shall be deemed as preventing Company from seeking injunctive or other equitable relief from the courts as necessary to prevent the actual or threatened infringement, misappropriation, or violation of our data security, intellectual property rights or other proprietary rights. ### C. Class Action/Jury Trial Waiver With respect to all persons and entities, regardless of whether they have obtained or used the site for personal, commercial or other purposes, all Claims must be brought in the parties’ individual capacity, and not as a plaintiff or class member in any purported class action, collective action, private attorney general action or other representative proceeding. This waiver applies to class arbitration, and, unless we agree otherwise, the arbitrator may not consolidate more than one person’s claims. You agree that, by entering into this agreement, you and Company are each waiving the right to a trial by jury or to participate in a class action, collective action, private attorney general action, or other representative proceeding of any kind. ## 10. General ### A. Assignment This Agreement, and any rights and licenses granted hereunder, may not be transferred or assigned by you, but may be assigned by Company without restriction. Any attempted transfer or assignment in violation hereof shall be null and void. ### B. Notification Procedures and Changes to the Agreement Company may provide notifications, whether such notifications are required by law or are for marketing or other business related purposes, to you via email notice, written or hard copy notice, or through posting of such notice on our website, as determined by Company in our sole discretion. Company reserves the right to determine the form and means of providing notifications to our Users, provided that you may opt out of certain means of notification as described in this Agreement. Company is not responsible for any automatic filtering you or your network provider may apply to email notifications we send to the email address you provide us. Company may, in its sole discretion, modify or update this Agreement from time to time, and so you should review this page periodically. When we change the Agreement in a material manner, we will update the ‘last modified’ date at the top of this page and notify you that material changes have been made to the Agreement. Your continued use of the Site after any such change constitutes your acceptance of the new Terms of Use. If you do not agree to any of these terms or any future Terms of Use, do not use or access (or continue to access) the Site. ### C. Entire Agreement/Severability This Agreement, together with any amendments and any additional agreements you may enter into with Company in connection with the Site, shall constitute the entire agreement between you and Company concerning the Site. If any provision of this Agreement is deemed invalid by a court of competent jurisdiction, the invalidity of such provision shall not affect the validity of the remaining provisions of this Agreement, which shall remain in full force and effect. ### D. No Waiver No waiver of any term of this Agreement shall be deemed a further or continuing waiver of such term or any other term, and Company’s failure to assert any right or provision under this Agreement shall not constitute a waiver of such right or provision. ### E. California Residents If you are a California resident, in accordance with Cal. Civ. Code §1789.3, you may report complaints to the Complaint Assistance Unit of the Division of Consumer Sites of the California Department of Consumer Affairs by contacting them in writing at 1625 North Market Blvd., Suite N 112 Sacramento, CA 95834, or by telephone at (800) 952-5210 or (916) 445-1254. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Re-certification: Maintaining AIUC-1 Source: https://standard.aiuc-1.com/re-certification-maintaining-aiuc-1 AIUC-1 certification is valid for one year. To maintain certification during the year, agents must be submitted for red-teaming each quarter. At the end of the year, a re-certification is required, where the organization must demonstrate that AIUC-1 requirements are still being met and that controls are effective - validated by an accredited auditor. ## Which version of the standard to audit against AIUC-1 is updated quarterly, with releases on January 15, April 15, July 15, and October 15 of each year. At the start of your re-certification, you will receive guidance on how the standard has changed since your last audit - which requirements are new or updated, and what your organization needs to implement before auditor fieldwork. Audits are generally conducted against the latest version of AIUC-1. We allow up to 30 days of grace period, to enable organizations to prepare for an audit against a constant standard version. ## Re-audit process 1. **Choose your auditor:** Continue with your existing auditor or select a new one. 2. **Scoping:** Confirm which agents are in scope and update your Statement of Applicability. We recommend adding newly deployed high-risk agents at this point - your certification should evolve with your security posture. 3. **Red-teaming:** AIUC re-runs technical evaluations against your in-scope agents, updated to reflect the current threat landscape. 4. **Full audit of control:** Your auditor reviews evidence across all in-scope requirements and controls. 5. **Updated report and certification:** You receive a new audit report and certificate, ready for your trust center. The process will start roughly two months before your existing certification expires. ## Effort required The re-certification is substantially lighter than the initial first audit: * **Controls remain in place:** Policies & technical controls implemented at the initial audit should still be in place, making evidence collection simple. * **Established evidence infrastructure:** Evidence locations, owners, and formats are established from the previous audit. For organizations expanding the scope of their AIUC-1 certification, additional effort should naturally be expected to demonstrate controls of new agent systems included. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # D. Reliability Source: https://standard.aiuc-1.com/reliability ## Requirements Prevent hallucinated outputs D001 · Mandatory Implement safeguards or technical controls to prevent hallucinated outputs. Keywords Hallucinations Technical Controls Capabilities Text-generation Voice-generation Code-generation [Open](/reliability/prevent-hallucinated-outputs) \[Retired] Third-party testing for hallucinations D002 · Mandatory Retired - see changelog (Q4 2026 update). Keywords Hallucinations Third-Party Testing [Open](/reliability/3rd-party-testing-for-hallucinations) Restrict unsafe tool calls D003 · Mandatory Implement safeguards or technical controls to prevent tool calls in AI systems from executing unauthorized actions, accessing restricted information, or making decisions beyond their intended scope. Keywords Tool Calls Tool Selection Technical Controls Capabilities Automation [Open](/reliability/restrict-unsafe-tool-calls) Third-party testing for reliability risk D004 · Mandatory Appoint expert third-parties to evaluate system robustness to reliability risk as defined in the AIUC-1 risk taxonomy at least every 3 months Keywords Tool Calls Tool Selection Third-Party Testing Capabilities Universal [Open](/reliability/3rd-party-testing-of-tool-calls) 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # D002: [Retired] Third-party testing for hallucinations Source: https://standard.aiuc-1.com/reliability/3rd-party-testing-for-hallucinations Retired - see changelog (Q4 2026 update). Keywords Hallucinations Third-Party Testing Application Mandatory Type Preventative Crosswalks NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 2.2: Deployed system value](/crosswalks/nist-ai-rmf) [MEASURE 1.3: Independent assessment](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.5: Validity and reliability](/crosswalks/nist-ai-rmf) [MEASURE 4.1: Context-specific measurement](/crosswalks/nist-ai-rmf) [MEASURE 4.2: Trustworthiness validation](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM09:25 - Misinformation](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) [AIS-05: Application Security Testing](/crosswalks/csa-aicm) [MDS-06: Adversarial Attack Analysis](/crosswalks/csa-aicm) [MDS-07: Robustness against Adversarial Attack / Model Hardening](/crosswalks/csa-aicm) ISO 42001 ? [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) IBM AI Risk Atlas ? [IBM 40: Inference - Poor model accuracy](/crosswalks/ibm-ai-risk-atlas) [IBM 71: Output - Hallucination](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) [PI1.3: Processing controls](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **This requirement was retired during the Q4, 2026 standard update.** See aiuc-1.com/changelog for more information D002.1 RetiredRetired Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # D004: Third-party testing for reliability risk Source: https://standard.aiuc-1.com/reliability/3rd-party-testing-of-tool-calls Appoint expert third-parties to evaluate system robustness to reliability risk as defined in the AIUC-1 risk taxonomy at least every 3 months Keywords Tool Calls Tool Selection Third-Party Testing Application Mandatory Frequency Every 3 months Type Preventative Capabilities Universal Crosswalks NIST AI RMF ? [GOVERN 6.1: Third-party risk policies](/crosswalks/nist-ai-rmf) [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 2.2: Deployed system value](/crosswalks/nist-ai-rmf) [MEASURE 1.3: Independent assessment](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.6: Safety evaluation](/crosswalks/nist-ai-rmf) [MEASURE 4.1: Context-specific measurement](/crosswalks/nist-ai-rmf) [MEASURE 4.2: Trustworthiness validation](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM06:25 - Excessive Agency](/crosswalks/owasp-top-10) ISO 42001 ? [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) CSA AICM ? [AIS-05: Application Security Testing](/crosswalks/csa-aicm) OWASP AIVSS ? [Agentic AI Tool Misuse](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 5: Agentic AI - Misaligned actions](/crosswalks/ibm-ai-risk-atlas) [IBM 9: Agentic AI - Function calling hallucination](/crosswalks/ibm-ai-risk-atlas) [IBM 11: Agentic AI - Incomplete AI agent evaluation](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.3: Goal Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.1: Reasoning Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.2: Memory System Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.1: Tool Exploitation](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI02 - Tool Misuse and Exploitation](/crosswalks/owasp-agentic-top-10) [ASI05 - Unexpected Code Execution](/crosswalks/owasp-agentic-top-10) [ASI10 - Rogue Agents](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Appointing qualified third-party assessors.** Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence. **Conducting regular testing.** Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter. **Maintaining documentation.** Including testing scope and results. D004.1 Evals: Third-party evaluation report assessing reliability riskThird-party evaluation report showing testing for reliability risk - including risks tested (e.g., hallucinations, source attribution, incorrectly executed tool actions), testing methodology and findings Category [Third-party Evals](/evidence/third-party-evals) Typical location Third-party evaluation report Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # D001: Prevent hallucinated outputs Source: https://standard.aiuc-1.com/reliability/prevent-hallucinated-outputs Implement safeguards or technical controls to prevent hallucinated outputs. Keywords Hallucinations Technical Controls Application Mandatory Frequency Every 12 months Type Preventative Capabilities Text-generation Voice-generation Code-generation Crosswalks NIST AI RMF ? [MEASURE 2.5: Validity and reliability](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM09:25 - Misinformation](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) [MDS-10: Model Continuous Monitoring](/crosswalks/csa-aicm) [MDS-11: Model Failure](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 40: Inference - Poor model accuracy](/crosswalks/ibm-ai-risk-atlas) [IBM 63: Output - Incomplete advice](/crosswalks/ibm-ai-risk-atlas) [IBM 71: Output - Hallucination](/crosswalks/ibm-ai-risk-atlas) [IBM 76: Output - Unreliable source attribution](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [PI1.2: Input completeness and accuracy](/crosswalks/soc-2) [PI1.3: Processing controls](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing factual accuracy controls.** For example, deploying available fact-checking mechanisms, flagging uncertain or low-confidence responses. D001.1 Config: Groundedness filterCode or configuration showing groundedness validation - may include filters checking responses against source documents, fact-checking API integration, or logic comparing generated content to retrieved context for factual accuracy. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Text-generation Voice-generation Code-generation **Establishing information source validation.** For example, requiring citations for factual claims, implementing source reliability checks. D001.2 Demonstration: User-facing citations & source attributionsUI or output format showing citations and source attributions provided to users - may include inline citations, source links, reference lists, or attribution labels identifying where information originated. Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Text-generation Voice-generation Code-generation May include ? **Maintaining uncertainty communication.** For example, displaying confidence levels, providing appropriate disclaimers for generated information. D001.3 Demonstration: User-facing uncertainty labelsUI or output format showing confidence levels, uncertainty disclaimers, or warnings for generated information - may include confidence score displays, low-certainty warnings, or standard disclaimers about potential inaccuracies. Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Text-generation Voice-generation Code-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # D003: Restrict unsafe tool calls Source: https://standard.aiuc-1.com/reliability/restrict-unsafe-tool-calls Implement safeguards or technical controls to prevent tool calls in AI systems from executing unauthorized actions, accessing restricted information, or making decisions beyond their intended scope. Keywords Tool Calls Tool Selection Technical Controls Application Mandatory Frequency Every 12 months Type Preventative Capabilities Automation Crosswalks MITRE ATLAS ? [AML-M0004: Restrict Number of AI Model Queries](/crosswalks/mitre-atlas) [AML-M0024: AI Telemetry Logging](/crosswalks/mitre-atlas) EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) NIST AI RMF ? [GOVERN 6.1: Third-party risk policies](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM06:25 - Excessive Agency](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [AIS-10: API Security](/crosswalks/csa-aicm) [AIS-06: Secure Application Deployment](/crosswalks/csa-aicm) [AIS-13: AI Sandboxing](/crosswalks/csa-aicm) [AIS-11: Agents Security Boundaries](/crosswalks/csa-aicm) [MDS-10: Model Continuous Monitoring](/crosswalks/csa-aicm) [MDS-11: Model Failure](/crosswalks/csa-aicm) [TVM-11: Guardrails](/crosswalks/csa-aicm) [TVM-12: Threat Analysis and Modeling](/crosswalks/csa-aicm) OWASP AIVSS ? [Agentic AI Tool Misuse](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 5: Agentic AI - Misaligned actions](/crosswalks/ibm-ai-risk-atlas) [IBM 7: Agentic AI - Unauthorized use](/crosswalks/ibm-ai-risk-atlas) [IBM 9: Agentic AI - Function calling hallucination](/crosswalks/ibm-ai-risk-atlas) [IBM 10: Agentic AI - Redundant actions](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.3: Goal Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.1: Reasoning Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.1: Tool Exploitation](/crosswalks/cisco-ai-security-safety-framework) [AITech-14.2: Abuse of Delegated Authority](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI01 - Agent Goal Hijack](/crosswalks/owasp-agentic-top-10) [ASI02 - Tool Misuse and Exploitation](/crosswalks/owasp-agentic-top-10) [ASI03 - Identity and Privilege Abuse](/crosswalks/owasp-agentic-top-10) [ASI05 - Unexpected Code Execution](/crosswalks/owasp-agentic-top-10) [ASI08 - Cascading Failures](/crosswalks/owasp-agentic-top-10) [ASI10 - Rogue Agents](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC5.1: Select and develop control activities](/crosswalks/soc-2) [PI1.2: Input completeness and accuracy](/crosswalks/soc-2) [PI1.3: Processing controls](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing tool call validation and authorization.** For example, restricting tool calls to approved functions and MCP servers, validating parameters before execution. D003.1 Config: Tool authorization & validationCode or configuration showing function and tool allowlists, parameter validation logic, or authz checks before tool execution - may include tool permission schemas, input validation functions, or access control lists restricting available tools per agent/user. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Automation **Enforcing rate limits and transaction caps for autonomous tool use.** D003.2 Config: Rate limits for toolsCode or configuration showing rate limits and transaction caps on tool usage - may include per-tool usage quotas, time-windowed limits, or circuit breakers preventing excessive autonomous tool calls. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Automation **Establishing execution monitoring and logging.** For example, tracking all tool calls, monitoring for unauthorized access attempts or scope violations. D003.3 Config: Tool call logLogging configuration, monitoring dashboard, or audit logs showing tracked tool calls - may include log entries capturing the originating MCP server, tool name, tool version, input parameters, and timestamps per invocation, alerts for unauthorized tool access attempts, or monitoring system flagging scope violations. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Capabilities Automation **Requiring human approval for sensitive tool operations.** For example, requiring human confirmation before executing high-risk actions, multi-step tool calls, implementing approval workflows for operations beyond autonomous boundaries. D003.4 Config: Human-approval workflowsApproval workflow configuration, code or ticketing system for sensitive, high-risk, or multi-step tool operations requiring human confirmation (e.g., executing financial transactions, deleting or irreversibly modifying records, and changing credentials or permissions). Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Automation May include ? **Reviewing patterns of AI tool usage.** For example, identifying anomalies, updating tool permissions, and retiring unused or high-risk functions during scheduled evaluations. D003.5 Documentation: tool call log reviewsReports or documentation showing periodic review of tool usage patterns, permission updates, and function retirement decisions - may include usage analytics identifying anomalies, change logs showing permission adjustments, or records of deprecated/retired tools with rationale. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Automation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C. Safety Source: https://standard.aiuc-1.com/safety ## Requirements Define AI risk taxonomy C001 · Mandatory Establish a risk taxonomy based on system capabilities and deployment context. Keywords Risk Taxonomy Severity Rating Capabilities Universal [Open](/safety/define-ai-risk-taxonomy) Conduct pre-deployment testing C002 · Mandatory Conduct internal testing of AI systems prior to deployment across risk categories for system changes requiring formal review or approval. Keywords Internal Testing Pre-Deployment Testing Capabilities Universal [Open](/safety/conduct-pre-deployment-testing) Prevent harmful outputs C003 · Mandatory Implement safeguards or technical controls to prevent harmful outputs including distressed outputs, angry responses, high-risk advice, offensive content, bias, and deception. Keywords Harmful Outputs Distressed Angry Advice Offensive Bias Capabilities Text-generation Voice-generation Image-generation [Open](/safety/prevent-harmful-outputs) Prevent out-of-scope outputs C004 · Mandatory Implement safeguards or technical controls to prevent out-of-scope outputs (e.g. political discussion, healthcare advice). Keywords Out-of-Scope Political Discussion Technical Controls Capabilities Text-generation Voice-generation [Open](/safety/prevent-out-of-scope-outputs) Prevent agent-specific high risk outputs C005 · Mandatory Implement safeguards or technical controls to prevent agent-specific high-risk outputs as defined in risk taxonomy. Keywords High-Risk Outputs Risk Taxonomy Technical Controls Capabilities Universal [Open](/safety/prevent-other-high-risk-outputs) Prevent output vulnerabilities C006 · Mandatory Implement safeguards to prevent security vulnerabilities in outputs from impacting users. Keywords Harmful Outputs Code Injection Data Exfiltration Capabilities Code-generation Text-generation Voice-generation [Open](/safety/prevent-output-vulnerabilities) Flag high risk outputs for human review C007 · Optional Implement an alerting system that flags high-risk outputs for human review. Keywords Human Review Escalation Capabilities Universal [Open](/safety/flag-high-risk-recommendations) Monitor AI risk categories C008 · Optional Implement monitoring of AI systems across risk categories. Keywords Monitoring High-Risk Outputs Capabilities Universal [Open](/safety/monitor-ai-risk-categories) Enable real-time feedback and intervention C009 · Optional Implement mechanisms to enable real-time user feedback collection, intervention and actioning mechanisms. Keywords Feedback Intervention User Control Transparency Capabilities Universal [Open](/safety/collect-real-time-feedback) Third-party testing for safety risk C010 · Mandatory Appoint expert third-parties to evaluate system robustness to safety risk as defined in the AIUC-1 risk taxonomy at least every 3 months Keywords Harmful Outputs Distressed Angry Advice Offensive Bias Risk Severity Toxigen Third-Party Testing Capabilities Universal [Open](/safety/3rd-party-testing-for-harmful-outputs) \[Retired] Third-party testing for out-of-scope outputs C011 · Mandatory Retired - see changelog (Q4 2026 update). Keywords Out-of-Scope Political Discussion Third-Party Testing [Open](/safety/3rd-party-testing-for-out-of-scope-outputs) \[Retired] Third-party testing for customer-defined risk C012 · Mandatory Retired - see changelog (Q4 2026 update). Keywords High-Risk Outputs Risk Taxonomy Third-Party Testing [Open](/safety/3rd-party-testing-for-other-risk) 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C010: Third-party testing for safety risk Source: https://standard.aiuc-1.com/safety/3rd-party-testing-for-harmful-outputs Appoint expert third-parties to evaluate system robustness to safety risk as defined in the AIUC-1 risk taxonomy at least every 3 months Keywords Harmful Outputs Distressed Angry Advice Offensive Bias Risk Severity Toxigen Third-Party Testing Application Mandatory Frequency Every 3 months Type Preventative Capabilities Universal Crosswalks NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 2.2: Deployed system value](/crosswalks/nist-ai-rmf) [MEASURE 1.3: Independent assessment](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.6: Safety evaluation](/crosswalks/nist-ai-rmf) [MEASURE 2.11: Fairness and bias](/crosswalks/nist-ai-rmf) [MEASURE 4.1: Context-specific measurement](/crosswalks/nist-ai-rmf) [MEASURE 4.2: Trustworthiness validation](/crosswalks/nist-ai-rmf) EU AI Act ? [Article 9: Risk Management System](/crosswalks/eu-ai-act) CSA AICM ? [GRC-11: Bias and Fairness Assessment](/crosswalks/csa-aicm) [A\&A-02: Independent Assessments](/crosswalks/csa-aicm) [TVM-06: Penetration Testing](/crosswalks/csa-aicm) ISO 42001 ? [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) IBM AI Risk Atlas ? [IBM 62: Output - Toxic output](/crosswalks/ibm-ai-risk-atlas) [IBM 58: Output - Decision bias](/crosswalks/ibm-ai-risk-atlas) [IBM 59: Output - Output bias](/crosswalks/ibm-ai-risk-atlas) [IBM 60: Output - Harmful output](/crosswalks/ibm-ai-risk-atlas) [IBM 84: Non-Technical - Unrepresentative risk testing](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) NYC LL 144 ? [5-301: Conduct Bias Audit](/crosswalks/nyc-ll-144) [5-302: Manage Audit Data](/crosswalks/nyc-ll-144) CO AI Act ? [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) OWASP Agentic Top 10 ? [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Appointing qualified third-party assessors.** Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence. **Conducting regular testing.** Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter. **Maintaining documentation.** Including testing scope and results. C010.1 Evals: Third-party evaluation report assessing safety riskThird-party evaluation report showing testing for safety risk - including risks tested (e.g., physical harm, emotional harm, inappropriate content, high-risk domain engagement, bias), testing methodology and findings Category [Third-party Evals](/evidence/third-party-evals) Typical location Third-party evaluation report Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C012: [Retired] Third-party testing for customer-defined risk Source: https://standard.aiuc-1.com/safety/3rd-party-testing-for-other-risk Retired - see changelog (Q4 2026 update). Keywords High-Risk Outputs Risk Taxonomy Third-Party Testing Application Mandatory Type Preventative Crosswalks NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 2.2: Deployed system value](/crosswalks/nist-ai-rmf) [MEASURE 1.3: Independent assessment](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.6: Safety evaluation](/crosswalks/nist-ai-rmf) [MEASURE 4.1: Context-specific measurement](/crosswalks/nist-ai-rmf) [MEASURE 4.2: Trustworthiness validation](/crosswalks/nist-ai-rmf) ISO 42001 ? [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) CSA AICM ? [A\&A-02: Independent Assessments](/crosswalks/csa-aicm) [TVM-06: Penetration Testing](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Cascading Failures](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 84: Non-Technical - Unrepresentative risk testing](/crosswalks/ibm-ai-risk-atlas) [IBM 85: Non-Technical - Incorrect risk testing](/crosswalks/ibm-ai-risk-atlas) [IBM 86: Non-Technical - Lack of testing diversity](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) CO AI Act ? [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **This requirement was retired during the Q4, 2026 standard update.** See aiuc-1.com/changelog for more information C012.1 RetiredRetired Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C011: [Retired] Third-party testing for out-of-scope outputs Source: https://standard.aiuc-1.com/safety/3rd-party-testing-for-out-of-scope-outputs Retired - see changelog (Q4 2026 update). Keywords Out-of-Scope Political Discussion Third-Party Testing Application Mandatory Type Preventative Crosswalks NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 2.2: Deployed system value](/crosswalks/nist-ai-rmf) [MAP 2.2: Knowledge limits](/crosswalks/nist-ai-rmf) [MEASURE 1.3: Independent assessment](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.6: Safety evaluation](/crosswalks/nist-ai-rmf) [MEASURE 4.1: Context-specific measurement](/crosswalks/nist-ai-rmf) [MEASURE 4.2: Trustworthiness validation](/crosswalks/nist-ai-rmf) ISO 42001 ? [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) IBM AI Risk Atlas ? [IBM 69: Output - Improper usage](/crosswalks/ibm-ai-risk-atlas) [IBM 83: Non-Technical - Incomplete usage definition](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **This requirement was retired during the Q4, 2026 standard update.** See aiuc-1.com/changelog for more information C011.1 RetiredRetired Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C009: Enable real-time feedback and intervention Source: https://standard.aiuc-1.com/safety/collect-real-time-feedback Implement mechanisms to enable real-time user feedback collection, intervention and actioning mechanisms. Keywords Feedback Intervention User Control Transparency Application Optional Frequency Every 3 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 14: Human Oversight](/crosswalks/eu-ai-act) ISO 42001 ? [A.8.3: External reporting](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 3.2: Human-AI oversight](/crosswalks/nist-ai-rmf) [MAP 3.5: Human oversight](/crosswalks/nist-ai-rmf) [MEASURE 3.3: User feedback systems](/crosswalks/nist-ai-rmf) CSA AICM ? [GRC-15: Human supervision](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 4: Agentic AI - Over- or under-reliance on AI agents](/crosswalks/ibm-ai-risk-atlas) [IBM 20: Agentic AI - AI agents' impact on human agency](/crosswalks/ibm-ai-risk-atlas) [IBM 64: Output - Over- or under-reliance](/crosswalks/ibm-ai-risk-atlas) CO AI Act ? [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) OWASP Agentic Top 10 ? [ASI01 - Agent Goal Hijack](/crosswalks/owasp-agentic-top-10) [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [PI1.1: Relevant processing information](/crosswalks/soc-2) [PI1.3: Processing controls](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Enabling user intervention capabilities.** For example, providing mechanisms for users to pause, stop, or redirect system behavior, implementing feedback collection tools for users to report issues or concerns, ensuring technical controls persist across devices and interaction contexts. **Ensuring accessibility of feedback and intervention mechanisms.** For example, adhering to WCAG 2.1 standards for color contrast, screen reader compatibility, keyboard navigation, and clear messaging for users with disabilities. C009.1 Demonstration: User intervention mechanismsIntervention controls (stop/pause/redirect buttons, feedback forms, issue reporting mechanisms) with accessibility features integrated (e.g. keyboard navigation, high contrast modes, screen reader labels) Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Universal May include ? **Reviewing user feedback and intervention logs at regular intervals, analyzing findings using structured methodologies (e.** g., categorizing by risk domain, frequency, and severity), and integrating corrective actions into product backlogs or compliance workflows, with records maintained for traceability. C009.2 Documentation: User feedback & intervention reviewsLogs, reports, or dashboard showing review, analysis and actioning of user feedback and intervention patterns - may include feedback summary reports, intervention frequency analysis, categorization by risk domain, documentation of system changes made in response to patterns, or integration with product backlog/compliance workflows. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C002: Conduct pre-deployment testing Source: https://standard.aiuc-1.com/safety/conduct-pre-deployment-testing Conduct internal testing of AI systems prior to deployment across risk categories for system changes requiring formal review or approval. Keywords Internal Testing Pre-Deployment Testing Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0016: Vulnerability Scanning](/crosswalks/mitre-atlas) EU AI Act ? [Article 9: Risk Management System](/crosswalks/eu-ai-act) [Article 27: Fundamental Rights Impact Assessment for High-Risk AI Systems](/crosswalks/eu-ai-act) ISO 42001 ? [A.6.2.5: AI system deployment](/crosswalks/iso-42001) [A.6.2.4: AI system verification and validation](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MANAGE 1.1: Purpose achievement](/crosswalks/nist-ai-rmf) [MAP 4.2: Internal risk controls](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.3: Performance demonstration](/crosswalks/nist-ai-rmf) [MEASURE 2.5: Validity and reliability](/crosswalks/nist-ai-rmf) [MEASURE 4.3: Performance tracking](/crosswalks/nist-ai-rmf) CSA AICM ? [AIS-05: Application Security Testing](/crosswalks/csa-aicm) [AIS-06: Secure Application Deployment](/crosswalks/csa-aicm) [AIS-07: Application Vulnerability Remediation](/crosswalks/csa-aicm) [AIS-12: Source Code Management](/crosswalks/csa-aicm) [CCC-02: Quality Testing](/crosswalks/csa-aicm) [AIS-04: Secure Application Development Lifecycle](/crosswalks/csa-aicm) [TVM-05: External Library Vulnerabilities](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 11: Agentic AI - Incomplete AI agent evaluation](/crosswalks/ibm-ai-risk-atlas) [IBM 84: Non-Technical - Unrepresentative risk testing](/crosswalks/ibm-ai-risk-atlas) [IBM 85: Non-Technical - Incorrect risk testing](/crosswalks/ibm-ai-risk-atlas) [IBM 86: Non-Technical - Lack of testing diversity](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC3.2: Identify and analyze risks](/crosswalks/soc-2) [CC8.1: Change management](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Conducting pre-deployment testing with documented results and identified issues.** For example, structured hallucination testing, adversarial prompting, safety unit tests, and scenario-based walkthroughs. **Completing risk assessments of identified issues before system deployment.** For example, potential impact analysis, mitigation strategies, and residual risk evaluation. **Obtaining approval sign-offs from designated accountable.** For example, documented rationale for approval decisions and maintained records for review purposes. C002.1 Documentation: Pre-deployment test and approval recordsTest results with identified issues and severity ratings, risk assessment with mitigation decisions, and approval sign-offs with rationale - may be combined in deployment gate documentation or provided as separate documents (e.g., test suite outputs from GitHub Actions/pytest, Jira/Linear tickets with risk assessment and approval, staging environment test reports, deployment checklist with sign-offs). Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal May include ? **Integrating AI system testing into established software development lifecycle (SDLC) gates.** For example, including threat modelling and risk evaluation during design phases, requiring risk evaluation and sign-off at staging or pre-production milestones, aligning with CI/CD or MLOps pipelines, and documenting test artefacts in shared repositories." C002.2 Config: SDLC integrationCI/CD pipeline configuration or workflow showing AI testing integrated as deployment gate - may include GitHub Actions/Jenkins/GitLab CI config files requiring test passage, pull request templates with testing checklists, or branch protection rules enforcing pre-deployment validation. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal **Implementing pre-deployment vulnerability scanning of AI artifacts and dependencies.** For example, scanning AI models and ML libraries for security vulnerabilities, validating runtime behavior for unsafe operations, and analyzing outputs for harmful content before deployment. C002.3 Documentation: Vulnerability scan resultsSecurity scanning tools or CI/CD pipeline showing vulnerability analysis of AI artifacts and dependencies - may include GitHub/GitLab security tab with dependency alerts, Snyk or Dependabot vulnerability findings, pip-audit or safety check terminal output showing CVE scans, model file scanning results, or CI/CD logs showing security scan execution. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal **Testing changes to open-weight model before deployment.** For example, re-running safety evaluations and guardrail test suites after major weights update via fine-tuning or quantization, or inference engine changes and comparing results to the prior model's baseline, and running targeted or automated checks for routine or low-risk changes. C002.4 Documentation: Open-weight model change regression testingDocumented testing approach and results for the model change identifying the prior and new model version, the risk categories tested, and regression results - may include evaluation suite outputs before and after the change, automated check results for low-risk changes, or guardrail test suite pass rates. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C001: Define AI risk taxonomy Source: https://standard.aiuc-1.com/safety/define-ai-risk-taxonomy Establish a risk taxonomy based on system capabilities and deployment context. Keywords Risk Taxonomy Severity Rating Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 9: Risk Management System](/crosswalks/eu-ai-act) ISO 42001 ? [A.5.2: AI system impact assessment process](/crosswalks/iso-42001) [A.5.3: Documentation of AI system impact assessments](/crosswalks/iso-42001) [A.5.4: Assessing AI system impact on individuals or groups of individuals](/crosswalks/iso-42001) [A.5.5: Assessing societal impacts of AI systems](/crosswalks/iso-42001) [4.1: Understanding the organization and its context](/crosswalks/iso-42001) [6.1.1: Actions to address risks and opportunities — General](/crosswalks/iso-42001) [6.1.2: AI risk assessment](/crosswalks/iso-42001) [6.1.3: AI risk treatment](/crosswalks/iso-42001) [6.1.4: AI system impact assessment](/crosswalks/iso-42001) [8.2: AI risk assessment](/crosswalks/iso-42001) [8.3: AI risk treatment](/crosswalks/iso-42001) [8.4: AI system impact assessment](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.3: Risk management processes](/crosswalks/nist-ai-rmf) [GOVERN 1.4: Risk management governance](/crosswalks/nist-ai-rmf) [GOVERN 4.2: Risk documentation](/crosswalks/nist-ai-rmf) [GOVERN 6.1: Third-party risk policies](/crosswalks/nist-ai-rmf) [MANAGE 1.2: Risk prioritization](/crosswalks/nist-ai-rmf) [MANAGE 1.3: Risk response planning](/crosswalks/nist-ai-rmf) [MANAGE 1.4: Residual risk documentation](/crosswalks/nist-ai-rmf) [MAP 1.5: Risk tolerance](/crosswalks/nist-ai-rmf) [MAP 5.1: Impact assessment](/crosswalks/nist-ai-rmf) [MEASURE 1.1: Risk metrics selection](/crosswalks/nist-ai-rmf) [MEASURE 2.10: Privacy risk assessment](/crosswalks/nist-ai-rmf) [MEASURE 2.11: Fairness and bias](/crosswalks/nist-ai-rmf) [MEASURE 3.1: Emergent risk tracking](/crosswalks/nist-ai-rmf) CSA AICM ? [A\&A-05: Audit Management Process](/crosswalks/csa-aicm) [A\&A-06: Remediation](/crosswalks/csa-aicm) [BCR-02: Risk Assessment and Impact Analysis](/crosswalks/csa-aicm) [CEK-07: Encryption Risk Management](/crosswalks/csa-aicm) [DSP-09: Data Protection Impact Assessment](/crosswalks/csa-aicm) [GRC-02: Risk Management Program](/crosswalks/csa-aicm) [MDS-11: Model Failure](/crosswalks/csa-aicm) [CCC-03: Change Management Technology](/crosswalks/csa-aicm) [MDS-12: Open Model Risk Assessment](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 67: Output - Nonconsensual use](/crosswalks/ibm-ai-risk-atlas) [IBM 69: Output - Improper usage](/crosswalks/ibm-ai-risk-atlas) [IBM 83: Non-Technical - Incomplete usage definition](/crosswalks/ibm-ai-risk-atlas) [IBM 84: Non-Technical - Unrepresentative risk testing](/crosswalks/ibm-ai-risk-atlas) [IBM 85: Non-Technical - Incorrect risk testing](/crosswalks/ibm-ai-risk-atlas) [IBM 86: Non-Technical - Lack of testing diversity](/crosswalks/ibm-ai-risk-atlas) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC3.1: Clear objectives for risk assessment](/crosswalks/soc-2) [CC3.2: Identify and analyze risks](/crosswalks/soc-2) [CC5.1: Select and develop control activities](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining risk categories with severity levels and examples based on industry and deployment context.** For example, classifying harmful outputs such as distressed outputs, angry responses, high-risk advice, offensive content, bias, and deception, identifying other high-risk use cases such as safety-critical instructions, legal recommendations, financial advice. **Aligning risk taxonomy with external frameworks and standards.** **Establishing severity grading appropriate to organizational context and risk tolerance.** For example, implementing consistent scoring methodology across risk categories, defining thresholds for flagging and human review. C001.1 Documentation: AI risk taxonomyInternal policy document, risk framework, or taxonomy defining AI risk categories with severity levels and examples specific to deployment context. Example taxonomies to draw upon include NIST AI RMF functions, EU AI Act article 9, ISO42001 controls. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal **Maintaining taxonomy currency with documented change management.** For example, updating based on emerging threats or incidents. C001.2 Documentation: Risk taxonomy reviewsMeeting notes, change log, or review documentation showing annnual reviews of the risk taxonomy. Could include review dates, participants, decisions made (categories added/removed/modified, threshold adjustments), rationale for changes, approvals records, and version history showing taxonomy updates over time with timestamps. Can be standalone or part of broader internal audit/review or change management procedures. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C007: Flag high risk outputs for human review Source: https://standard.aiuc-1.com/safety/flag-high-risk-recommendations Implement an alerting system that flags high-risk outputs for human review. Keywords Human Review Escalation Application Optional Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0020: Generative AI Guardrails](/crosswalks/mitre-atlas) NIST AI RMF ? [GOVERN 3.2: Human-AI oversight](/crosswalks/nist-ai-rmf) [MAP 3.5: Human oversight](/crosswalks/nist-ai-rmf) CSA AICM ? [GRC-15: Human supervision](/crosswalks/csa-aicm) ISO 42001 ? [A.6.1.2: Objectives for responsible development of AI system](/crosswalks/iso-42001) [A.9.3: Objectives for responsible use of AI system](/crosswalks/iso-42001) [A.9.2: Processes for responsible use of AI systems](/crosswalks/iso-42001) OWASP AIVSS ? [Agent Untraceability](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 4: Agentic AI - Over- or under-reliance on AI agents](/crosswalks/ibm-ai-risk-atlas) [IBM 64: Output - Over- or under-reliance](/crosswalks/ibm-ai-risk-atlas) OWASP Agentic Top 10 ? [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [PI1.3: Processing controls](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Defining high-risk output criteria drawing on risk taxonomy.** C007.1 Documentation: Definition of high-risk output criteriaDocument or policy defining high-risk outputs requiring human review - should specify criteria for flagging (e.g. financial advice thresholds, medical/legal/safety domains, reputational harm triggers). Can be standalone or included in existing AI risk taxonomy/AI risk policy. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal **Implementing automated detection mechanisms for high-risk outputs.** For example, using content filtering, risk scoring, or classification models to identify outputs requiring review or flagging. C007.2 Config: High-risk detection mechanismsDetection code, configuration file, or rules engine showing high-risk output filtering - may include keyword lists or regex patterns flagging sensitive topics, scoring logic assigning risk values to recommendations, if/then rules defining high-risk conditions, ML model configuration (e.g., classification thresholds in config.yaml), or API response showing confidence scores with risk thresholds. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal May include ? **Establishing human review workflows for flagged high-risk outputs.** For example, assigning reviewers, defining escalation procedures for complex cases, managing review queues with response time tracking, documenting review decisions, and reviewing workflow effectiveness regularly. C007.3 Documentation: Human review workflowsWorkflow documentation or ticketing system configuration showing human review process for flagged outputs - may include runbook with reviewer assignments and escalation paths, queue management in Jira/Linear/support ticketing with pending review tracking, SLA targets for review response times, or procedure document defining review decision documentation requirements. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C008: Monitor AI risk categories Source: https://standard.aiuc-1.com/safety/monitor-ai-risk-categories Implement monitoring of AI systems across risk categories. Keywords Monitoring High-Risk Outputs Application Optional Frequency Every 12 months Type Detective Capabilities Universal Crosswalks EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) ISO 42001 ? [A.5.4: Assessing AI system impact on individuals or groups of individuals](/crosswalks/iso-42001) [A.6.2.6: AI system operation and monitoring](/crosswalks/iso-42001) [A.9.4: Intended use of the AI system](/crosswalks/iso-42001) [6.1.1: Actions to address risks and opportunities — General](/crosswalks/iso-42001) [6.1.2: AI risk assessment](/crosswalks/iso-42001) [6.1.3: AI risk treatment](/crosswalks/iso-42001) [8.2: AI risk assessment](/crosswalks/iso-42001) [8.3: AI risk treatment](/crosswalks/iso-42001) [9.1: Monitoring, measurement, analysis and evaluation](/crosswalks/iso-42001) [A.9.2: Processes for responsible use of AI systems](/crosswalks/iso-42001) NIST AI RMF ? [GOVERN 1.5: Risk monitoring and review](/crosswalks/nist-ai-rmf) [MANAGE 3.1: Third-party monitoring](/crosswalks/nist-ai-rmf) [MANAGE 4.1: Post-deployment monitoring](/crosswalks/nist-ai-rmf) [MEASURE 2.4: Production monitoring](/crosswalks/nist-ai-rmf) [MEASURE 4.3: Performance tracking](/crosswalks/nist-ai-rmf) CSA AICM ? [GRC-02: Risk Management Program](/crosswalks/csa-aicm) [MDS-11: Model Failure](/crosswalks/csa-aicm) [TVM-03: Vulnerability Remediation Schedule](/crosswalks/csa-aicm) [MDS-12: Open Model Risk Assessment](/crosswalks/csa-aicm) [TVM-07: Vulnerability Remediation Schedule](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Untraceability](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 85: Non-Technical - Incorrect risk testing](/crosswalks/ibm-ai-risk-atlas) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) SOC 2 ? [CC2.1: Use of relevant, quality information](/crosswalks/soc-2) [CC3.2: Identify and analyze risks](/crosswalks/soc-2) [CC7.2: Anomaly monitoring](/crosswalks/soc-2) [CC7.3: Security event evaluation](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Establishing ongoing monitoring of AI outputs across risk categories.** For example, conducting regular evaluations prioritized by risk severity, sampling outputs for review, and tracking system behavior patterns. C008.1 Logs: AI risk monitoringMonitoring dashboard, logging system, or evaluation reports showing ongoing AI output tracking - may include output sampling logs with review results, behavior trace logs showing system patterns, prompt-response logging configuration, evaluation schedules prioritized by risk severity, or monitoring metrics dashboard tracking trends over time. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal May include ? **Maintaining documentation.** For example, recording identified scenarios with clear examples, updating risk taxonomy based on monitoring findings and incidents. C008.2 Documentation: Monitoring findingsDocument or change log showing identified risk scenarios with examples - may include incident reports triggering taxonomy changes, risk scenario database with concrete examples, or version history of risk taxonomy showing updates with rationale linked to monitoring findings. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal **Integrating AI output monitoring with existing security tools.** For example, forwarding alerts and flagged outputs to SIEM platforms, applying standard logging formats (e.g. JSON, syslog) to support automated threat detection workflows. C008.3 Config: Security toolingSIEM integration, log forwarding configuration, or security tool settings showing AI monitoring data flowing into existing security infrastructure - may include Splunk/Datadog/Elastic forwarding rules for AI alerts, JSON/syslog format configuration for AI logs, or SIEM dashboard showing AI-related events alongside other security telemetry. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C003: Prevent harmful outputs Source: https://standard.aiuc-1.com/safety/prevent-harmful-outputs Implement safeguards or technical controls to prevent harmful outputs including distressed outputs, angry responses, high-risk advice, offensive content, bias, and deception. Keywords Harmful Outputs Distressed Angry Advice Offensive Bias Application Mandatory Frequency Every 12 months Type Preventative Capabilities Text-generation Voice-generation Image-generation Crosswalks EU AI Act ? [Article 9: Risk Management System](/crosswalks/eu-ai-act) NIST AI RMF ? [MEASURE 2.11: Fairness and bias](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM09:25 - Misinformation](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) [GRC-11: Bias and Fairness Assessment](/crosswalks/csa-aicm) [GRC-09: Acceptable Use of the AI Service](/crosswalks/csa-aicm) [LOG-15: Output Monitoring](/crosswalks/csa-aicm) [TVM-11: Guardrails](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Goal and Instruction Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 58: Output - Decision bias](/crosswalks/ibm-ai-risk-atlas) [IBM 59: Output - Output bias](/crosswalks/ibm-ai-risk-atlas) [IBM 60: Output - Harmful output](/crosswalks/ibm-ai-risk-atlas) [IBM 62: Output - Toxic output](/crosswalks/ibm-ai-risk-atlas) [IBM 66: Output - Spreading disinformation](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-2.1: Jailbreak](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) CO AI Act ? [6-1-1702: Developer Duties](/crosswalks/co-ai-act) [6-1-1703: Deployer Duties](/crosswalks/co-ai-act) OWASP Agentic Top 10 ? [ASI09 - Human-Agent Trust Exploitation](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC5.1: Select and develop control activities](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing content filtering for harmful output types.** For example, detecting and blocking distressed responses, angry language, offensive content, biased statements, and deceptive information. C003.1 Config: Harmful output filteringContent filtering rules, moderation API configuration, or classifier settings showing detection and blocking logic for harmful output types - may include filtering rules in code, third-party moderation tool configuration (e.g., OpenAI Moderation API, Perspective API), or custom classifier model settings with harm category definitions. Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: LLM output filtering logic Capabilities Text-generation Voice-generation Image-generation **Implementing guardrails for advice generation.** For example, restricting high-risk recommendations in sensitive domains, requiring disclaimers for guidance. C003.2 Config: Guardrails for high-risk adviceSystem prompts, guardrail rules, or domain restrictions showing safety controls on advice generation - may include defensive prompting, domain-specific output restrictions (e.g., medical/legal/financial advice blocklists), or conditional response templates that add warnings for sensitive topics. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Text-generation Voice-generation Image-generation May include ? **Implementing bias detection and mitigation controls.** For example, monitoring for discriminatory patterns, implementing fairness checks in outputs. C003.3 Config: Guardrails for biased outputsDocumentation of bias eval results testing for stereotypical responses across demographic attributes, manual review logs documenting bias assessments, or output filtering rules blocking discriminatory patterns - may include automated fairness evaluation tools or bias monitoring dashboards if implemented. Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: LLM output filtering logic Capabilities Text-generation Voice-generation Image-generation **Evaluating harm mitigation controls using performance metrics.** C003.4 Documentation: Filtering performance benchmarksTest results, metrics dashboard, or evaluation report showing performance of harm controls - may include false positive/negative rates, coverage analysis of test scenarios, benchmark results against harm datasets (e.g., ToxiGen, RealToxicityPrompts), or confusion matrices showing filtering accuracy across harm categories. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Text-generation Voice-generation Image-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C005: Prevent agent-specific high risk outputs Source: https://standard.aiuc-1.com/safety/prevent-other-high-risk-outputs Implement safeguards or technical controls to prevent agent-specific high-risk outputs as defined in risk taxonomy. Keywords High-Risk Outputs Risk Taxonomy Technical Controls Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks EU AI Act ? [Article 9: Risk Management System](/crosswalks/eu-ai-act) NIST AI RMF ? [MANAGE 1.4: Residual risk documentation](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) CSA AICM ? [GRC-09: Acceptable Use of the AI Service](/crosswalks/csa-aicm) [LOG-15: Output Monitoring](/crosswalks/csa-aicm) [TVM-11: Guardrails](/crosswalks/csa-aicm) [STA-10: Primary Service and Contractual Agreement](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Goal and Instruction Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 60: Output - Harmful output](/crosswalks/ibm-ai-risk-atlas) [IBM 61: Output - Harmful code generation](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-2.1: Jailbreak](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC3.2: Identify and analyze risks](/crosswalks/soc-2) [CC5.1: Select and develop control activities](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing detection and blocking mechanisms aligned with organizational risk taxonomy.** For example, deploying filtering based on defined risk categories and severity thresholds. **Implementing response actions for detected risks.** For example, blocking high-severity outputs, flagging medium-risk content for review, logging violations for monitoring and analysis. C005.1 Config: Risk detection and responseFiltering rules, system configuration, or code showing detection logic mapped to AI risk taxonomy categories and corresponding response actions per severity level - may include risk classifiers with block/flag/log rules, content moderation API configuration defining actions by risk type, or defensive prompting. Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: LLM output filtering logic Capabilities Universal May include ? **Establishing escalation procedures for flagged high-risk content.** For example, defining when human review is required and establishing approval workflows for edge cases. C005.2 Documentation: Human review workflowsDocumentation or workflow configuration showing human review and escalation procedures for flagged content - may include runbook defining escalation criteria and review SLAs, workflow diagram showing approval process, or ticketing system configuration (Jira, Linear) with content review queues and assignment rules. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal **Implementing automated real-time interventions.** For example, blocking or modifying outputs based on severity. C005.3 Config: Automated response mechanismsCode or system configuration showing automated response mechanisms - may include logic blocking or modifying outputs based on risk scores, or dynamic warning messages triggered by content flags. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C004: Prevent out-of-scope outputs Source: https://standard.aiuc-1.com/safety/prevent-out-of-scope-outputs Implement safeguards or technical controls to prevent out-of-scope outputs (e.g. political discussion, healthcare advice). Keywords Out-of-Scope Political Discussion Technical Controls Application Mandatory Frequency Every 12 months Type Preventative Capabilities Text-generation Voice-generation Crosswalks EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) NIST AI RMF ? [MAP 2.2: Knowledge limits](/crosswalks/nist-ai-rmf) [MAP 3.4: Operator proficiency](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) [GRC-09: Acceptable Use of the AI Service](/crosswalks/csa-aicm) [LOG-15: Output Monitoring](/crosswalks/csa-aicm) [TVM-11: Guardrails](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Goal and Instruction Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 69: Output - Improper usage](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.1: Direct Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-2.1: Jailbreak](/crosswalks/cisco-ai-security-safety-framework) [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC5.1: Select and develop control activities](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Detecting and blocking out-of-scope requests.** For example, detecting conversations outside intended use cases, blocking prohibited topics, providing redirection messages when users hit boundaries, and escalating or restricting access for repeated violations. C004.1 Config: out-of-scope guardrailsBlocking rules, defensive prompting, or filtering configuration showing how out-of-scope requests are detected and handled - may include topic blocklists, redirection message templates, escalation rules for repeated attempts, or system prompts defining allowed topics. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Text-generation Voice-generation **Tracking out-of-scope violations and updating boundaries.** For example, logging boundary violations, adjusting restrictions based on misuse patterns. C004.2 Logs: Out-of-scope attemptsLogs showing out-of-scope attempts with frequency data. May include documentation of boundary updates made in response to violations, monitoring dashboard of flagged requests, change log showing restriction updates with rationale, or incident reports triggering scope adjustments. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Capabilities Text-generation Voice-generation May include ? **Providing user guidance on system capabilities and limitations.** For example, communicating what the AI system can and cannot do, intended use cases, and topics or requests outside the system's scope. C004.3 Demonstration: User guidance on scopeUser-facing guidance explaining system capabilities and limitations - may include onboarding tooltips or welcome screens, help documentation or FAQs describing intended use, UI warnings when approaching scope boundaries, or published usage guidelines. Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Text-generation Voice-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # C006: Prevent output vulnerabilities Source: https://standard.aiuc-1.com/safety/prevent-output-vulnerabilities Implement safeguards to prevent security vulnerabilities in outputs from impacting users. Keywords Harmful Outputs Code Injection Data Exfiltration Application Mandatory Frequency Every 3 months Type Preventative Capabilities Code-generation Text-generation Voice-generation Crosswalks MITRE ATLAS ? [AML-M0020: Generative AI Guardrails](/crosswalks/mitre-atlas) EU AI Act ? [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) OWASP Top 10 ? [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) [TVM-02: Malware and Malicious Instructions Protection Policy and Procedure](/crosswalks/csa-aicm) [AIS-07: Application Vulnerability Remediation](/crosswalks/csa-aicm) OWASP AIVSS ? [Insecure Agent Critical Systems Interaction](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 61: Output - Harmful code generation](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.4: Multi-Modal Injection and Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.3: Protocol Manipulation](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI05 - Unexpected Code Execution](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC6.8: Malicious software prevention](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Establishing output sanitization and validation procedures before presenting content to users.** For example, encoding or stripping potentially malicious content, validating structured outputs against safe schemas, blocking unsafe URLs, and enforcing secure rendering modes. C006.1 Config: Output sanitizationCode or configuration implementing output sanitization - may include HTML/JavaScript/shell syntax encoding functions, URL validation or rewriting rules blocking unsafe links, schema validation checking structured outputs (JSON/YAML/XML) against whitelists, CSP header configuration, or template rendering with auto-escaping enabled. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation Text-generation Voice-generation **Implementing content handling and security labelling based on trust level.** For example, marking untrusted or third-party content, distinguishing external data from system-generated content, and applying differentiated security controls based on content source. C006.2 Demonstration: Content handling and labelling for untrusted contentUI or code showing trust-based content handling - may include visual indicators marking third-party content (badges, styling, warning icons), metadata tags tracking content source and trust level, or code applying conditional security controls based on content origin (e.g., stricter sanitization for external sources). Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Code-generation Text-generation Voice-generation May include ? **Detecting advanced output-based attack patterns.** For example, identifying prompt injection attempts, model subversion techniques, payloads targeting downstream systems, or obfuscated exploits designed to bypass filters. C006.3 Config: Adversarial output detectionDetection rules or monitoring system identifying advanced attack patterns in outputs - may include pattern matching for prompt injection chains or jailbreak tokens, payload signature scanning detecting command injection or SQL queries, or anomaly detection flagging obfuscated exploits bypassing basic filters. Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: LLM output filtering logic Capabilities Code-generation Text-generation Voice-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Scoping the AIUC-1 audit Source: https://standard.aiuc-1.com/scoping AIUC-1 is designed to cover all the risks that matter for secure adoption of agentic AI. The standard has 6 foundational principles: Data & Privacy, Security, Safety, Reliability, Accountability, Society. Within these principles are 50 requirements with a list of technical & policy controls for each requirement. Not every control applies to every agent. Scoping an AIUC-1 audit answers two questions: * What AI systems are you certifying? * What AIUC-1 requirements must be met? Scoping is completed upfront, with AIUC and your auditor of choice. The output is a defined boundary of AI systems in-scope and the controls they will be audited against. ## Part 1: What AI systems are you certifying? ### Systems in Scope Two questions determine your certification scope: 1. What is your role? Are you an AI agent developer, deployer or both? Which agentic AI systems (or “agents”) are in scope? 2. Only include agentic AI systems in the scope - AIUC-1 does not cover other systems ### Systems in scope: Guidance > **What is the difference between an AI deployer and developer?** > > AI developers build the agentic platform and capabilities, and determine the safe-configuration defaults engineered into agents. AI deployers configure the agentic platform for their own use case, and deploy agents in their own environment. AI developers can be AI deployers and vice versa. Developers are responsible for making sure that secure defaults are in place and documented. Deployers are responsible for configuring AI systems securely given their deployment context. > **Which agents should you certify?** > > AIUC-1 is most relevant for higher risk agentic AI systems that are: > > * **Critical to the business** - for example, customer-facing agents, where brand is on the line > * **Highly capable** - for example, agents with access to sensitive data or access to tools like a CRM or payment processing > * **Subject to legal, compliance, or stakeholder requirements** - for example, an AI recruitment system classified as high-risk under the EU AI Act with legal obligations, which may require third-party validation before deployment > **What constitutes high-risk agents?** > > An agent's risk profile is driven by three factors: > > * **Capabilities (what the agent can do)** - for example, the modalities it supports (text, voice, image, video) and its level of autonomy > * **Architecture (how the agent is built)** - for example, what data it can access or which tools it can call > * **Deployment context (where the agent operates)** - for example, whether it is internally or externally facing, if it’s deployed by a large bank or a small YC company, or designed for consumer or business audiences > **How many agents can I certify?** > > You can certify multiple agents at once, or start with one high-risk agent and expand your scope after your first certification. ***Note**: prioritize agents that are accessible via external API. Programmatic access enables the ability to run a high volume of automated technical tests - required to pass the AIUC-1 audit. Agents only accessible through a platform UI require a more manual evaluation approach which is often costlier.* ## Part 2: What AIUC-1 requirements must be met? ### Statement of Applicability AIUC-1 has 50 requirements. Requirements are either mandatory or optional to earn AIUC-1 certification. Each requirement comes with a list of: 1. **Core controls**: These are controls organizations should implement to pass AIUC-1. If core controls are not demonstrated, organizations must submit alternative evidence demonstrating how they meet the requirement 2. **Supplemental controls**: These are controls organizations may implement in addition and are not required to pass AIUC-1. Instead, organizations opt-in to supplemental controls relevant given the AI agent’s capabilities, architecture, and deployment context. Application of each of these controls depend on your AI system. The output is a Statement of Applicability, signed off by the auditor: the definitive list of requirements and controls your agents are audited against. To guide organizations and auditors, each AIUC-1 requirement is tagged with “Capabilities”, e.g. “universal” or “code-generation”. If an agent does not have the capability, the AIUC-1 requirement should be viewed as optional. ### Statement of Applicability: Guidance 1. **Baseline** - all mandatory requirements and core controls apply by default. 2. **Scoping out** - a mandatory requirement can only be excluded with a documented, legitimate business reason signed off by the auditor. A core control can be excluded if the organization demonstrates alternative ways of meeting the requirement. 3. **Opting in** - organizations can add any number of optional requirements and supplemental controls to their scope. Typical reasons to opt in: 4. **Showcase strengths** - demonstrate gold-standard controls beyond industry standard, in areas where your organization already excels 5. **Meet customer or regulatory demands** - where specific buyers or regulations expect controls beyond the baseline given the deployment context & agent capabilities ***Note**: Scope is disclosed in your certification and audit report. Your audit report shows exactly which requirements and controls were tested - exclusions are documented, and opted-in requirements and controls are provided visibility. Customers reading your report can see precisely what your certification covers.* ### Get Started [Get in touch](/contact) to begin scoping your AIUC-1 audit. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B. Security Source: https://standard.aiuc-1.com/security ## Requirements Third-party testing for security risk B001 · Mandatory Appoint expert third-parties to evaluate system robustness to security risk as defined in the AIUC-1 risk taxonomy at least every 3 months Keywords Adversarial Testing Red Teaming Prompt Injection Jailbreak Capabilities Universal [Open](/security/test-adversarial-robustness) Detect adversarial input B002 · Optional Implement monitoring capabilities to detect and enable responding to adversarial inputs and prompt injection attempts. Keywords Monitor Adversarial Jailbreak Prompt Injection Capabilities Universal [Open](/security/detect-adversarial-input) Manage public release of technical details B003 · Optional Implement controls to prevent over-disclosure of technical information about AI systems and organizational details that could enable adversarial targeting. Keywords Public Disclosure Open-Source External Threats Capabilities Universal [Open](/security/limit-technical-over-disclosure) Prevent AI endpoint scraping B004 · Mandatory Implement safeguards to prevent probing or scraping of external AI endpoints. Keywords Scraping Probing Rate Limiting Query Quotas Zero Trust Capabilities Universal [Open](/security/prevent-ai-endpoint-scraping) Implement real-time input filtering B005 · Optional Implement real-time input filtering using automated moderation tools. Keywords Prompt Injection Jailbreak Adversarial Input Protection Capabilities Text-generation Voice-generation Image-generation [Open](/security/implement-real-time-input-filtering) Prevent unauthorized AI agent actions B006 · Mandatory Implement safeguards to prevent AI agents from performing actions beyond intended scope and authorized privileges. Keywords Access Permissions Agent Permissions Capabilities Automation [Open](/security/enforce-contextual-access-controls) Enforce user access privileges to AI systems B007 · Mandatory Establish and maintain user access controls and admin privileges for AI systems in line with policy. Keywords Access Controls Organizational Policy Capabilities Universal [Open](/security/enforce-ai-access-privileges) Protect AI system deployment environment B008 · Mandatory Implement security measures for AI system deployment environments including encryption, access controls and authorization. Keywords Model Environment Encryption Access Controls Capabilities Universal [Open](/security/protect-model-deployment-environment) Limit output over-exposure B009 · Mandatory Implement output limitations and obfuscation techniques to safeguard against information leakage. Keywords Output Obfuscation Fidelity Reduction Information Leakage Adversarial Use Response Filtering Capabilities Text-generation Voice-generation Image-generation [Open](/security/limit-output-over-exposure) Promote secure patterns in generated code B010 · Mandatory Implement safeguards to promote secure patterns and prevent known vulnerabilities in generated code. Capabilities Code-generation [Open](/security/promote-secure-code-patterns) 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B002: Detect adversarial input Source: https://standard.aiuc-1.com/security/detect-adversarial-input Implement monitoring capabilities to detect and enable responding to adversarial inputs and prompt injection attempts. Keywords Monitor Adversarial Jailbreak Prompt Injection Application Optional Frequency Every 3 months Type Detective Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0003: Model Hardening](/crosswalks/mitre-atlas) [AML-M0015: Adversarial Input Detection](/crosswalks/mitre-atlas) [AML-M0024: AI Telemetry Logging](/crosswalks/mitre-atlas) [AML-M0021: Generative AI Guidelines](/crosswalks/mitre-atlas) EU AI Act ? [Article 15: Accuracy Robustness and Cybersecurity](/crosswalks/eu-ai-act) [Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems](/crosswalks/eu-ai-act) NIST AI RMF ? [GOVERN 1.5: Risk monitoring and review](/crosswalks/nist-ai-rmf) [MEASURE 2.4: Production monitoring](/crosswalks/nist-ai-rmf) [MEASURE 2.7: Security and resilience](/crosswalks/nist-ai-rmf) [MEASURE 3.1: Emergent risk tracking](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM01:25 - Prompt Injection](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [AIS-08: Input Validation](/crosswalks/csa-aicm) [MDS-07: Robustness against Adversarial Attack / Model Hardening](/crosswalks/csa-aicm) [TVM-01: Threat and Vulnerability Management Policy and Procedures](/crosswalks/csa-aicm) [TVM-04: Detection Updates](/crosswalks/csa-aicm) [UEM-09: Anti-Malware Detection and Prevention](/crosswalks/csa-aicm) [TVM-02: Malware and Malicious Instructions Protection Policy and Procedure](/crosswalks/csa-aicm) [AIS-10: API Security](/crosswalks/csa-aicm) [LOG-14: Input Monitoring](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Goal and Instruction Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 41: Inference - Evasion attack](/crosswalks/ibm-ai-risk-atlas) [IBM 43: Inference - Jailbreaking](/crosswalks/ibm-ai-risk-atlas) [IBM 46: Inference - Prompt injection attack](/crosswalks/ibm-ai-risk-atlas) [IBM 49: Inference - Context overload attack](/crosswalks/ibm-ai-risk-atlas) [IBM 52: Inference - Indirect instructions attack](/crosswalks/ibm-ai-risk-atlas) [IBM 53: Inference - Social hacking attack](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.1: Direct Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-1.2: Indirect Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-1.4: Multi-Modal Injection and Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-2.1: Jailbreak](/crosswalks/cisco-ai-security-safety-framework) [AITech-3.1: Masquerading / Obfuscation / Impersonation](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.3: Protocol Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-5.1: Memory System Persistence](/crosswalks/cisco-ai-security-safety-framework) [AITech-5.2: Configuration Persistence](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.2: Memory System Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.4: Token Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.1: Model or Agentic System Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.2: Detection Evasion](/crosswalks/cisco-ai-security-safety-framework) [AITech-11.2: Model-Selective Evasion](/crosswalks/cisco-ai-security-safety-framework) [AITech-17.1: Sensor Spoofing](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI01 - Agent Goal Hijack](/crosswalks/owasp-agentic-top-10) [ASI06 - Memory and Context Poisoning](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC6.6: Protection against external threats](/crosswalks/soc-2) [CC6.8: Malicious software prevention](/crosswalks/soc-2) [CC7.2: Anomaly monitoring](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Establishing detection and alerting.** For example, implementing monitoring for prompt injection patterns, jailbreak techniques, adversarial input attempts, and exceeding rate limits, configuring alerts and threat notifications for suspicious activities. B002.1 Config: Adversarial input detection and alertingMonitoring system, SIEM, or detection code showing rules and alerts for adversarial inputs - may include prompt injection detection patterns, jailbreak technique signatures, rate limit monitoring with threshold alerts, or notification configurations (Slack, PagerDuty, email) Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Implementing incident logging and response procedures.** For example, logging suspected adversarial attacks with relevant context, escalating to designated personnel based on severity, and documenting response actions in a centralized system. B002.2 Logs: Adversarial incident and responseIncident management system or logs showing adversarial attack handling - may include log entries with timestamps and user/session context, escalation runbooks defining severity thresholds, or incident tickets in Jira/PagerDuty/ServiceNow documenting response actions and workflows. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Engineering Tooling Capabilities Universal **Maintaining detection effectiveness through quarterly reviews.** For example, updating detection rules based on emerging adversarial techniques, analyzing incident patterns and documenting system improvements. B002.3 Documentation: Updates to detection configQuarterly review documentation showing detection updates - for example, review meeting notes with incident pattern analysis, updated detection rules with version history, or tracking records showing rule improvements (e.g. GitHub/Jira tickets). Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Internal processes Capabilities Universal May include ? **Implementing adversarial input detection prior to AI model processing where feasible.** For example, using pre-processing filters to flag likely threats before model processing. B002.4 Config: Pre-processing adversarial detectionPre-processing filtering logic or gateway - may include pattern-matching or heuristic code checking inputs before model processing, WAF or API gateway rules blocking adversarial patterns, or IP-based filtering. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Integrating adversarial input detection into existing security operations tooling.** For example, forwarding flagged inputs to SIEM platforms, correlating detection with authentication and network logs, enabling SOC teams to triage AI-related security events. B002.5 Config: AI security alertsSIEM platform, SOC tooling, or log forwarding configuration showing adversarial detection integration - may include Splunk/Datadog/Elastic SIEM ingesting AI adversarial alerts, correlation rules linking AI events with authentication or network logs, SOC dashboard displaying AI security event triage, or code forwarding flagged inputs to security platforms. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B007: Enforce user access privileges to AI systems Source: https://standard.aiuc-1.com/security/enforce-ai-access-privileges Establish and maintain user access controls and admin privileges for AI systems in line with policy. Keywords Access Controls Organizational Policy Application Mandatory Frequency Every 3 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0005: Control Access to AI Models and Data at Rest](/crosswalks/mitre-atlas) [AML-M0019: Control Access to AI Models and Data in Production](/crosswalks/mitre-atlas) OWASP Top 10 ? [LLM02:25 - Sensitive Information Disclosure](/crosswalks/owasp-top-10) [LLM06:25 - Excessive Agency](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [DSP-07: Data Protection by Design and Default](/crosswalks/csa-aicm) [DSP-08: Data Privacy by Design and Default](/crosswalks/csa-aicm) [IAM-01: Identity and Access Management Policy and Procedures](/crosswalks/csa-aicm) [IAM-02: Strong Password Policy and Procedures](/crosswalks/csa-aicm) [IAM-03: Identity Inventory](/crosswalks/csa-aicm) [IAM-04: Separation of Duties](/crosswalks/csa-aicm) [IAM-05: Least Privilege](/crosswalks/csa-aicm) [IAM-06: User Access Provisioning](/crosswalks/csa-aicm) [IAM-07: User Access Changes and Revocation](/crosswalks/csa-aicm) [IAM-08: User Access Review](/crosswalks/csa-aicm) [IAM-09: Segregation of Privileged Access Roles](/crosswalks/csa-aicm) [IAM-10: Management of Privileged Access Roles](/crosswalks/csa-aicm) [IAM-13: Uniquely Identifiable Users](/crosswalks/csa-aicm) [IAM-14: Strong Authentication](/crosswalks/csa-aicm) [IAM-15: Passwords and Secrets Management](/crosswalks/csa-aicm) [IAM-16: Authorization Mechanisms](/crosswalks/csa-aicm) [IAM-17: Knowledge Access Control - Need to Know](/crosswalks/csa-aicm) [IAM-18: Output Modification and Special Authorization](/crosswalks/csa-aicm) [LOG-04: Audit Logs Access and Accountability](/crosswalks/csa-aicm) [LOG-09: Log Protection](/crosswalks/csa-aicm) [LOG-12: Access Control Logs](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 7: Agentic AI - Unauthorized use](/crosswalks/ibm-ai-risk-atlas) [IBM 8: Agentic AI - Exploit trust mismatch](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-14.1: Unauthorized Access](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI02 - Tool Misuse and Exploitation](/crosswalks/owasp-agentic-top-10) [ASI03 - Identity and Privilege Abuse](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC5.2: General controls over technology](/crosswalks/soc-2) [CC6.1: Logical access security](/crosswalks/soc-2) [CC6.2: User registration and deprovisioning](/crosswalks/soc-2) [CC6.3: Role-based access management](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing system-level access controls tailored to AI systems.** For example, using role-based or attribute-based access to restrict access to model configuration, training datasets, tool-calling capabilities, or prompt logs, based on job function and system sensitivity. **Restricting administrative and configuration privileges to authorized personnel.** For example, limiting ability to alter system behavior, tools, or models. B007.1 Config: User access controlsIAM platform, permission files, or admin panel showing role-based or attribute-based access restrictions for AI system resources (model configurations, training datasets, tool-calling capabilities, prompt logs) - may include IAM role assignments, permission policies, or authorization code validating user permissions before accessing sensitive AI components. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal **Conducting access reviews and updates at least quarterly.** For example, validating access assignments, updating based on policy or role changes, documenting access changes with AI-specific context (e.g. model access justification, changes to agent capability boundaries, or access to sensitive prompt/response history). B007.2 Documentation: Access reviewsQuarterly access review documentation - may include access review meeting notes, tracking records of access changes with justifications, or reports documenting role changes and access modifications based on policy updates. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B006: Prevent unauthorized AI agent actions Source: https://standard.aiuc-1.com/security/enforce-contextual-access-controls Implement safeguards to prevent AI agents from performing actions beyond intended scope and authorized privileges. Keywords Access Permissions Agent Permissions Application Mandatory Frequency Every 12 months Type Preventative Capabilities Automation Crosswalks NIST AI RMF ? [MAP 2.1: Task definition](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [AIS-11: Agents Security Boundaries](/crosswalks/csa-aicm) [IAM-19: Agent Access Restriction](/crosswalks/csa-aicm) [DSP-07: Data Protection by Design and Default](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Access Control Violation](/crosswalks/owasp-aivss) [Agent Orchestration and Multi-Agent Exploitation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 5: Agentic AI - Misaligned actions](/crosswalks/ibm-ai-risk-atlas) [IBM 7: Agentic AI - Unauthorized use](/crosswalks/ibm-ai-risk-atlas) [IBM 8: Agentic AI - Exploit trust mismatch](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.3: Goal Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-3.1: Masquerading / Obfuscation / Impersonation](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.1: Agent Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-5.2: Configuration Persistence](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.2: Memory System Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-14.2: Abuse of Delegated Authority](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI01 - Agent Goal Hijack](/crosswalks/owasp-agentic-top-10) [ASI02 - Tool Misuse and Exploitation](/crosswalks/owasp-agentic-top-10) [ASI03 - Identity and Privilege Abuse](/crosswalks/owasp-agentic-top-10) [ASI05 - Unexpected Code Execution](/crosswalks/owasp-agentic-top-10) [ASI07 - Insecure Inter-Agent Communication](/crosswalks/owasp-agentic-top-10) [ASI10 - Rogue Agents](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC5.1: Select and develop control activities](/crosswalks/soc-2) [CC6.3: Role-based access management](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing technical restrictions that limit agent capabilities to authorized scope.** For example, restricting agent access to approved backend services, APIs and MCP servers, enforcing network segmentation or API gateway rules, or implementing service-level authorization preventing access to sensitive systems. B006.1 Config: Agent service access restrictionsConfiguration showing technical limitations on agent backend access - may include API gateway rules restricting accessible services, network policies defining allowed endpoints, MCP server allowlist or registration configuration restricting which MCP servers and tools the agent may connect to, service-level authorization configuration, or architecture diagram showing agent isolation boundaries including MCP server placement and network segmentation. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Automation **Deploying monitoring and alerting for agent actions that exceed security boundaries.** For example, logging all agent service interactions, alerting on access attempts to unauthorized systems or APIs, or anomaly detection flagging unusual connection patterns. B006.2 Config: Agent security monitoring and alertingImplementation of monitoring configuration tracking agent security-relevant actions - may include logging setup capturing agent service calls and authentication attempts, alert rules for unauthorized system access, security monitoring dashboard showing agent infrastructure interactions, or example logs demonstrating boundary violations are detected. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Logs Capabilities Automation May include ? **Implementing additional safeguards to contain runtime risk.** For example, enabling sandboxed execution environments with configurable filesystem, network, and credential restrictions for agent-executed code and first-party MCP servers, monitoring MCP tool definitions for unauthorized changes after initial approval, providing pre-execution authorization hooks that verify runtime tool calls against defined policy before execution proceeds, or scanning agent configuration artifacts such as hooks, skills and rules for prompt injection or unauthorized behavior. B006.3 Config: Execution-level safeguardsConfiguration or code demonstrating runtime containment controls — may include sandbox or container configuration showing configurable filesystem, network, and credential restrictions for agent code execution environments and first-party MCP servers, tool definition integrity controls showing how unauthorized post-approval changes are detected, pre-execution hook or policy engine configuration showing tool calls are verified at runtime, or scanning of agent configuration artifacts for prompt injection or malicious patterns. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Automation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B005: Implement real-time input filtering Source: https://standard.aiuc-1.com/security/implement-real-time-input-filtering Implement real-time input filtering using automated moderation tools. Keywords Prompt Injection Jailbreak Adversarial Input Protection Application Optional Frequency Every 12 months Type Detective Capabilities Text-generation Voice-generation Image-generation Crosswalks OWASP Top 10 ? [LLM01:25 - Prompt Injection](/crosswalks/owasp-top-10) [LLM04:25 - Data and Model Poisoning](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) MITRE ATLAS ? [AML-M0015: Adversarial Input Detection](/crosswalks/mitre-atlas) [AML-M0021: Generative AI Guidelines](/crosswalks/mitre-atlas) NIST AI RMF ? [MEASURE 2.7: Security and resilience](/crosswalks/nist-ai-rmf) CSA AICM ? [LOG-14: Input Monitoring](/crosswalks/csa-aicm) [AIS-08: Input Validation](/crosswalks/csa-aicm) [AIS-15: Prompt Differentiation](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Goal and Instruction Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 50: Inference - Direct instructions attack](/crosswalks/ibm-ai-risk-atlas) [IBM 53: Inference - Social hacking attack](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.2: Indirect Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.4: Token Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-11.2: Model-Selective Evasion](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI01 - Agent Goal Hijack](/crosswalks/owasp-agentic-top-10) [ASI06 - Memory and Context Poisoning](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC8.1: Change management](/crosswalks/soc-2) [PI1.2: Input completeness and accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Integrating automated moderation tools to filter inputs before they reach the foundation model.** For example, integrating third-party moderation APIs, implementing custom filtering rules, configuring blocking or warning actions for flagged content, and establishing confidence thresholds based on risk category and severity B005.1 Config: Input filteringModeration tool integration showing API configuration, filtering rules, action settings (block/warn/modify), and confidence thresholds for different violation categories - this could be screenshots of configuration files, admin dashboard settings, or API integration code. Example moderation tools: OpenAI Moderation API, Claude content filtering, VirtueAI/Hive/Spectrum Labs Category [Technical Implementation](/evidence/technical-implementation) Typical location Eng: User LLM input filtering logic Engineering Tooling Capabilities Text-generation Voice-generation Image-generation May include ? **Documenting the moderation logic and rationale.** For example, explaining chosen moderation tools, threshold justifications, and decision criteria for different risk categories. B005.2 Documentation: Input moderation approachDocument explaining moderation approach including tool selection rationale, threshold settings with justifications, action logic for different violation types, and examples of how different input categories are handled. Category [Technical Implementation](/evidence/technical-implementation) Typical location Internal processes Engineering Practice Capabilities Text-generation Voice-generation Image-generation **Providing feedback to users when inputs are blocked.** B005.3 Demonstration: Warning for blocked inputsUser-facing messages or UI flows showing how blocked inputs are communicated to users - this could be error messages, warning dialogs, or alternative suggestions provided when content is filtered. Category [Technical Implementation](/evidence/technical-implementation) Typical location Product Capabilities Text-generation Voice-generation Image-generation **Logging flagged prompts for analysis and refinement of filters, while ensuring compliance with privacy obligations.** B005.4 Logs: Input filteringLogging system showing how flagged inputs are captured, what metadata is included/excluded for privacy, retention policies, and audit trail - may include privacy documentation explaining logging disclosures to users. Category [Technical Implementation](/evidence/technical-implementation) Typical location Logs Capabilities Text-generation Voice-generation Image-generation **Periodically evaluating filter performance and adjusting thresholds accordingly.** For example, accuracy, latency, false positives/negatives. B005.5 Documentation: Input filter performanceReport or dashboard showing analysis of filter performance metrics (false positives, false negatives, accuracy, latency) and documented threshold adjustments made based on performance data - should include timestamps and rationale for changes. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Text-generation Voice-generation Image-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B009: Limit output over-exposure Source: https://standard.aiuc-1.com/security/limit-output-over-exposure Implement output limitations and obfuscation techniques to safeguard against information leakage. Keywords Output Obfuscation Fidelity Reduction Information Leakage Adversarial Use Response Filtering Application Mandatory Frequency Every 12 months Type Preventative Capabilities Text-generation Voice-generation Image-generation Crosswalks MITRE ATLAS ? [AML-M0002: Passive AI Output Obfuscation](/crosswalks/mitre-atlas) NIST AI RMF ? [MEASURE 2.10: Privacy risk assessment](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM02:25 - Sensitive Information Disclosure](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) [LLM09:25 - Misinformation](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 47: Inference - Prompt leaking](/crosswalks/ibm-ai-risk-atlas) [IBM 74: Output - Revealing confidential information](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.1: Membership Inference](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.2: Data Exfiltration / Exposure](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.3: Information Disclosure](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.4: Prompt/Meta Extraction](/crosswalks/cisco-ai-security-safety-framework) [AITech-10.2: Model Inversion](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC8.1: Change management](/crosswalks/soc-2) [PI1.4: Output delivery accuracy](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Reducing or limiting the number of results shown in outputs to relevant only to balance security and utility.** For example, character limits, limits on inference time. B009.1 Config: Output volume limitsCode or configuration implementing output restrictions - may include character or token limits, inference time limits, result count restrictions, or timeout configurations preventing excessive output. Can be demonstrated by product demo showing system timeout when requesting output exceeding limits. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Product Capabilities Text-generation Voice-generation Image-generation May include ? **Providing user-facing notices or documentation about output limitations.** B009.2 Demonstration: User output noticesProduct interface showing user notices about output limitations - may include messages indicating truncated or suppressed outputs for security or privacy reasons, user documentation explaining limitation policies, or help articles describing output restrictions. Category [Operational Practices](/evidence/operational-practices) Typical location Product Capabilities Text-generation Voice-generation Image-generation **Limiting the fidelity of model outputs in certain use cases.** For example, applying output rounding, threshold bands, or obfuscation techniques to reduce the risk of model inversion. B009.3 Config: Output precision controlsCode implementing output fidelity limitations - may include rounding logic for numerical outputs, threshold bands reducing precision, or obfuscation techniques preventing model inversion, precision-sensitive data disclosure, or adversarial model extraction attacks. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Text-generation Voice-generation Image-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B003: Manage public release of technical details Source: https://standard.aiuc-1.com/security/limit-technical-over-disclosure Implement controls to prevent over-disclosure of technical information about AI systems and organizational details that could enable adversarial targeting. Keywords Public Disclosure Open-Source External Threats Application Optional Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0000: Limit Public Release of Information](/crosswalks/mitre-atlas) [AML-M0001: Limit Model Artifact Release](/crosswalks/mitre-atlas) OWASP Top 10 ? [LLM02:25 - Sensitive Information Disclosure](/crosswalks/owasp-top-10) [LLM07:25 - System Prompt Leakage](/crosswalks/owasp-top-10) CSA AICM ? [AIS-09: Output Validation](/crosswalks/csa-aicm) [AIS-15: Prompt Differentiation](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 42: Inference - Extraction attack](/crosswalks/ibm-ai-risk-atlas) [IBM 47: Inference - Prompt leaking](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-10.2: Model Inversion](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC6.6: Protection against external threats](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Documenting limitations on technical information release.** For example, limiting public disclosure of model architectures, algorithms, training data details, system configurations, and performance metrics, requiring approval before sharing technical specifications or implementation details. **Controlling organizational information to balance transparency with security.** For example, limiting disclosure of AI team details, development timelines, and other information that could reveal technical capabilities, reviewing public communications for sensitive information. B003.1 Documentation: Technical information disclosure guidelinesPolicy document, SOP, or handbook section defining limitations and approval requirements for publicly sharing AI system technical details - may include communication policy limiting disclosure of model architectures or configurations, engineering handbook with approval workflows for technical specifications, or internal procedures controlling release of organizational AI information. Category [Operational Practices](/evidence/operational-practices) Typical location Internal policies Capabilities Universal May include ? **Establishing approval processes.** For example, requiring designated review for public content referencing AI capabilities in e.g. publications, presentations, and marketing materials, and documenting approved disclosures with business justification. B003.2 Documentation: Public disclosure approval recordsApproval email, ticket, or review documentation for public AI communications - may include approval requests in email or Jira/Slack for blog posts or press releases, marketing review records for AI capability disclosures, or periodic security review logs for public-facing AI content. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B004: Prevent AI endpoint scraping Source: https://standard.aiuc-1.com/security/prevent-ai-endpoint-scraping Implement safeguards to prevent probing or scraping of external AI endpoints. Keywords Scraping Probing Rate Limiting Query Quotas Zero Trust Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0003: Model Hardening](/crosswalks/mitre-atlas) [AML-M0004: Restrict Number of AI Model Queries](/crosswalks/mitre-atlas) EU AI Act ? [Article 15: Accuracy Robustness and Cybersecurity](/crosswalks/eu-ai-act) NIST AI RMF ? [MEASURE 2.7: Security and resilience](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM02:25 - Sensitive Information Disclosure](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) [LLM10:25 - Unbounded Consumption](/crosswalks/owasp-top-10) CSA AICM ? [AIS-10: API Security](/crosswalks/csa-aicm) [UEM-01: Endpoint Devices Policy and Procedures](/crosswalks/csa-aicm) [UEM-05: Endpoint Management](/crosswalks/csa-aicm) [UEM-09: Anti-Malware Detection and Prevention](/crosswalks/csa-aicm) [UEM-10: Software Firewall](/crosswalks/csa-aicm) [UEM-11: Data Loss Prevention](/crosswalks/csa-aicm) [UEM-14: Third-Party Endpoint Security Posture](/crosswalks/csa-aicm) [TVM-06: Penetration Testing](/crosswalks/csa-aicm) OWASP AIVSS ? [Agentic AI Tool Misuse](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 42: Inference - Extraction attack](/crosswalks/ibm-ai-risk-atlas) [IBM 47: Inference - Prompt leaking](/crosswalks/ibm-ai-risk-atlas) [IBM 56: Inference - Attribute inference attack](/crosswalks/ibm-ai-risk-atlas) [IBM 57: Inference - Membership inference attack](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.4: Multi-Modal Injection and Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-8.2: Data Exfiltration / Exposure](/crosswalks/cisco-ai-security-safety-framework) [AITech-10.1: Model Extraction](/crosswalks/cisco-ai-security-safety-framework) [AITech-10.2: Model Inversion](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) [AITech-13.1: Disruption of Availability](/crosswalks/cisco-ai-security-safety-framework) [AITech-13.2: Cost Harvesting / Repurposing](/crosswalks/cisco-ai-security-safety-framework) SOC 2 ? [CC6.6: Protection against external threats](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing systems distinguishing between high-volume legitimate usage and adversarial behavior.** For example, using behavioral analytics and user profiling to calibrate detection thresholds and prevent false positives against trusted users. B004.1 Config: Anomalous usage detectionAnomaly detection system or configuration file - may include behavioral analytics dashboard (Datadog, Elastic, Splunk) with user scoring rules, rate limiting configuration with tier-based thresholds (config.yaml, API gateway settings), user allowlists or reputation tables, or code implementing session-based threshold logic. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Engineering Code Capabilities Universal **Implementing rate limiting and query restrictions.** For example, establishing per-user quotas to prevent model extraction, blocking excessive query patterns, implementing progressive restrictions for suspicious behavior, or using economic disincentives for high-volume usage. B004.2 Config: Rate limitsRate limiting configuration for API endpoints - may include per-user quota settings, query throttling rules, progressive restriction policies, WAF configuration (Cloudflare, AWS WAF, Azure Application Gateway) with blocking rules for excessive patterns, or pricing tier settings implementing usage-based cost increases. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Tooling Capabilities Universal **Conducting simulated external attack testing of AI endpoints.** For example, performing automated attack simulations, testing endpoint protection effectiveness against high-volume and distributed attacks, and documenting methodologies appropriate to organizational threat profile. B004.3 Report: External pentest of AI endpointsThird-party penetration test report for AI endpoints including attack simulations tested (e.g. scraping attempts, brute force, reconnaissance), rate limiting and endpoint protection validation, distributed attack testing, test methodology, and findings on protection effectiveness. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal **Maintaining endpoint security through remediation.** For example, tracking identified vulnerabilities, implementing protective measures based on testing outcomes, and regularly updating endpoint defenses and detection thresholds. B004.4 Documentation: Vulnerability remediationIssue tracking system (GitHub, Jira, Linear) showing endpoint vulnerability lifecycle - must include vulnerability identification, remediation proposal, implementation, and production deployment with timestamps and approval records. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Practice Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B010: Promote secure patterns in generated code Source: https://standard.aiuc-1.com/security/promote-secure-code-patterns Implement safeguards to promote secure patterns and prevent known vulnerabilities in generated code. Application Mandatory Frequency Every 12 months Type Preventative Capabilities Code-generation Crosswalks SOC 2 ? [CC5.2: General controls over technology](/crosswalks/soc-2) [CC6.8: Malicious software prevention](/crosswalks/soc-2) [CC7.1: Vulnerability detection and monitoring](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Implementing safeguards to promote secure patterns for common web vulnerability classes in generated code.** For example, defaulting to parameterized queries or safe ORM patterns for database access, applying output encoding and contextual escaping to prevent cross-site scripting, or enforcing HTTPS/TLS in generated network and API code. B010.1 Config: Secure defaults for common vulnerability classesCode, configuration, or system prompt excerpt demonstrating secure defaults for common vulnerability classes, may include system prompt guidance directing the model toward parameterized queries and safe ORM patterns, framework scaffolding that applies output encoding by default, or sample generations on database or UI prompts showing safe patterns used without explicit user request. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation **Implementing safeguards to promote secure patterns for authentication and authorization in generated code.** For example, defaulting to vetted authentication libraries or patterns on auth-related prompts, applying access control checks and least-privilege patterns by default, or avoiding generation of custom cryptographic or authentication primitives. B010.2 Config: Secure defaults for authentication and authorizationCode, configuration, or system prompt excerpt demonstrating secure defaults for auth, may include system prompt guidance directing the model toward established auth libraries (e.g., Auth0, Clerk, framework-native auth), or sample generations on auth-related prompts showing vetted patterns rather than custom implementations. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation **Implementing safeguards to prevent dependency risks in generated code.** For example, avoiding wildcard version specifications (e.g., \* or latest) in generated manifests, verifying that suggested packages exist in their respective registries before including them in generated code, or applying guidance that avoids known-abandoned or typosquatted packages. B010.3 Config: Safe dependency specification in generated codeCode, configuration, or system prompt excerpt demonstrating safe dependency specification, may include system prompt guidance directing the model toward pinned versions and verified packages, registry validation logic checking generated package names against known registries, or sample generations showing appropriate version specifications across ecosystems. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation May include ? **Implementing safeguards to promote secure defaults for session management in generated code.** For example, applying HttpOnly, Secure, and SameSite flags to session cookies by default, or defaulting to CSRF protections on state-changing endpoints. B010.4 Config: Secure session and cookie defaultsCode, configuration, or sample generations showing secure session and cookie defaults in generated code, may include system prompt guidance, framework scaffolding configuration, or sample generations on session-management-related prompts. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation **Implementing safeguards to promote defensive programming patterns in generated code.** For example, defaulting to input validation on user-supplied data, applying safe error handling that avoids exposing stack traces or internal details, or defaulting to rate limiting on generated public-facing endpoints. B010.5 Config: Input validation and error handling defaultsCode, configuration, or sample generations showing input validation and error handling defaults, may include system prompt guidance, framework scaffolding patterns, or sample generations on prompts generating user-facing endpoints. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Code-generation **Implementing safeguards to prevent generated logging code from capturing secrets or personal information.** For example, defaulting logging patterns to exclude sensitive fields, or applying guidance that avoids logging full request bodies or auth headers. B010.6 Config: Logging defaults in generated codeCode, configuration, or sample generations showing safe logging defaults in generated code, may include system prompt guidance, logging templates used in scaffolding, or sample generations on logging-related prompts. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Logs Capabilities Code-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B008: Protect AI system deployment environment Source: https://standard.aiuc-1.com/security/protect-model-deployment-environment Implement security measures for AI system deployment environments including encryption, access controls and authorization. Keywords Model Environment Encryption Access Controls Application Mandatory Frequency Every 12 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0005: Control Access to AI Models and Data at Rest](/crosswalks/mitre-atlas) [AML-M0012: Encrypt Sensitive Information](/crosswalks/mitre-atlas) [AML-M0019: Control Access to AI Models and Data in Production](/crosswalks/mitre-atlas) EU AI Act ? [Article 15: Accuracy Robustness and Cybersecurity](/crosswalks/eu-ai-act) OWASP Top 10 ? [LLM07:25 - System Prompt Leakage](/crosswalks/owasp-top-10) CSA AICM ? [AIS-06: Secure Application Deployment](/crosswalks/csa-aicm) [AIS-14: AI Cache Protection](/crosswalks/csa-aicm) [CEK-01: Encryption and Key Management Policy and Procedures](/crosswalks/csa-aicm) [CEK-03: Data Encryption](/crosswalks/csa-aicm) [CEK-04: Encryption Algorithm](/crosswalks/csa-aicm) [CEK-19: Key Compromise](/crosswalks/csa-aicm) [CEK-10: Key Generation](/crosswalks/csa-aicm) [CEK-11: Key Purpose](/crosswalks/csa-aicm) [CEK-12: Key Rotation](/crosswalks/csa-aicm) [CEK-13: Key Revocation](/crosswalks/csa-aicm) [CEK-14: Key Destruction](/crosswalks/csa-aicm) [CEK-15: Key Activation](/crosswalks/csa-aicm) [CEK-16: Key Suspension](/crosswalks/csa-aicm) [CEK-17: Key Deactivation](/crosswalks/csa-aicm) [CEK-18: Key Archival](/crosswalks/csa-aicm) [CEK-20: Key Recovery](/crosswalks/csa-aicm) [CEK-21: Key Inventory Management](/crosswalks/csa-aicm) [IAM-04: Separation of Duties](/crosswalks/csa-aicm) [IAM-14: Strong Authentication](/crosswalks/csa-aicm) [MDS-01: Training Pipeline Security](/crosswalks/csa-aicm) [MDS-02: Model Artifact Scanning](/crosswalks/csa-aicm) [MDS-08: Model Integrity Checks](/crosswalks/csa-aicm) [UEM-08: Storage Encryption](/crosswalks/csa-aicm) [AIS-02: Application Security Baseline Requirements](/crosswalks/csa-aicm) [DSP-07: Data Protection by Design and Default](/crosswalks/csa-aicm) [MDS-09: Model Signing/Ownership Verification](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Memory and Context Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 7: Agentic AI - Unauthorized use](/crosswalks/ibm-ai-risk-atlas) [IBM 29: Training Data - Data poisoning](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.3: Goal Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-6.1: Training Data Poisoning](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.1: Reasoning Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-10.1: Model Extraction](/crosswalks/cisco-ai-security-safety-framework) [AITech-11.1: Environment-Aware Evasion](/crosswalks/cisco-ai-security-safety-framework) [AITech-14.1: Unauthorized Access](/crosswalks/cisco-ai-security-safety-framework) [AITech-16.1: Eavesdropping](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI03 - Identity and Privilege Abuse](/crosswalks/owasp-agentic-top-10) [ASI04 - Agentic Supply Chain Vulnerabilities](/crosswalks/owasp-agentic-top-10) [ASI05 - Unexpected Code Execution](/crosswalks/owasp-agentic-top-10) [ASI07 - Insecure Inter-Agent Communication](/crosswalks/owasp-agentic-top-10) [ASI10 - Rogue Agents](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC5.2: General controls over technology](/crosswalks/soc-2) [CC6.1: Logical access security](/crosswalks/soc-2) [CC6.6: Protection against external threats](/crosswalks/soc-2) [CC6.7: Secure transmission and removal](/crosswalks/soc-2) [CC6.8: Malicious software prevention](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Enforcing caller authentication across API endpoints and agentic interfaces.** For example, applying scoped API tokens or signed requests for model API access; enforcing OAuth 2.0 or OIDC token validation with appropriate scoping for MCP server connections; implementing mutual authentication for agent-to-agent interfaces. B008.1 Config: API and agentic interface authenticationConfiguration or code showing caller authentication controls - may include scoped API token or signed request configuration for model API endpoints, OAuth token scoping or OIDC validation middleware for MCP server connections, or mutual authentication configuration for agent-to-agent interfaces (e.g. A2A protocol authentication config). Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Securing data in transit across model API endpoints and agentic interfaces.** For example, enforcing TLS for all model API endpoint traffic, MCP server connections, and agent-to-agent communication channels; implementing credential rotation policies for long-lived service connections. B008.2 Config: API and agentic interface transport securityConfiguration or code showing transport security controls - may include TLS/HTTPS certificate configuration for model API endpoints, MCP server traffic, or agent-to-agent connections, or credential rotation policy documentation for service-level MCP or A2A connections. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal May include ? **Verifying model integrity before and during deployment.** For example, using cryptographic checksums or signed artifacts to detect tampering, scanning model files for malicious payloads. B008.5 Config: Model integrity verificationDeployment pipeline or code implementing model integrity checks - may include cryptographic checksum verification, model artifact signature validation, hash comparison before deployment, model scanning configuration detecting malicious payloads (e.g. Pickle, ONNX) using tools like Cisco's pickle-fuzzer, Trail of Bit's Fickling, or deployment logs recording model version hashes. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Enforcing data integrity across agentic interfaces.** For example, implementing cryptographic message signing for agent-to-agent communication; applying schema validation and input sanitization to MCP tool call inputs and outputs. B008.3 Config: Agentic interface data integrityConfiguration or code showing data integrity controls for agentic interfaces - may include cryptographic message signing configuration for agent-to-agent interfaces (e.g. signed agent cards), or schema validation configuration applied to MCP tool call inputs and outputs. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal **Securing model hosting environments.** For example, using up-to-date and minimal container images, scanning for known vulnerabilities in dependencies and base images, and applying infrastructure-level isolation techniques based on risk level (e.g. container namespaces, VM separation, or dedicated GPU access). B008.4 Config: Model hosting securityContainer configuration or infrastructure setup for model hosting - may include Dockerfile with minimal base images and up-to-date dependencies, vulnerability scanning results from Trivy or Snyk for container images, or infrastructure configuration showing isolation techniques (container namespaces, VM separation, network policies, dedicated GPU allocation). Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # B001: Third-party testing for security risk Source: https://standard.aiuc-1.com/security/test-adversarial-robustness Appoint expert third-parties to evaluate system robustness to security risk as defined in the AIUC-1 risk taxonomy at least every 3 months Keywords Adversarial Testing Red Teaming Prompt Injection Jailbreak Application Mandatory Frequency Every 3 months Type Preventative Capabilities Universal Crosswalks MITRE ATLAS ? [AML-M0003: Model Hardening](/crosswalks/mitre-atlas) [AML-M0004: Restrict Number of AI Model Queries](/crosswalks/mitre-atlas) NIST AI RMF ? [GOVERN 4.3: Testing and incident sharing](/crosswalks/nist-ai-rmf) [MEASURE 2.1: TEVV documentation](/crosswalks/nist-ai-rmf) [MEASURE 2.6: Safety evaluation](/crosswalks/nist-ai-rmf) [MEASURE 2.7: Security and resilience](/crosswalks/nist-ai-rmf) OWASP Top 10 ? [LLM01:25 - Prompt Injection](/crosswalks/owasp-top-10) [LLM04:25 - Data and Model Poisoning](/crosswalks/owasp-top-10) [LLM05:25 - Improper Output Handling](/crosswalks/owasp-top-10) [LLM08:25 - Vector and Embedding Weaknesses](/crosswalks/owasp-top-10) CSA AICM ? [AIS-07: Application Vulnerability Remediation](/crosswalks/csa-aicm) [MDS-06: Adversarial Attack Analysis](/crosswalks/csa-aicm) [MDS-07: Robustness against Adversarial Attack / Model Hardening](/crosswalks/csa-aicm) [TVM-01: Threat and Vulnerability Management Policy and Procedures](/crosswalks/csa-aicm) [TVM-03: Vulnerability Remediation Schedule](/crosswalks/csa-aicm) [TVM-05: External Library Vulnerabilities](/crosswalks/csa-aicm) [TVM-06: Penetration Testing](/crosswalks/csa-aicm) [TVM-07: Vulnerability Remediation Schedule](/crosswalks/csa-aicm) [TVM-08: Vulnerability Prioritization](/crosswalks/csa-aicm) [TVM-12: Threat Analysis and Modeling](/crosswalks/csa-aicm) [TVM-13: Threat Response](/crosswalks/csa-aicm) [AIS-08: Input Validation](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Cascading Failures](/crosswalks/owasp-aivss) [Agent Goal and Instruction Manipulation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 41: Inference - Evasion attack](/crosswalks/ibm-ai-risk-atlas) [IBM 43: Inference - Jailbreaking](/crosswalks/ibm-ai-risk-atlas) [IBM 46: Inference - Prompt injection attack](/crosswalks/ibm-ai-risk-atlas) [IBM 50: Inference - Direct instructions attack](/crosswalks/ibm-ai-risk-atlas) [IBM 52: Inference - Indirect instructions attack](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-1.1: Direct Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-1.2: Indirect Prompt Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-1.3: Goal Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-1.4: Multi-Modal Injection and Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-2.1: Jailbreak](/crosswalks/cisco-ai-security-safety-framework) [AITech-3.1: Masquerading / Obfuscation / Impersonation](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.1: Agent Injection](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.2: Context Boundary Attacks](/crosswalks/cisco-ai-security-safety-framework) [AITech-4.3: Protocol Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-5.1: Memory System Persistence](/crosswalks/cisco-ai-security-safety-framework) [AITech-5.2: Configuration Persistence](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.2: Memory System Corruption](/crosswalks/cisco-ai-security-safety-framework) [AITech-7.4: Token Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.1: Model or Agentic System Manipulation](/crosswalks/cisco-ai-security-safety-framework) [AITech-9.2: Detection Evasion](/crosswalks/cisco-ai-security-safety-framework) [AITech-11.2: Model-Selective Evasion](/crosswalks/cisco-ai-security-safety-framework) [AITech-12.2: Insecure Output Handling](/crosswalks/cisco-ai-security-safety-framework) [AITech-17.1: Sensor Spoofing](/crosswalks/cisco-ai-security-safety-framework) [AITech-19.1: Cross-Modal Inconsistency Exploits](/crosswalks/cisco-ai-security-safety-framework) [AITech-19.2: Fusion Payload Split](/crosswalks/cisco-ai-security-safety-framework) OWASP Agentic Top 10 ? [ASI01 - Agent Goal Hijack](/crosswalks/owasp-agentic-top-10) [ASI06 - Memory and Context Poisoning](/crosswalks/owasp-agentic-top-10) SOC 2 ? [CC2.3: External communication of controls](/crosswalks/soc-2) [CC4.1: Ongoing and separate evaluations](/crosswalks/soc-2) [CC4.2: Evaluate and communicate deficiencies](/crosswalks/soc-2) [CC7.2: Anomaly monitoring](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Appointing qualified third-party assessors.** Including selecting assessors with relevant technical capabilities for identified risk areas, maintaining records of assessor qualifications and independence. **Conducting regular testing.** Including defining testing scope and methodologies based on risk taxonomy and performing assessments of high-risk areas at least every quarter. **Maintaining documentation.** Including testing scope and results. B001.1 Evals: Third-party evaluation report assessing security riskThird-party evaluation report showing testing for security risk - including risks tested (e.g., insecure outputs, prompt injection), testing methodology and findings Category [Third-party Evals](/evidence/third-party-evals) Typical location Third-party evaluation report Capabilities Universal May include ? **Aligning adversarial testing with broader security testing programs.** For example, integrating AI-specific test cases into broader penetration testing, sharing threat models across red/blue teams, aligning test cycles with security audit and compliance calendars. B001.2 Documentation: Security program integrationPenetration test reports with AI-specific test cases, shared threat models, and testing calendars, or documentation of broader security program incorporating AI adversarial testing requirements. Category [Operational Practices](/evidence/operational-practices) Typical location Engineering Practice Internal processes Capabilities Universal Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # Earn SOC 2 & AIUC-1 together Source: https://standard.aiuc-1.com/soc2-joint-offering [AICPA](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services) and AIUC-1 have partnered to let organizations earn SOC 2 and AIUC-1 together: * One engagement with your existing SOC 2 auditor * One comprehensive audit report * Quarterly testing of agents against real-world risks The engagement is offered by all Big 4 firms and several other CPA firms including Schellman, Grant Thornton, EisnerAmper and BDO. **Organizations earn a full SOC 2 attestation and AIUC-1 certification**\ Unlike other "SOC plus" engagements (e.g. SOC 2 + HITRUST), where organizations are required to pursue full certification as a separate engagement, the SOC 2 + AIUC-1 engagement is designed so that organizations earn a full SOC 2 attestation and AIUC-1 certification. ## Joint audit process Both frameworks are scoped upfront and pursued in the same audit window, in one engagement with your organization’s existing SOC 2 auditor. This helps organizations to cover agents & cybersecurity in one engagement. **Typical SOC 2 + AIUC-1 process** ![Timeline of the joint SOC 2 and AIUC-1 audit process](https://mintcdn.com/aiuc-28e27073/7jVrfOJQme2j0R-0/images/CleanShot-2026-10-16-at-17.26.08@2x.png?fit=max\&auto=format\&n=7jVrfOJQme2j0R-0\&q=85\&s=3862507633636a5fce564588c71c57d8) ### Scoping Each framework is scoped to its relevant domain. SOC 2 covers the organizational systems within its audit scope. AIUC-1 covers the specified agents or platforms and their security, safety and reliability risks. ![AIUC-1 agents within the organization-wide SOC 2 audit scope](https://mintcdn.com/aiuc-28e27073/7jVrfOJQme2j0R-0/images/CleanShot-2026-10-16-at-17.31.33@2x.png?fit=max\&auto=format\&n=7jVrfOJQme2j0R-0\&q=85\&s=085482a1419860554d83f667ccd45342) > ****Read more:** SOC 2 coverage** > > * Scope defined in the Management Assertion > * Covers security and data controls across the whole organization: access, encryption, change management, incident response > * Mix of technical and governance controls > ****Read more:** AIUC-1 coverage** > > * Scope defined in the Management Assertion - limited to AI agent systems > * Covers agent-specific security, safety and reliability risks > * Mix of technical & governance controls > * Includes quarterly technical evaluations of agents themselves > > Read more about AIUC-1 scoping [here](https://standard.aiuc-1.com/scoping). To earn AIUC-1 certification, the AI systems in scope are tested against 1,000-5,000+ real-world scenarios covering different attack types for applicable risks. \ > \ > More on the testing methodology [here](https://standard.aiuc-1.com/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope). > ****Read more:** Certifying individual agents vs. agent platforms** > > AIUC-1 Certification is used by organizations in two ways: > > ![Clean Shot 2026 10 16 At 17 36 14@2x](https://mintcdn.com/aiuc-28e27073/7jVrfOJQme2j0R-0/images/CleanShot-2026-10-16-at-17.36.14@2x.png?fit=max\&auto=format\&n=7jVrfOJQme2j0R-0\&q=85\&s=8e957aa8fe91ca6d44fa0fc2a0a63e6c) ### Evidence Collection The joint engagement simplifies evidence collection for organizations: * Auditors typically share one combined request list * Overlapping requests are only submitted once * Organizations can use their desired GRC platform for the joint engagement - e.g. Vanta, Drata, Fieldguide **Full crosswalk between SOC 2 & AIUC-1 [here](https://standard.aiuc-1.com/crosswalks/soc-2)** ### Final deliverable After completing the full audit, organizations will receive one unified audit report combining: * Full SOC 2 attestation report of selected SOC 2 TSCs * Full AIUC-1 certification report of applicable AIUC-1 requirements including technical evaluation results of agent behaviour. ## FAQs > **Which auditors offer SOC 2 & AIUC-1 together** > > SOC 2 + AIUC-1 is available with BDO, Deloitte, EisnerAmper, EY, Grant Thornton, KPMG, PwC and Schellman. Additional firms hold provisional AIUC-1 accreditation - contact us [here](https://www.aiuc-1.com/contact) if you are interested in pursuing agent certification with another auditor. > **When is SOC 2 & AIUC-1 relevant for organizations?** > > SOC 2 + AIUC-1 is relevant for organizations: > > * Developing agents & agent platforms sold to enterprises > * Deploying agents in high-risk environments - whether developed in-house or by vendors > * Subject to regulatory requirements for agents such as SOX, the EU AI Act, CA SB 243, NYC Local Law 144 > * Using coding agents for production code (coding-agents are a typical AIUC-1 use case) > * Facing AI security reviews or questionnaires from enterprise buyers > **When is SOC 2 & AIUC-1 not relevant for organizations?** > > SOC 2 + AIUC-1 is less relevant for organizations: > > * Primarily using AI chatbots like Copilot, Claude or ChatGPT > * Using agents for low-risk use cases that are internally facing > * Restricting agents from accessing sensitive data and activate tools > * Not subject to new AI regulation > * Developing agents primarily sold to small companies with limited security requirements > **What does this add to SOC 2 on its own?** > > The joint offering adds AI agent security to your SOC 2 audit through one combined engagement. AIUC-1 covers agent-specific security, safety and reliability risks and requires technical evaluations to validate agent deployments. > **Who are all parties involved and the responsibilities of each?** > > * Licensed CPA firms perform the SOC 2 & AIUC-1 engagement and issue the report. > * AIUC or accredited technical evaluation body runs the quarterly technical testing. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # F. Society Source: https://standard.aiuc-1.com/society ## Requirements Prevent AI cyber misuse F001 · Mandatory Implement or document guardrails to prevent AI-enabled misuse for cyber attacks and exploitation. Keywords Cyber Attacks Capabilities Text-generation Automation Voice-generation Code-generation [Open](/society/prevent-ai-cyber-misuse) Prevent catastrophic misuse F002 · Mandatory Implement or document guardrails to prevent AI-enabled catastrophic system misuse (chemical / bio / radio / nuclear). Keywords CBRN Chemical Bioweapon Radioactive Nuclear Capabilities Text-generation Voice-generation Image-generation [Open](/society/prevent-catastrophic-misuse) 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # F001: Prevent AI cyber misuse Source: https://standard.aiuc-1.com/society/prevent-ai-cyber-misuse Implement or document guardrails to prevent AI-enabled misuse for cyber attacks and exploitation. Keywords Cyber Attacks Application Mandatory Frequency Every 12 months Type Preventative Capabilities Text-generation Automation Voice-generation Code-generation Crosswalks NIST AI RMF ? [MEASURE 2.7: Security and resilience](/crosswalks/nist-ai-rmf) ISO 42001 ? [A.5.5: Assessing societal impacts of AI systems](/crosswalks/iso-42001) CSA AICM ? [GRC-02: Risk Management Program](/crosswalks/csa-aicm) [GRC-09: Acceptable Use of the AI Service](/crosswalks/csa-aicm) [GRC-10: AI Impact Assessment](/crosswalks/csa-aicm) [GRC-12: Ethics Committee](/crosswalks/csa-aicm) [TVM-11: Guardrails](/crosswalks/csa-aicm) OWASP AIVSS ? [Agent Identity Impersonation](/crosswalks/owasp-aivss) IBM AI Risk Atlas ? [IBM 53: Inference - Social hacking attack](/crosswalks/ibm-ai-risk-atlas) [IBM 61: Output - Harmful code generation](/crosswalks/ibm-ai-risk-atlas) [IBM 65: Output - Dangerous use](/crosswalks/ibm-ai-risk-atlas) [IBM 66: Output - Spreading disinformation](/crosswalks/ibm-ai-risk-atlas) [IBM 67: Output - Nonconsensual use](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-17.1: Sensor Spoofing](/crosswalks/cisco-ai-security-safety-framework) [AITech-18.1: Fraudulent Use](/crosswalks/cisco-ai-security-safety-framework) [AITech-18.2: Malicious Workflows](/crosswalks/cisco-ai-security-safety-framework) CA SB 53 ? [22757.12: Transparency & Reporting Obligations](/crosswalks/ca-sb-53) SOC 2 ? [CC7.3: Security event evaluation](/crosswalks/soc-2) ## Control activities ## Typical evidence Should include ? **Results of testing from foundation model developer on offensive cyber capabilities and mitigations.** F001.1 Documentation: Foundation model cyber capabilitiesProvider model cards, cybersecurity assessment reports from model developers, or foundation model documentation describing offensive cyber capabilities and mitigations Category [Legal Policies](/evidence/legal-policies) Typical location Vendor Contracts Capabilities Text-generation Automation Voice-generation Code-generation May include ? **Implementing malicious use detection and blocking.** For example, deploying available content filtering to detect requests for malicious code generation, attack planning, and vulnerability exploitation guidance, configuring automated blocking of cyber attack assistance requests, maintaining databases of prohibited use patterns. F001.2 Config: Cyber use detectionContent filtering rules blocking cyber attack requests, keyword or pattern matching detecting malicious code generation attempts, automated blocking configuration for exploit development queries, or prohibited use pattern database. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Text-generation Automation Voice-generation Code-generation **Assessing and mitigating cyber capabilities for open-weight models.** For example, re-running cyber misuse evals on the modified model or adding output classifiers for exploit and malware generation. F001.3 Documentation: Cyber capability assessment for modified modelsAssessment showing base model and version, modifications made, whether the developer's results still hold, and compensating guardrails applied - may include a short memo, re-run eval results or guardrail configuration. Category [Operational Practices](/evidence/operational-practices) Typical location Internal processes Capabilities Text-generation Automation Voice-generation Code-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # F002: Prevent catastrophic misuse Source: https://standard.aiuc-1.com/society/prevent-catastrophic-misuse Implement or document guardrails to prevent AI-enabled catastrophic system misuse (chemical / bio / radio / nuclear). Keywords CBRN Chemical Bioweapon Radioactive Nuclear Application Mandatory Frequency Every 12 months Type Detective Capabilities Text-generation Voice-generation Image-generation Crosswalks ISO 42001 ? [A.5.5: Assessing societal impacts of AI systems](/crosswalks/iso-42001) CSA AICM ? [GRC-02: Risk Management Program](/crosswalks/csa-aicm) [GRC-09: Acceptable Use of the AI Service](/crosswalks/csa-aicm) [GRC-10: AI Impact Assessment](/crosswalks/csa-aicm) [GRC-12: Ethics Committee](/crosswalks/csa-aicm) [TVM-11: Guardrails](/crosswalks/csa-aicm) IBM AI Risk Atlas ? [IBM 60: Output - Harmful output](/crosswalks/ibm-ai-risk-atlas) [IBM 65: Output - Dangerous use](/crosswalks/ibm-ai-risk-atlas) Cisco AI Security Framework ? [AITech-15.1: Harmful Content](/crosswalks/cisco-ai-security-safety-framework) ## Control activities ## Typical evidence Should include ? **Results of testing from foundation model developer on CBRN capabilities and mitigations.** F002.1 Documentation: Foundation model CBRN capabilitiesList of foundation models used with CBRN capability information - may include provider model cards with CBRN assessments, weapons of mass destruction risk evaluations from model developers, or other documentation describing CBRN-related capabilities and mitigations. Category [Legal Policies](/evidence/legal-policies) Typical location Vendor Contracts Capabilities Text-generation Voice-generation Image-generation May include ? **Establishing catastrophic misuse monitoring.** For example, monitoring AI system interactions for patterns indicating weapons development or mass harm intent, implementing real-time alerting for detected catastrophic misuse attempts, documenting suspicious queries and system responses. F002.2 Config: Catastrophic misuse monitoringMonitoring dashboard or alert configuration for catastrophic misuse patterns - may include usage monitoring flagging CBRN-related queries, alert rules for weapons development patterns, logs of detected and blocked catastrophic misuse attempts, or incident records documenting suspicious CBRN-related interactions. Category [Technical Implementation](/evidence/technical-implementation) Typical location Engineering Code Capabilities Text-generation Voice-generation Image-generation Organizations can submit alternative evidence demonstrating how they meet the requirement. 37.782274° N -122.392147° W FIG. A (SITE INDEX) Artificial Intelligence Underwriting Company SFO NYC LON Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input. I. Standard II. Learn III. Office 100 © AIUC — ALL RIGHTS RESERVED # AIUC-1 Governance Source: https://standard.aiuc-1.com/standard-governance AIUC-1 is created by the Artificial Intelligence Underwriting Company ([AIUC](/learn/contribute)), a Public Benefit Corporation headquartered in San Francisco. ### AIUC-1 Consortium The AIUC-1 standard is developed and maintained with the [AIUC-1 Consortium](/consortium), uniting 300+ security & risk leaders across the Fortune 500. The standard is updated quarterly following the [process described below](#quarterly-updates). The process is designed on the following principles: 1. **Broad input:** All consortium members can propose changes to AIUC-1 each quarter. The input shapes quarterly release priorities alongside changes to legislation, new incidents, and new agent capabilities. 2. **Focused updating:** AIUC Standards team collect inputs and translate them into formal standard changes. For some changes, smaller working groups are created to work through proposed changes in a targeted way. 3. **Transparent review:** All proposed standard changes go through a transparent peer-review, enabling consortium members to question and challenge proposed updates. AIUC Standards team finalize standard changes based on peer-review feedback before final release. All changes are documented in a public [changelog](/changelog). An AIUC-1 advisory group has been formed to review standard governance and propose additional steps. For example, adding a formal review step by an advisory board for each standard release. Details of their work, including how it has been implemented, will be shared as part of the next release of AIUC-1 on January 15th, 2027. ### AIUC-1 Certification To earn AIUC-1 Certification, organizations must submit to a control audit by an accredited auditor and submit agents to technical evaluations: * [Accredited auditors](https://standard.aiuc-1.com/accredited-auditors) validate that organizations have implemented effective controls to meet all applicable AIUC-1 requirements. The auditor writes the AIUC-1 audit report and issues a recommendation to certify. * **Technical evaluations** validate how agents behave against real world risk. Results are included in the audit report, graded by severity. To pass AIUC-1 Certification, organizations must demonstrate no Critical (P0) or Major (P1) findings. Evaluations are currently conducted only by AIUC, to ensure consistent quality and methodology across certified agents. The final AIUC-1 Certification is issued by AIUC. **Expanding technical evaluator ecosystem** A pilot program was launched in Q3, 2026 with independent entities completing the technical evaluations of agents required in AIUC-1. The entities follow AIUC-1 evaluation guidelines to ensure consistent quality and methodology across certified agents. Pending successful results, the ecosystem of independent technical evaluators will grow similarly to the [ecosystem of accredited auditors](https://standard.aiuc-1.com/accredited-auditors). To accelerate ecosystem creation, parts of the AIUC-1 evaluation methodology have already been released publicly, including: * [Risk taxonomy](https://standard.aiuc-1.com/evals-taxonomy/risks) - a comprehensive taxonomy of agent risk areas by category * [Attack taxonomy](https://standard.aiuc-1.com/evals-taxonomy/attacks) - an overview of benign and adversarial tactics to elicit risks * [Incident database](https://standard.aiuc-1.com/evals-taxonomy/incident-database) - a sample of real-world incidents used to ensure evals are realistic > ****Accrediting technical evaluators**** > > Accreditation criteria for technical evaluators are being developed in parallel with the pilot. To earn accreditation, technical evaluators must demonstrate the ability to consistently and at a high quality: > > 1. Scope evaluations to the relevant risk areas, drawing on the risk taxonomy > 2. Execute a representative set of benign and adversarial agent attacks, drawing on the attack taxonomy and incident database > 3. Grade evaluation results consistently, following the AIUC-1 grading methodology > 4. Maintain strong governance and security, including sensitive data protection, independence from the organizations they evaluate, and secure handling of evaluation results and agent access ### Quarterly updates AIUC-1 is updated each quarter on January 15, April 15, July 15 and October 15 to ensure that the standard evolves as technology, risk, and regulation evolves. Quarterly updates follow a documented process involving: 1. Prioritization sessions with executive consortium members 2. Technical working sessions with consortium members & technical contributors 3. Peer-review of all standard changes 4. Transparent change management with public line-by-line [changelog](https://standard.aiuc-1.com/changelog) ![7aec2fa2811da9210c9ab945c003f182fe51c5a9 3877x1315](https://mintcdn.com/aiuc-28e27073/7jVrfOJQme2j0R-0/images/7aec2fa2811da9210c9ab945c003f182fe51c5a9-3877x1315.avif?fit=max\&auto=format\&n=7jVrfOJQme2j0R-0\&q=85\&s=7694ed94314a95669bd5fb48c67a38fe) ### Tenets guiding standard updates AIUC-1 is designed to be: * **Adoption-focused.** We prioritize requirements that enterprise customers demand and vendors can pragmatically meet, increasing confidence without adding unnecessary compliance. * **AI-focused.** We do not cover non-AI risks that are addressed in frameworks or regulations like SOC 2, ISO 27001, or GDPR. * **Insurance-enabling.** We prioritize risks that lead to direct harms and financial losses. * **Adapting to regulation.** We update AIUC-1 to make it easier to comply with new regulations. * **Adapting to AI progress.** We update AIUC-1 to keep up with new capabilities, like reasoning capabilities and new modalities. * **Adapting to the threat landscape.** We update AIUC-1 in response to real-world incidents. * **Continuously improving.** We regularly update the standard based on real-world deployment experience and stakeholder feedback. * **Predictable.** We review the standard and push updates quarterly, on January 15, April 15, July 15, and October 15 of each year. Certifications remain valid for the full year, with the standard version locked at certification. * **Transparent.** We keep a public changelog and share our lessons. ### Guarantees No standard can eliminate all risks inherent in deploying AI systems, and certification represents a point-in-time assessment of controls, not a warranty of future performance or outcomes. Organizations change, systems evolve, and new risks emerge. AIUC-1 quarterly technical evaluations are designed to mitigate this risk, so that an AIUC-1 certificate demonstrates that an organization takes AI governance seriously and has invested in demonstrable controls that work in practice when evaluated. But it should not substitute independent risk assessment and ongoing monitoring. ### Frequently asked questions Answers to FAQs [here](https://standard.aiuc-1.com/faq) ### **Provide input on AIUC-1** We welcome feedback, ideas, suggestions, and criticism. [Provide input on AIUC-1](/learn/contribute).