ARTIFICIAL INTELLIGENCE SECURITY STANDARD

AI Governance · Acceptable Use · Model and Data Risk · Prompt Injection · Shadow AI

Table of Contents

1. Purpose and Scope
2. Principles
3. AI Use Categories
4. Acceptable Use of AI
5. Data and AI
6. In-House and Embedded AI Systems
7. AI-Specific Threats
8. Third-Party AI Services
9. Shadow AI
10. Roles and Responsibilities
11. Regulatory and Framework Alignment Summary
12. Document Control

1. Purpose and Scope

Artificial intelligence entered the organization faster than any technology before it, and it entered mostly without asking. Employees use AI assistants. Vendors embed AI features into software already in use. Teams build applications on top of AI models. Each of these creates security exposure that none of the existing CERG standards squarely owns: data leaving the organization in a prompt, decisions made by a model no one validated, an application vulnerable to attacks that did not exist three years ago.

This standard establishes the requirements for the secure use of AI across CERG-managed environments: acceptable use, how data and AI interact, the security of in-house and embedded AI systems, the AI-specific threats the program must defend against, the assessment of third-party AI services, and the control of unsanctioned AI use.

It applies to every use of AI by CERG-managed teams and systems: third-party AI services and assistants, AI features embedded in other software, and AI applications the organization builds itself. It is technology-neutral and is written to survive the rapid change in the AI field.

AI Is Not Exempt From the Rest of CERG

An AI system is software. It runs on infrastructure, it processes data, it is accessed by identities, and it is built by developers. Everything CERG already requires still applies: an in-house AI application is governed by the secure development standard, the data it touches is governed by the data governance standard, its access is governed by the access standard. This standard does not replace those. It adds the requirements that are genuinely specific to AI, and it makes explicit that AI does not get a pass on the requirements that already exist.

2. Principles

1. AI use is sanctioned use. AI is used through services and tools the program has assessed and approved. Unsanctioned AI is shadow IT and is treated as such (Section 9).
2. A prompt is an export. Data placed into an AI system, especially a third-party one, has left the organization’s control boundary as surely as if it were emailed out. It is governed by the data classification scheme.
3. AI output is reviewed, not trusted. AI output can be wrong, biased, or manipulated. A human reviews AI output before it is used for a consequential decision. Accountability for the decision stays with the human.
4. AI does not decide alone where it matters. An AI system does not make a final consequential decision, about a person, a safety action, a control system, without a human in the loop.
5. AI risk is assessed before adoption. An AI service or AI feature is risk-assessed before it is used, like any other technology, and reassessed as its capability changes.
6. The same rules scale. A five-person team and a sixty-person team both sanction AI tools, classify what goes into them, and review what comes out. The rigor scales; the principles do not.

3. AI Use Categories

CERG governs three categories of AI use. The requirements differ by category.

4. Acceptable Use of AI

1. Use sanctioned AI tools. Employees use the AI services and tools the program has assessed and approved. The list of sanctioned AI tools is maintained by Governance using CERG-TMPL-AI-002 or an equivalent local register and is visible to staff.
2. Classify before you prompt. Before data is placed into an AI tool, the user considers its classification per CERG-STD-DG-001. Section 5 governs what may go where.
3. Review AI output before relying on it. AI-generated content, code, analysis, or recommendations are reviewed by a competent person before being used. AI-generated code additionally passes the gates in CERG-STD-SDL-001; AI is not an exception to code review.
4. Do not use AI to make prohibited decisions unaided. AI does not unilaterally make decisions about employment, safety, control system operation, or anything else where Principle 4 applies.
5. Attribute and disclose where required. Where a regulator, a contract, or a customer requires disclosure that AI was used, that disclosure is made.

5. Data and AI

This section applies the data classification scheme to AI use. It is the most important operational section of the standard.

1. A prompt to a third-party AI service is treated as external sharing. Placing data into a consumed AI service is governed by the external-sharing rules of CERG-STD-DG-001 §6.
2. Classification limits on AI input: - Public and Internal data may be placed into sanctioned AI tools. - Confidential data may be placed only into AI services that have been assessed and approved for Confidential data, with contractual assurance that input is not used to train the provider’s models and is handled to the program’s bar. - Restricted data, including CUI and BES Cyber System Information, is not placed into a third-party AI service unless that service is explicitly authorized for that regulated category and an authorization is recorded. For CUI this means the service satisfies CERG-STD-CUI-001.
3. Training data is classified data. Data used to train, fine-tune, or ground an in-house or embedded AI system carries its classification, and the resulting model is treated as carrying the classification of its most sensitive training data.
4. AI interactions are logged where they touch sensitive data. Use of AI systems that process Confidential or Restricted data is logged per CERG-STD-LM-001.

The Prompt Is the Leak

The most common AI security failure is mundane: an employee pastes a sensitive document into a public AI assistant to summarize it. The data is now on a third party’s infrastructure, possibly used to train a model, possibly retained indefinitely, and entirely outside the organization’s control. No model was hacked. No clever attack occurred. Someone simply typed. CERG governs AI primarily by governing what goes into the prompt, because the prompt is where the data actually leaves.

6. In-House and Embedded AI Systems

An AI application the organization builds is software and is fully governed by CERG-STD-SDL-001. In addition:

1. AI applications go through architecture review. An AI application or integration is subject to project intake and architecture review per CERG-PRC-AR-001, with the AI-specific threats in Section 7 explicitly in scope of the threat model.
2. The model is an inventoried component. A model, whether trained in-house or a third-party model the application depends on, is a component recorded in the asset inventory per CERG-STD-AM-001, the AI system and model register using CERG-TMPL-AI-003 or an equivalent local record, and, where applicable, in the software bill of materials per CERG-STD-SDL-001 §8.
3. Model provenance is known. The source of any third-party or open model used is known and trusted. A model from an unverified source is a supply chain risk.
4. AI applications enforce least privilege. An AI system, and any agent or tool-using capability it has, operates with the least privilege required. An AI agent does not run with broad standing access on the assumption it will behave.
5. AI output that triggers action is bounded. Where an AI system can trigger an action, send a message, change a record, call an API, the actions it can take are constrained and high-consequence actions require human confirmation.

7. AI-Specific Threats

CERG-built and embedded AI systems are designed and tested against the AI-specific threat classes below, aligned to the OWASP Top 10 for LLM Applications. These threats are explicitly in scope of the threat model required by CERG-STD-SDL-001.

8. Third-Party AI Services

1. AI services are assessed before adoption. A consumed AI service or an AI-enabled vendor feature is risk-assessed before use through CERG-PRC-TPRM-001 and recorded through CERG-TMPL-AI-001 or an equivalent local intake. The assessment covers, at minimum: what the provider does with input data, whether input trains the provider’s models, data retention and location, and the provider’s own security posture.
2. Embedded AI features are assessed when they appear. A vendor adding an AI feature to existing software is a material change to that vendor’s risk profile and triggers reassessment. AI features that arrive silently in an update are caught by the reassessment cadence in CERG-PRC-TPRM-001.
3. Approval is by data classification. A service is approved for a maximum data classification per Section 5. Approval for Internal use is not approval for Confidential or Restricted use.
4. The sanctioned list is maintained. The outcome of assessment is the sanctioned AI tools list, maintained using CERG-TMPL-AI-002 or an equivalent local register, which states each tool and the maximum classification it is approved for.

9. Shadow AI

Shadow AI is the use of AI services that the program has not assessed or approved. It is the dominant AI risk in most organizations.

1. Shadow AI is shadow IT. Unsanctioned AI use is treated as unsanctioned technology under CERG-STD-IT-001. It is discovered, assessed, and then either sanctioned or stopped.
2. Discovery looks for it. The program actively looks for unsanctioned AI use, through network and SaaS discovery and through expense and procurement signals. AI use that is invisible cannot be governed.
3. The response is a path to sanctioned use, not only a block. When shadow AI is found, the program assesses whether the underlying need can be met by a sanctioned tool and provides one. A pure block with no sanctioned alternative drives the use further underground. This is the “yes, and…” model of CERG-GOV-FRM-001 applied to AI: enable the need, on safe ground.
4. Repeated or high-risk shadow AI is a risk register entry. A pattern of shadow AI, or a single instance involving Confidential or Restricted data, is recorded and tracked per CERG-PRC-RM-001.

Banning AI Does Not Work. Governing It Does.

An organization that responds to AI by banning it does not eliminate AI use; it eliminates its visibility into AI use. Employees who see a genuine productivity gain will use AI on personal devices and personal accounts, where the organization has no assessment, no contract, and no control at all. The defensible position is the CERG position everywhere else: provide sanctioned tools that meet a real need, govern what data goes into them, and treat the unsanctioned use that remains as a finding to be brought into the light.

10. Roles and Responsibilities

Roles below are the canonical role names from CERG-GOV-OM-001 §6.1.

11. Regulatory and Framework Alignment Summary

12. Document Control

Revision History

Review Triggers

• Material change to how the organization uses AI
• New or changed AI regulation
• Revision of the NIST AI Risk Management Framework or the OWASP LLM Top 10
• A significant AI-related security incident
• Direction from the CISO

Cyber Engineering owns this document. The Engineering Pillar Leader (Application Security) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes.

Related Documents

Source: standards/CERG-STD-AI-001_Artificial_Intelligence_Security_Standard.md · Download .md · View on GitHub