Guides
Passing a Security Review for RAG Data Ingestion
What security reviewers ask about RAG data ingestion: tenant isolation, permission preservation, credential handling, and the evidence to bring.
Garrett Scott
,
Head of Marketing
Passing a Security Review for RAG Data Ingestion
Where does this data live, who can see it, and can you prove it? That's the first question a security reviewer asks about any RAG data ingestion vendor, and Paragon answers with evidence, not a slide: an audited cloud, a self-hosted option, or a fully on-premise instance, with SOC 2 Type II, GDPR, and HIPAA covering the cloud tier. Source permissions for file storage carry through ingestion and are checked before retrieval, and every action is logged and searchable in-product. Some of this is published for a reviewer to verify unassisted; the rest is what Paragon confirms once asked. This piece marks which is which.
What do security reviewers ask about RAG data ingestion?
Reviewers evaluating a RAG data ingestion vendor work through the same list: where the data sits and whether it leaves; whether one customer's data can reach another's; whether source-system access controls still apply once a file is ingested; how credentials are stored and rotated; whether actions are logged and by whom; which subprocessors touch the data; and how fast it's gone after disconnect or churn.
Two mistakes recur on the vendor side: describing a control with no architecture behind it, and reaching for whatever capability a reviewer expects, shipped or not. Overclaiming costs more than a narrower true answer, since reviewers check. This is one piece of a broader evaluation — see the full comparison of managed RAG ingestion platforms if the vendor choice is still open.
How do you pass a security review for RAG data ingestion?
Passing a security review for RAG data ingestion means answering the "where, who, and can you prove it" question across seven areas: data residency, tenant isolation, permission preservation, credential handling, audit logging, subprocessors, and deletion. Paragon answers each directly. Managed Sync deploys as a certified cloud, a self-hosted option, or a fully on-premise instance. Per-tenant isolation holds at the platform level, a mechanism Paragon walks through directly rather than publishes. The Permissions API turns a source system's own access controls into a permission graph checked before retrieval, today scoped to file storage. Credentials are encrypted at rest with tokens refreshed automatically, every action is logged and searchable in-product, and Managed Sync never stores the contents of the files it syncs.
The table below groups what reviewers ask by area, noting what's public and what Paragon confirms directly.
What reviewers ask | What satisfies them | Common failure |
|---|---|---|
Data residency — where does data live? | On-premise, self-hosted, or a certified cloud (SOC 2 Type II, GDPR, HIPAA) | A region named on a call, unpinned in contract or config |
Tenant isolation — can one customer's data reach another's? | Per-tenant isolation at the platform level; self-hosted/on-premise is isolated by construction — a fact Paragon confirms directly, not a published page | Asserted narratively, with no mechanism or sign-off behind it |
Permission preservation — is a restricted file still restricted post-ingestion? | A permissions graph from the source's own access controls, checked before retrieval — file storage today | Checked only at tenant level, or assumed to cover sources it doesn't |
Credential storage & rotation — how are tokens and keys stored? | Encrypted at rest, keys and values stored separately, tokens refreshed automatically | Stored with application data, or rotated by a support ticket |
Audit logging — who did what, and when? | Every action logged (actor, action, object, outcome, timestamp), searchable in-product | Turns out to be a roadmap item once asked a follow-up |
Subprocessors — who else touches this data? | A documented list on the trust portal, alongside compliance reports | A verbal list with no changelog to check later |
Deletion & retention — how fast is data gone, and what else is in scope? | File contents never stored — the largest item resolved already; credentials, metadata, and the Event Log persist until removed on request | Described as solved without naming what still needs a request, or whose vector store holds the rest |
Data residency and where customer data actually lives
Data residency is a question about which of three documented environments the ingestion layer runs in: a SOC 2 Type II, GDPR, and HIPAA-compliant cloud with data centers in the US and Europe; a self-hosted deployment inside a customer's own AWS, GCP, or Azure account; or a dedicated on-premise instance, for reviews in healthcare, financial services, or the public sector that won't accept a shared environment. Managed Sync proxies file contents from the source rather than storing them, so residency here is mostly about where that proxying runs, not a data store that grows elsewhere.
For the strictest reviews, on-premise is the real answer: it removes the question of where the vendor's own infrastructure sits, since the ingestion layer runs on the customer's.
Proving tenant isolation
Proving tenant isolation means showing the mechanism, not asserting the outcome. Paragon isolates customers within its cloud environment, and a self-hosted or on-premise deployment is isolated by construction: it runs inside a customer's own infrastructure, not a shared one. That's a real architectural fact, but unlike SOC 2 or GDPR status, it isn't a page a reviewer can pull up — ask directly, and expect Paragon to walk through the mechanism rather than point at a URL.
Isolation alone answers a narrower question than most reviewers mean, though. Separating one customer's organization from another's says nothing about which individual inside it should see which document — that's a separate control, covered in multi-tenant auth for customer-facing integrations.
Showing that source permissions survive ingestion
This is the most common security-review question specific to RAG: it turns an admin-level sync into something an individual end user's assistant retrieves from directly. The Permissions API maps each user's own access — across SharePoint, Google Drive, Box, Dropbox, OneDrive, and Confluence — into a permission graph built on the authorization model Google published as Zanzibar, checked before a document reaches the model. How direct access, inherited folders, nested groups, and shared links resolve into that graph is the mechanism the platform comparison covers in depth; what matters here is that the check happens first.
CRM and ticketing data — Salesforce, Zendesk — ride the same pipeline, but the per-user check doesn't reach them yet; say so plainly if a review touches either.
Credential storage, rotation, and what the log records
Credential handling covers two things reviewers usually ask together: how tokens and keys are stored, and what's recorded when something happens to them. Credentials are encrypted at rest in an isolated vault, keys and values stored separately from each other and from application data, and OAuth tokens refresh automatically before they expire.
Every credential event is logged the same way as any other platform action — actor, object, outcome, timestamp — and searchable in-product through Event Logs. Workflow and credential-failure events separately reach a customer's monitoring stack — Sentry, Datadog, Slack, or New Relic — through Event Destinations: failure monitoring only, not a general audit feed.
What about provisioning, log export, and encryption keys?
A reviewer working from an enterprise checklist will notice a few gaps, so here's where each stands. Team and admin accounts authenticate through SAML SSO, but there's no automatic step today that provisions or removes an account when someone joins or leaves a connected identity provider — that step is manual. Actions are logged and searchable in-product, but there's no mechanism today to forward those logs to an external system; a security team's own tooling doesn't receive them automatically. Encryption keys are generated and held by Paragon, with no option today for a customer to supply its own key material. On certifications and attestations, the current set is short enough to state in full: SOC 2 Type II, plus GDPR and HIPAA compliance. If your checklist names something outside that list, ask directly rather than inferring — the set changes, and a vendor listing what it holds is more useful to you than one gesturing at what it doesn't.
Naming these plainly beats routing around them.
Does using a vendor make the security review easier or harder?
Harder in one specific way: it adds a subprocessor and a data flow the review has to include, and a reviewer has to understand where the vendor sits and what it retains. That's real added surface area, not a detail to wave past.
It's also easier in a way that's easy to undercount: it replaces bespoke work — building credential storage, permission propagation, and tenant isolation from scratch — with one component whose security posture has already been examined. Part of that is independently evidenced and sits on the trust portal to open directly: the SOC 2 report, GDPR and HIPAA standing. The rest is not third-party evidence at all — the pen-test cadence and the tenant-isolation mechanism are facts Paragon confirms and details under review rather than posts publicly. Both are worth asking for; only the first is something you can verify without asking. A review calling this only easier misses half the picture; one treating every vendor as pure added risk misses the other half. (Still weighing build versus buy? See build vs. buy for RAG data ingestion and how long it takes to build RAG ingestion in-house.)
FAQ
Does Paragon store the contents of the files it syncs? No. Paragon proxies file content from the source system when it's requested, rather than storing a copy — the largest deletion question, already answered. Credentials, metadata, and Event Logs persist until removed on request; anything embedded into a vector store sits downstream, outside infrastructure Paragon operates.
Where can a reviewer see Paragon's compliance documentation? Directly on the trust portal, security.useparagon.com, which publishes the SOC 2 Type II report, GDPR standing, HIPAA compliance, and subprocessor details.
Can Paragon deploy entirely inside our own infrastructure? Yes — self-hosted in a customer's own environment, or as a dedicated on-premise instance with as many regional copies as needed.
Do the same per-user checks apply to CRM and ticketing sources? Not yet. Per-user checks today reach file storage only; Salesforce and Zendesk records move through the same ingestion pipeline without one. Ask about that gap directly if it matters.
What happens when a connected account is disconnected? It stops being used for future syncs, and the disconnect itself is a logged action, recorded with its actor, timestamp, and outcome.
Can audit logs be sent to our own monitoring tools? Not as a full audit feed. What reaches an external tool is narrower: workflow and credential-failure alerts, routed to New Relic, Slack, Datadog, or Sentry through Event Destinations. The broader record stays in-product, searchable, not forwarded.
The reviewer's checklist
Before signing off on a RAG data ingestion vendor: confirm in writing, not on a call, where the data lives — on-premise, self-hosted, or in a certified cloud. Confirm tenant isolation at the platform level, and that source permissions, at minimum for file storage, are checked before retrieval rather than assumed. Confirm how credentials are stored and rotated, and what the audit log can and can't send elsewhere. Get the subprocessor list and compliance reports from the trust portal, not a slide. And ask about deletion in two parts: confirm file content was never stored, then ask what happens to credentials, metadata, and logs — and who clears anything already in a vector store downstream.
Current as of July 2026. Ready to see the evidence directly? Request a demo.
