Ingestion and retention controls
Define approved document sources, file types, malware checks, storage locations, retention periods, deletion paths, and treatment of personal or sensitive data.
Document AI security
Security and governance for RAG, OCR, and AI agents.
Keep source permissions, document data, generated answers, and automated actions inside explicit technical and operational boundaries.
BlueMouse.ai designs security into the full document intelligence path: ingestion, OCR extraction, storage, indexing, retrieval, model use, human review, integration, and retention. Controls are mapped to the workflow and your organisation's requirements before production access is enabled.
SourcesPermission-aware retrieval
ReviewConfidence and approval gates
EvidenceCitations and audit trail
Security by design
Control what enters the system, what can be retrieved, and what can act.
Permission-aware RAG
Filter retrieval by user, group, repository, region, or classification so a generated answer cannot expose content the requester was not allowed to open.
Extraction confidence and review
Apply confidence thresholds, field validation, exception queues, and human review before uncertain OCR output reaches an operational system.
Citation traceability
Return source references with RAG answers and record the retrieved passages, model version, prompt path, and decision context required for investigation.
Model and provider boundaries
Select private, open-source, or commercial models based on data sensitivity, provider settings, residency needs, performance, and acceptable risk.
Least-privilege agents
Give an agent only the tools and operations required for its role, with separate read, draft, submit, approve, and administrator permissions.
Operational governance
Make quality, exceptions, and changes visible.
Human approval and escalation
Define which extracted values, answers, or proposed actions can proceed automatically and which require a named reviewer. Low confidence, conflicting evidence, sensitive records, and high-impact actions can route to dedicated queues.
Evaluation, logs, and change control
Monitor OCR accuracy, retrieval relevance, citation validity, answer quality, approval rates, exceptions, latency, and cost. Test changes to documents, prompts, models, and indexes before promoting them to production.
Data handling by stage
Where document data goes, and what protects it at each step.
Security reviews ask the same questions in the same order: what data enters, where it is stored, who can reach it, what leaves the boundary, and how long it stays. This is how a typical RAG or OCR deployment answers them. The specifics are agreed per project and written into the design document before production access is enabled.
| Stage | Data present | Controls | Evidence produced |
|---|---|---|---|
| Ingestion | Source files from approved repositories, mailboxes, or scanners | Allow-listed sources and file types, malware scanning, size limits, checksum on receipt | Ingestion log with source, time, checksum, and outcome for every file |
| OCR extraction | Page images, extracted text, and field values | Processing inside the agreed boundary; no third-party OCR service unless approved; temporary artefacts deleted after extraction | Field-level confidence and validation results per document |
| Storage and indexing | Documents, chunks, embeddings, and metadata | Encryption at rest, per-repository or per-tenant separation, access-control metadata stored with every chunk | Index manifest listing sources, versions, and permission scope |
| Retrieval | User query and the chunks that user may see | Permission filter applied before ranking, not after; query and result logged with the requester's identity | Retrieval trace per answer: chunks, scores, and filters applied |
| Model use | Prompt containing the query and retrieved passages | Model chosen for the data class: private, open-source in your environment, or a commercial API under no-training and limited-retention terms; retrieved text treated as data, never as instructions | Model version, prompt template version, and token usage per request |
| Review and actions | Draft answers, extracted values, proposed actions | Named reviewer roles; approval before any write action; separate permissions for read, draft, submit, and approve | Approval record with reviewer, time, and the change made |
| Retention and deletion | Everything above | Retention periods per data class; deletion paths that remove chunks and embeddings as well as source files | Deletion report per request, verifiable against the index manifest |
Common questions
Answers to the questions security reviews ask first.
These are the questions that arrive in supplier questionnaires and architecture reviews. The answers describe how we work; each one is confirmed for your environment in the design document. Our own website's data handling is described in the privacy notice.
Does our data leave our environment?
Only where the design says it does. With on-premise or private-cloud deployment, documents, indexes, and models all stay inside your boundary. If a commercial model API is chosen, only the prompt and the retrieved passages cross to the provider, under business terms, and the design document names exactly which data crosses which boundary.
Is our data used to train models?
No. We do not train models on client data. Where a commercial API is used, we use the business terms that exclude training and limit retention. Where an open-source model runs in your environment, no external party sees the data at all.
How do you stop one user seeing another's documents?
Permissions from the source systems are stored as metadata on every chunk, and the filter is applied before ranking, so unauthorised content is never a candidate. Group membership is synchronised from your directory, and a permission test suite runs before go-live and after every index change.
What is logged, and can we see it?
Every request produces a trace: the requester, the query, the filters applied, the chunks retrieved with scores, the model and prompt version, the answer, its citations, and any approval. Logs live in your environment under your retention rules, and personal data in logs is handled according to your policy.
How is personal or special-category data handled?
Documents are classified at ingestion, and routing rules decide whether a class of content is excluded, redacted, or restricted to named groups. We supply the data-flow description your data protection assessment needs. Our healthcare documents page shows the pattern for the most sensitive case.
Can an AI agent act without a person?
Only within the scope written into its role. Write actions require approval by default; an agent cannot acquire new tools at runtime; and every action, approved or automatic, is logged with the evidence it acted on. Our AI agents page describes the approval model.
How do you handle prompt injection from documents?
Retrieved text is treated as data rather than instructions, tools are allow-listed per role, and answers are grounded and cited so a reviewer can check the source. Injection attempts are part of the evaluation set run before release and after model or prompt changes.
Do you hold security certifications?
Ask us directly and we will state our current position on certifications and insurance plainly rather than imply coverage. Most engagements run inside the client's own certified environment and follow the client's policies; we supply the technical documentation, data-flow diagrams, and control descriptions your reviewers need for supplier due diligence.
Who is responsible for what?
The design document includes a responsibilities matrix. Typically you own identity, infrastructure, and source permissions; we own the pipeline code, evaluation, and documentation; and monitoring is shared with named contacts on both sides. Nothing is assumed.
Architecture choices
Match deployment to the information boundary.
The right control set depends on the documents, users, jurisdictions, connected systems, and consequences of an error. We can design an on-premise, private-cloud, commercial API, or hybrid architecture and document the responsibilities around each component. See our private RAG and OCR deployment options for the trade-offs.
Trust architecture
Put the security review before the production rollout.
Bring the document sources, user groups, workflow actions, and risk constraints. We will help map the controls that a production RAG, OCR, or agent system needs.