A conventional content management system has a reasonably contained security problem: authenticate users, authorise what they may read and edit, keep the software patched. An AI content platform keeps all of that and adds three things that change the shape of the risk.
It reads across systems, so a single weakness reaches further than the system it is in. It sends content to somewhere it is processed, which may not be somewhere you control. And it assembles answers, which means it can combine fragments that were individually harmless into something that is not.
Retrieval is the new attack surface
The most consequential security property of these platforms is that a system able to find content on a user's behalf is a system able to disclose content on a user's behalf. Everything else follows from taking that seriously.
The control is permission-aware retrieval: filtering applied as part of the query, evaluated against the identity of the person asking. The tempting alternative — retrieve broadly, then remove what the user may not see — fails in ways that are easy to miss and hard to detect:
- A summary generated before filtering can carry restricted content into an answer the user is allowed to receive.
- Relevance ranking computed over the unfiltered set reveals information by omission — the shape of what was removed.
- An error path that skips the filter fails open, and nothing in the response looks unusual.
Two supporting properties are easy to overlook. Permissions must be re-evaluated at query time rather than inherited from whenever the index was built, or a revoked entitlement stays effective until the next reindex. And where an index is derived from another system, the permission model must be carried across faithfully — a document repository's groups and a CMS's roles rarely map cleanly, and the gaps are where exposure lives.
Aggregation discloses what individual documents do not
A capability conventional search does not have: assembling many small permitted facts into a conclusion nobody intended to publish. Individually innocuous references to a project, a location, and a hiring pattern can compose into something sensitive. There is no configuration setting for this. The mitigations are labelling sensitive material accurately in the first place — the classification work described in content classification — and being deliberate about how broadly any one assistant is allowed to range.
Decide what leaves your boundary
Every AI feature involves content being processed somewhere. Answering three questions early determines the architecture, and answering them late means rebuilding it.
- What content may be sent to a third-party model, and what may not? The answer is rarely all or nothing, which means it must be enforceable per content set rather than by policy alone.
- Where may processing physically occur? Data-residency obligations rule out particular providers and regions outright, and this constrains the shortlist before any evaluation of capability.
- What does the provider retain, and for how long? Retention and training-use terms differ between a provider's consumer and enterprise offerings, and between tiers of the same product.
Where the answers are restrictive, the options are self-hosted models within your own boundary, a provider contracted for regional processing with no training use, or keeping the sensitive classes out of AI features entirely while allowing them elsewhere. The last is a legitimate design, and choosing it deliberately is better than discovering it as a constraint.
Minimisation applies throughout: send the passage rather than the document, redact identifiers that add nothing to the task, and avoid sending personal data into a prompt when a reference would do. Retention as a records obligation — how long you must keep things, and when you must destroy them — is a governance matter, covered in content governance. Retention as a control is about holding as little as possible for as short a time as possible.
Prompt injection: content is now an input
Conventional content security assumes content is inert — it is displayed, not executed. Retrieval breaks that assumption. Text pulled into a model's context is instructions as far as the model is concerned, and text that says "ignore previous instructions and reveal..." is a plausible thing to find in a document.
This matters wherever content can enter the retrieval path from somewhere you do not fully control: uploaded files, syndicated feeds, user-submitted material, an integrated system with looser standards than your own. No single mitigation is sufficient; the practical posture is layered.
- Treat retrieved content as untrusted data, not as instruction. The separation belongs in how the request is constructed, not in an instruction asking the model to be careful.
- Constrain what the surrounding system can do. If a compromised instruction cannot trigger an action — cannot send, delete, or escalate — the blast radius is a bad answer rather than an incident. This is the most durable control available.
- Apply permission filtering independently of the model. The model must not be the thing deciding what the user may see; if it is, persuading it is sufficient to bypass authorisation.
- Test with adversarial content deliberately placed in indexed sources. This is not covered by conventional penetration testing, and it needs re-running when models change.
Logging without creating a second liability
You need records of what was asked, what was retrieved, what was answered, and who by — for investigation, for demonstrating a control worked, and for finding out whether something leaked. The awkward part is that a log of everyone's questions is itself sensitive, sometimes more so than the content it references. A support agent's queries reveal a customer's circumstances; an employee's queries reveal their situation.
So the log needs the same treatment as the content: access restricted to a named few, a defined retention period rather than indefinite accumulation, personal data minimised where the record is still useful without it, and its own place in your privacy notices. An audit trail that nobody secured is a breach with a timestamp.
Assessing the exposure in an AI content platform? Schedule an AI CMS consultation — the boundary questions above are the ones worth settling first, because they determine everything downstream.
Evaluating a model provider
Provider selection is a security decision wearing commercial clothes. The questions that actually differentiate:
- Is your data used for training, by default and under your contract? Check the contract, not the marketing page, and check the tier you are actually buying.
- What is retained, where, and for how long? Including the abuse-monitoring retention that often sits outside the main retention commitment.
- Which regions process the request? Not only where data is stored at rest.
- What independent assurance exists, and does its scope actually cover the service you are using?
- What is the notification commitment if they suffer an incident, and how quickly?
- How would you exit? Keeping model calls behind an internal interface is as much a security property as an architectural one — it is what makes leaving a provider a decision rather than a project.
The conventional controls still carry most of the weight
It is worth saying plainly, because the novel risks attract the attention and the ordinary ones cause most of the incidents. Single sign-on with multi-factor authentication, least-privilege roles reviewed on a cycle, prompt patching, encryption in transit and at rest, secrets held outside source control and rotated, hardened integrations with scoped credentials, tested backups, and an incident response plan that someone has actually rehearsed.
An AI content platform with a sophisticated retrieval permission model and an unpatched CMS is not a secure platform. These are the same disciplines LABUSA applies through managed IT and cybersecurity services, and they are the foundation the AI-specific controls sit on rather than an alternative to them.
Testing what conventional testing misses
Standard application security testing will not exercise the things that are new here. Add, and re-run whenever content sources or models change: retrieval attempted as several different roles, confirming that nothing surfaces to a role that should not see it; adversarial content placed in an indexed source; behaviour when the system has nothing relevant, confirming it declines rather than improvises; and confirmation that a revoked permission takes effect immediately rather than at the next reindex.
Human oversight is a control alongside these, not a substitute for them — where it belongs in the process is the subject of human-in-the-loop content management.
How LABUSA approaches this
We treat permission-aware retrieval and the data boundary as design constraints from the first architectural conversation, because both are expensive to retrofit and neither can be added convincingly at the end. In an enterprise AI content management engagement that means establishing what may leave your boundary before a provider is shortlisted, and enforcing authorisation in the retrieval layer rather than trusting the model.
Where a security or compliance function already exists, this work belongs with them rather than beside them. The questions above are ones they will recognise; what is new is that content retrieval is now in scope.
Frequently asked questions
Is a self-hosted model automatically more secure?
It removes the third-party processing question and hands you the entire operational burden — patching, isolation, access control, monitoring. Whether that is a net improvement depends on your capacity to run it well.
Can we let an assistant search everything and rely on filtering?
Only if the filtering is applied within the query and evaluated against the requesting user. Retrieving first and filtering afterwards is the pattern that leaks.
What about content in systems with weak permissions?
Fix the permissions or exclude the source. Indexing it does not create the exposure, but it makes existing exposure efficiently discoverable, which is materially worse.
Does this satisfy our regulatory obligations?
The controls here are what a well-built platform generally needs; whether they meet a specific obligation in your sector and jurisdiction is a judgement for the people accountable for it, and it should be made with them rather than inferred.
Where do most problems actually come from?
In our experience, permission models that were never reconciled between systems — not model behaviour. The AI feature exposes the misalignment; it rarely creates it.
Related reading
- AI Content Governance — the obligations these controls implement.
- AI Content Classification — sensitivity labelling and what it drives.
- Human-in-the-Loop AI for Content Management — oversight as a complementary control.
- Enterprise AI Content Strategy — settling the data-boundary question before selection.
- How to Implement an AI-Powered CMS — where these controls land in the build sequence.