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.
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.