AIS-10Cloud & AI Related

API Security

Specification

Define and implement processes, procedures, and technical measures to secure APIs. Review and update for any improvements at least annually or after significant system changes.

Threat coverage

Model manipulation

Data poisoning

Sensitive data disclosure

Model theft

Model/Service Failure

Insecure supply chain

Insecure apps/plugins

Denial of Service

Loss of governance

Architectural relevance

Physical infrastructure

Network

Compute

Storage

Application

Data

Lifecycle

Preparation

Team and expertise, Resource provisioning

Development

Guardrails, Design

Evaluation

Validation/Red Teaming

Deployment

AI applications, Orchestration

Delivery

Continuous monitoring, Maintenance, Operations

Retirement

Archiving

Ownership / SSRM

Shared Cloud Service Provider-Model Provider (Shared CSP-MP)

The CSP and MP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.

Model

Shared Cloud Service Provider-Model Provider (Shared CSP-MP)

Orchestrated

Shared Model Provider-Orchestrated Service Provider (Shared MP-OSP)

The MP and OSP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.

Application

Owned by the Application Provider (AP)

The Application Provider (AP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer. The AP is responsible and accountable for the implementation of the control within its own infrastructure/environment. If the control has downstream implications on the users/customers, the AP is responsible for enabling the customer and/or upstream partner in the implementation/configuration of the control within their risk management approach. The AP is accountable for carrying out the due diligence on its upstream providers (e.g MPs, Orchestrated Services) to verify that they implement the control as it relates to the service/product develop and offered by the AP. These providers build and offer end-user applications that leverage generative AI models for specific tasks such as content creation, chatbots, code generation, and enterprise automation. These applications are often delivered as software-as-a-service (SaaS) solutions. These providers focus on user interfaces, application logic, domain-specific functionality, and overall user experience rather than underlying model development. Example: OpenAI (GPTs,Assistants), Zapier, CustomGPT, Microsoft Copilot (integrated into Office products), Jasper (AI-driven content generation), Notion AI (AI-enhanced productivity tools), Adobe Firefly (AI-generated media), and AI-powered customer service solutions like Amazon Rufus, as well as any organization that develops its AI-based application internally.

Implementation guidelines

[Applicable to all providers (CSP, MP, OSP, AP) excluding AIC unless otherwise specified]
1. Establish provider-specific policy scopes for securing APIs, covering authorization, key management, testing, and threat mitigation across the API lifecycle (design, implementation, deployment, monitoring). Ensure policies address unique API risks like injection, abuse, or exposure.

2. Define roles for API security oversight, involving cross-functional teams (e.g., security engineers, API developers, compliance). Set approval workflows with senior management and security leads to align measures with organizational risk goals.

3. Create structured documentation standards for API security measures, including procedures for key management, authorization protocols, testing schedules, and threat mitigation. Use templates to document controls, risk assessments, and remediation steps consistently.

4. Implement a review process for API security measures. Conduct reviews and updates at least annually or after significant changes (e.g., new API endpoints, vulnerabilities, dependency updates). Align with standards like OWASP API Security Top 10, NIST SP 800-53, and applicable laws (e.g., GDPR, CCPA).

5. Define requirements for communicating API security policies: distribute formal documentation, mandate training for API developers and operators, and run awareness campaigns. Ensure accessibility via internal portals and comprehension across teams.

6. Set policies for API security quality assurance, including requirements for secure API design (e.g., rate limiting, input validation), regular testing (e.g., penetration testing, fuzzing), and monitoring (e.g., anomaly detection). Require audit logs for API access and usage.

Auditing guidelines

1. Evaluate API Security Baseline Controls: Review access control layers (IAM policies), network restrictions (VPC service controls), and token scopes.

2. Review Customer-Facing API Documentation: Verify published APIs clearly outline security best practices (e.g., scope minimization, rate limits).

3. Inspect Abuse Detection and API Throttling: High-availability APIs are attractive targets for DDoS or misuse. Validate enforcement of automatic throttling, blacklisting, or behavior-based blocks.

4. Check for Secure Defaults in API Creation: Developers often accept defaults. Ensure APIs are created with HTTPS-only access, key rotation enabled, and default quotas set.

5. Assess Regular Review and Change Management: Confirm APIs are reviewed post-update and that customer notifications are issued for security-impacting changes.

Standards mappings

ISO 42001Partial Gap

42001: 6.1 - Actions to address risks and opportunities
27001: 6.1 - Actions to address risks and opportunities
27001: A.5.15 - Access control
27001: A.5.20 - Addressing information security within supplier agreements
27001: A.5.21 Managing information security in the information and communication technology (ICT) supply
chain
27001: A.8.21 - Security of network services
27001: A.8.24 - Use of cryptography
27001: A.8.26 - Application security requirements

Addendum

Add a dedicated API security control, ideally linked to AI-specific risks and integration points.

EU AI ActNo Gap

Article 15 (5)
Article 53 and Annex XI
Article 55

Addendum

N/A

NIST AI 600-1Partial Gap

GV-6.1-009
MS-2.6-006
MS-2.7-007
MS-2.10-001
MS-2.7-009

Addendum

NIST AI 600-1 is missing specific security requirements for APIs and a requirement to perform the reviews annually.

BSI AIC4Full Gap

Not Applicable

Addendum

No concrete implementation guidelines to specific API methods.

AI-CAIQ questions (2)

AIS-10.1

Are processes, procedures and technical measures to secure APIs, including authorization flaws, API key management, regular security testing, defined, implemented and evaluated?

AIS-10.2

Are technical measures for any improvements reviewed and updated at least annually or after significant system changes?