Connector and Read-Only Access Disclosure
1. What a connector is
A connector links a system your company already runs to Trooth so that Trooth can witness signals from it: the configuration and status facts that become the evidence on your Network profile. Connectors exist because self-attested claims are not evidence. This document explains what access a connector has, what Trooth reads through it, and how to take that access away.
2. How authorization works
Today every connector takes a credential you create at the provider and paste into Trooth: an API token, or for AWS an access key pair or a role Trooth assumes. None of them uses an OAuth consent screen yet, so the access Trooth has is whatever you gave that credential. Trooth never asks for and never sees your password to the connected system. Section 3A lists, for each connector, the permissions Trooth asks you to grant and whether they are read-only; the plan for each is in the same table.
3. Read access, by design
Connectors are designed for reading. Witnessing observes a connected system and records what it saw, with source and timestamp; it does not change settings, write data, or take action in the connected system. Most connectors today take a token you create in the provider and paste into Trooth, so there is no provider consent screen: the access is whatever you gave that token, and each connector shows the permissions it needs before you connect. Grant read-only access where the provider offers it. Some provider permissions also allow writing, Salesforce's api scope among them; Trooth does not use them to write, and the connector says when a permission it needs can write.
3A. Each connector's credential and permissions
This table is generated from the connector definitions the service runs and is checked against them on every build. "Read-only" says whether the permissions Trooth asks for are read-only in the provider's own model. It does not say the credential you paste is: Trooth stores the credential you give it and does not refuse one that can write, so grant only what the table lists.
| Connector | How you connect today | Permissions Trooth asks for | Read-only | Planned |
|---|---|---|---|---|
| GitHub | A token you create at the provider and paste in | Repository Administration: read, Repository Metadata: read, Organization Administration: read, Organization Members: read | Not established | GitHub App installation, which scopes per-repository and can be revoked from GitHub itself |
| Cloudflare | A token you create at the provider and paste in | Zone: Zone: Read, Zone: Zone Settings: Read | Yes, the permissions asked for are read-only | No change planned |
| GitLab | A token you create at the provider and paste in | read_api, read_repository, read_user | Yes, the permissions asked for are read-only | GitLab OAuth application authorization |
| AWS | An access key pair, or a role Trooth assumes | SecurityAudit (AWS managed policy; review effective permissions) | Not established | No change planned |
| Okta | A token you create at the provider and paste in | API token (carries the role of the administrator who creates it) | Not established | Okta OAuth service application with granted read scopes |
| Google Workspace | A token you create at the provider and paste in | admin.directory.user.readonly, admin.directory.group.readonly, admin.directory.domain.readonly | Yes, the permissions asked for are read-only | Google OAuth consent flow with domain-wide read scopes |
| Microsoft Entra ID | A token you create at the provider and paste in | User.Read.All, Group.Read.All, Policy.Read.All | Yes, the permissions asked for are read-only | Entra ID application with admin-consented read scopes |
| Slack | A token you create at the provider and paste in | team:read, users:read, channels:read | Yes, the permissions asked for are read-only | Slack app install with read-only bot scopes |
| Salesforce | A token you create at the provider and paste in | api | No: this permission can write | A connected app restricted to read-only profiles |
| Stripe | A token you create at the provider and paste in | A restricted key for the one read GET /v1/account (the minimum resource permission is not established) | Not established | No change planned |
| Paddle | A token you create at the provider and paste in | No permissions: GET /event-types, which Paddle serves to a key with none | Yes, the permissions asked for are read-only | No change planned |
| Brex | A token you create at the provider and paste in | users.readonly | Yes, the permissions asked for are read-only | No change planned |
A connector marked "Not established" carries the permissions of whoever creates the credential, as an Okta API token does, or needs a permission the provider does not name for the one request Trooth makes, as Stripe's does. Treat it as able to do whatever that credential can do. Stripe, Paddle and Brex each make one request per sync and keep only whether it succeeded and its HTTP status; the response body is discarded. A Stripe secret key, which starts sk_, is refused before it is stored; use a restricted key, which starts rk_.
4. What is collected
Through a connector, Trooth reads the signals the methodology describes: configuration state, security posture facts, and status information from the connected system. Observed signals become witnessed evidence with a source and a timestamp, re-read on a recurring schedule. What Trooth retains and for how long is governed by the Privacy Policy and the Data Retention Summary.
5. Revoking access
You can disconnect a connector from your workspace at any time, and you can also revoke Trooth's access directly at the connected provider; either is effective. After revocation, Trooth can no longer re-read the system: previously witnessed facts stop refreshing and age accordingly, which your profile reflects honestly. Evidence already recorded remains subject to the retention rules above.
6. Credential security
A credential you paste is encrypted at rest (AES-256-GCM) and sent to the provider only over TLS, only to read. It is deleted within 24 hours of disconnecting the connector or closing the account. Trooth's own access to production systems is role-restricted, as the Trust Center describes.
7. Contact
Questions about connector access: security@trooth.co or support@trooth.co.
Revision note. Revised September 26, 2026. Section 3 said the provider's consent screen shows what is being granted. Most connectors take a pasted token and have no consent screen, so the section now says what happens instead and names the one permission that can write. No right or obligation was narrowed, and the correction is recorded under our publication and correction policy.
Revision note. Revised September 26, 2026 (second revision). Section 2 said connectors authorize through OAuth with a broker, and section 6 said tokens are handled through that broker. No connector uses OAuth today: each takes a credential you create and paste. Both sections now say so, and a new section 3A lists each connector's credential, the permissions Trooth asks for, whether those are read-only, and what is planned, generated from the connector definitions the service runs. No right or obligation was narrowed, and the correction is recorded under our publication and correction policy.
Revision note. Revised September 28, 2026. Section 3A listed Stripe, Paddle and Brex as "Not yet listed". Each makes one request per sync, and the table now names the least permission that request needs from the provider's own documentation: none for Paddle, users.readonly for Brex, and for Stripe a restricted key, with the minimum resource permission stated as not established because Stripe does not name it. The table is also now a real table rather than a paragraph of text. No right or obligation was narrowed, and the correction is recorded under our publication and correction policy.
Revision note. Revised September 28, 2026 (second revision). Section 3A had no row for Cloudflare, although the service runs a Cloudflare connector, and the connection form said its permissions were not listed. The table now names the two read permissions that connector's requests need: Zone: Zone: Read and Zone: Zone Settings: Read. A token with wider permissions, such as Cloudflare's Read all resources template, also works but is not needed. No right or obligation was narrowed, and the correction is recorded under our publication and correction policy.
Revision note. Revised September 28, 2026 (third revision). Section 3A now says that a Stripe secret key is refused before it is stored. The service used to store whatever key it was given; it now keeps only a restricted key. No right or obligation was narrowed, and the correction is recorded under our publication and correction policy.