canonical: https://jentic.com/apis/googleapis.com/securitycenter # Google Security Command Center API Security Command Center (SCC) is Google Cloud's centralized vulnerability and threat reporting service for GCP organizations. The API gives programmatic access to assets, findings, sources, and notification configs - the same data surfaced in the SCC dashboard. Agents can list and filter findings, mute or change finding state, group assets and findings, manage notification configs that stream events to Pub/Sub, and run BigQuery exports. ## For AI agents List, mute, and triage GCP security findings, group assets, and stream new findings to Pub/Sub or BigQuery for AI agents. ## Scope Does not handle log ingestion, asset inventory enumeration, or IAM policy changes - use for surfacing, triaging, and routing GCP security findings only. ## Capabilities - List and filter findings across an organization, folder, or project by category, severity, and state - Mute findings or set their state to ACTIVE or INACTIVE for triage workflows - Group assets and findings by arbitrary fields to produce posture summaries - Manage notification configs that publish new or updated findings to a Pub/Sub topic - Configure BigQuery exports for long-term finding analytics - List and update sources, including custom sources used by partner detectors ## Use cases ### Centralized Cloud Security Posture Pull findings from Security Command Center into a SIEM, ticketing system, or agent-driven posture dashboard. The API exposes assets across the GCP organization plus findings from built-in detectors (SHA, ETD, WSS, Container Threat Detection) and partner sources, with rich filtering and grouping. Most teams replace screen-scraping the SCC UI with a daily API sync. Example prompt: Call POST /v1/organizations/{orgId}/sources/-/findings:group with groupBy='category,severity' and filter='state="ACTIVE"' to summarise active findings. ### Automated Triage and Mute Build automation that mutes known-benign findings (like internal IPs flagged as public-exposed test resources) so analysts only see actionable items. The setMute action records the rationale and stops downstream notifications, while setState lets you mark findings as INACTIVE once underlying issues are fixed. Mute rules and per-finding mutes are both supported. Example prompt: Call POST /v1/{name}:setMute with muteState='MUTED' on a finding identified as a false positive, then POST setState with state='INACTIVE'. ### Streaming Findings to Pub/Sub Create a notification config so that every new or updated finding matching a filter is published to a Pub/Sub topic. Downstream subscribers (Cloud Run, BigQuery, on-prem SOC) get near-real-time delivery and can replay messages. This is the standard pattern for integrating SCC with custom incident response pipelines. Example prompt: Call POST /v1/organizations/{orgId}/notificationConfigs with pubsubTopic and a filter like 'severity="HIGH" OR severity="CRITICAL"'. ### AI Agent Security Co-Pilot An AI agent acts as a co-pilot to a security team, reading new findings each morning, grouping them by category, drafting Jira tickets for the top issues, and muting recurring noise. Through Jentic the agent searches for SCC operations by intent and never holds raw GCP service account keys. Example prompt: List ACTIVE findings with severity in (HIGH, CRITICAL), group by category, then for each top category create a Jira ticket and call setMute on duplicates. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /v1/{+parent}/sources/-/findings | List findings under an org, folder, or project | | POST | /v1/{+parent}/sources/-/findings:group | Group findings by arbitrary fields | | POST | /v1/{+name}:setMute | Mute or unmute a finding | | POST | /v1/{+name}:setState | Set a finding state to ACTIVE or INACTIVE | | POST | /v1/{+parent}/notificationConfigs | Create a Pub/Sub notification config | | POST | /v1/{+parent}/bigQueryExports | Create a BigQuery export for findings | ## Key resources - **findings** — List, get, group, mute, and update state on security findings - **assets** — List and group GCP assets, run scans, and read security marks - **sources** — Manage detector sources including partner sources - **notificationConfigs** — Create configs that publish findings to Pub/Sub - **bigQueryExports** — Configure long-running exports of findings into BigQuery ## Why Jentic - **Setup:** Wiring Google Security Command Center by hand means configuring a service account, minting OAuth access tokens against securitycenter.googleapis.com, and learning its finding filter DSL yourself. Through Jentic you install once, import the Security Command Center API from the API Directory, store the OAuth credential once, and your agent calls it. - **Permission scoping:** Security Command Center puts the finding in the URL path (/v1/{name}:setMute, /v1/{name}:setState), so a rule can pin your agent to the findings under one organization or source: it can list and group findings there and nothing else. You choose the operations it may call, so state changes like setState or setMute are not included unless you add them. - **Credential handling:** Your Security Command Center OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'list active high severity findings' or 'mute a finding', and Jentic returns the matching Security Command Center operation with its filter schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Google Cloud Asset Inventory API** — Inventories every GCP resource so SCC findings can be correlated with asset metadata and ownership. - **Google Cloud Logging API** — Provides the underlying audit and platform logs that complement SCC findings during incident investigation. - **AWS Security Hub** — AWS's equivalent CSPM and findings aggregator. - **AWS GuardDuty** — AWS's threat detection service, narrower than Security Hub's aggregator role. ## FAQ ### What authentication does the Security Command Center API use? SCC uses OAuth 2.0 with the cloud-platform scope and IAM permissions like roles/securitycenter.findingsViewer or findingsEditor at the organization level. Through Jentic these credentials are stored encrypted in your Jentic One instance and a scoped token is provided at execution. ### Can I bulk mute findings with the Security Command Center API? Yes. POST /v1/{name}:bulkMute accepts a filter expression (e.g. category and resource attributes) and a muteAnnotation, then mutes every matching finding asynchronously and returns a long-running operation. ### What are the rate limits for the Security Command Center API? Google enforces a default per-organization quota of 600 read requests per minute and 60 write requests per minute, with separate group/list call budgets. Quotas can be raised via the Cloud Console quota page. ### How do I subscribe to new findings through Jentic? Run the Jentic search query 'create a security command center notification config', load the POST /v1/organizations/{org}/notificationConfigs operation, and execute it with your Pub/Sub topic and filter. New matching findings will publish to the topic in near real time. ### Does SCC support folder- and project-level finding queries? Yes. Findings can be listed under organizations/{org}/sources/-, folders/{folder}/sources/-, or projects/{project}/sources/- parents. Filters use the standard SCC filter syntax. ### Can the API export findings to BigQuery for analytics? Yes. Create a BigQueryExport resource under your organization or project that points at a target dataset; SCC will stream finding events to a structured table. List and update operations on bigQueryExports let you manage them over time. ### Can I limit what my agent is allowed to do with the Security Command Center API? Yes. Because you run Jentic One yourself, your own rules decide which Security Command Center operations and which OAuth credential your agent may use. Since the API puts the finding in the URL path (for example /v1/{name}:setMute and /v1/{name}:setState), a rule can pin the agent to the findings under a single organization or source, letting it list and group findings there and nothing else. State-changing calls like setMute and setState are only available to the agent if you explicitly add them, so read-only triage and write actions stay separated as you choose.