Google Policy Simulator API
Browse all Google APIs✓ Official Vendor SpecSecurityComplianceoauth23 EndpointsREST
For Agents
Simulate proposed IAM policy changes by replaying past access requests and comparing decisions before applying the change.
Use for: Simulate a Cloud IAM policy change before applying it, Create a Replay to test removing a role binding, List per-access decisions for a Policy Simulator Replay, Check whether tightening a custom role would break production access
Not supported: Does not modify IAM policies, query historical activity, or troubleshoot a single live access denial — use only to create and read IAM Replays.
The Google Cloud Policy Simulator API lets administrators model the impact of a proposed IAM policy change before they apply it. Three endpoints support replay workflows: create a Replay under a parent organisation, folder, or project, fetch a single Replay's status and metadata, and list ReplayResults that show how each historical access request would have been decided under the candidate policy. Security and platform teams use simulations to confirm that tightening a role or removing a binding will not break production access.
Install Jentic One Beta
Connect the Policy Simulator API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Policy Simulator 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://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
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 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 Policy Simulator API.
Create a Replay under an organisation, folder, or project to model a candidate IAM policy change
Fetch the status and metadata of an in-flight or completed Replay
List per-access ReplayResults showing decision differences between baseline and proposed policies
Identify previously-allowed accesses that would be denied under a tighter policy
Confirm that a proposed least-privilege change does not break production traffic
Use Cases
Patterns agents use Policy Simulator API for, with concrete tasks.
★ Pre-Change IAM Validation
Before a platform team removes an over-broad role binding, they create a Replay against the proposed policy to confirm no real access was relying on the removed permissions. The Replay reads recent access logs under the parent, evaluates each request twice, and lists differences. Teams skip the change if differences include traffic from production identities and proceed if the diff is empty.
POST /v1/{parent}/replays with body containing the proposed policy override, then GET /v1/{name} until state=SUCCEEDED, then GET /v1/{parent}/results and report any AccessTuples whose decision flipped from ALLOW to DENY.
Bulk Custom Role Tightening
Security engineers tightening a custom role across a large organisation use Replay to evaluate the proposed changes against thousands of past access requests in one batch. Per-access ReplayResults pinpoint every identity, resource, and permission whose decision would change, letting the team build a targeted exception list before they roll out the new role definition.
Create a Replay with the tightened custom role, list ReplayResults filtered to decision=DIFFERENT, and aggregate by principal and resource to produce an exception list.
Audit Evidence for IAM Changes
Compliance programmes require evidence that proposed IAM changes were assessed before they were applied. By creating a Replay per change request and attaching the Replay name and ReplayResults summary to the change ticket, teams produce automated evidence that satisfies SOC 2 and ISO 27001 control objectives without manual screenshots.
On every IAM change request, POST /v1/{parent}/replays with the proposed delta, attach the returned Replay name to the change ticket, and store the SUCCEEDED status as audit evidence.
AI Agent Policy Modelling via Jentic
Cloud security agents that propose IAM cleanups can call Policy Simulator through Jentic to validate every proposed change before they emit a write. Jentic stores the cloud audit credentials in its vault and exposes the replays.create, replays.get, and results.list operations as three search-load-execute calls so the agent can model, poll, and read results in a single short flow.
Search Jentic for 'simulate a Google Cloud IAM policy change', load the replays.create schema, execute it with the proposed policy, then poll replays.get and list results once succeeded.
Key Endpoints
3 endpoints — the google cloud policy simulator api lets administrators model the impact of a proposed iam policy change before they apply it.
METHOD
PATH
DESCRIPTION
GET
/v1/{name}
Get a single Replay by name with status and metadata
POST
/v1/{parent}/replays
Create a Replay under an organisation, folder, or project
GET
/v1/{parent}/results
List ReplayResults for a completed Replay
GET
/v1/{name}
Get a single Replay by name with status and metadata
POST
/v1/{parent}/replays
Create a Replay under an organisation, folder, or project
GET
/v1/{parent}/results
List ReplayResults for a completed Replay
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
Google Cloud service-account credentials are stored encrypted in the Jentic vault. Agents receive scoped, short-lived access tokens at call time so the service account JSON never enters agent context.
Intent-based discovery
Agents search Jentic with intents like 'simulate a Google Cloud IAM policy change' and receive the matching replays.create, replays.get, or results.list operation with its full input schema.
Time to first call
Direct integration: 2-4 days for service account audit roles, async polling, and result aggregation. Through Jentic: under 1 hour.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Policy Simulator API through Jentic.
What authentication does the Policy Simulator API use?
It uses OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope and is typically called with a service account that has org- or folder-level IAM audit permissions. Through Jentic the credential is held encrypted in the Jentic vault and a scoped access token is injected at call time.
Can I check whether removing a role binding will break access?
Yes. POST /v1/{parent}/replays with the proposed policy override creates a Replay that re-evaluates recent access requests against the candidate policy. GET /v1/{parent}/results then lists every request whose decision changed, so removed bindings that production traffic actually depended on surface as ALLOW-to-DENY flips.
What are the rate limits for this API?
The API enforces standard Google Cloud project quotas measured in queries per minute. Replays are asynchronous — the create call returns quickly and the heavy work is done server-side, so the practical bottleneck is usually the time the Replay itself takes rather than QPS.
How do I simulate an IAM change through Jentic?
Run jentic search 'simulate a Google Cloud IAM policy change', load the schema for POST /v1/{parent}/replays, execute it with the proposed policy override, then call /v1/{name} to poll status and /v1/{parent}/results to read the per-access decisions.
Is the Policy Simulator API free?
There is no per-call charge for creating Replays or reading results. Standard Google Cloud project quotas apply, and Replay execution time depends on the volume of access logs under the chosen parent.
Can I run a Replay across an entire organisation at once?
Yes. The {parent} path parameter accepts organizations/{org}/locations/{loc}, folders/{folder}/locations/{loc}, or projects/{project}/locations/{loc}. Org-level Replays cover all access logs under the organisation, but they take longer and consume more quota than narrower scopes.
GET STARTED