canonical: https://jentic.com/apis/googleapis.com/cloud-ids

# Google Cloud IDS API

The Cloud IDS API manages Cloud Intrusion Detection System endpoints on Google Cloud. Cloud IDS is built on Palo Alto Networks threat detection technology and inspects mirrored VPC traffic for malware, spyware, command-and-control activity, and other network-based threats. The API provides CRUD over IDS endpoints attached to a VPC and a region, lists locations where Cloud IDS is available, and exposes long-running operations that track endpoint provisioning. Detected threats themselves are streamed to Cloud Logging and Security Command Center; this API is the control plane for the inspection endpoints, not the threat feed.

## For AI agents

Provision and manage Cloud Intrusion Detection System endpoints on a Google Cloud VPC to inspect mirrored traffic for malware, C2, and other network threats.

## Scope

Does not return detected threats, manage firewall rules, or scan web apps - use for Cloud IDS endpoint lifecycle (create, list, update, delete) on a VPC only.

## Capabilities

- Create a Cloud IDS endpoint attached to a specified VPC, region, and severity threshold
- List Cloud IDS endpoints in a project and region with their state and threat-severity settings
- Get a single Cloud IDS endpoint to inspect its network, severity threshold, and update timestamps
- Update a Cloud IDS endpoint to change severity threshold or threat exception lists
- Delete a Cloud IDS endpoint when its inspection scope is no longer required
- Track long-running endpoint provisioning operations to confirm readiness
- List supported Cloud IDS locations to plan multi-region deployments

## Use cases

### Production VPC Threat Inspection

Security teams running production workloads on Google Cloud deploy a Cloud IDS endpoint per VPC and per region of interest, with severity threshold tuned to MEDIUM or LOW. Mirrored VPC traffic is inspected by Palo Alto threat signatures and any detections are emitted to Cloud Logging and Security Command Center. The API drives this provisioning as code so endpoints are reproducible across environments.

Example prompt: Create a Cloud IDS endpoint named prod-eu in projects/p/locations/europe-west1 attached to network projects/p/global/networks/prod-vpc with severity LOW, and poll the returned operation until done.

### Regional Rollout Inventory

When expanding into a new region, a SecOps team lists Cloud IDS endpoints across the project to confirm coverage matches the workload footprint. Gaps are filled by creating new endpoints; over-provisioned endpoints in unused regions are deleted. The API's list and locations operations make this auditable.

Example prompt: List all Cloud IDS endpoints under projects/p across all locations, then for each region with no endpoint produce a remediation plan with location, network, and proposed severity.

### Severity Tuning After False Positives

Operations teams adjust an IDS endpoint's severity threshold after a wave of low-severity false positives, or extend the threat-exceptions list to silence specific signatures. The API supports PATCH on the endpoint resource so the change is auditable and revertible.

Example prompt: Update endpoint projects/p/locations/europe-west1/endpoints/prod-eu to set severity to MEDIUM and add threatExceptions for signature IDs 12345 and 67890, then confirm the response shows the new values.

### AI Agent IDS Health and Drift Check

An AI agent runs a daily health check on Cloud IDS deployments via Jentic, listing endpoints, comparing configurations against declared policy, and surfacing drift to SecOps. The agent uses a service-account credential isolated by Jentic so raw private keys never enter its context.

Example prompt: List Cloud IDS endpoints under projects/p across all locations, compare each one's severity field against declared-ids.yaml, and emit a drift report listing endpoints whose severity does not match the declared value.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{+parent}/endpoints | List Cloud IDS endpoints under a project and location |
| POST | /v1/{+parent}/endpoints | Create a new Cloud IDS endpoint |
| GET | /v1/{+name} | Get a Cloud IDS endpoint by name |
| PATCH | /v1/{+name} | Update a Cloud IDS endpoint |
| DELETE | /v1/{+name} | Delete a Cloud IDS endpoint |
| GET | /v1/{+name}/locations | List supported Cloud IDS locations |
| GET | /v1/{+name}/operations | List long-running operations |
| POST | /v1/{+name}:cancel | Cancel a long-running operation |

## Key resources

- **Endpoints** — Create, list, get, update, and delete Cloud IDS endpoints attached to a VPC in a region
- **Locations** — Discover the regions that support Cloud IDS
- **Operations** — Track and cancel long-running endpoint provisioning operations

## Why Jentic

- **Setup:** Wiring the Cloud IDS API by hand means configuring admin OAuth2, narrowing to the cloud-platform scope, refreshing tokens, and URL-encoding its endpoint and operation resource paths yourself. Through Jentic you install once, import the Cloud IDS API from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** Resource names travel in the URL path (/v1/{parent}/endpoints, /v1/{name}), so a rule can pin your agent to one project or location's IDS endpoints: it lists and inspects endpoints under that parent and nothing else. You choose the operations it may call, so destructive ones like endpoint deletion are not included unless you add them.
- **Credential handling:** Your Cloud IDS admin credential is stored once, encrypted, by your own Jentic One instance and injected at execution time as a short-lived cloud-platform access token. The service-account key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a cloud ids endpoint' or 'list cloud ids endpoints', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without browsing the URL-encoded resource-name conventions.

## Related APIs

- **Network Security API** — Manages security policies (firewall, TLS inspection) that complement Cloud IDS network-traffic inspection.
- **Web Security Scanner API** — Scans App Engine and Compute Engine web apps for vulnerabilities; Cloud IDS inspects network traffic for active threats.
- **Identity and Access Management (IAM) API** — IAM grants the ids.endpoints.* roles required to call this API.

## FAQ

### What authentication does the Cloud IDS API use?

Google OAuth 2.0 with the cloud-platform scope and an IAM principal that holds ids.endpoints.* permissions on the parent project. Through Jentic the credential is held encrypted in the vault and exchanged for a scoped access token at call time.

### Can I update an existing Cloud IDS endpoint's severity?

Yes. Call PATCH /v1/{+name} on the endpoint resource with severity set to INFORMATIONAL, LOW, MEDIUM, HIGH, or CRITICAL. Endpoint updates run as long-running operations; poll the returned operation name until done.

### What are the rate limits for the Cloud IDS API?

Google enforces a per-project quota on Cloud IDS admin operations (default in the low hundreds of QPS). Most actions are infrequent control-plane changes that complete via long-running operations within minutes.

### How do I deploy a Cloud IDS endpoint through Jentic?

Search Jentic with 'create cloud ids endpoint', load the POST /v1/{+parent}/endpoints operation, and execute with parent set to projects/{p}/locations/{region} and a body specifying network, severity, and endpoint id. Jentic handles OAuth and returns the operation name.

### Does the Cloud IDS API return detected threats?

No. Detected threats are exported to Cloud Logging and surface in Security Command Center. This API is the control plane for IDS endpoints; consume threat findings via the Cloud Logging or Security Command Center APIs.

### Can I limit what my agent is allowed to do with the Cloud IDS API?

Yes. Because your Jentic One instance is self-hosted, you set the rules that decide which Cloud IDS operations and which credential your agent may use. Since Cloud IDS resource names travel in the URL path (/v1/{parent}/endpoints and /v1/{name}), you can pin the agent to a single project or location so it only lists and inspects the endpoints under that parent and nothing else. You also choose which operations it may call, so destructive ones like endpoint deletion stay out of reach unless you explicitly grant them.