1. Why AI Security Matters in the Public Sector

Artificial intelligence is increasingly being adopted by public organizations for administrative automation, civil-service support, document analysis, information retrieval, prediction, decision support, and other services.

However, public-sector AI systems may process sensitive administrative information, personal information, internal documents, policy-related information, and data associated with important infrastructure.

Therefore, protecting only the AI model is not sufficient.

The AI Security Guidebook describes AI security as covering traditional information-system security as well as AI-specific assets such as AI models, training data, and input/output data. A compromise or manipulation of an AI model or dataset can affect the security, safety, and reliability of the entire AI system.

Chapter 2 therefore organizes security measures according to several deployment scenarios:

AI systems dedicated to internal networks
Internal AI systems connected to external networks
Public-facing AI systems connected to internal networks
Commercial AI services

The guidebook focuses specifically on securing AI models, data, and infrastructure, while other cybersecurity requirements should be addressed through applicable national information-security policies and guidelines.

2. AI Security Goes Beyond Traditional Cybersecurity

Traditional information security mainly focuses on servers, networks, applications, databases, and data.

AI systems introduce additional assets and risks:

AI model manipulation
Training-data poisoning
Unauthorized access to RAG data
Prompt injection
Sensitive information leakage
Model extraction
Adversarial attacks
Excessive AI privileges
AI supply-chain compromise
Insufficient AI monitoring

The AI Security Guidebook identifies 15 AI-specific security threats and maps them to 30 security measures.

This approach is broadly consistent with international AI-security work. NIST's Generative AI Profile recommends managing AI risks across the AI lifecycle, while OWASP's 2025 LLM security work highlights prompt injection, sensitive-information disclosure, supply-chain risks, data/model poisoning, and excessive agency among important risks.

3. The 30 Security Measures

The guidebook's M01–M30 controls can be understood as follows.

M01–M03: Secure Data and Components

M01 — Use data from trusted sources

Verify the identity and reliability of data providers and distributors before using external data.

M02 — Use AI models and libraries from trusted sources

Verify official distribution channels, digital signatures, hashes, versions, and provenance.

M03 — Inspect data

Check for malicious content, unauthorized sensitive information, abnormal values, poisoning, and AI backdoors before data is used.

The guidebook specifically recommends data integrity controls, anomaly detection, metadata, hashes, and change-history management.

M04–M07: Protect Sensitive Data

M04 — Encrypt data

Protect raw and training data against unauthorized disclosure or manipulation and manage encryption keys securely.

M05 — Control data access

Apply least privilege based on users, groups, datasets, and access paths.

M06 — Require prior approval for sensitive information

Establish an approval process before sensitive or confidential data is used for training or retraining.

M07 — Use training data appropriate to the security classification

The classification of training data should match the purpose and security level of the AI system. Public-facing systems should receive particularly careful treatment when internal or sensitive information is involved.

M08–M12: Logging, Inventory, and Integrity

M08 — Data logging and monitoring

Record access and modification activities involving raw and training data.

M09 — AI system logging and monitoring

Monitor user requests, AI responses, access history, unusual prompt patterns, and excessive calls.

M10 — Maintain data collection specifications

Track the source, collection date, method, size, hash, and history of datasets.

M11 — Maintain AI component specifications

Maintain an inventory of models, datasets, libraries, versions, hashes, and change histories.

M12 — Verify component integrity

Regularly verify models, datasets, and libraries against their trusted originals using hashes or digital signatures.

M13–M18: Secure the AI Interface and Network

M13 — Input/output filtering

Inspect both user inputs and AI outputs for sensitive information, prohibited content, and malicious patterns.

M14 — Limit input length and format

Restrict prompt length, file types, file sizes, and other input characteristics.

M15 — Use multiple guardrails

Do not rely on a single AI safety mechanism. Combine authentication, input filtering, policy enforcement, model controls, output filtering, and authorization.

M16 — Prevent leakage of model architecture and weights

Protect model information from unauthorized extraction.

M17 — Strengthen AI system boundary security

Pay particular attention to interfaces between internal and external networks.

M18 — Protect communication channels

Protect data exchanged between users, AI systems, and connected services.

M19–M21: Control AI Actions

M19 — Limit excessive privileges

Give AI only the permissions required for its intended function.

M20 — Require approval for sensitive commands

Important actions should require human review and approval.

M21 — Establish emergency response procedures

Organizations should be able to detect abnormal behavior, restrict AI functions, disconnect systems, and restore normal operation.

These measures become especially important when AI is connected to operational or control systems. The guidebook's AI water-treatment example recommends human intervention, network isolation, and continuous monitoring to prevent AI errors from causing safety incidents.

M22–M27: Test, Update, and Recover

M22 — Consider explainable AI

Important decisions should have mechanisms that help administrators understand or trace the basis of AI outputs.

M23 — Conduct adversarial testing

Test AI systems from an attacker's perspective before deployment.

M24 — Train or harden models against adversarial attacks

Consider attack patterns during model development and evaluation.

M25 — Check vulnerabilities and apply security updates

Continuously manage vulnerabilities in models, frameworks, libraries, operating systems, databases, and infrastructure.

M26 — Recover AI models

Maintain trusted model versions that can be restored after corruption or compromise.

M27 — Rate-limit requests

Limit excessive AI requests to reduce denial-of-service risks and uncontrolled resource consumption.

OWASP's 2025 LLM security work also highlights uncontrolled consumption and unexpected resource or cost impacts as an important risk area.

M28–M30: Disposal, Vendors, and People

M28 — Completely delete AI system components

Securely dispose of models, training data, backups, logs, and storage media.

M29 — Manage vendor security

Security requirements should apply to contractors throughout data collection, model development, deployment, operation, maintenance, and disposal.

M30 — Establish security policies and user training

Users should understand what information may be entered into AI services, what information must never be entered, and what security settings and approval procedures are required.

4. Security Priorities by Deployment Type

Internal-network-only AI

Key controls include:

Network separation
Security-classification-based data access
Least privilege
Human approval for sensitive actions
Continuous monitoring
Emergency response

The guidebook specifically emphasizes keeping important systems and data protected from unauthorized AI control or modification.

Internal AI connected to external networks

The major issue is the security of externally sourced data and the network boundary.

Recommended considerations include:

Trusted external data sources
Data inspection before use
Malware and poisoning detection
Boundary security
DMZ or intermediary systems where appropriate
Output inspection before sending data externally
Component integrity verification

Public-facing AI connected to internal networks

The greatest concern is that untrusted external users may interact with an AI system that has access to internal resources.

Important controls include:

Input filtering
Output filtering
Request-rate limiting
Security-classification-based data access
Network boundary protection
Logging and monitoring
Adversarial testing

The guidebook specifically highlights these measures for public-facing AI services connected to internal networks.

5. Commercial AI Services

When public organizations use commercial AI services, users may enter text, documents, images, or other information.

The guidebook therefore recommends particular attention to:

Preventing sensitive information input
Input/output filtering
Logging and monitoring
Network boundary protection
Security settings
User education
Vendor security management

It also recommends using only data that can appropriately be disclosed and considering controls that prevent organizational information from being used improperly for model improvement or training.

6. A Practical Implementation Process

For a public-sector AI project, a practical security process can be summarized as:

1. Define the AI purpose

↓
2. Identify the deployment type

↓
3. Classify all data

↓
4. Define minimum AI privileges

↓
5. Design input/output controls

↓
6. Design logging and monitoring

↓
7. Conduct adversarial security testing

↓
8. Establish emergency shutdown and recovery

↓
9. Continuously manage vulnerabilities and updates

↓
10. Securely dispose of models and data

This lifecycle-oriented approach is consistent with the broader direction of NIST AI RMF, which treats AI risk management as an ongoing activity across the AI lifecycle rather than a one-time security check.

7. Security by Design Should Start Before Development

One of the most important messages in the AI Security Guidebook is that security should be incorporated from the planning stage.

Before collecting data or training a model, organizations should define:

AI objectives
Required functions
Data classifications
Security requirements
Access permissions
Network boundaries
Monitoring requirements
Emergency response procedures
Model and data disposal procedures

In other words, public organizations should ask not only:

“What can this AI do?”

but also:

“What must this AI never be allowed to do?”

This distinction is particularly important when AI is connected to internal administrative systems or operational infrastructure.

Conclusion

The central message of Chapter 2 of the AI Security Guidebook is simple:

AI security is not merely model security. It is the security of the entire AI system.

For national and public organizations, this means protecting:

Data + AI Models + Infrastructure + Users + Privileges + Network Boundaries + Supply Chain + Monitoring + Recovery + Disposal

The guidebook provides 30 security measures and deployment-specific recommendations to help organizations apply this principle in practice.

International frameworks such as NIST AI RMF, OWASP's LLM security guidance, and ISO/IEC 42001 also reinforce the importance of lifecycle-based AI risk management, organizational controls, secure design, and continuous improvement.

For public-sector IT and security professionals, the practical lesson is therefore clear:

Do not treat AI security as a final inspection after the AI system has been built. Design security into the AI system from planning and data collection through model development, deployment, operation, maintenance, and final disposal.