canonical: https://jentic.com/apis/googleapis.com/accesscontextmanager

# Google Access Context Manager API

The Access Context Manager API lets Google Cloud organisations define attribute-based access controls on requests to Google Cloud services. It exposes operations to manage access policies, access levels (boolean expressions over device, IP, and identity attributes), and service perimeters that restrict data movement between projects. Security and platform teams use it to enforce zero-trust controls and to build VPC Service Controls perimeters around regulated workloads.

## For AI agents

Define and manage Google Cloud access policies, access levels, and service perimeters so an agent can enforce attribute-based access control and VPC Service Controls programmatically.

## Scope

Does not handle IAM role grants, audit log retrieval, or Google personnel access decisions - use for managing access policies, access levels, and service perimeters only.

## Capabilities

- Create and manage access policies scoped to a Google Cloud organisation
- Define access levels using boolean expressions over device posture, IP ranges, and identity attributes
- Configure service perimeters that restrict which projects can read or write to specified Google Cloud services
- List the GCP services supported by VPC Service Controls so policies stay in sync with new launches
- Manage authorized orgs descriptors that allow cross-organisation perimeter ingress and egress
- Commit dry-run perimeter changes after validation so policy rollouts can be staged

## Use cases

### VPC Service Controls Rollout

A platform team wraps regulated GCP projects in a VPC Service Controls perimeter to prevent data exfiltration. The Access Context Manager API exposes accessPolicies and servicePerimeters operations so the team can define perimeter resources, add projects, and stage changes via dry-run before committing to enforcement.

Example prompt: Create a service perimeter named 'regulated-data' under accessPolicies/123, add projects/billing-prod and projects/audit-prod, and restrict storage.googleapis.com and bigquery.googleapis.com.

### Conditional Access Levels

A security team enforces that only managed devices on the corporate IP range can call sensitive admin APIs. Access Context Manager exposes access-level resources whose conditions combine device posture, IP CIDR, and identity attributes; the team attaches the access level to IAM Conditions to gate access at the API edge.

Example prompt: Create an access level 'corp-managed' under accessPolicies/123 that requires devicePolicy.requireCorpOwned=true and an IP in 203.0.113.0/24.

### Cross-Organisation Ingress Allowlisting

A multi-tenant SaaS hosting customer data in different organisations whitelists specific partner orgs to reach a shared analytics perimeter. Authorized orgs descriptors expose the partner allowlist, and ingress and egress policies on the perimeter reference those descriptors to permit defined flows.

Example prompt: Create an authorizedOrgsDescriptor named 'partner-org' listing the customer's organisation IDs, and reference it from the ingress policy of the analytics perimeter.

### AI Agent Policy Audit

An AI agent embedded in the platform tooling reviews every access policy weekly through Jentic. It enumerates access levels and perimeters, flags overly broad IP ranges or unrestricted services, and posts a summary to the security review channel.

Example prompt: List every accessLevel in accessPolicies/123, identify any with an IP condition broader than /16 or a missing device-policy clause, and reply with a markdown audit summary.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/accessPolicies | List access policies under an organisation |
| POST | /v1/accessPolicies | Create a new access policy |
| GET | /v1/services | List Google Cloud services supported by VPC Service Controls |
| GET | /v1/{+name} | Get an access policy, level, perimeter, or service resource |
| POST | /v1/{+name}:cancel | Cancel an in-progress long-running operation |

## Key resources

- **Access Policies** — Top-level container for access levels and service perimeters under an organisation
- **Access Levels** — Boolean expressions over device, IP, and identity attributes that gate access to Google Cloud APIs
- **Service Perimeters** — Boundary around projects that restricts data movement for a configured set of Google Cloud services
- **Authorized Orgs Descriptors** — Allowlist of partner organisations referenced by perimeter ingress and egress policies
- **Services** — Catalogue of Google Cloud services supported by VPC Service Controls

## Why Jentic

- **Setup:** Wiring the Access Context Manager API by hand means configuring Google OAuth 2.0, minting short-lived access tokens from a refresh token, and directing calls at accesscontextmanager.googleapis.com with the correct IAM bindings. Through Jentic you install once, import the Access Context Manager API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Access Context Manager puts the policy resource in the URL path (/v1/{+name}), so a rule can pin your agent to one access policy: it can read that policy's access levels and perimeters and nothing else. You choose the operations it may call, so changes like replacing a service perimeter or cancelling an operation are not included unless you add them.
- **Credential handling:** Your Google OAuth credential is stored once, encrypted, by your own Jentic One instance and exchanged for short-lived access tokens at execution time. The refresh token never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an access level for corp devices' or 'list service perimeters', and Jentic returns the matching Access Context Manager operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Access Approval API** — Approve or dismiss Google personnel access requests against the same organisation
- **Google Cloud IAM API** — Manage IAM policies and Conditions that reference access levels
- **Cloud Resource Manager API** — List projects and folders that perimeters reference

## FAQ

### What authentication does the Access Context Manager API use?

It uses Google OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope. The calling principal needs the accesscontextmanager.policyAdmin or policyEditor role on the access policy. Jentic stores the OAuth credential in its encrypted vault and exchanges it for short-lived access tokens at request time.

### Can I create a service perimeter without disrupting traffic?

Yes. The API supports dry-run perimeters via servicePerimeters.replaceAll and the commit operation. Dry-run perimeters log violations without blocking traffic, so teams can validate the perimeter scope and then call accessPolicies.servicePerimeters.commit to enforce.

### What are the rate limits for the Access Context Manager API?

The default quota is 60 write requests and 600 read requests per minute per organisation, shared across access policies, levels, and perimeters. Long-running operations (perimeter creates and updates) return an Operation resource that the client polls until done.

### How do I list all service perimeters in an organisation through Jentic?

Run jentic search 'list service perimeters in google cloud', load the accessPolicies.servicePerimeters.list operation, and execute it with the parent set to accessPolicies/{policy_id}. The agent receives a typed list of perimeter resources with their restrictedServices and resources arrays.

### Is the Access Context Manager API free?

Yes. There is no per-call charge for Access Context Manager. The underlying Google Cloud services that the perimeters protect are billed normally.

### Can I limit what my agent is allowed to do with the Access Context Manager API?

Yes. Because Jentic One is self-hosted, your own rules decide which Access Context Manager operations and credentials the agent may use. Since the policy resource sits in the URL path (/v1/{+name}), you can pin the agent to a single access policy so it only reads that policy's access levels and service perimeters. You also choose the exact operations it may call, so write actions like replacing a service perimeter or cancelling a long-running operation are excluded unless you add them.