Google Security Command Center API
Browse all Google APIs41
AI ReadinessNon-Ready (D-)41/100
Official vendor OpenAPI document · agent-readySecurityThreat Detectionoauth234 EndpointsREST
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.
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.
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.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgoogleapis.com%2Fsecuritycenter" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgoogleapis.com%2Fsecuritycenter" | sh
jentic register # connects your agent to your Jentic One instanceJentic 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
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
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
POST
/v1/{+parent}/bigQueryExports
Create a BigQuery export for findings
Jentic AI Readiness Score
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
S
Security Command Center API
- Non-Ready (D-)41/100
37
Foundational Compliance56
Developer Experience & Jentic Compatibility22
AI-Readiness & Agent Experience94
Agent Usability63
Security61
AI DiscoverabilityPowered by JenticScoring Framework 1.0.0 | Scoring Engine 0.4.0
Show dimension breakdown
37
Foundational Compliance
Base layer of spec validity and structural soundness.
Grade: FSignals: 4
49%
Lint Results
Aggregated quality score from linter diagnostics, weighted by severity.
100%
Resolution Completeness
Percentage of `$ref` references that resolve successfully.
0%
Specification Validity
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
0%
Structural Integrity
Structural correctness score based on schema issues using logarithmic dampening.
56
Developer Experience & Jentic Compatibility
Clarity, completeness, and ingestion readiness for developers and tooling.
Grade: CSignals: 4
0%
Example Density
How richly the API is illustrated with examples.
100%
Example Validity
Percentage of examples that conform to their schemas.
25%
Response Coverage
Percentage of operations with complete response definitions (success, client error, server error).
100%
Tooling Readiness
Health of API ingestion, bundling, and resolution within Jentic pipelines.
22
AI-Readiness & Agent Experience
Semantic breadth, depth, and agent comprehension for AI systems.
Grade: FSignals: 4
88%
Description Coverage
Coverage of descriptions across API elements.
0%
Error Standardization
Coverage of RFC 9457 Problem Details for error responses.
0%
OperationId Quality
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
0%
Summary Coverage
Coverage of summaries across operations/tags/info.
94
Agent Usability
Functional utility, complexity comfort, and AI orchestration readiness.
Grade: A+Signals: 1
94%
Complexity Comfort
Agent comfort level based on API operational and structural complexity.
63
Security
Trust, risk posture, and security compliance.
Grade: B-Signals: 1
62%
Authentication Strength
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
61
AI Discoverability
Findability, semantic richness, and reasoning readiness.
Grade: B-Signals: 1
61%
Descriptive Richness
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 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.
Related APIs
Alternatives and complements available in the Jentic catalogue.
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.
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.
GET STARTED