Giving AI Agents Access to Company Data Without the Risk
Safe company-data access for AI agents starts with task-level permissions, data minimisation, identity-aware retrieval, output controls, and complete audit trails.
Do not start by connecting all company knowledge
A broad connection feels useful because the agent can answer more questions, but it erases important boundaries. Payroll, legal files, sales notes, support records, and product documents have different owners, retention rules, and audiences. Search relevance is not authorisation.
Start with one use case and one approved corpus. Classify the information, identify the lawful and contractual basis for processing it, and list prohibited fields. Preserve the requesting user's permissions through retrieval so the agent cannot reveal a record the user could not open directly.
Exposure rises faster than convenience
Use controls before, during, and after retrieval
Before retrieval, authenticate both the person and the workload. Translate the task into an allowlisted query and apply row-, field-, and document-level permissions. During retrieval, cap the number and size of results, remove secrets and unnecessary personal data, and attach provenance so the answer can point back to evidence.
After retrieval, scan outputs for protected data, apply destination rules, and log the data sources used. A response that is safe in an internal workspace may be unsafe in email. Set retention periods for prompts, traces, embeddings, and provider logs; deletion must cover every copy.
| Risk | Weak approach | Better control |
|---|---|---|
| Excess access | One shared service credential | User-delegated or scoped workload identity |
| Prompt injection | Trust retrieved documents | Separate instructions from data and constrain tools |
| Sensitive output | Filter only the query | Inspect response and destination |
| Unknown provenance | Return blended text | Keep source IDs and timestamps |
| Persistent exposure | Store everything | Purpose-bound retention and deletion |
Retrieved data can attack the agent
Documents, tickets, and web pages can contain instructions that try to redirect the model or trigger a tool. The system must treat this content as data, not authority. Keep system rules separate, label sources, disallow dynamic tool creation, validate every action independently, and require approval when an untrusted source influences a consequential action.
Test with deliberately malicious documents and permission edge cases. Safe access is demonstrated when the system refuses or escalates correctly, not only when it answers normal questions.
Build an identity-aware retrieval path
- 01
Classify the source
Identify owner, sensitivity, residency, retention, quality, and the groups allowed to use it.
- 02
Bind an identity
Carry the authenticated user and organisation through every query; autonomous work uses its own workload identity.
- 03
Authorise before searching
Apply document, row, and field filters in deterministic infrastructure before candidates reach the model.
- 04
Minimise and label context
Return the smallest useful excerpts with source, time, permissions, and confidence metadata.
- 05
Control the destination
Recheck sensitive output before it enters email, tickets, documents, or another tool.
Secure the entire data lifecycle
Inventory the copies created by ingestion, parsing, chunking, embeddings, caches, prompts, traces, provider logs, exports, and backups. Apply retention to each layer. When a source record changes or access is revoked, propagate that change to search indexes and caches within a defined period. Test deletion rather than assuming it works.
Keep development and evaluation data separate from live production access. Mask or synthesise sensitive fields where possible. Do not let engineers troubleshoot by copying full prompts into informal channels. Give authorised reviewers tools that reveal the minimum evidence needed to diagnose a run.
Adversarial access tests
- A user cannot retrieve another role's or tenant's records
- A malicious document cannot expand tool permissions
- Secrets and prohibited fields are removed from context and output
- Revoked access disappears from indexes and caches on time
- Every answer can identify its authorised source evidence
Frequently asked questions
Should an AI agent use an employee's permissions?
Often yes for user-initiated tasks, because it preserves existing access boundaries. Autonomous jobs should use a separate narrowly scoped workload identity.
Is a vector database a security boundary?
No. It is a retrieval component. Access policy must be enforced when content is indexed and queried, with metadata that cannot be overridden by the model.
Can prompts prevent data leaks?
Prompts help guide behaviour but are not a reliable access-control mechanism. Enforce permissions, filtering, and destination rules in deterministic code.