Book a security assessment

A staged approach to rolling out AI services securely

Internal, partially exposed, customer-exposed: why AI risk changes with exposure, and the controls and tests each stage needs before you widen access.

AI SecurityBy Mohan YelnaduPublished 2 min read

Most organizations aren’t deciding whether to adopt AI. They’re deciding how fast. The risk is that security review becomes a single gate at the end, applied the same way to an internal summarizer and a customer-facing agent.

Those two services carry very different risks. A better model ties controls to exposure: who can reach the service, and what the service can reach.

Three stages left to right: Internal (staff only), Partially exposed (partners and pilot users), and Customer-exposed (anyone on the internet), with the controls added at each stage.
Each stage widens who can reach the model. Controls accumulate; none are dropped.

Stage 1: Internal#

Staff-only tools: assistants over internal docs, code helpers, ticket summarizers. The users are trusted, but the data often isn’t meant for everyone.

Get these right before anything faces outward:

  • Data boundaries. The model should only retrieve what the asking user is allowed to see. Retrieval that ignores document permissions is the most common internal finding.
  • Access control and logging. Know who used what, and keep prompts and responses where your incident team can reach them.
  • Tool permissions. If the assistant can call APIs, give it the narrowest scope that works.

Stage 2: Partially exposed#

Partners, pilot customers, a beta group. Now some users aren’t yours, and some inputs, such as uploaded documents, emails and web pages, come from people you’ve never met.

This is where indirect prompt injection becomes real. Content the model reads can contain instructions, and the model may follow them.

SW-F-0311High

Support assistant follows instructions embedded in uploaded documents

Asset
support-assistant · document upload
Impact
A crafted file could make the assistant reveal other customers' ticket data.
Fix
Isolate retrieved content from instructions and enforce per-user data scoping.
Validatedexpert reviewIllustrative example, not a client finding

Before widening access, test for:

  • Instructions hidden in documents, pages and emails the model processes
  • Leakage of data from other users, sessions or tenants
  • Abuse of any tools the model can call on the user’s behalf

A configuration review helps here too. This is the kind of change we often recommend before stage 2:

assistant/config.ts
export const assistant = {
  model: 'your-model',
  retrieval: {
    scope: 'requesting-user', // was: 'workspace'
    maxDocuments: 8,
    treatContentAs: 'data', // never as instructions
  },
  tools: ['search_tickets'], // removed: 'export_tickets'
};

Stage 3: Customer-exposed#

Anyone can reach it, and some of them will be trying to break it.

Everything from the earlier stages still applies. Add:

  • Adversarial testing by people whose job is to make the service misbehave, before launch and after every significant change
  • Guardrail validation, testing that output filters and policies hold up against deliberate attempts to get around them
  • Monitoring and response: detection for abuse patterns, and a way to pull a feature quickly

Moving between stages#

A service should earn its next stage. A simple rule works: no service widens exposure until the tests for the next stage have run and the findings are fixed or accepted by someone accountable.

That keeps AI rollout fast where risk is low, and careful where it isn’t, without one review gate slowing everything down.