Google Chrome Verified Access API
Browse all Google APIs✓ Official Vendor SpecIdentity AuthAuthenticationoauth22 EndpointsREST
For Agents
Issue and verify cryptographic challenges so an agent can confirm a request comes from a managed Chrome device before granting access to a protected resource.
Use for: I need to issue a Verified Access challenge before granting access to an internal app, Verify that a signed challenge response comes from a managed Chrome device, Check whether a Chrome client is enrolled in our enterprise policy, Generate a fresh challenge for every login attempt to an admin console
Not supported: Does not handle user authentication, password policies, or non-Chrome device verification — use for Chrome and ChromeOS device-trust challenge and verify only.
The Chrome Verified Access API lets enterprise services confirm that a request originates from a managed, policy-compliant Chrome device or ChromeOS user before granting access to sensitive resources. The integration uses a challenge-response handshake: the relying server requests a challenge, the Chrome client signs it via the Verified Access extension, and the server verifies the signed response against Google. It is used for zero-trust gating of internal apps, VPNs, and SaaS resources.
Install Jentic One Beta
Connect the Chrome Verified Access API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Chrome Verified Access 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 Chrome Verified Access API.
Generate a Verified Access challenge for a relying party to send to a Chrome client
Verify a signed challenge response and return the device or user verdict
Gate internal applications behind device-trust enforcement
Confirm ChromeOS device enrollment state as part of a zero-trust access decision
Validate that a request originates from a Chrome browser running on a managed device
Use Cases
Patterns agents use Chrome Verified Access API for, with concrete tasks.
★ Zero-Trust Access to Internal Applications
Security teams gate access to internal admin consoles and finance tools behind device trust by issuing a Verified Access challenge during sign-in and refusing the session if the response does not verify against a managed Chrome device. The challenge is short-lived and unique per login, preventing replay attacks. Integration is two endpoints: generate, then verify.
Call /v2/challenge:generate during a login and call /v2/challenge:verify with the signed response
VPN and Network Access Control
Enterprises require Chrome Verified Access verification before issuing a VPN client certificate or admitting a device to a corporate network segment. The verification endpoint returns a verdict that includes device enrollment state and policy compliance, which the network access controller uses to allow or deny the join request. This complements existing 802.1X workflows and enforces device-level trust on top of user authentication.
Verify a signed Verified Access response and grant a VPN certificate only when the device verdict is enrolled and compliant
Protecting SaaS Resources with Device Trust
SaaS providers serving Chrome enterprise customers use the Verified Access API to add a device-bound check to their authentication flow. The relying app generates a challenge per session, the Chrome extension signs it on the user's managed device, and the SaaS backend verifies the response before issuing the application token. This prevents stolen credentials from being used outside the enrolled device fleet.
Wire Verified Access challenge and verify endpoints into the SaaS login callback
AI Agent Access Decision Workflow
An AI agent integrated through Jentic checks a Verified Access verdict before performing a privileged operation on behalf of a user. The agent calls the generate endpoint to obtain a challenge, relays it through the Chrome client, then submits the response to the verify endpoint and only proceeds if the verdict confirms the device is managed and compliant. Jentic isolates the OAuth token so the agent never holds the raw verifiedaccess scope credential.
Search Jentic for verify chrome device, load the schema, and call verify with the signed response token
Key Endpoints
2 endpoints — the chrome verified access api lets enterprise services confirm that a request originates from a managed, policy-compliant chrome device or chromeos user before granting access to sensitive resources.
METHOD
PATH
DESCRIPTION
POST
/v2/challenge:generate
Generate a Verified Access challenge token
POST
/v2/challenge:verify
Verify a signed challenge response and return the device verdict
POST
/v2/challenge:generate
Generate a Verified Access challenge token
POST
/v2/challenge:verify
Verify a signed challenge response and return the device verdict
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
Verified Access OAuth tokens are stored encrypted in the Jentic vault (MAXsystem). Agents receive scoped access tokens — raw OAuth tokens never enter the agent's context, which is critical because the verifiedaccess scope grants device-trust verification powers across the enterprise.
Intent-based discovery
Agents search Jentic for intents like 'verify a chrome device' and Jentic returns the challenge:verify operation with its full input schema, so the agent can submit a signed response without reading Google's discovery doc.
Time to first call
Direct Verified Access integration: 2-3 days for OAuth setup, Chrome extension wiring, and verdict handling. Through Jentic: under 1 hour for the API side — search, load schema, execute (Chrome client side still requires the Verified Access extension).
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Chrome Verified Access API through Jentic.
What authentication does the Chrome Verified Access API use?
The Chrome Verified Access API uses OAuth 2.0 with the https://www.googleapis.com/auth/verifiedaccess scope. Through Jentic, the OAuth token is stored encrypted in the MAXsystem vault and only a scoped reference is exposed to the agent at execution time.
How does the Chrome Verified Access API confirm a device is managed?
The relying server calls /v2/challenge:generate to obtain a short-lived challenge, sends it to the Chrome client where the Verified Access extension signs it using a device-bound key, then submits the signed response to /v2/challenge:verify. The verify response indicates whether the signature came from an enrolled and policy-compliant device.
What are the rate limits for the Chrome Verified Access API?
Verified Access enforces standard Google Cloud per-project quotas with a default of 600 requests per minute per project across both challenge endpoints. Higher quotas can be requested in the Cloud Console for high-volume relying parties.
How do I integrate Chrome device trust through Jentic with the Verified Access API?
Install the Jentic SDK with pip install jentic, search for verify chrome device, load the schema for POST /v2/challenge:verify, then call it with the challengeResponse the Chrome extension returned. Pair this with /v2/challenge:generate at the start of the flow to obtain the challenge token.
Does the Chrome Verified Access API work outside Chrome and ChromeOS?
No. The signing step relies on the Verified Access extension running in Chrome on a managed device or on ChromeOS, so requests originating from other browsers cannot produce a valid challenge response. Use a different device-trust signal for non-Chrome clients.
What is the difference between v1 and v2 of the Verified Access API?
v2 unifies the user-facing and device-facing verification flows into a single challenge:verify endpoint and returns a richer verdict object including device enrollment state. New integrations should use v2; v1 is retained for backward compatibility with older Chrome extension versions.
GET STARTED