An AI environment is a set of APIs. The model is reached over one, the retrieval service exposes another, the connectors consume half a dozen more, and anything the system can act on is reached the same way.
Which means most of what goes wrong here is not novel. It is the failure set the OWASP API Security Top 10 has described for years, arriving in a context where teams are thinking about models rather than about interfaces.
The ordinary failures, in an AI setting
Authorization at the object level
API1:2023 Broken Object Level Authorization is the most common serious API flaw, and it is the same defect described in AI identity and access management wearing different clothes: a request that names a resource, served without checking whether this caller may have that resource.
In an AI environment it appears wherever a retrieval or connector endpoint accepts a document identifier, a conversation identifier or a source reference. A conversation history endpoint that returns any thread by id is the version that shows up most often, because history feels like a display feature rather than an access decision.
Authentication on internal services
API2:2023 Broken Authentication. The retrieval service and the model gateway are frequently built as internal components and deployed with weak or absent authentication because they sit inside the network. That is precisely the assumption zero trust exists to remove, and the components in question can read a large proportion of organizational knowledge.
Consumption without limits
API4:2023 Unrestricted Resource Consumption, which OWASP's LLM list mirrors as LLM10:2025 Unbounded Consumption. Model calls cost money per request, so the failure mode has a financial dimension that ordinary APIs do not: an unauthenticated or unrate-limited endpoint is a spending vulnerability as well as an availability one, and the bill is the first indication.
Configuration
API8:2023 Security Misconfiguration. Permissive cross origin rules, debug endpoints left reachable, verbose errors returning stack traces or fragments of prompts, and default credentials on a serving component installed quickly for a pilot that then became production.
Inventory
API9:2023 Improper Inventory Management. AI projects proliferate endpoints quickly, across teams, and an endpoint nobody has listed is an endpoint nobody is patching. The pilot deployed to prove a concept, still running, still holding credentials, is the archetype.
Credentials, which is where the real exposure sits
An AI environment integrated with six systems is a place where six systems' credentials live. That concentration is the security property that matters most, and it is rarely stated when the integrations are being agreed.
The controls are unglamorous and well established. Secrets in a managed secrets store rather than in configuration files, environment variables committed to a repository, or the prompt itself. Distinct credentials per integration, so that scope can be reasoned about and one can be revoked without taking down the rest. Rotation that has actually been performed once, rather than a rotation policy that has never been exercised. And scopes reviewed against what the integration does, because a connector granted write access for a feature that was never built keeps it indefinitely.
NIST's SP 800-53 covers identification, authentication and system communications protection for systems of any sensitivity. None of it is AI specific and all of it applies.
Outbound is a control point too
Most API security attention faces inward. An AI environment also makes outbound calls, to model providers and to whatever tools it can invoke, and that direction deserves its own controls.
Restricting which external endpoints the environment may reach turns an exfiltration path into a blocked connection. It also constrains a specific and under-appreciated risk: where the system can fetch a URL, an instruction inside retrieved content can direct it to fetch one chosen by somebody else. That is server side request forgery, API7:2023, reached through the model rather than through a parameter, and an allowlist of reachable destinations is the control that does not depend on detecting the instruction.
The gateway pattern, and what it is worth
Where more than one application uses AI, routing model traffic through a single internal service is worth the component it adds. It gives one place to hold provider credentials, apply authentication and rate limits, record usage, and switch providers or versions without changing every application.
The caution is that a gateway concentrates. It holds the credentials, sees every prompt and response, and becomes a single point of failure for anything depending on it. It is a component that deserves the treatment given to an authentication service rather than to an internal utility, and it should not be built before there is more than one consumer to justify it.
Validate what comes back
Model output is generated text, and where it is used for anything beyond display it is untrusted input. OWASP calls this LLM05:2025 Improper Output Handling in its Top 10 for LLM Applications, and the failure is familiar: text reaching a browser, a shell, a query or an onward API call without validation is an injection vector regardless of which component produced it.
Output that is parsed as structured data needs schema validation, because a model asked for JSON returns something JSON-shaped rather than something guaranteed to conform. Output used to construct a call to another system needs the same treatment any user supplied parameter would get. The relevant question is never whether the model is trustworthy; it is what happens when the text is wrong.
Logging at the interface
The API layer is a good place to record what happened, because it sees every call regardless of which application made it: who called, what was asked, which model and version answered, how long it took and what it cost.
Two cautions. Request and response bodies contain the sensitive material, so logging them wholesale creates a store that needs its own protection, covered in AI logging, monitoring and auditing. And error responses should not carry internal detail outward: a stack trace or a fragment of a system prompt in an error body is a disclosure, and OWASP tracks the second as LLM07:2025 System Prompt Leakage.
What a pilot leaves behind
Almost every AI environment starts as a proof of concept, and proofs of concept are built to demonstrate rather than to survive. The specific residue is predictable enough to look for deliberately.
A credential issued to whoever built it, still working, attached to no owner. An endpoint reachable from more of the network than intended, because restricting it was not necessary for the demonstration. Broad connector scopes granted to avoid debugging permissions during a two week trial. No rate limit, because there was one user. And no entry in any inventory, because the pilot was never expected to still be running.
The dangerous property is that the pilot frequently becomes production without a decision being taken, so nothing triggers the review that a new production system would get. Treating the transition as an event, with the six checks below applied to it, is the cheapest control available here.
A short assessment
- List every AI related endpoint, including pilots. The list is usually longer than expected.
- For each, establish what authenticates the caller and what authorizes the specific resource.
- Find where provider credentials live, and confirm rotation has been done rather than planned.
- Establish whether outbound destinations are restricted, and to what.
- Check whether rate and cost limits exist per caller rather than only in aggregate.
- Read an error response and see what it reveals.
Six questions, each with a factual answer. The ones without an answer are the finding.
Where to go next
The authorization model behind these interfaces is AI identity and access management, and the retrieval pipeline they serve is secure RAG architecture. Where the caller is a system permitted to act rather than a person asking a question, securing AI agents in the enterprise covers what changes. The wider environment is how to build a private AI environment, and the surrounding security practice is our Security capability.
LABUSA reviews this surface as part of integrating AI with business systems. Get in touch to discuss an assessment.
Sources and further reading
- OWASP, API Security Top 10, 2023 edition, including API1 Broken Object Level Authorization, API2 Broken Authentication, API4 Unrestricted Resource Consumption, API7 Server Side Request Forgery, API8 Security Misconfiguration and API9 Improper Inventory Management.
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications, 2025, including LLM05 Improper Output Handling, LLM07 System Prompt Leakage and LLM10 Unbounded Consumption.
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5.
Both OWASP lists are community security guidance, authoritative on threats and mitigations rather than on regulatory obligation. Every source above was opened and read on 20 August 2026.