连接器数据访问

Read file/folder names and sharing settings (never file contents) to map who can access what.

Read SharePoint Online site, library, and file sharing settings (never file contents) to map who can access what.

Read OneDrive for Business sharing links and permissions to find anonymous / guest / org-wide exposure.

Distinguish your members from external guests, and read groups — the internal/external boundary.

Inventory Entra app registrations / service principals and their consented scopes — the "who gave that app access" surface (Agent Guard).

Read the user directory (display name, sign-in state, guest vs member) to attribute access and flag dormant accounts — never mailbox or file contents.

Read Security Defaults, Conditional Access, app-consent and external-collaboration policies to audit the tenant security baseline (legacy-auth block, MFA enforcement, shadow-AI consent).

Read the authentication-methods registration report to measure MFA coverage across the tenant.

Read sign-in and audit activity metadata that backs the MFA / sign-in posture checks (no message or file contents).

Read privileged role assignments (Global Administrator and other admin roles) to flag over-broad standing privilege.

Read delegated OAuth consent grants (which users authorized which third-party apps) — the shadow-AI / OAuth-phishing surface.

List public channels (incl. Slack Connect external shared channels) and their membership — never message contents — to map who can reach which channel.

List private channels and their membership (metadata only) so private-channel exposure can be assessed.

Find files shared with a public link ("anyone with the link") so public file exposure can be flagged — file contents are never read.

Enumerate workspace members, bots, and guests, and read each member’s 2FA-registration status to assess two-factor enforcement.

Resolve member email addresses to separate your org from multi-channel guests and Slack Connect external members — the internal/external boundary.

List Slack user groups so broad group grants on sensitive channels can be attributed.

Read workspace identity and join/discovery settings to audit workspace-level configuration.

Read page/database titles and their sharing settings (never the page body) to map who can access what across teamspaces.

Distinguish your members from guests and external collaborators — the internal/external boundary.

Inventory teamspace membership, group grants, and installed integrations + their capabilities — the "who gave that integration access" surface (Agent Guard).

Organizations: list org members, teams, and installed GitHub Apps — never source code — to map who and what can reach which repository. Personal accounts: only used to confirm the account type.

Read repository visibility, collaborator lists, and deploy keys (including whether each key is read-only) — on your organization or your own repositories. Never source code.

Identify the connected account and distinguish members from outside collaborators — the internal/external boundary.

Inventory installed GitHub Apps and the permission grants they hold — the "which bot still has admin?" surface (Agent Guard) — for an organization or for your personal account.

Read the Copilot seat inventory — who holds a seat and when it was last used — to flag seats of departed members and seats idle 90+ days. We only ever read; seats are never assigned or removed without an explicit fix action you approve.

Read Copilot-related organization audit-log events (GitHub Enterprise Cloud only) as supporting evidence for Copilot policy findings. Absent on non-Enterprise orgs — the connector degrades gracefully.

Assume the read-only role the 8200.dev CloudFormation template creates in your account — scoped by a unique External ID you control — to read IAM without any long-lived key leaving your account.

Read IAM users, roles, groups, policies, MFA/access-key metadata (never secret material), the password policy, and role trust policies to map account hygiene and who/what can do what.

Read role trust relationships to find roles assumable broadly (public / cross-account) — the "who/what can assume this role" surface (Agent Guard).

Read users, profiles, permission sets, objects, Connected Apps, AI-agent (Agentforce/Einstein) metadata, and security configuration via the REST + Tooling API (never record contents beyond what governance needs) to map who — and which AI agent or OAuth app — can access which data.

Keep the read-only connection alive without re-prompting — issues the refresh token so scheduled re-scans run unattended.

Read-only access to all files, folders, collaborations, and shared-link settings (never file contents) to map who can access what across the enterprise.

Read file/folder names and metadata (never file contents) to enumerate what exists across the team.

Read shared links and shared-folder members to find public-link, team-wide, and external exposure.

Read the connected account/team identity — the internal/external boundary.

On Dropbox Business, enumerate team members and groups so internal vs. external sharing can be classified (Business plan only).

List users and their status, last-login, enrolled MFA factors, and admin roles — to find accounts without MFA, admin sprawl, and dormant or deactivated users that still hold access.

List groups and the built-in "Everyone" group to expand group-based app access.

List app integrations and per-app user/group assignments — who can sign into which application (the core IdP governance surface), including AI / OAuth apps and their scopes.

Read password, sign-on, and session policy to check minimum standards (password strength, admin MFA, session lifetime).

Read a bounded slice of the System Log to flag suspicious events (repeated failed logins, new admin grants, new app additions) and detect zombie apps with no recent sign-in.

Read each bot's identity and capabilities — username, name, whether it can join groups, and whether it can read ALL group messages (privacy mode) — to inventory the bot and flag over-broad message access.

Read each bot's webhook configuration — URL, whether it is HTTPS, custom-certificate use, the subscribed update types, and the pending-update backlog — to find insecure (HTTP) endpoints, data flowing to external AI providers, and overloaded/unmonitored bots.

Read your teammates (admins) — name, email, inbox seat — to inventory who can access the support inbox and customer data, and to flag accounts without two-factor authentication.

Read team structure to map how support access is organized across the workspace.

Read workspace identity and configuration — the Fin AI Agent and custom bots, their knowledge sources and handover policy, installed integrations, and security settings (identity verification) — to govern what your AI agents can say and what apps can read (never conversation or message contents).

Read account identity and security configuration (SSO, two-factor enforcement, IP restrictions, sandbox) to assess the account-level security posture.

Read agents and admins — name, email, role — to inventory who can access tickets and customer data and to flag accounts without two-factor authentication.

Read custom agent roles and their permissions to find roles with elevated/destructive access such as ticket deletion.

Read installed marketplace apps to find third-party (including AI) integrations that can read ticket and customer data (never ticket contents or customer messages).

Read your WhatsApp Business Accounts, phone numbers, 2-Step Verification state, quality ratings, and subscribed apps to audit their security posture — never message contents.

Read the business portfolio and the system users assigned to each WhatsApp Business Account to flag over-broad standing access (MANAGE).

Read workspace members and roles, teams and their public/private state, API keys, authorized OAuth apps, and webhooks — the access + configuration surface. Never issue contents; never write.

Read projects, project visibility, permission schemes, issue-security schemes, webhooks, automation rules, and the labels/security levels of issues — the access + configuration surface. Never issue contents; never write.

Read the user directory (display name, account type, active state) to distinguish members from portal customers and external guests and to flag admin sprawl and dormant accounts — the internal/external boundary.

Obtain a refresh token so the Connector Health Daemon can keep the read-only connection alive without re-prompting an admin — never grants any additional data access.

Read-only access to your Cloud Platform resources — project IAM policy, service accounts and their keys, API keys, enabled APIs, audit-log configuration, VPC firewalls, and Cloud Storage bucket policies — to audit your project security posture. Never grants any write access.

Read the list and metadata of your GCP projects so the scan can identify which project it is auditing. Read-only.

Read the user directory (display name, sign-in state, guest vs member, MFA registration) to audit account and MFA hygiene — never mailbox, file, or credential contents.

Read groups, their membership type, visibility, and owners to find ownerless, public, and guest-bearing groups.

Read Conditional Access, authorization (guest-invite), and authentication policies to audit MFA enforcement and legacy-auth blocking.

Read Identity Protection risk state (at-risk / confirmed-compromised users) to surface accounts that need attention. Requires Entra ID P2.

Read sign-in and audit activity metadata that backs the MFA-coverage and sign-in-log posture checks (no message or file contents).

Read privileged directory-role assignments (Global Administrator and other admin roles) to flag over-broad standing privilege and admins without MFA.

Read Privileged Identity Management (PIM) eligible-role schedules to check whether just-in-time activation is in use. Requires Entra ID P2.

Read the API-key inventory (id, name, created, last-used, expiry, workspace scope) to find stale, org-wide, orphaned, and never-expiring keys. Key secrets are never readable.

Read organization members and their roles to detect admin-role sprawl and keys whose creator has left the organization.

Read audit-log events (who did what, when) as the activity feed. Optional — the connector degrades gracefully if unavailable on your plan.

Read organization members and their roles (owner/reader) to detect admin-role sprawl and keys whose creator has left the organization.

Read the project list so API keys can be attributed to their project scope (org-wide admin keys vs project-scoped keys).

Read the API-key inventories (admin + per-project) with OpenAI’s native last-used timestamps to find stale, org-wide, and orphaned keys. Key secrets are never readable (values are redacted by OpenAI).

Read audit-log events as the activity feed. Optional — audit logging is an opt-in OpenAI setting; if it is off, a setup-completeness finding tells you exactly that.

List the workspace’s exported compliance-log windows (conversations, file uploads, admin actions, auth events — metadata, never message contents) as governance evidence. The Compliance Platform is read-only by design.

Read organization members and their roles to detect admin-role sprawl and keys whose creator has left the organization.

Read the API-key inventory (name, status, workspace scope, created/expiry — never the secrets). Honesty note: Anthropic reports no per-key last-use, so staleness relies only on Anthropic’s own inactive classification.

Read workspace names so keys can be attributed to their scope (default-workspace keys have org-wide reach).

Read the daily usage report (token totals only) to power the usage-spike anomaly check against your trailing 30-day baseline.

Read team members and roles (owner/member) to detect owner-role sprawl.

Read per-member daily usage (server-side metrics only — tamperable client-side editor telemetry is never used) to find paid seats with no activity.

Read per-member spend and monthly limits to flag uncapped usage-based spend.

Read team audit-log events (trailing 30 days) as the activity feed.