canonical: https://jentic.com/apis/googleapis.com/networksecurity # Google Network Security API The Network Security API configures and manages Google Cloud network security policies - address groups, authorization policies, server and client TLS policies, gateway security policies, and security profile groups. It provides the control plane for shaping which traffic is allowed across VPC networks, load balancers, and Google Cloud workloads. Use it to define IP allow lists, enforce mTLS, attach URL filtering rules, and bind security profiles to gateways. The spec exposes 47 endpoints across regional locations and long-running operations. ## For AI agents Configure and manage Google Cloud network security policies - address groups, TLS policies, authorization policies, and security profile groups - across regional locations. ## Scope Does not handle VPC firewall rule enforcement, identity-level access control, or DDoS mitigation - use for declaring network security policy resources only. ## Capabilities - Create address groups and add or remove IP CIDRs to drive allow/deny rules across VPCs - Author authorization policies that gate east-west and north-south traffic on managed gateways - Roll out server and client TLS policies to enforce mTLS between Google Cloud services - Define gateway security policies and attach URL filtering rules to mediate egress traffic - Bind security profile groups to firewall and gateway resources for layered threat inspection - Track regional rollout via long-running operations and cancel in-flight changes when needed ## Use cases ### Centralised IP allow lists across regions Maintain reusable address groups that hold allowed or blocked IP CIDRs, then reference them from firewall and authorization policies across multiple regions. The Network Security API lets you add, clone, and remove items from a group atomically so policy changes propagate through one source of truth instead of dozens of inline rules. Suitable for organisations standardising egress controls or enforcing partner allow lists across hundreds of VPCs. Example prompt: Create an address group named partner-allowlist in us-central1, add CIDRs 203.0.113.0/24 and 198.51.100.0/24, and confirm the operation finished successfully. ### Mutual TLS enforcement between services Author server and client TLS policies that enforce mTLS for traffic between Google Cloud workloads exposed via load balancers and service mesh endpoints. The API stores certificate authorities, validation rules, and SAN lists as policy resources you attach to backend services. Useful for zero-trust deployments that need cryptographic identity instead of network-level trust. Example prompt: Create a server TLS policy that requires client certificates issued by a specific CertificateAuthorityService CA and attach it to the backend service my-grpc-service. ### Gateway URL filtering and threat inspection Define gateway security policies with ordered URL filtering rules and bind security profile groups for deep inspection. The API targets traffic flowing through Secure Web Proxy and other Google Cloud network gateways so security teams can block categories, log decisions, and route traffic through TLS interception. Reduces the friction of editing rule sets directly inside the gateway console. Example prompt: Create a gateway security policy gw-egress-policy in europe-west1, add a URL filtering rule that denies category gambling, and bind security profile group threats-default. ### Agent-driven network security automation via Jentic Through Jentic, AI agents can author and update network security resources without holding raw OAuth tokens. The agent issues an intent like configure mTLS, Jentic returns the matching Network Security API operation with its input schema, and execution happens with credentials brokered via your Jentic One instance. This lets ops chatbots and remediation agents adjust policies in response to alerts in seconds. Example prompt: Use Jentic to find the operation that adds items to an address group, load its schema, and execute it to add 10.0.0.0/8 to corp-internal-ranges. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /v1/{+addressGroup}:addItems | Add IP CIDRs to an address group | | POST | /v1/{+addressGroup}:removeItems | Remove IP CIDRs from an address group | | POST | /v1/{+parent}/addressGroups | Create a new address group | | GET | /v1/{+addressGroup}:listReferences | List policies that reference an address group | | POST | /v1/{+name}:cancel | Cancel a long-running operation | | GET | /v1/{+name}/operations | List operations for a parent resource | ## Key resources - **addressGroups** — Reusable IP CIDR groups referenced by firewall and authorization policies - **authorizationPolicies** — Allow/deny rules evaluated against principals and request attributes - **serverTlsPolicies** — Server-side TLS configuration including mTLS requirements - **clientTlsPolicies** — Client-side TLS configuration for outbound connections - **gatewaySecurityPolicies** — Gateway-level policies with URL filtering rules and profile group bindings - **securityProfileGroups** — Reusable groupings of security profiles for layered inspection ## Why Jentic - **Setup:** Wiring the Network Security API by hand means standing up Google OAuth 2.0 with a service account, minting scoped access tokens, and handling long-running operation polling and retries against networksecurity.googleapis.com yourself. Through Jentic you install once, import the Network Security API from the API Directory, store the OAuth credential once, and your agent calls it. - **Permission scoping:** The Network Security API puts the resource in the URL path (/v1/{+addressGroup}, /v1/{+parent}/addressGroups), so a rule can pin your agent to one address group or parent location: it can add and remove items and list references there and nothing else. You choose the operations it may call, so you can allow item edits while leaving group creation out of the allowed set. - **Credential handling:** Your Google OAuth credential for the Network Security API 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 'add an IP to an allow list' or 'list address group references', and Jentic returns the matching Network Security API operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Compute Engine API** — Compute Engine owns VPC firewall rules that consume Network Security address groups - **Security Command Center API** — Security Command Center surfaces findings that often drive Network Security policy changes - **Identity and Access Management API** — IAM controls identity-level access; Network Security controls network-level reachability ## FAQ ### What authentication does the Network Security API use? The API uses Google OAuth 2.0 with the cloud-platform scope. When called through Jentic, the OAuth token is brokered from your encrypted Jentic One instance so agents never see the raw credential. ### Can I manage IP allow lists with the Network Security API? Yes. The addItems, removeItems, and cloneItems operations on /v1/{+addressGroup} let you mutate address group membership, and the resulting groups can be referenced from firewall rules and authorization policies. ### What are the rate limits for the Network Security API? Google Cloud applies per-project quotas for control-plane writes - typically a few hundred mutating operations per minute. Exact ceilings appear in the Cloud Console quotas page; treat large rollouts as long-running by polling the operations endpoint. ### How do I create a server TLS policy through Jentic? Search Jentic for create server tls policy, load the schema for the POST on /v1/{+parent}/serverTlsPolicies, and execute it with the parent location and policy body. The Jentic SDK runs the call asynchronously and returns the long-running operation handle. ### Does this API handle data plane packet filtering? No - the API is a control plane that defines policy resources. Packet enforcement happens inside the VPC firewall, load balancers, and Secure Web Proxy data planes that consume these policies. ### How do I track a long-running rollout? Every mutating call returns an operation. Poll /v1/{+name}/operations and inspect the done field; cancel in-flight changes by POSTing to /v1/{+name}:cancel. ### Can I limit what my agent is allowed to do with the Network Security API? Yes. Because you run Jentic One yourself, your own rules decide which Network Security API operations and credentials your agent may use. Since this API carries the resource in the URL path (like /v1/{+addressGroup} and /v1/{+parent}/addressGroups), you can pin an agent to a single address group or parent location and allow only specific calls such as addItems, removeItems, and listReferences while leaving address group creation out of the allowed set. The OAuth credential stays with your Jentic One instance and is injected at execution time, so the agent can act only within the operations you have approved.