Google Security Command Center API

Name: Security Command Center API
Brand: Security Command Center API
Availability: InStock

✓ Official Vendor SpecSecurityThreat Detectionoauth234 Endpoints

Install Jentic One Beta

Connect the Security Command Center API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Security Command Center API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Security Command Center API.

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

GET STARTED

Start building with Security Command Center API

Explore with Jentic

View OpenAPI Document

For Agents

List, mute, and triage GCP security findings, group assets, and stream new findings to Pub/Sub or BigQuery for AI agents.

Use for: List all HIGH severity findings opened in the last 7 days, Mute a finding that has been triaged as a false positive, Set up a Pub/Sub notification for new findings in my organization, Group findings by category to see the top issue types

Not supported: Does not handle log ingestion, asset inventory enumeration, or IAM policy changes - use for surfacing, triaging, and routing GCP security findings only.

Use Cases

Patterns agents use Security Command Center API for, with concrete tasks.

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

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.

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.

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.

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

34 endpoints — security command center (scc) is google cloud's centralized vulnerability and threat reporting service for gcp organizations.

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

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

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.

Intent-based discovery

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.

Time to first call

FAQs

Specific to using Security Command Center API through Jentic.

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.

Google Security Command Center API

Connect the Security Command Center API to your agent

Capabilities

Start building with Security Command Center API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs