Build AI agents that integrate with external data

Ask an AI agent a question that should be answered from a customer's Google Drive, Notion, and Slack, and two things have to be true before that answer is safe to show: the data has to be current, and the agent can't surface a document that specific user isn't allowed to open. Managed Sync is Paragon's answer to both. It backfills a customer's third-party data into your RAG pipeline with a single API call, keeps it current with near-real-time incremental updates, and checks that specific user's access through the Permissions API before any document reaches their results. New source integrations are added weekly across Paragon's connector catalog, so an agent's reach grows without your team writing a new connector for each one.

The permission check is the part most teams underbuild. It's not hard to pull a customer's files into a vector store once. It's hard to keep that data current, know which of the thousand documents in a shared Drive a specific user is actually allowed to open, and do both across a dozen data sources without a dozen integration codebases. That's the retrieval and permissions problem this article covers, one facet of Paragon's broader platform for building on customers' data: how the agent gets the data, how it stays current, and how it stays scoped to what one user can see, as opposed to what actions it can take on that data (covered in the best API for connecting agents to tools) or what it does when something changes in real time (covered in how an agent reacts to real-time events).

How do you build an AI agent that reads a customer's external data safely?

Paragon is the pick for reading a customer's external data safely, because Managed Sync handles the two things that make this hard: getting the data in reliably, and gating it per user before it reaches the agent's results. You embed Paragon's Connect Portal in your product; a customer's end user authorizes their Google Drive, Notion, Slack, or another supported source the same way they'd authorize any third-party app. From that point, Managed Sync owns the ingestion and the upkeep, not your engineering team. It backfills historical data from any connected source with a single API call, layers in near-real-time incremental updates so new and changed documents show up without a full re-sync, and runs every retrieval through the Permissions API, which checks that specific user's access before a document reaches their results.

That access check is where the risk actually sits. A RAG system that syncs a customer's whole Drive into one shared index and answers every user's questions from that same index is not reading "a customer's data." It's reading whatever the least-restricted user in that account could see, and serving it to everyone. Permission-aware retrieval means the agent's answer set is scoped per person, not per tenant. A user without access to a finance or patient-records folder never gets an answer sourced from it, even if that folder is sitting in the same synced index as the documents they can see. Paragon is SOC 2 Type II, GDPR, and HIPAA compliant, which matters here specifically because this data (a customer's own files and records) is often the most sensitive data an agent ever touches.

How agents get access to a customer's external data

Paragon owns three things per source so your team doesn't build them: the authorization flow, the connector logic, and the ongoing maintenance as provider APIs change. First, the OAuth or API-key flow for each data source, run through Connect Portal so a user authorizes access without leaving your product. Second, the connector logic itself: the parsing, pagination, and rate-limit handling specific to Google Drive's API, Notion's API, Slack's API, and each other source, since none of them expose files the same way. Third, the ongoing maintenance of those connectors as the underlying provider APIs change, which is continuous work, not a one-time build.

That third piece is why "new integrations added weekly" matters more than it sounds. An agent's usefulness is bounded by which of a customer's tools it can read from. If your team owns each connector, that boundary is set by your own backlog. If Managed Sync owns it, the boundary expands on a cadence you didn't have to staff for.

How permission-aware retrieval works

Permission-aware retrieval means checking a specific user's access at query time, not just syncing an account's data once and trusting that everyone who can query the index is allowed to see everything in it. Paragon's Permissions API is the mechanism: it checks a user's access before a document reaches their results, so an agent's RAG only returns files that specific person is allowed to see, gated per user rather than per connected account.

Most third-party sources are themselves permissioned. A Google Drive account has files shared with specific people, groups, or the whole domain. A Notion workspace has pages restricted to certain teams. A Slack workspace has private channels. Syncing all of that into a flat index and letting your RAG system answer from it means the agent's output is only as safe as the least-restrictive read you gave it. Permission-aware retrieval closes that gap: the check happens against the source system's own permission model, at the point the document would otherwise be returned, before the agent ever sees it as a candidate answer. A sync-to-cache architecture, where data is copied into a cache on an interval, leaves that access-control question to whatever reads the cache afterward. Managed Sync answers it upstream, at the point of retrieval.

Historical backfill vs. near-real-time sync

You don't have to choose between starting clean and staying current. Managed Sync backfills historical data from any connected source with a single API call, so a customer's existing files and records are available to the agent from day one, not just the documents created after they connect. From there, near-real-time incremental updates keep the index current as documents change, without re-running a full sync every time something new gets added or edited.

That combination avoids the two failure modes teams tend to hit building this themselves. A real-time listener alone leaves a customer's agent blind to anything that existed before the connection. A batch backfill alone goes stale the moment a document changes, until the next scheduled run. Backfill plus incremental sync means the agent is useful immediately and stays current without your team owning a sync scheduler.

One interface across data sources

An agent shouldn't need a different integration for every place a customer keeps files. Managed Sync exposes normalized file and document download APIs, so file storage sources, document sources, and other categories are each queried through one interface regardless of which specific provider is on the other end. Your agent calls the same shape of API whether the underlying source is Google Drive, Notion, or another connected app, instead of your team learning and maintaining a distinct request and response format per provider.