what they can call. AI security is a content problem: control what the model says and
on what basis. These require different architectures. Applying one to the other leaves
a system that looks secure and is not.
The Threat Model Has Changed
An enterprise API that returns wrong data because of a misconfigured query is a
bug. An enterprise AI assistant that generates confidently wrong guidance — citing a
maintenance procedure that does not apply to the asset being serviced, or referencing
a regulation that was superseded — is a safety and liability risk.
The threat categories unique to AI systems that do not exist for conventional APIs:
- Prompt injection: a crafted input that instructs the model to
override its system prompt, reveal out-of-scope data, or act outside its defined
boundary. Unlike SQL injection, there is no sanitiser that neutralises this completely.
The model’s instruction-following capability is the vulnerability. - Scope leakage through retrieval: if the RAG retrieval layer is not
scoped to the caller’s authorised data, the model may include documents from other
tenants, roles, or domains in its response — without knowing it should not. - Hallucination as incorrect advice: in operational contexts,
plausible-but-wrong outputs have direct consequences. A wrong diagnosis. A wrong
configuration recommendation. A wrong compliance interpretation. - Excessive agency: an AI that can take write actions — create records,
trigger workflows, send messages — has a blast radius proportional to its action scope.
Incorrect reasoning leads to incorrect actions.
The Architecture Response
Security is enforced in the retrieval layer, not the prompt. The model receives only the data the caller is authorised to see. Azure AI Content Safety screens all inputs and outputs. Every LLM call is logged with full context to an immutable audit store. AI systems begin as read-only and advise-only — write actions are introduced only after trust is established through observed behaviour.
The retrieval scoping principle is the most important: the model cannot be trusted to
enforce data boundaries because it is a generative system. It will use whatever context
it receives. The access control decision must happen before the model sees anything.
The control sequence at IBM watsonx deployments and Azure OpenAI implementations
I have worked on:
- API gateway validates the caller’s identity token and resolves their roles.
- The AI orchestrator constructs a scoped retrieval query — filtered to the caller’s
authorised data domain, site, and role. - Azure AI Search applies document-level access filters. Out-of-scope documents are
never retrieved regardless of query relevance. - The model generates from a context it received only because the caller was authorised
to see it.
There is no prompt engineering that bypasses step 3. That is the point.
Content Safety Is Not Optional
Azure AI Content Safety runs on all inputs before they reach the model and on all
outputs before they reach the user. It detects injection patterns, jailbreak attempts,
and disallowed content categories. In IBM watsonx deployments, the equivalent governance
controls are applied through the platform’s built-in guardrails configuration.
Groundedness evaluation is a separate check: a secondary inference call that assesses
whether the model’s response is supported by the retrieved context. Below threshold,
the response is replaced with a transparent fallback. An AI that says “I cannot answer
this from the available data” is not failing. It is working correctly.
On audit trails: build the audit log before you need it for an investigation, not after. Every LLM call — user identity, query, retrieved chunks, system prompt version, generated response — logged immutably. When a compliance review asks “what did the AI advise about this incident last Tuesday,” you should be able to answer in under a minute.
Minimal Action Scope as a Trust Strategy
The AI assistants I have designed begin as read-only systems. They advise; they do not
act. Recommendations are structured suggestions presented to a human who takes action
through the appropriate authorised channel. This is not a limitation imposed by lack of
confidence in the technology. It is a deliberate strategy for building the evidence base
needed to justify expanding the action scope over time. Trust in AI systems is earned
through observed behaviour — not assumed at launch.