Read-only against SharePoint, with list content kept in your database

Least-privilege access

SPSync authenticates against Microsoft Entra ID. Delegated sign-in sees only what the signed-in person can see. For unattended sync, app permissions are granted per site with Sites.Selected, so an admin approves access to named sites. Tenants that require their own app registration can bring it. The admin permissions guide lists what to grant and why, and the first-run wizard in every edition produces a one-page pack for the admin.

Read-only

SPSync never writes to SharePoint. It requests read permissions only, and there is no code path that creates, updates or deletes SharePoint items. Two-way sync is on the roadmap as an explicit, per-replication opt-in with its own permissions.

What an AI agent or assistant can see

An agent that reads the replica holds a database login and no Microsoft Graph permission. The app registration SPSync uses is the only one in the path, scoped per site with Sites.Selected for unattended sync, and the agent never sees its token. However many questions the agent asks, SharePoint receives only the delta round SPSync was going to run anyway.

SharePoint item permissions are not copied into the replica or into any search index SPSync writes. The replica holds every row of each list you chose to replicate, so the boundary on what an agent sees is the one you set in the database. You set it with a read-only role granted on specific tables or views, and with row-level security where one agent should see one region or team. The same applies to a Copilot Studio agent grounded on Azure SQL or Azure AI Search filled by SPSync.

Nothing an agent does to the copy reaches SharePoint, because SPSync has no code path that writes there. Auditing what an agent read uses the database's own tools: pgAudit or log_statement on Postgres, a database audit specification on SQL Server, built-in auditing on Azure SQL. The agent data layer page sets out the grants and the audit in detail, and the custom agent governance resource explains why Copilot's own controls do not cover an agent you built. Write-back to SharePoint is designed around changes a person approves and is not shipped.

Assistants that set SPSync up

An AI assistant can set SPSync up and run it through the admin MCP server. We designed it on the assumption that the assistant is helpful but fallible, and that a conversation is no place for a secret. The server works on SPSync's configuration and never returns the rows in your replica. What an assistant can do with it is described on the AI and agents page.

An assistant connects with an agent token. A token has a name, an access level of read or manage, an expiry of 90 days unless you choose another, and can be revoked. It is shown once and SPSync keeps only a hash of it. It is accepted on the /mcp address and nowhere else, and the API key and the desktop app's own token are not accepted there. The server checks the access level before a tool runs, so a read token cannot call a tool that changes anything. A revoked or expired token is refused on its next request.

Connection strings, client secrets and API keys never pass through the model. The assistant gives you a link, you type the value into the page it opens, and SPSync stores it. The link works once, expires after fifteen minutes and is tied to the token that asked, one record and one field. No tool takes a secret as an argument or returns one, and a destination read masks its credentials in the same way the API does.

A person stays in the loop where it matters. Sign-in is a device code you enter. A tenant admin's consent and a Sites.Selected grant go to the people who can give them, as a link, a draft message or the PowerShell to run. A delete, or replacing a stored credential, shows a preview first and needs a confirmation the server checks, which works once and expires. The tools that need a person say so, so a client that can stop for one does.

Every tool call is recorded with the token, the client name and version, the tool, the arguments with anything secret-shaped removed, the outcome and the duration. A diagnostics bundle includes these records, and the Activity screen shows them under an AI assistants filter. An agent token is never passed on to another service. Calls to Microsoft Graph use the connection's own sign-in or credential.

Where data goes

Desktop app and command line

List rows travel from SharePoint, through the engine on your machine or server, into your database. Configuration and tokens are stored locally, in files only your user account can read. Protection by the operating system's secure credential store is not in the desktop app yet. Nothing from SharePoint or your database is sent to SPSync. Activating a licence sends licensing.spsync.io the machine details listed in the privacy notice: a one-way hash of the hardware identifier, the hostname, the operating system and the app version. Diagnostics go to SPSync only when you choose to send them.

In your Azure

The managed application runs in your own Azure subscription, in the Azure region you choose at deployment. It can use your own app registration (so conditional access and Tenant Restrictions policies scoped to that app apply the same way they would to any other application in your tenant) and VNet-integrate the worker itself, so it reaches your database and any other private Azure SQL or Postgres endpoint through your own network, optionally with no public ingress to the worker at all. Your list content, credentials and database connection details never leave your subscription, and there is no cross-tenant control plane holding them. Two things do call out to SPSync. First, an activation call to licensing.spsync.io when a worker container starts without a cached activation (in practice each new replica or revision); periodic refresh is not wired yet. It sends either the licence key (if you bought a licence directly) or the Marketplace plan and region, plus the Azure resource group id (which contains your subscription id), the subscription id, the worker's hostname, its operating system and the app version, and nothing from SharePoint or your databases. Those records are stored by SPSync's licensing service (Supabase) and kept for as long as needed to administer your licence and a reasonable period afterwards. Second, diagnostics you explicitly choose to send to support.spsync.io. We upgrade the deployment with you. If your tenant restricts outbound traffic, allow-list licensing.spsync.io.

Outbound endpoints to allow

If your network allows outbound traffic by name, SPSync needs HTTPS (port 443) to these hosts and no others of its own. There is no fixed IP range to publish, because the engine runs on your machine or in your subscription and leaves through your own network.

The Azure edition also reaches the public container registry to pull its image (ghcr.io and pkg-containers.githubusercontent.com), and its own control-store database and Key Vault inside your subscription. Nothing from SharePoint or your database is sent to the SPSync hosts above.

Where credentials are stored, edition by edition

This is the position today, including what is still to do.

• Desktop app: destination passwords and API keys, bring-your-own-app client secrets and the Microsoft sign-in token cache, including the refresh token, are stored in plain text inside the local configuration database. The file and the folders SPSync creates are readable only by your user account on macOS and Linux, and on Windows the profile folder permissions apply. That keeps other accounts out but does not stop your own account, a process running as you or a backup you take from reading them. Moving them to the operating system's secure credential store is planned, not shipped.
• Server and command line: the server keeps the same secrets in its control database in plain text, so protect that database as you would the secrets themselves. The command-line tool on its own keeps its sign-in token cache in the operating system's secure credential store.
• In your Azure: the generated deployment secrets (the control-store connection string, API key, sign-in password, session secret and your licence key if supplied) are held in a Key Vault in your subscription and read by the worker's own managed identity. Destination credentials you enter are stored in the deployment's own database, in plain text for now. Key Vault references for them are planned, not shipped.

Identity, your own app registration and the Azure edition

By default every edition signs in through one multi-tenant Entra application that SPSync owns. Any edition can instead use an app registration in your own tenant, which is what you need when Tenant Restrictions v2 or a conditional access policy is scoped to named client apps. The sign-in authority is built from each connection's own tenant, so no per-deployment change is needed. In the Azure edition you enter your app's client ID in the deployment's advanced step and register the worker's callback address on it, with the delegated Graph permissions Sites.Read.All, User.Read and offline_access. Unattended sync uses an app registration on the connection itself, with Sites.Selected granted by your admin on each named site. The admin permissions guide has the exact steps, and the SharePoint Online connection page shows what a connection needs.

In the Azure edition the worker itself reaches its Key Vault and storage through a user-assigned managed identity with role-based access, not a shared secret or an account key.

Conditional access and Tenant Restrictions v2

SPSync signs in through standard Entra ID and does not work around anything. Conditional access policies scoped to the user, the device or the app registration apply as they would to any other application, and Tenant Restrictions v2 is met by using an app registration in your own tenant. We have not tested this against a live tenant that enforces such a policy, so run a sign-in from a session that should fail the policy in a test tenant before relying on it.

Data flow

The same shape, wherever SPSync runs: SharePoint is read-only, list content is written to your database alone, and nothing SPSync-controlled sits between the two other than the engine itself.

SharePoint / Microsoft Graph
        |  (read-only, delegated or Sites.Selected app permissions)
        v
  SPSync engine  ----(desktop/CLI: local machine)----------------+
        |                                                        |
        |  (in your Azure: your VNet, optional private endpoint) |
        v                                                        v
  Your database                                          Your local files, or in Azure
  (SQL Server, Postgres,                                 the deployment's Key Vault
   Azure SQL, etc.)                                      and database (config, tokens,
                                                         credentials; never SPSync's)

Throttling and tenant health

SPSync follows Microsoft's guidance for Graph and SharePoint Online: a decorated user agent, Retry-After handling and resource-unit metering per tenant. To keep heavy loads to quiet hours, start command-line runs from your own scheduler; the desktop app and the Azure edition run on a fixed interval. A replication is designed not to degrade SharePoint for the people using it.

Documents

Privacy policy, data protection agreement and the sub-processor list. Security questionnaires: contact support.