The architectural principle
The AI should never hold credentials. It should request operations from a layer that holds them, validates the request, checks the requesting user's permissions, executes, and logs. That inversion is what makes AI data access defensible to a security team.
Written for teams who want AI assistants using real business data and have to satisfy a security review before that happens.
Why the obvious approaches fail review
| Approach | Why it fails |
|---|---|
| Database credentials in the AI config | Unbounded access; no per-user permissions; no audit |
| Broad API key | Grants everything the key can do, not what the user can |
| Export data into a vector store | Stale immediately; data now duplicated outside its controls |
| Screen scraping a UI | Fragile, unauditable, and usually violates terms |
Every one of these fails the same question: "what could this system access if it were compromised or manipulated?" If the honest answer is "everything", the review stops there.
The architecture that passes
- An access layer between AI and systems. The AI calls it; it calls your systems. Credentials live here and never reach the model.
- Narrow, named operations. "Get order status by order ID" — not "query the orders table". Each with a validated input schema.
- Permission mapping to the real user. The layer resolves who is asking and constrains results to what that person could see directly.
- Confirmation on consequential actions. Reads are automatic; writes, sends, deletes and payments require explicit human approval.
- Comprehensive audit logging — identity, request, parameters, result summary, timestamp.
- Rate limiting per user and per session.
The Model Context Protocol is a standard way to build exactly this layer, though the principle matters more than the protocol — a well-designed internal API achieves the same thing.
The rule that makes or breaks the design: never expose a general-purpose query capability. A "run this SQL" or "call any endpoint" tool recreates the broad-credentials problem behind a thin wrapper. Every tool should do one narrow thing, with inputs you validate.
Prompt injection: the risk unique to this architecture
Your agent reads content authored outside your organisation — supplier emails, customer tickets, uploaded documents, web pages. Any of it may contain text crafted to manipulate the model.
- Treat all retrieved content as untrusted data, never as instructions. This should be explicit in the system design, not assumed.
- Separate instructions from content structurally in the prompt, so the model can distinguish them.
- Constrain what tools can do — even a fully manipulated agent should be unable to exfiltrate or destroy, because the tools do not permit it.
- Require confirmation for anything outbound — sending data anywhere is exactly what an injection attack wants.
- Test adversarially before deployment, with documents containing injection attempts.
The defence that actually holds: assume the model can be manipulated, and design so that a manipulated model still cannot do serious harm. Filtering suspicious content helps but is not sufficient — narrow tool scope and approval gates are what contain the blast radius when filtering fails.
Data residency and provider terms
Questions worth asking your vendor explicitly, and getting answered in writing:
- Which model provider and which tier — and what is the data retention policy on that tier?
- Is content used for training? Enterprise tiers typically say no; confirm it.
- Where does processing occur geographically, and can a region be specified?
- What is stored in your own infrastructure versus the provider's?
- How is data deleted when a customer exercises a deletion right?
- What is logged, where, and for how long?
For teams serving European customers, deletion rights deserve particular attention — including whether content can be removed from a vector index, not just from the source system.
What the security review will ask
- "What can this system access?" Answer with a list of named operations, not a system name.
- "What happens if it is compromised?" Answer with the blast radius, which should be small.
- "How do we know what it did?" Answer with the audit log schema and retention.
- "Can it act without a human?" Answer with the specific list of gated versus automatic actions.
- "How is it tested against manipulation?" Answer with adversarial test results.
- "How do we turn it off?" Answer with the revocation path and how quickly it takes effect.
Preparing these answers before the review — rather than during it — is the difference between a two-week approval and a stalled project.
A deployment sequence that builds confidence
- Read-only, one system, internal users. Prove the permission model with the lowest possible stakes.
- Review the audit logs with your security team. Real data, real usage.
- Add write operations with mandatory approval on every action.
- Relax approval selectively where the logs show reliability, keeping it on anything irreversible.
- Widen the user base, with monitoring and a tested revocation path.
Need AI connected to internal systems in a way your security team will approve? Tell us which systems and who needs access. See our MCP server service, MCP security practices, and guardrails to demand.