API Security for AI Services
5 minutes
5 Questions
API Security for AI Services addresses the protection of the programmatic interfaces through which AI models are exposed, consumed, and orchestrated. In modern AI deployments, models are rarely accessed directly; instead, they are wrapped in REST, gRPC, or GraphQL APIs that handle inference requests, fine-tuning jobs, embedding generation, and agent tool calls. These APIs become the primary attack surface, so securing them is central to AI Security Management. Key controls begin with strong authentication and authorization. API keys alone are insufficient; mature deployments use OAuth 2.0, mutual TLS, short-lived tokens, and fine-grained scopes that restrict which models, versions, or capabilities a client may invoke. Rate limiting and quota enforcement are essential, both to control cost and to mitigate model extraction attacks, where adversaries issue many queries to reconstruct or clone a proprietary model. Input validation and output filtering are AI-specific extensions of classic API hygiene. Requests must be inspected for prompt injection, oversized payloads, malicious file uploads, and encoded instructions, while responses should be screened for sensitive data leakage, harmful content, and unintended tool invocations. Schema enforcement and content moderation layers act as guardrails at the API boundary. Observability is another pillar: comprehensive logging of requests, responses, token usage, latency, and anomaly scores supports forensic analysis, abuse detection, and compliance evidence. Logs themselves must be protected, since they may contain confidential prompts or personal data, requiring redaction and retention policies. Supply chain considerations matter when consuming third-party AI APIs. Organizations should vet providers for data residency, training-on-customer-data policies, encryption in transit and at rest, and incident disclosure commitments. Gateway architectures, such as an AI gateway or API management layer, centralize policy enforcement, key rotation, and model routing while abstracting vendor differences. Ultimately, API security for AI services integrates traditional API security practices with AI-specific threat models, such as those described in the OWASP Top 10 for LLM Applications, ensuring confidentiality, integrity, and availability of intelligent systems.
API Security for AI Services (ISACA AAISM – AI Technologies and Controls)
Why API Security for AI Services Matters
Almost every modern AI capability is delivered through an Application Programming Interface (API). Organisations call third-party foundation models (such as hosted large language models) over REST or gRPC endpoints, expose their own models to internal applications and partners through APIs, and chain multiple AI services together using API-driven orchestration. This means the API layer has become the primary attack surface for AI systems. If the API is weak, the model, the data it processes, and the business logic behind it are all exposed – regardless of how well the model itself was trained or tested.
From an AAISM perspective, API security sits at the intersection of classic application security and AI-specific risk. A compromised AI API can lead to data leakage (training data, prompts, personal data), model theft through extraction attacks, financial loss through abuse of pay-per-token services (sometimes called denial of wallet), prompt injection delivered via API parameters, unauthorised model use, and regulatory non-compliance. Security managers must therefore treat AI APIs as critical assets with their own threat model, controls, and governance.
What API Security for AI Services Is
API security for AI services is the set of policies, architectural patterns, technical controls, and monitoring practices that protect the interfaces through which AI models are consumed and exposed. It covers three directions of traffic:
1. Outbound consumption – your organisation calling external AI providers (for example, an LLM vendor API). Key concerns: key management, data sent to the provider, contractual and privacy obligations, and dependency risk.
2. Inbound exposure – your organisation publishing its own AI model or AI-enabled service to users, customers, or partners. Key concerns: authentication, authorisation, abuse prevention, output filtering, and availability.
3. Internal integration – AI agents, plug-ins, tools, and microservices communicating with each other and with enterprise systems. Key concerns: least privilege, trust boundaries, and uncontrolled autonomous actions.
The discipline draws heavily on the OWASP API Security Top 10 (e.g., Broken Object Level Authorisation, Broken Authentication, Unrestricted Resource Consumption, Security Misconfiguration) and on the OWASP Top 10 for LLM Applications (e.g., Prompt Injection, Sensitive Information Disclosure, Insecure Plugin Design, Model Denial of Service, Model Theft). AAISM candidates should be able to connect these two frameworks.
How It Works – Core Control Areas
1. Authentication and Credential Management
Every call to an AI API should be authenticated. Common mechanisms include API keys, OAuth 2.0 bearer tokens, mutual TLS (mTLS), and signed requests. The management priority is the lifecycle of credentials: generate them securely, store them in a secrets vault (never in source code, client-side applications, or notebooks), rotate them regularly, scope them narrowly, and revoke them immediately on compromise or staff departure. Hard-coded AI provider keys leaking through public code repositories is one of the most frequent real-world incidents.
2. Authorisation and Least Privilege
Authentication proves who is calling; authorisation decides what they may do. Controls include role-based or attribute-based access control, per-model and per-function scopes, tenant isolation in multi-tenant AI platforms, and object-level checks so one user cannot retrieve another user's conversation history, fine-tuned model, or uploaded documents. For AI agents that call tools, authorisation must bound which actions the agent may invoke and on which data, preventing excessive agency.
3. Input Validation and Prompt Handling
AI APIs accept free-form natural language, which cannot be validated like a structured field. Controls still apply: enforce schema validation on the request envelope (JSON structure, parameter types, size limits), restrict allowed parameters (temperature, system prompt override, tool selection), sanitise or isolate untrusted content before it is combined with system instructions, and deploy prompt-injection detection layers. Separate the control plane (system prompts, configuration) from the data plane (user content) so that users cannot alter model behaviour through the API.
4. Output Filtering and Data Loss Prevention
Responses from an AI API can contain sensitive data, harmful content, hallucinated instructions, or code. Controls include output content moderation, redaction of personal or confidential data, DLP inspection on both requests and responses, and policies defining what data categories may be sent to external AI providers. Many organisations route all AI API traffic through a gateway or proxy that enforces these policies centrally.
5. Rate Limiting, Quotas and Abuse Prevention
AI inference is computationally expensive and often billed per token. Without limits, attackers can run up costs, degrade availability (model denial of service), or systematically query the model to reconstruct it (model extraction) or infer training data (membership inference). Controls include per-key and per-user rate limits, token and cost budgets, anomaly detection on query patterns, CAPTCHA or step-up authentication for suspicious clients, and alerting on spend thresholds.
6. Transport and Data Protection
All AI API traffic must use TLS 1.2 or higher, with certificate validation enforced. Consider mTLS for high-trust integrations, encrypt stored prompts and responses, apply retention limits to logs that contain user content, and verify the provider's data-handling commitments (for example, whether submitted data is used for model training). Data residency and cross-border transfer rules frequently apply to AI API calls.
7. API Gateway and Architecture Controls
A dedicated API gateway (or an AI-specific gateway sometimes called an LLM gateway or AI firewall) provides a single enforcement point for authentication, rate limiting, logging, routing, schema validation, and policy. It also supports vendor abstraction, allowing the organisation to switch providers or fail over without rewriting applications – an important resilience control given third-party dependency risk. Zero-trust principles apply: do not trust internal AI services by default; authenticate and authorise every hop.
8. Logging, Monitoring and Incident Response
Comprehensive logging of who called which model, when, with what parameters, and what was returned (subject to privacy constraints) is essential for forensics, audit, and compliance. Monitor for spikes in volume, unusual prompt patterns, repeated failed authentication, high error rates, and abnormal output categories. Integrate AI API telemetry into the SIEM and define playbooks for key compromise, injection attacks, data leakage, and provider outages.
9. Secure Development and Testing
Treat AI APIs like any production API: threat model them, include them in secure code review, run dynamic API security testing, perform AI red teaming (adversarial prompts, jailbreak attempts, extraction attempts), maintain an API inventory to eliminate shadow or zombie AI endpoints, and version and deprecate endpoints deliberately.
10. Third-Party and Supply-Chain Governance
When consuming external AI APIs, the organisation inherits the provider's risk. Due diligence should cover security certifications (e.g., SOC 2, ISO 27001), data usage and retention terms, availability SLAs, incident notification obligations, sub-processor transparency, and exit strategy. Contracts should be aligned with internal AI policies and applicable regulation.
How to Answer Exam Questions on API Security for AI Services
AAISM is a management-level certification. Questions rarely ask you to configure a specific product; they ask you to select the best control, the first step, the primary risk, or the most appropriate response from a governance and risk perspective. Apply the following reasoning pattern:
1. Identify the direction of traffic in the scenario: is the organisation consuming an external AI API, exposing its own, or integrating agents internally? Each has different dominant risks (data leakage and dependency for outbound; abuse and unauthorised access for inbound; excessive agency for internal).
2. Map the threat to a control category: unauthorised access points to authentication and authorisation; unexpected cost or outage points to rate limiting and quotas; leaked secrets point to key management and secrets vaults; manipulated model behaviour points to input validation and separation of system and user content; exposure of sensitive data points to output filtering and DLP.
3. Prefer preventive, centralised, and risk-based answers. ISACA generally favours a gateway or policy enforcement point over ad-hoc application-level fixes, least privilege over broad access, and risk assessment or threat modelling before purchasing tooling.
4. Distinguish root cause from symptom. If a question describes a leaked API key found in a public repository, the best long-term answer is usually to implement secrets management and scanning processes, with key rotation as the immediate action – not simply to delete the repository.
5. Consider governance, not only technology. Many correct answers involve policy (what data may be sent to external AI services), contracts (provider obligations), inventory (knowing all AI APIs in use), and monitoring (detecting misuse), rather than a purely technical fix.
Exam Tips: Answering Questions on API Security for AI Services
• Know the vocabulary: API key, OAuth 2.0, mTLS, API gateway, LLM gateway, rate limiting, token quota, denial of wallet, model extraction, membership inference, prompt injection, excessive agency, shadow API, zombie API, BOLA (Broken Object Level Authorisation). Questions often hinge on recognising which term describes the scenario.
• Remember that AI APIs are still APIs. If an answer option reflects a classic API security best practice (authenticate every call, validate inputs, encrypt in transit, log and monitor, apply least privilege), it is likely correct even in an AI context. Do not be distracted into thinking AI requires abandoning fundamentals.
• Recognise the AI-specific additions: free-form inputs that cannot be fully validated, outputs that may contain sensitive or harmful content, per-token cost exposure, model theft through query volume, and agents that take autonomous actions. When a question stresses one of these, choose the control designed for it (output filtering, cost quotas, query anomaly detection, bounded tool permissions).
• Watch for the words FIRST, BEST, PRIMARY, MOST. For FIRST, favour assessment, inventory, or classification steps. For BEST or MOST effective, favour the control that addresses root cause and is enforced centrally. For PRIMARY risk, choose the consequence most directly tied to the scenario rather than a secondary effect.
• Hard-coded or shared credentials are always wrong. Any option that stores API keys in client code, spreadsheets, or shared chat tools, or that reuses one key across teams, should be eliminated immediately.
• Third-party AI provider questions usually test due diligence, data-handling terms, data residency, and contractual controls. The organisation remains accountable for data it sends to a provider; outsourcing processing does not outsource responsibility.
• Rate limiting serves multiple purposes. If a question mentions cost overruns, availability degradation, or systematic probing of the model, rate limiting and quotas are frequently the intended answer, often paired with monitoring.
• Separation of system prompts from user input is the key architectural defence against prompt injection delivered through an API. If a scenario describes users altering model behaviour, look for options about isolating control instructions, restricting overridable parameters, and validating or filtering untrusted content.
• Logging must be balanced with privacy. If an option proposes logging full prompts and responses indefinitely without controls, consider whether a more balanced answer (redaction, retention limits, access controls on logs) is available.
• Think like a security manager, not an engineer. When in doubt, choose the answer that establishes a repeatable, policy-driven, auditable control supported by risk assessment, rather than a one-time technical patch.
Summary
API security for AI services protects the gateway through which AI value – and AI risk – flows. It combines established API security disciplines (authentication, authorisation, encryption, validation, rate limiting, logging, gateway architecture, and lifecycle management) with AI-specific concerns (prompt injection, output leakage, model extraction, cost abuse, agent permissions, and provider data handling). For the AAISM exam, anchor your answers in risk-based, centralised, preventive controls; recognise the AI-specific threats; and always favour governance-aligned solutions that address root causes over quick technical fixes.
Almost every modern AI capability is delivered through an Application Programming Interface (API). Organisations call third-party foundation models (such as hosted large language models) over REST or gRPC endpoints, expose their own models to internal applications and partners through APIs, and chain multiple AI services together using API-driven orchestration. This means the API layer has become the primary attack surface for AI systems. If the API is weak, the model, the data it processes, and the business logic behind it are all exposed – regardless of how well the model itself was trained or tested.
From an AAISM perspective, API security sits at the intersection of classic application security and AI-specific risk. A compromised AI API can lead to data leakage (training data, prompts, personal data), model theft through extraction attacks, financial loss through abuse of pay-per-token services (sometimes called denial of wallet), prompt injection delivered via API parameters, unauthorised model use, and regulatory non-compliance. Security managers must therefore treat AI APIs as critical assets with their own threat model, controls, and governance.
What API Security for AI Services Is
API security for AI services is the set of policies, architectural patterns, technical controls, and monitoring practices that protect the interfaces through which AI models are consumed and exposed. It covers three directions of traffic:
1. Outbound consumption – your organisation calling external AI providers (for example, an LLM vendor API). Key concerns: key management, data sent to the provider, contractual and privacy obligations, and dependency risk.
2. Inbound exposure – your organisation publishing its own AI model or AI-enabled service to users, customers, or partners. Key concerns: authentication, authorisation, abuse prevention, output filtering, and availability.
3. Internal integration – AI agents, plug-ins, tools, and microservices communicating with each other and with enterprise systems. Key concerns: least privilege, trust boundaries, and uncontrolled autonomous actions.
The discipline draws heavily on the OWASP API Security Top 10 (e.g., Broken Object Level Authorisation, Broken Authentication, Unrestricted Resource Consumption, Security Misconfiguration) and on the OWASP Top 10 for LLM Applications (e.g., Prompt Injection, Sensitive Information Disclosure, Insecure Plugin Design, Model Denial of Service, Model Theft). AAISM candidates should be able to connect these two frameworks.
How It Works – Core Control Areas
1. Authentication and Credential Management
Every call to an AI API should be authenticated. Common mechanisms include API keys, OAuth 2.0 bearer tokens, mutual TLS (mTLS), and signed requests. The management priority is the lifecycle of credentials: generate them securely, store them in a secrets vault (never in source code, client-side applications, or notebooks), rotate them regularly, scope them narrowly, and revoke them immediately on compromise or staff departure. Hard-coded AI provider keys leaking through public code repositories is one of the most frequent real-world incidents.
2. Authorisation and Least Privilege
Authentication proves who is calling; authorisation decides what they may do. Controls include role-based or attribute-based access control, per-model and per-function scopes, tenant isolation in multi-tenant AI platforms, and object-level checks so one user cannot retrieve another user's conversation history, fine-tuned model, or uploaded documents. For AI agents that call tools, authorisation must bound which actions the agent may invoke and on which data, preventing excessive agency.
3. Input Validation and Prompt Handling
AI APIs accept free-form natural language, which cannot be validated like a structured field. Controls still apply: enforce schema validation on the request envelope (JSON structure, parameter types, size limits), restrict allowed parameters (temperature, system prompt override, tool selection), sanitise or isolate untrusted content before it is combined with system instructions, and deploy prompt-injection detection layers. Separate the control plane (system prompts, configuration) from the data plane (user content) so that users cannot alter model behaviour through the API.
4. Output Filtering and Data Loss Prevention
Responses from an AI API can contain sensitive data, harmful content, hallucinated instructions, or code. Controls include output content moderation, redaction of personal or confidential data, DLP inspection on both requests and responses, and policies defining what data categories may be sent to external AI providers. Many organisations route all AI API traffic through a gateway or proxy that enforces these policies centrally.
5. Rate Limiting, Quotas and Abuse Prevention
AI inference is computationally expensive and often billed per token. Without limits, attackers can run up costs, degrade availability (model denial of service), or systematically query the model to reconstruct it (model extraction) or infer training data (membership inference). Controls include per-key and per-user rate limits, token and cost budgets, anomaly detection on query patterns, CAPTCHA or step-up authentication for suspicious clients, and alerting on spend thresholds.
6. Transport and Data Protection
All AI API traffic must use TLS 1.2 or higher, with certificate validation enforced. Consider mTLS for high-trust integrations, encrypt stored prompts and responses, apply retention limits to logs that contain user content, and verify the provider's data-handling commitments (for example, whether submitted data is used for model training). Data residency and cross-border transfer rules frequently apply to AI API calls.
7. API Gateway and Architecture Controls
A dedicated API gateway (or an AI-specific gateway sometimes called an LLM gateway or AI firewall) provides a single enforcement point for authentication, rate limiting, logging, routing, schema validation, and policy. It also supports vendor abstraction, allowing the organisation to switch providers or fail over without rewriting applications – an important resilience control given third-party dependency risk. Zero-trust principles apply: do not trust internal AI services by default; authenticate and authorise every hop.
8. Logging, Monitoring and Incident Response
Comprehensive logging of who called which model, when, with what parameters, and what was returned (subject to privacy constraints) is essential for forensics, audit, and compliance. Monitor for spikes in volume, unusual prompt patterns, repeated failed authentication, high error rates, and abnormal output categories. Integrate AI API telemetry into the SIEM and define playbooks for key compromise, injection attacks, data leakage, and provider outages.
9. Secure Development and Testing
Treat AI APIs like any production API: threat model them, include them in secure code review, run dynamic API security testing, perform AI red teaming (adversarial prompts, jailbreak attempts, extraction attempts), maintain an API inventory to eliminate shadow or zombie AI endpoints, and version and deprecate endpoints deliberately.
10. Third-Party and Supply-Chain Governance
When consuming external AI APIs, the organisation inherits the provider's risk. Due diligence should cover security certifications (e.g., SOC 2, ISO 27001), data usage and retention terms, availability SLAs, incident notification obligations, sub-processor transparency, and exit strategy. Contracts should be aligned with internal AI policies and applicable regulation.
How to Answer Exam Questions on API Security for AI Services
AAISM is a management-level certification. Questions rarely ask you to configure a specific product; they ask you to select the best control, the first step, the primary risk, or the most appropriate response from a governance and risk perspective. Apply the following reasoning pattern:
1. Identify the direction of traffic in the scenario: is the organisation consuming an external AI API, exposing its own, or integrating agents internally? Each has different dominant risks (data leakage and dependency for outbound; abuse and unauthorised access for inbound; excessive agency for internal).
2. Map the threat to a control category: unauthorised access points to authentication and authorisation; unexpected cost or outage points to rate limiting and quotas; leaked secrets point to key management and secrets vaults; manipulated model behaviour points to input validation and separation of system and user content; exposure of sensitive data points to output filtering and DLP.
3. Prefer preventive, centralised, and risk-based answers. ISACA generally favours a gateway or policy enforcement point over ad-hoc application-level fixes, least privilege over broad access, and risk assessment or threat modelling before purchasing tooling.
4. Distinguish root cause from symptom. If a question describes a leaked API key found in a public repository, the best long-term answer is usually to implement secrets management and scanning processes, with key rotation as the immediate action – not simply to delete the repository.
5. Consider governance, not only technology. Many correct answers involve policy (what data may be sent to external AI services), contracts (provider obligations), inventory (knowing all AI APIs in use), and monitoring (detecting misuse), rather than a purely technical fix.
Exam Tips: Answering Questions on API Security for AI Services
• Know the vocabulary: API key, OAuth 2.0, mTLS, API gateway, LLM gateway, rate limiting, token quota, denial of wallet, model extraction, membership inference, prompt injection, excessive agency, shadow API, zombie API, BOLA (Broken Object Level Authorisation). Questions often hinge on recognising which term describes the scenario.
• Remember that AI APIs are still APIs. If an answer option reflects a classic API security best practice (authenticate every call, validate inputs, encrypt in transit, log and monitor, apply least privilege), it is likely correct even in an AI context. Do not be distracted into thinking AI requires abandoning fundamentals.
• Recognise the AI-specific additions: free-form inputs that cannot be fully validated, outputs that may contain sensitive or harmful content, per-token cost exposure, model theft through query volume, and agents that take autonomous actions. When a question stresses one of these, choose the control designed for it (output filtering, cost quotas, query anomaly detection, bounded tool permissions).
• Watch for the words FIRST, BEST, PRIMARY, MOST. For FIRST, favour assessment, inventory, or classification steps. For BEST or MOST effective, favour the control that addresses root cause and is enforced centrally. For PRIMARY risk, choose the consequence most directly tied to the scenario rather than a secondary effect.
• Hard-coded or shared credentials are always wrong. Any option that stores API keys in client code, spreadsheets, or shared chat tools, or that reuses one key across teams, should be eliminated immediately.
• Third-party AI provider questions usually test due diligence, data-handling terms, data residency, and contractual controls. The organisation remains accountable for data it sends to a provider; outsourcing processing does not outsource responsibility.
• Rate limiting serves multiple purposes. If a question mentions cost overruns, availability degradation, or systematic probing of the model, rate limiting and quotas are frequently the intended answer, often paired with monitoring.
• Separation of system prompts from user input is the key architectural defence against prompt injection delivered through an API. If a scenario describes users altering model behaviour, look for options about isolating control instructions, restricting overridable parameters, and validating or filtering untrusted content.
• Logging must be balanced with privacy. If an option proposes logging full prompts and responses indefinitely without controls, consider whether a more balanced answer (redaction, retention limits, access controls on logs) is available.
• Think like a security manager, not an engineer. When in doubt, choose the answer that establishes a repeatable, policy-driven, auditable control supported by risk assessment, rather than a one-time technical patch.
Summary
API security for AI services protects the gateway through which AI value – and AI risk – flows. It combines established API security disciplines (authentication, authorisation, encryption, validation, rate limiting, logging, gateway architecture, and lifecycle management) with AI-specific concerns (prompt injection, output leakage, model extraction, cost abuse, agent permissions, and provider data handling). For the AAISM exam, anchor your answers in risk-based, centralised, preventive controls; recognise the AI-specific threats; and always favour governance-aligned solutions that address root causes over quick technical fixes.
Test mode:
AAISM - API Security for AI Services Example Questions
Test your knowledge of API Security for AI Services
Question 1
Which threat to an AI inference API is MOST amplified when each response returns the full per-class confidence scores rather than only the predicted label?
Question 2
An enterprise exposes a RAG-based LLM service to partners through an API gateway. The gateway authenticates each partner by API key and enforces quotas. One partner reports that responses cite source passages retrieved from another partner's uploaded contracts. Gateway logs show only that partner's valid, in-quota calls. Which design weakness MOST likely explains this exposure?
Question 3
An enterprise exposes a fine-tuned classification model to business partners through an authenticated API that returns full confidence scores for every prediction. Monitoring shows one partner key submitting very high volumes of systematically varied inputs, a pattern consistent with an attempt to replicate the model's behavior. Which control should the information security manager implement to BEST reduce this risk?
Unlock Premium Access
Advanced in AI Security Management
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 3073 Superior-grade Advanced in AI Security Management practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- AAISM: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More API Security for AI Services questions
21 questions (total)
Other AI Technologies and Controls concepts
AI Architecture Within Enterprise ArchitectureAI Development Life Cycle Security TouchpointsAI System Components and Attack SurfaceArchitecture Review and Security Sign-Off for AIContent Safety Filters and GuardrailsControl Testing, Assurance and Continuous ValidationCross-Border Data Transfer and Residency for AIData Access Controls and Segregation for AI PipelinesData Classification and Handling for AIData Leakage Prevention for AI Inputs and OutputsData Minimization, Anonymization and PseudonymizationData Provenance, Lineage and Labeling ControlsData Quality, Integrity and Validation ControlsData Retention, Deletion and Unlearning RequestsDetection and Response Integration for AI SystemsEncryption of AI Data at Rest, in Transit and in UseEthical Review and Responsible AI AssessmentExplainability and Interpretability ControlsFairness and Bias Testing ControlsFine-Tuning and Prompt Engineering SecurityIdentity and Access Management for Models and DataInput Validation and Prompt Filtering ControlsKill Switches, Circuit Breakers and Fallback ModesLogging, Auditing and Traceability of AI InteractionsMaintenance, Retraining and Drift ResponseMapping Security Controls to AI RiskMLOps and LLMOps Security ControlsModel Cards, Datasheets and AI DocumentationModel Decommissioning and Secure RetirementModel Selection: Build, Buy, Fine-Tune or PromptModel Validation, Testing and Acceptance CriteriaModel Versioning, Change Management and RollbackMonitoring Model Behavior and Anomaly DetectionOutput Filtering, Moderation and ValidationPre-Deployment Security Testing of AI ModelsPreventive, Detective and Corrective Controls for AIPrivacy by Design for AI SystemsPrivacy-Enhancing Technologies for AIRate Limiting, Quotas and Abuse PreventionRisk-Based Human Oversight of AI Inputs and OutputsRobustness and Reliability ControlsSecrets, Keys and Model Artifact ProtectionSecure Deployment and Release of AI ModelsSecure Deployment: Cloud, On-Premises and Edge AISecure Training Environments and PipelinesSecuring AI Agents, Tools and PluginsSecuring LLM Applications and RAG PipelinesSecurity Architecture Patterns for AI ApplicationsSecurity by Design and Threat-Informed RequirementsSecurity Metrics and Dashboards for AI ControlsSynthetic Data and Its Security ImplicationsTraining Data Security and Integrity ControlsTransparency, Disclosure and User NotificationTrust and Safety Operations for Generative AIZero Trust and Segmentation for AI Workloads