All evidence
Download evidence list| Requirement | Control activity | Evidence | Tags |
|---|---|---|---|
A001: Establish input data 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 | |
A001: Establish input data 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. | |
A001: Establish input data 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 | |
A002: Establish output data policy 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. | |
A002: Establish output data policy 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. | |
A003: Limit AI agent data access 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. | |
A003: Limit AI agent data access 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. | |
A003: Limit AI agent data access 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. | |
A004: 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. | |
A004: 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. | |
A004: 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. | |
A004: 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. | |
A005: 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 | |
A005: 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. | |
A005: 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. | |
A006: 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 ControlTechnical ImplementationEng: LLM output filtering logicEng: User LLM input filtering logic |
A006: 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. | |
A007: 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. | |
A007: 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. | |
A007: 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. | |
A008: Prevent leakage of credentials and secrets 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). | |
A008: Prevent leakage of credentials and secrets 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. | |
A008: Prevent leakage of credentials and secrets 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. | |
A008: Prevent leakage of credentials and secrets 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. | |
A008: Prevent leakage of credentials and secrets 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. | |
B001: Third-party testing of adversarial robustness Mandatory Requirement | Establishing a taxonomy for adversarial risks. For example, drawing on NIST’s AI 100-2e2023 attack classifications and aligning these to system architecture and use cases. Conducting comprehensive adversarial testing at least quarterly. For example, performing structured red-teaming, prompt injection assessments, jailbreaking attempts, adversarial perturbation testing, semantic manipulation, and simulated malicious tool invocations. Maintaining secure testing documentation. For example, recording test cases, methods, outcomes, and system behaviors with restricted access controls, implementing secure storage for sensitive testing materials. Establishing improvement processes based on findings. For example, assigning owners and remediation timelines based on test severity, tracking fixes through risk registers or issue management systems, documenting updates to safeguards and procedures. | B001.1 Report: adversarial testing results. Third-party evaluation report showing adversarial robustness testing - must include risk taxonomy tested, testing methodology and findings, secure documentation practices, and improvement tracking with remediation timelines and documentation. | |
B001: Third-party testing of 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. | |
B002: Detect adversarial input Supplemental 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) | |
B002: Detect adversarial input Supplemental 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. | |
B002: Detect adversarial input Supplemental 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). | |
B002: Detect adversarial input Supplemental 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. | |
B002: Detect adversarial input Supplemental 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. | |
B003: Manage public release of technical details Supplemental 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. | |
B003: Manage public release of technical details Supplemental 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. | |
B004: 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. | |
B004: 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. | |
B004: 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. | |
B004: 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. | |
B005: Implement real-time input filtering Supplemental 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 | |
B005: Implement real-time input filtering Supplemental 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. | |
B005: Implement real-time input filtering Supplemental 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. | |
B005: Implement real-time input filtering Supplemental 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. | |
B005: Implement real-time input filtering Supplemental 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. | |
B006: Prevent unauthorized AI agent actions 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. | |
B006: Prevent unauthorized AI agent actions 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. | |
B006: Prevent unauthorized AI agent actions 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. | |
B007: Enforce user access privileges to AI systems 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. | |
B007: Enforce user access privileges to AI systems 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. | |
B008: Protect AI system 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). | |
B008: Protect AI system 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. | |
B008: Protect AI system 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. | |
B008: Protect AI system 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). | |
B008: Protect AI system 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. | |
B009: 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. | |
B009: 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. | |
B009: 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. | |
B010: Promote secure patterns in generated code 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. | |
B010: Promote secure patterns in generated code 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. | |
B010: Promote secure patterns in generated code 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. | |
B010: Promote secure patterns in generated code 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. | |
B010: Promote secure patterns in generated code 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. | |
B010: Promote secure patterns in generated code 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. | |
C001: 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. | |
C001: 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 annual 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. | |
C002: 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). | |
C002: 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. | |
C002: 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. | |
C003: 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. | |
C003: 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. | |
C003: 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. | |
C003: 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. | |
C004: 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. | |
C004: 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. | |
C004: 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. | |
C005: Prevent agent-specific 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. | |
C005: Prevent agent-specific 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. | |
C005: Prevent agent-specific 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. | |
C006: 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. | |
C006: 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). | |
C006: 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. | |
C007: Flag high risk outputs for human review Supplemental 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. | |
C007: Flag high risk outputs for human review Supplemental 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. | |
C007: Flag high risk outputs for human review Supplemental 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. | |
C008: Monitor AI risk categories Supplemental 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. | |
C008: Monitor AI risk categories Supplemental 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. | |
C008: Monitor AI risk categories Supplemental 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. 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. | |
C009: Enable real-time feedback and intervention Supplemental 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) | |
C009: Enable real-time feedback and intervention Supplemental 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. | |
C010: Third-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 performing assessments of harmful outputs at least every quarter, defining testing scope and methodologies based on risk classifications and industry benchmarks like ToxiGen, coordinating with internal security and testing teams. Maintaining documentation. Including testing scope, results, and remediation actions taken, tracking follow-up activities and resolution timelines. | C010.1 Report: Harmful output testing. Third-party evaluation report showing harmful output testing - must include documentation of assessor qualifications, testing methodology and findings, and improvement tracking with remediation timelines and documentation. | |
C011: Third-party testing for out-of-scope 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 out-of-scope outputs at least every quarter. Maintaining documentation. Including testing scope, results, and remediation actions taken, tracking follow-up activities and resolution timelines. | C011.1 Report: Out-of-scope output testing. Third-party evaluation report showing out-of-scope output testing - must include documentation of assessor qualifications, testing methodology and findings, and improvement tracking with remediation timelines and documentation. | |
C012: Third-party testing for customer-defined 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, results, and remediation actions taken, tracking follow-up activities and resolution timelines. | C012.1 Third-party evaluation report assessing customer-defined risk. Third-party evaluation report showing testing of customer-defined risk - must include documentation of assessor qualifications, testing methodology and findings, and improvement tracking with remediation timelines and documentation. | |
D001: 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. | |
D001: 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. | |
D001: 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. | |
D002: Third-party testing for hallucinations 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 at least every quarter. Maintaining documentation. Including testing scope, results, and remediation actions taken, tracking follow-up activities and resolution timelines. | D002.1 Report: Hallucination testing results. Third-party evaluation report showing hallucination testing - must include risk taxonomy tested, testing methodology and findings, and improvement tracking with remediation timelines and documentation. | |
D003: 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. | |
D003: 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. | |
D003: 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. | |
D003: 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, code requiring human confirmation, or ticketing system for sensitive, high-risk, or multi-step tool operations | |
D003: 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. | |
D004: Third-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 tool calls at least every quarter. Maintaining documentation. Including testing scope, results, and remediation actions taken, tracking follow-up activities and resolution timelines. | D004.1 Report: Tool call testing. Third-party evaluation report showing tool call testing - must include risk taxonomy tested, testing methodology and findings, and improvement tracking with remediation timelines and documentation. | |
E001: 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 | |
E002: 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 | |
E002: 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. | |
E003: 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 | |
E003: 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. | |
E004: 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. | |
E004: 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. | |
E005: Document data storage security 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. | |
E006: 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. | |
E007: [Retired] Document system change approvals Supplemental Requirement | Documenting formal review and approval decisions for changes defined in E004: Assign accountability. | E007.1 Retired. This requirement was merged into E004 at the Q1, 2026 standard update. See aiuc-1.com/changelog for more information | Mandatory Control |
E008: 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. | |
E008: 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. | |
E009: Monitor third-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. | |
E009: Monitor third-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). | |
E010: 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 | |
E010: 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. | |
E010: 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. | |
E010: 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. | |
E011: 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. | |
E011: 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. | |
E012: 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. | |
E013: Implement quality management system Supplemental 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. | |
E013: Implement quality management system Supplemental 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. | |
E013: Implement quality management system Supplemental 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. | |
E013: Implement quality management system Supplemental 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. | |
E013: Implement quality management system Supplemental 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. | |
E014: [Retired] Share transparency reports Supplemental Requirement | This requirement was merged into E017 at the Q1, 2026 standard update. See aiuc-1.com/changelog for more information | E014.1 Not applicable. Not applicable | Supplemental Control |
E015: Log AI system 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). | |
E015: Log AI system 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. | |
E015: Log AI system 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. | |
E015: Log AI system 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. | |
E016: 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. | E016.1 Demonstration: Text AI disclosure. Text-based AI disclosure - may include chatbot interface with “You’re chatting with AI” notice, messaging system showing AI agent identifier, website chat widget with AI disclosure banner, or automated email/SMS with AI generation notice. | |
E016: Implement AI disclosure mechanisms Mandatory Requirement | Implementing AI disclosure for voice-based interactions. For example, providing audio notifications at the beginning of voice calls or interactions. | E016.2 Demonstration: Voice AI disclosure. Transcript or audio recording of voice AI disclosure. | |
E016: Implement AI disclosure mechanisms Mandatory Requirement | 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. | E016.3 Demonstration: Labelling AI-generated content. AI generation labeling implementation - may include Content Credentials or C2PA metadata embedded in files, visible watermarking system with AI generation marks, classifier output detecting and flagging AI-generated content, or metadata tagging system marking files as artificially generated. | |
E016: Implement AI disclosure mechanisms Mandatory Requirement | 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. | E016.4 Demonstration: Automation AI disclosure. AI automation disclosure in product - may include “Powered by AI” or “AI Agent” labels in interface, workflow dashboard displaying AI-automated tasks, status indicators showing “AI is handling this” or “Automated by AI,” or notification messages stating “AI agent completed your request.” | |
E016: Implement AI disclosure mechanisms Mandatory Requirement | Establishing reactive disclosure capabilities when users ask if they are interacting with AI. | E016.5 Demonstration: System response to AI inquiry. Chatbot or voice agent transcript responding to “Are you AI?” | |
E017: Document system transparency policy Supplemental 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. | |
E017: Document system transparency policy Supplemental 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). | |
E017: Document system transparency policy Supplemental 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. | |
F001: 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 | |
F001: 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. | |
F002: 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. | |
F002: 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. |
37.782274° N -122.392147° WFIG. A (SITE INDEX)
Artificial Intelligence Underwriting Company
CodeStructural unita.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