Security
Where the document goes, and where it doesn't
Redtrail is built so that the document stays in your SharePoint, the relay between your agent and your Word session keeps nothing, and the optional change history is encrypted under a key you can hold yourself. This page is the plain statement of that architecture, written for the person who has to approve it.
On this page
Data flow
- The add-in runs inside the user's Word session on Windows, Mac or the web. It signs in with the user's Entra ID and talks to SharePoint with the user's own token, exactly as Word does. It executes the agent's operations locally through Office.js.
- The reflector is a stateless relay. It binds the OAuth grant of an MCP client to that user's open Word sessions and routes tool calls between them. Every tool payload crosses it inside an opaque envelope; the reflector reads the envelope's routing headers (document id, tool name, call id, mode) and nothing else. It never calls Graph and never touches SharePoint.
- The MCP client (Claude Code, Claude.ai, Cowork, Cursor, Copilot Studio and others) is where the model runs. Those platforms process document text in plaintext by design; that is the nature of the agent you chose, not something Redtrail adds or can remove, except in end-to-end mode.
- The history store is opt-in. It receives one event per agent operation. Identifiers, timestamps, anchors and hashes are stored in the clear so the log can be searched; the text fields (what was expected, what was there before, what was written, and the instruction) are encrypted under a per-tenant key, or under a key held in your own Azure Key Vault.
What we store, and what we never store
Stored
- Tenant id, user principal name, named agent devices and their OAuth grants
- Session metadata: document id, SharePoint site/drive/item ids, version pointers, timestamps
- Audit rows: operation type, anchor structure, hash chain, outcome (no content)
- History events, with content fields encrypted (opt-in)
- Tenant policy: allowlists, seat groups, retention, region, kill-switch state
Never stored
- Document snapshots or files. SharePoint versions are the only full copies.
- Tool payloads passing through the reflector, in logs or otherwise
- Plaintext of history content fields, on any tier
- SharePoint access tokens: the add-in uses them; the reflector never receives them
- A staff-accessible path to decrypt customer-held-key history
Privacy tiers
| Agent | Path | Content visible to the reflector |
|---|---|---|
| Claude Code, Cursor, Cowork with the local plugin | End-to-end mode (v1.1, on request) | No |
| Claude.ai, mobile, Cowork via remote connector | OAuth grant | Yes, in transit only. Zero retention. |
| Copilot Studio, Power Automate, other cloud agents | OAuth grant | Yes, in transit only. Zero retention. |
v1 ships the standard path: TLS everywhere, a stateless reflector, no payload logging, signed audit metadata. We state plainly that agent platforms process content in plaintext by design and that our relay never stores it. The hosted service is fronted by Cloudflare, which terminates TLS at its edge before re-encrypting to the reflector; end-to-end mode and self-hosting are the options for tenants who want no third party in the content path.
Identity and permissions
- User identity is Entra ID (Google Workspace as a secondary option). The add-in signs in silently through Office single sign-on; the MCP client signs in through OAuth against the reflector with the same identity. The reflector binds the two, so an agent can only reach documents that user has open.
- Agent identity: every OAuth grant registers a named device ("Claude Code on randys-macbook", "Copilot Studio agent X"). It appears in the task pane and in every audit row, and tenants can allowlist client types.
- Tracked-change authorship comes from the Word session's signed-in user. In v1 the human who owns the session is the author of record and the agent is recorded in the task pane and history.
- Delegated scopes requested by the Entra app registration are minimal:
openid profile email, andFiles.ReadWriteonly where the add-in must read SharePoint versions for history replay. - Auto-apply without per-edit approval is only possible while change tracking is on. This is enforced in the add-in, not exposed as a preference.
History store controls
- Keying: streams are keyed by (tenant, document UUID). A document shared across tenants has two independent streams.
- Encryption at rest: per-tenant keys. On the Enterprise tier the add-in fetches the tenant key from your Azure Key Vault with the user's token, encrypts client-side, and uploads ciphertext. Dashboards and the CLI decrypt client-side. Revoking the key makes history dark, for us as well.
- Integrity: each stream is a hash chain. Retention-driven deletions leave an explicit gap marker so chain verification stays honest.
- Region: US or EU at tenant creation.
- Export, pause, delete: per document and per tenant. Export is a JSONL archive; hard delete returns a signed receipt. Off-boarding is export-all then delete-all.
- No snapshots: the store keeps events, never copies of the document.
End-to-end mode
For agents that run on the user's machine (Claude Code, Cursor, Claude Desktop and Cowork through a local plugin), a v1.1 option keeps the reflector from ever seeing plaintext. The add-in shows a short pairing code; the user gives it to the agent; the two sides run a password-authenticated key exchange through the reflector and derive fresh session keys, held in memory only and rebuilt on every document load. The pairing code is never used as the key itself, so an observer holding ciphertext gains nothing from guessing it. Every envelope in both directions is then authenticated encryption that the reflector only forwards.
The envelope format is the same in both modes, so end-to-end is an add-on to the shipped relay, not a different product.
Operational security
- Reflector and history store run as separate services; the admin console is a separate application over their metadata. No process holds both the routing role and the storage role.
- All external traffic is TLS 1.3. Internal service traffic is mutually authenticated.
- Audit metadata is emitted as OpenTelemetry and can be pushed to your webhook, Event Hub or Log Analytics workspace, and surfaces in Microsoft Agent 365 observability when the reflector is registered there.
- Kill switches at tenant, user, session and agent-grant level take effect on live sessions immediately.
- Self-hosted deployment of the reflector (Docker image, Azure template) is available on the Enterprise tier for tenants that need the relay inside their own boundary.
- Publisher Verification and Publisher Attestation on the Microsoft Marketplace listing; SOC 2 examination is scheduled on the first enterprise request.
Reporting a vulnerability
Please write to [email protected] with "Security report" in the subject. We acknowledge within two business days and keep you informed until the issue is resolved. We do not pursue good-faith researchers.