Connector scopes

Read-only by default. Writes require explicit customer authorization.

Garde1's evidence collection runs against integrated vendor APIs through scoped, auditable connectors. Assessment and recommendation workflows are read-only across every integration. Write-capable scopes are opt-in per connector for remediation and baseline application workflows only, gated by explicit customer authorization, and recorded in the audit log. This page catalogs the scopes by category. The full scope manifest for each connector is documented inside the product before you grant consent.

← /security ← /compliance Responsibility matrix

Principle: least privilege. Connectors are read-only by default for assessment and recommendation workflows, and implement least-privilege scopes for evidence collection. Garde1 does not request administrator privileges where a reader role suffices. Write-capable scopes exist only for remediation and baseline application workflows, and are never enabled silently — they are opt-in per connector, surface an explicit consent prompt naming the workflow class, and every write is logged in the customer-visible audit log. The zero-trust corollary: even granted writes are bound to the consented workflow class, scoped to a single tenant, and recorded against the granting user's identity.

Scopes by category

Category & vendors	What we read	Default writes
Identity providers / SSO Microsoft Entra ID & External ID, Okta, Google Workspace, Duo, Ping Identity	Users, groups, role assignments, sign-in logs, conditional access policies, MFA enforcement, app assignments	None. Opt-in: Disable a sign-in (lockout) when a baseline remediation needs it; only with explicit customer authorization on the workflow and customer-owned service principal.
Endpoint management / MDM Microsoft Intune, Jamf, NinjaOne	Device inventory, compliance status, configuration profiles, application inventory, encryption posture, patch level	None. Opt-in: Trigger remediation of a non-compliant device when the customer has explicitly enabled write-capable baseline workflows.
EDR / endpoint protection Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne	Detections, alerts, isolation status, agent health, threat intel feed metadata	None.
Cloud providers AWS, Microsoft Azure, Google Cloud	IAM users / roles / policies, SCPs, S3 / blob / GCS bucket configurations, security group rules, Config / Policy compliance, CloudTrail / Activity Log metadata, GuardDuty / Security Center findings, key rotation status	None. Opt-in: Apply a documented remediation (e.g., tighten a bucket policy, rotate a key, disable an unused IAM principal) when the customer has explicitly enabled write-capable remediation workflows on the connected account.
SIEM / log analytics Microsoft Sentinel, Splunk, Wazuh	Alert and incident metadata, log source health, detection rule status. Garde1 does not ingest raw log content into its own data store.	None.
Vulnerability management Tenable	Asset inventory, scan results, finding severity, exception status	None.
Network / firewall Cisco, Palo Alto Networks, Aruba Central, UniFi	Firewall rules, VPN configurations, network segmentation, wireless SSID / encryption posture	None.
Source control GitHub, GitLab	Repository protection settings, branch protection, secret scanning + Dependabot alerts, organization membership, audit logs	None.
Communications Slack, Microsoft Teams, Microsoft Exchange Online Protection	Workspace / tenant configuration, retention settings, anti-malware and anti-phishing posture, DLP policy metadata. Garde1 does not read message content.	None.
Other Brivo (physical access), KnowBe4 (training), ServiceNow (ticketing), Kiteworks (secure file)	Access control events, training completion records, ticket lifecycle, file transfer audit. Scoped per connector documentation.	None.

How a write is authorized

When a customer enables a write-capable workflow on a connector, the consent flow records four artifacts:

Which connector, by stable slug — not by human-readable name, so a rename can't silently broaden authorization.
Which scope was granted (the OAuth permission or IAM action), with a permanent reference in the consent record.
Which user approved it, when, and from which IP / user agent.
What workflow class may use it (e.g. baseline apply, remediation execute) — Garde1 does not reuse the scope for anything outside the consented workflow class.

Every write attempted under that authorization lands as a record in the 365-day immutable audit log alongside the grant reference. Customers can revoke a consent at any time; existing rows remain in the audit log but no new writes are accepted.

PII minimization on ingest

Connector reads pull more raw data than any single control needs. Garde1 minimizes the payload at the ingest stage rather than storing the full dump and filtering later. Concretely:

Display names and personal device identifiers are dropped unless a specific control evaluation requires them.
End-user email addresses are hashed where the control only needs presence-of-account, not the identity itself.
Administrator and service-account identifiers are retained where they are load-bearing for the control (e.g., AC-2 account management).
Raw activity logs are not stored — the pipeline keeps aggregates (counts, posture, last-seen) and points back to the source-of-truth log in your SIEM.

The same minimization carries through to LLM evaluation: prompts include the minimum context required to render a determination, not the full evidence payload. See garde1.com/security/ai for the complete “what we send / what we don't” table.

What Garde1 never does

Read end-user file or mailbox content. Connectors read configuration and security metadata only. Garde1 does not request a Mail.Read or Files.Read scope on Microsoft Graph; comparable scopes are excluded across every vendor.
Store customer credentials in plaintext. Vendor API tokens are encrypted at the application layer with AES-256 before they reach Postgres; the encryption key lives in AWS Secrets Manager.
Reuse a customer's token across tenants. Tokens are stored under the organization that consented to them, and database-layer tenant isolation prevents cross-tenant retrieval even if the application layer is bypassed.
Make changes outside an explicitly consented workflow class. A write scope granted for a baseline workflow is not usable by a remediation workflow without a separate consent.

How vendor credentials are stored

Connector credentials (API tokens, OAuth refresh tokens) are two-way by necessity — we have to use them at every poll to call the vendor API, so they can't be one-way hashed. The protection model below is what we run today.

Control	Status	What it does
KMS envelope encryption, per-use unwrapping	Live	Tokens are stored as KMS-wrapped data keys, unwrapped per-use against a customer-managed KMS key. Plaintext never lives in the database or on disk. Every decrypt is a CloudTrail event tied to the calling principal — auditable per-token.
Tenant scoping	Live	Each token is stored under the customer's organization identifier, and database-layer row-level security blocks cross-tenant reads even if the application layer is bypassed.
Dynamic OAuth refresh (short-lived access tokens)	Live	Where the vendor supports OAuth (Microsoft Graph, Google, Okta, GitHub, GitLab, etc.) Garde1 stores only the refresh token and mints a fresh short-lived access token at poll time. Vendors without OAuth (legacy API-key vendors) stay on the envelope-encrypted path above.

Revoking access

Disconnect a connector inside the Garde1 app at any time; the token is invalidated immediately and the consent record is closed. Customers can additionally revoke consent at the vendor side (Entra admin consent grant, Google Workspace OAuth app, AWS IAM role) and Garde1 will stop receiving data on the next poll cycle.