On October 22, 2026, Google announced general availability of Anthropic-managed Claude on Google Cloud. Teams can use Google IAM and billing to reach Anthropic's platform, including Managed Agents, which remains in beta. Before adopting it, check what happens to an agent when you remove the identity that started it.
Anthropic explicitly documents that existing sessions and scheduled deployments survive the creator's Google Cloud access revocation. Access is checked at creation. An offboarding ticket therefore needs evidence about the resources that identity left behind.
The procedure below is based on documentation. General Analysis has not tested a live deployment for this article.
Identify the service before approving access#
The new route uses claude.googleapis.com and the AnthropicGoogleCloud client. The Google-managed offering uses the Agent Platform endpoints and AnthropicVertex. Both accept Google credentials, but their IAM grants are separate. Calls to api.anthropic.com use neither route. Service identification reference.
Record the endpoint, Google project, Anthropic organization, workspace, and calling identity in the application inventory. Use those records to find the resources affected by an access change.
Google's setup documentation describes a new Anthropic organization. Existing organization settings and ZDR arrangements do not carry over. Google and Anthropic process their respective parts of the service independently; storage and inference may route outside Google Cloud. Recheck any approval that depended on Google being the sole processor or on an existing regional deployment.
For onboarding, complete the Marketplace subscription and activation, enable claude.googleapis.com and anthropic-managed-claude.cloudpartnerservices.goog, and record the resulting organization and workspace IDs. Use the vendor setup procedure. Keep the responder's access separate from the identity being removed so cleanup remains possible.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Review what each role can reach#
The IAM reference makes two consequential distinctions:
roles/claude.viewercan read file contents, batch results, and full session event histories. Treat this as access to workload data.roles/claude.userincludes workspace writes and agent operations, including session updates and deployment runs. It is broader than permission to send one model request.
roles/claude.admin adds organization permissions. Among those predefined roles, it alone opens the Claude Console. Roles granted on a project cover all its workspaces; Anthropic directs teams needing separate access to use separate Google Cloud projects.
Before approval, have the workload owner name the data each identity needs and the operations it can perform. Store that decision beside the identity-to-resource inventory. Our agent security baseline covers the surrounding tool and credential controls.
Capture evidence before the offboarding exercise#
Enable Data Access logging for claude.googleapis.com before the pilot. Most request routes use that log type, which starts disabled. Admin Activity logging covers a different set of routes. Consult the route-level audit mapping when choosing representative requests.
Google's logging configuration guide also describes inherited configuration, exempted principals, and permissions needed to read Data Access logs. Check those conditions before interpreting an empty result as no activity.
In Logs Explorer, select the intended project and use a bounded time window. This illustrative filter finds entries for the service; replace the example timestamps with your exercise window.
Code source: illustrative; syntax follows Google's Logging query language.
protoPayload.serviceName="claude.googleapis.com"
timestamp >= "2026-10-26T10:00:00Z"
timestamp < "2026-10-26T11:00:00Z"
Start without an identity filter so a missing attribution field does not hide the entire record. Inspect the returned identity, method, resource, and status fields before narrowing the query. Reconcile known application requests with received entries and preserve unresolved matches. The filter is a discovery aid, not proof that every agent action was logged.
Keep application resource IDs and session events alongside these records. The Compliance API guide explains why retained platform evidence, runtime telemetry, and destination-system records answer different questions.
Require evidence for each part of revocation#
Use the following acceptance matrix as an engineering recommendation. Record observed results separately from these expected conditions.
| Scope | Action to verify | Evidence required before closing |
|---|---|---|
| New API requests | Remove the departing identity's effective access. | A controlled request with that identity is denied; other grants have been reviewed. |
| Scheduled work | Pause or retire each affected deployment. | Saved deployment state and reconciliation of runs created around the change. |
| Existing sessions | Interrupt and inspect each affected session. | Processed interruption, current session state, and accounted-for pending calls. |
| Dynamic workflow runs | Stop unresolved runs and verify their outcomes. | Every recorded run has an ending event; unexplained runs remain open in the incident record. |
| Downstream effects | Revoke or restrict the relevant business-system authority. | Destination records settle whether pending writes occurred and whether further writes remain possible. |
The service's creation-time access rule is why the first row cannot close the others. The lifecycle details below determine what the remaining evidence must show.
Stop schedules and resolve active work#
Consider a hypothetical service account that created a nightly review deployment and an active session. Remove its effective API access, but retain a separate authorized responder to inspect and stop those resources. Also stop the application's dispatch path from creating replacement work under another identity.
Pausing a deployment suppresses future scheduled triggers. It leaves existing sessions running and still permits manual runs. Archiving ends the schedule permanently. Choose the lifecycle action deliberately, and review who can still invoke the manual run endpoint. Deployment lifecycle documentation.
For an active session, send user.interrupt on its own when the intention is to stop. The response means the event was queued. Wait for it to be processed and inspect the resulting state; an in-progress tool can delay interruption. Sending a new task with the interrupt would direct more work. Interrupt semantics.
Dynamic workflows need another check. An interrupt ends no workflow run, and runs may pause or continue. Resolve waiting tool calls, then follow the documented stop procedure and retain each workflow_run.status_ended. A budget cap can prevent the stop message; raising it can resume work. Keep downstream authority restricted while resolving that case. Workflow interruption reference. Our workflow recovery guide covers the detailed cleanup sequence.
Preserve the event history before destructive cleanup. A denied API call, paused schedule, or accepted interrupt cannot establish whether a write already reached a connected service. For an uncertain operation, use its destination record to determine the outcome before retrying or recording containment as complete.
Give the offboarding owner the resource inventory and observed results. If a run or downstream operation remains unresolved, leave that item open with a named responder.
