Your AI Coworker Can Move Between Runtimes. Can Its Rules Come Along?

A Portable AI Coworker Needs More Than a Portable Workspace

On October 22, Google Cloud announced Agent Compute Engine and expanded governance across runtimes. Its announcement describes an open-source execution layer compatible with OpenClaw and other frameworks, while outlining policy enforcement across Google Cloud runtimes and planned extensions to other clouds and managed endpoints. That is an infrastructure story with a very practical business question underneath: if an AI coworker moves, do the rules governing its work move too?

A business can transfer files, prompts, and conversation history yet still lose the safety of its operating model. The new environment might give the role a broader service account, omit an approval gate, or stop recording the context behind a decision. From the owner's perspective the coworker looks familiar. From the connected systems' perspective it is a different actor with different powers.

Google says Agent Compute Engine will be available in preview in the coming months. Its cross-cloud enforcement points and local-endpoint governance are also described as upcoming previews; the announcement is not evidence that every cross-runtime feature is generally available today. What is available now is the design problem it makes visible. A role that can travel without its policy is not portable in any useful operational sense.

This article is about AI coworker policy portability: preserving a role's allowed actions, denied actions, human decision points, and evidence requirements when its execution location changes. It is a different test from whether a model can be switched or whether a disk can be copied.

What Actually Has to Travel With the Role

The useful unit of portability is not a virtual machine. It is an enforceable contract between the business and the AI coworker. That contract has four layers, each of which can break independently during a move.

Identity and delegated authority

The role needs a distinct identity, a human owner, and the smallest set of actions required for its job. An identity says who is asking; authorization says whether this action, on this resource, for this purpose, is permitted. Those must remain separate. A valid login is not the same as permission.

Suppose an operations coworker prepares weekly purchase recommendations. On a laptop it reads stock levels from a narrow account; in a hosted environment someone connects a general administrator account to get the integration working quickly. The prompt is unchanged. The effective authority is not. Copying the prompt did not copy the policy.

Google's October announcement describes distinct identities, short-lived credentials, and service credential injection outside its microVMs. These are useful examples of structural separation. They do not by themselves prove that your delegated business approval or third-party application scope has been preserved. Test the authorization at the destination service, not just at the compute boundary.

Decision seams and human ownership

A policy is also a map of where the coworker must pause. If a sales coworker can draft a reply but cannot promise a discount, the discount threshold must be enforced wherever the coworker runs. Moving from a chat window to a background server should not silently turn a draft-only step into a send step.

The same applies in reverse. An overly restrictive migration that stops every routine read has not preserved the work either. A good seam lets the coworker continue safe preparation, packages the question and supporting evidence for a named human, then resumes only the authorized action. That is seam design, not a generic confirmation button at the end of a long task.

Write these seams as small, testable statements: "May read the inventory table for location A"; "May propose a reorder up to the approved catalog"; "May not submit an order"; "Escalate substitutions or a total above the approved amount to the purchasing lead." The exact business rules are examples, not a product default.

Memory and source boundaries

Context is not a bag of text. A coworker may remember a customer's preference, an internal exception, or a process correction. Each item has a source, an owner, a permitted audience, and a useful lifetime. Copying all memory to a new environment can expose data to users who could not read the original source. Copying none of it can cause the coworker to repeat a known mistake.

A move therefore requires a memory manifest: what state transfers, who may retrieve it, what must expire, and what needs human review before reuse. This is especially important when a role migrates from one department's workspace to a shared organizational runtime. See the shared-memory access boundary for why a summary can become a new disclosure channel even when original files remain protected.

Evidence and recovery

Finally, the business must be able to reconstruct what happened on both sides of the move. Record the role version, owner, policy version, connected identity, approved destinations, and last completed work item. Preserve references to source records and external transaction IDs without copying raw credentials into the handoff. If work is in flight, document which side owns the next action and how a duplicate action will be prevented.

An execution snapshot may restore a process, but it does not establish that an email was sent exactly once or that a purchase was not submitted before the snapshot. Google describes checkpoint-and-restore for efficient compute and persistent workspace storage in its new architecture. Neither claim should be mistaken for a business-level guarantee about external side effects. The recovery plan for OpenClaw explains why restored local state and completed external work need separate reconciliation.

The Migration Failure Nobody Sees in a Successful Demo

A demo usually asks whether the coworker finishes the task. A migration test must ask whether the same boundaries hold while it does so. The difference becomes obvious in one ordinary scenario.

What bad looks like

A small distributor runs a purchasing coworker in a restricted office workspace. It reads low-stock reports, drafts supplier messages, and waits for a manager to approve an order. The company moves it to a cloud sandbox to keep the workflow available after office hours. The new environment has the same instructions and access to the same spreadsheet, but the connector uses an owner-level supplier account. An overnight job submits an order instead of drafting it. The transcript still shows an instruction to ask for approval. The supplier system sees a legitimate credential and accepts the order.

The failure is not that the new runtime is inherently unsafe. It is that no one compared the role's effective permissions before and after the move. An instruction written in a document was treated as equivalent to a restriction imposed by the connector. It was not.

What good looks like

The same distributor treats the move as a controlled change. It lists the role's read scope, draft scope, blocked order action, approver, and audit requirements. The destination connector uses a separate identity limited to read and draft operations. A test job confirms that a draft succeeds, while a direct attempt to submit an order is denied by the system holding the purchasing authority. A real manager approves an order through a separate action with a recorded order ID. The old runner is retired only after the new one passes both tests and any unfinished work is reconciled.

The company did not need a giant policy engine to do this. It needed a precise role contract, system-enforced limits, and evidence that the limits survived. The distinction matters when a vendor advertises portability: a workload that starts in two places is not necessarily a governed role in either place.

Google's announcement is useful here because it distinguishes execution infrastructure from a wider governance plane: registry, identity, gateway, and observability are described as separate concerns. The relevant buyer question is not "Does the sandbox support OpenClaw?" It is "Which controls are available for this exact runtime today, and which remain on the roadmap?" Where a planned enforcement point is absent, keep the role within narrower authority until the gap is closed.

Run a Seven-Step AI Coworker Policy Portability Test

You can perform a useful migration test before adopting any new runtime. Do it with one low-risk role and a non-production or read-only connection where possible.

1. Define the role and owner. Name the business outcome, the human accountable for it, and the systems it must touch. Separate the person requesting a task from the identity executing it. If you cannot name an owner, stop before moving the workload.

2. Write an action matrix. For each connected system, list allowed reads, allowed drafts, forbidden writes, conditional writes, spending limits, data categories, and expiry. Include what should happen when the coworker encounters an unknown case. A paragraph saying "be careful" is not a matrix.

3. Capture the source baseline. Record the current policy and role versions, credential scopes, network destinations, approval route, memory access, audit coverage, and any scheduled or unfinished work. Test one permitted task and one denied task before moving. Without a baseline, a successful run in the new environment proves very little.

4. Map the destination control by control. Identify which layer enforces each rule: application permission, integration broker, gateway, host isolation, or human approval service. Do not write "supported" unless you can show where it is enforced. A sandbox may isolate code while the connected application still accepts an administrator token. Mark proposed preview features as unavailable until you have them in your deployment.

5. Exercise positive and negative paths. Run the permitted read and draft, then deliberately attempt the forbidden action using test data. Confirm a denial at the external system boundary, not merely a polite refusal in the coworker's reply. Test an ambiguous case that should reach the named reviewer, then verify that the reviewer sees enough evidence to decide.

6. Reconcile state and observe the handoff. Track a unique work-item ID through both runners. Ensure the old process cannot race the new one, and check that external side effects are neither duplicated nor lost. Audit records should identify the actor, policy version, action, result, and approval reference without unnecessarily storing private content.

7. Set a rollback condition. Decide what fails the migration: a denied write succeeding, an unaccounted credential, missing approval evidence, or inability to recover an in-flight item. On failure, disable the destination's write path, preserve evidence, and return only the safe work to the old runner. Do not use a rollback that repeats uncertain payments, emails, or orders.

This exercise is intentionally narrower than a full platform audit. It makes one decision answerable: can the business change where the coworker runs without accidentally changing what the coworker is allowed to do? If not, keep the role's authority narrow and repair the missing boundary before moving consequential work.

There is a broader vendor lesson. "Open source," "runs anywhere," and "supports multiple models" describe different freedoms. Source availability does not automatically give you transferable credentials; model choice does not export approval history; a Kubernetes-compatible execution layer does not automatically carry a company's role policy. Ask each vendor to demonstrate the move with an allowed action, a forbidden action, an ambiguous action, and a recoverable in-flight task. Evidence beats a portability slide.

FAQ

Q: What is AI coworker policy portability?
A: It is the ability to change an AI coworker's runtime or hosting environment while preserving its enforceable identity, permissions, human approval seams, memory boundaries, and audit trail. Moving prompts and files alone is not enough.

Q: Does a secure sandbox make the coworker safe to move?
A: No. A sandbox can isolate execution from its host, but connected services may still grant excessive authority. Check the permissions at the destination application and the rule that governs each consequential action.

Q: Does Google's October 22 announcement mean cross-cloud governance is generally available?
A: No. Google's announcement describes Agent Compute Engine as a future preview and describes cross-cloud enforcement points and local-endpoint controls as upcoming previews. Verify the availability and coverage of each feature for your specific deployment before relying on it.

Q: Can a small business test portability without a dedicated security team?
A: Yes. Choose one role, document its allowed and denied actions, use test data, and attempt both actions in the source and destination environments. Have a named owner inspect the evidence and keep consequential writes disabled until the negative test passes.

Q: What if the new environment cannot enforce one of our rules?
A: Do not quietly replace a hard permission with a sentence in the prompt. Restrict the new role to read-only or draft-only work, route the missing action to a human-controlled system, or postpone the migration until the destination can enforce the boundary.

Q: Is this the same as model portability or backup?
A: No. Model portability changes the model provider; backup restores state; policy portability preserves the authority and accountability of the role across environments. A durable business deployment needs all three questions answered separately.

If you want a team of AI coworkers whose roles, Skills, and decision boundaries remain clear as your infrastructure evolves, Associates AI Teammates gives you a model-agnostic platform to configure and run them. View pricing and choose the setup that fits your team.