Spots 
The API is the primary boundary through which clients, applications, AI agents, workers, integrations, and external systems interact with a secure AI platform. A modern AI platform may expose APIs for: Every API endpoint therefore represents a potential security boundary.
A secure API architecture must enforce security consistently rather than relying on individual developers to remember every control for every endpoint. This chapter establishes a reusable API security architecture covering: Authentication middleware A typical secure request pipeline is: The exact ordering may vary for individual controls, but the principle is consistent: Security should be enforced systematically before sensitive business operations execute. Security should be enforced systematically before sensitive business operations execute. API traffic should use HTTPS. TLS protects data while moving between: It protects against network-level interception of: authentication credentials generated content metadata Production APIs should not expose sensitive functionality over unencrypted HTTP. HTTP can generally be redirected to HTTPS at the edge where appropriate.
The API gateway provides a centralized enforcement point. Potential responsibilities include: However, the gateway should not become the only authorization boundary. Application services must still enforce business authorization. Authentication middleware establishes the identity associated with a request. The resulting context might contain: The identity context should be generated from trusted authentication data. A request context can be represented conceptually as: This context should be treated as server-generated security state. Client-supplied values should not override it. Is this caller allowed to perform this operation? Is this caller allowed to perform this operation? Authorization can operate at multiple levels: RBAC assigns permissions through roles. Roles should not automatically provide unrelated permissions. For complex applications, permissions can be more precise.
This allows policies to be composed more precisely than relying entirely on broad roles. An endpoint may require both: This helps prevent IDOR/BOLA vulnerabilities. A typical API request may follow:
Not every endpoint requires every step, but the application should have explicit policies rather than accidental behavior. Some endpoints may intentionally be public. Public endpoints still require: Public does not mean unrestricted. Authentication endpoints deserve special protection because they are attractive to automated attackers. credential abuse detection generic authentication errors API keys are useful for machine-to-machine or developer integrations. A key can conceptually contain: The secret should not be stored unnecessarily in plaintext. Where practical, store a protected representation that allows verification without exposing the original secret. A useful API-key architecture separates: The key ID helps identify which credential is being used. The secret provides authentication.
This allows the server to efficiently locate metadata without storing the entire secret in searchable plaintext. API keys should have minimal permissions. for a key used only by a generation service. Least privilege reduces the impact of credential compromise. A key should not remain valid indefinitely unless there is a documented reason and compensating controls. Users should be able to revoke compromised keys. A safe rotation workflow is: This allows services to migrate without unnecessary downtime. For production systems, overlapping validity for a controlled migration period may be useful. OAuth 2.0 is an authorization framework. OpenID Connect builds an identity layer on top of OAuth 2.0. These technologies can support: The platform should distinguish authentication from delegated authorization.
For browser-based applications, a common architecture uses an authorization-code-based flow with appropriate protections. Modern implementations should use PKCE where applicable to protect the authorization flow. When accepting an identity from an OIDC provider, the platform should validate relevant token properties such as: The application should not simply trust arbitrary identity claims received from the client. Users may connect multiple identity providers to one account.
Account linking should require sufficient authentication to prevent an attacker from attaching their own external identity to a victim's account. Cross-Origin Resource Sharing controls browser-origin access. A secure API should explicitly define allowed origins. rather than broadly allowing arbitrary origins. When cookies or credentials are involved, CORS configuration becomes particularly sensitive. Cookie-based authentication requires protection against cross-site request forgery. Referer validation where appropriate avoiding state changes through GET strict CORS configuration State-changing operations should normally use methods such as: Every API endpoint should validate: Validation should occur before business logic. The server should reject unexpected or invalid input. Static TypeScript types do not validate external network input.
This is unsafe to assume: because an HTTP request can still contain: Runtime schemas should validate actual network data. Common approaches include schema-validation libraries or equivalent server-side validation systems. For security-sensitive operations, prefer explicit fields. Instead of accepting arbitrary JSON: and reject or ignore unauthorized fields according to the API contract. This helps prevent mass-assignment vulnerabilities. Endpoints should verify expected content types. An endpoint designed for JSON should not blindly parse arbitrary content. Content-type enforcement can also reduce unexpected parser behavior. Every endpoint should have an appropriate maximum request size.
The API is the primary boundary through which clients, applications, AI agents, workers, integrations, and external systems interact with a secure AI platform.