A cloud delivery model where AI capabilities are consumed through APIs, SDKs, or managed tools instead of being built and hosted internally. For security teams, the important issue is not the model alone but the identities, permissions, and data paths used to invoke it.
Expanded Definition
AI as a Service, often shortened to AIaaS, is a consumption model in which an organisation invokes hosted AI capabilities through APIs, SDKs, or managed platforms rather than operating the model stack itself. In NHI security, the critical concern is not whether the model is proprietary or open source, but which machine identities, secrets, and service-to-service permissions are allowed to call it.
Definitions vary across vendors because AIaaS can refer to foundational model APIs, managed copilots, embedding services, or workflow agents exposed by cloud providers. That ambiguity matters: a simple inference API may carry different identity, logging, and data exposure risks than an agentic workflow that can read mailboxes, query SaaS systems, and trigger actions. NHI Management Group treats AIaaS as an execution surface that must be governed like any other privileged external dependency, with explicit scoping, auditability, and data minimisation. Mapping that surface to controls in the NIST Cybersecurity Framework 2.0 helps security teams anchor ownership, monitoring, and response.
The most common misapplication is treating AIaaS as a generic SaaS subscription, which occurs when teams grant broad API keys and trust the provider to handle identity, data handling, and least privilege end to end.
Examples and Use Cases
Implementing AIaaS rigorously often introduces dependency and egress-control constraints, requiring organisations to weigh rapid capability access against tighter credential governance and data handling rules.
- A software team uses a hosted text-generation API for customer support drafting, but limits the service account to a single project, rotates its secret, and logs every prompt and response for review.
- A security operations group connects an AI summarisation service to ticketing and chat systems, but restricts write actions so the service can suggest responses without creating or closing incidents.
- An enterprise uses embedding endpoints to classify internal documents, while blocking sensitive files from leaving approved repositories and validating retention settings before upload.
- A product team adopts an AI agent service that can call downstream tools, but applies just-in-time approval for high-impact actions and reviews the resulting permissions as a privileged integration.
- An organisation studies compromise patterns such as the LLMjacking research and related DeepSeek breach reporting to understand how exposed credentials and mismanaged access can turn AI consumption into attacker infrastructure.
These patterns align with public guidance from the NIST Cybersecurity Framework 2.0, especially where identity, logging, and third-party risk intersect.
Why It Matters in NHI Security
AIaaS expands the blast radius of a single credential because the same secret may unlock inference, retrieval, data upload, and tool execution in one external service. That makes the NHI problem larger than model choice: a compromised service account can expose prompts, training inputs, downstream connectors, and privileged automation paths. NHI Management Group research shows the operational cost of secret weakness is already high, with the average estimated time to remediate a leaked secret at 27 days, even as many organisations believe their secrets management is mature. In practice, AIaaS often becomes the place where those assumptions fail first.
Security teams also need to account for how fast attackers move once credentials surface. The LLMjacking research shows exposed AWS credentials are often probed within minutes, which is why AIaaS integrations must be monitored like high-value NHI dependencies rather than ordinary app plugins. Where AI services are embedded into business workflows, mis-scoped access can quietly bypass human approval chains and data boundaries. Organisations typically encounter the full impact only after a secret leak, abnormal spend spike, or unauthorized tool action, at which point AI as a Service becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | AIaaS relies on secrets and service identities that fall under NHI secret management risks. |
| NIST CSF 2.0 | PR.AC | AIaaS access control, logging, and third-party exposure map directly to identity governance. |
| NIST AI RMF | AIaaS introduces data, misuse, and accountability risks covered by AI risk management guidance. |
Treat AIaaS endpoints as privileged services and enforce least privilege, monitoring, and auditability.
