How Noru stores connector credentials, what each authentication model can and cannot do, and what read-only really means per provider.

Credential storage

Secrets are encrypted at rest with authenticated encryption, using a dedicated key held by Noru outside the database. Which fields count as secret is fixed per provider: for example the AWS external ID, the Cloudflare API token, the Datadog API and application keys, the GitHub installation token, and the GitLab access token, refresh token, and self-hosted client secret.

That list is enforced in three places:

Where	What happens
Storage	Encrypted on write, decrypted only when a sync needs the value
Background syncs	Secrets are never copied into the scheduled work itself; each run reads them from the encrypted record at execution time
The app	Secret fields are redacted before a connection's settings reach the browser

OAuth access and refresh tokens are encrypted the same way. Evidence signing uses a separate key, so a compromise of one does not expose the other.

Authentication models

Model	Providers	What Noru holds	Lifetime and refresh
OAuth	GitLab, DigitalOcean, Confluence, Linear, Vercel, Supabase, Google, Microsoft	An access token scoped to the authorizing user, plus a refresh token where issued	Refreshed before expiry; a refused refresh marks the source Disconnected
GitHub App	GitHub	The installation id; installation tokens are minted per sync from Noru's App private key	Tokens are short-lived and never reused across runs
IAM role assumption	AWS	A role ARN and a per-integration external ID; no AWS access keys	STS AssumeRole sessions of at most one hour
Workload Identity Federation	Google Cloud	Project, pool, and provider identifiers; no service account key	Token exchange plus impersonation, one-hour access tokens
Service principal	Microsoft Azure	Client credentials for a dedicated application identity	Client-credential token per sync
API key	Cloudflare, Databricks, Datadog, Detectify, Neo4j Aura, HaileyHR, JungleMap	The key itself, encrypted	Verified on validation or first sync; rotate on the provider side

Scope versus collection

A scope describes what a credential could call. Noru calls a fixed list of endpoints, and that list is what each provider page documents under Permissions in detail. Three examples of the gap:

GitLab's read_api scope reads every API the connecting user can see; Noru calls eleven endpoints and never requests file contents or CI variables.
Datadog's application key may carry many scopes; Noru makes six calls and names the scope each one needs.
AWS's SecurityAudit managed policy reads far more than Security Hub; the breadth beyond the calls listed on the AWS page is unused.

Where you can narrow a credential below what the dialog suggests, the provider page says which calls will fail and how the sync reports it.

Read-only claims and their exceptions

Every connector is read-only in the sense that it issues no writes. The exceptions worth knowing are about what a read returns.

Provider	The claim	What to know
GitHub	Metadata and settings only	The App does not request Contents; branches are never listed. Some requested permissions are never used by the sync
Vercel	"Collect environment variable metadata (not values)"	Names and targets only
Azure	Dedicated read-only application identity	Created by the connect script; treat the identity's role assignments as the boundary
DigitalOcean	28 granular `:read` scopes	Enforced exactly: a grant with any other scope is revoked and rejected
Cloudflare	Read token you choose	DNS records are stored in full, including TXT record contents; they are not redacted
Google Cloud	Viewer-class roles	Cloud Logging audit entries are stored verbatim, one evidence row per entry
AWS	`SecurityAudit` plus Security Hub reads	The 50 most recent CloudTrail events are collected; Lambda environment variables are never stored

Read-only still means data leaves

Read access to DNS, audit logs, and configuration copies those records into your Noru organization as evidence. Scope the token or the include switches before you connect if they could contain something you would not put in an audit package.

Revoke on the provider side

Deleting a data source in Noru removes Noru's copy of the credential. Except for DigitalOcean, where Noru revokes the token remotely before deleting, the provider-side revocation is your step.

Provider	What to revoke
GitHub	Uninstall the Noru GitHub App from the organization
GitLab	Revoke the authorized application in your user settings (self-hosted: also delete the OAuth application)
AWS	Delete the CloudFormation stack, which removes the role
Google Cloud	Run the teardown script offered in the delete dialog, which removes the pool, provider, and reader service account
Microsoft Azure	Delete the application identity created by the connect script
Cloudflare, Datadog, Detectify, Neo4j Aura, HaileyHR, JungleMap	Delete the API token or key
Databricks	Revoke the personal access token in User Settings
Confluence, Linear, Vercel, Supabase, Google, Microsoft	Remove Noru from the connected applications list
DigitalOcean	Nothing; revoked automatically on delete

Delete in Noru

Open the row's menu and choose Delete, then confirm with Delete data source (I have run teardown, delete for Google Cloud and Azure, which offer a teardown script first).

Deletion is irreversible

Evidence, assets, identities, and sync history collected through the source are removed with it. Reconnecting creates a new integration with a new id.

Who can connect

Connecting, syncing, reauthenticating, changing the frequency, and deleting all require write permission on the organization, which admins and editors have. Viewers can read the list, the drawer, the evidence, and the sync history. See Roles and permissions and RBAC and the security model.

What Noru does with collected data

Nothing collected through a data source is used to train models. Every AI call Noru makes on your behalf runs under zero data retention at the model layer. The commitments are in the Terms (section 4.6) and the DPA (sections 3.5 and 3.6).

Permissions and security