Persistent and runtime agents need different identity controls

Choose the identity object before granting authority

A persistent coworker is an organizational actor. Its durable account can receive messages, own or create calendar events and files, appear in a directory, accumulate sharing relationships, and continue across sessions. The CIO should require a sponsor, business role, account type, legal and policy basis, approved data domains, mailbox and Drive custody, naming convention, authentication method, permitted collaboration spaces, external-sharing rule, and joiner, mover, suspension, and leaver events. The account should not inherit a human employee template without deciding who owns assets and unfinished work when the role, sponsor, team, or vendor changes. ^[1]

A runtime session is an execution boundary. Its control record should name the invoking principal, workload, runtime and platform version, session identifier, tool credentials, delegated scopes, network boundary, secret source, state and memory locations, snapshot or image, timeout, concurrency, logs, and termination event. Scale to zero ends compute consumption; it does not by itself revoke a token, delete retained state, transfer a created asset, or close a downstream session. The identity design must show which durable person or service authorizes the session and where that authority is narrowed for the work. ^[2]

Keep shipped controls separate from identity roadmap

AWS’s September 18 article describes current runtime isolation, usage-based execution, memory reclamation, and snapshot-based starts. It places session-context keys that would give unattended agents scoped identity in a section headed “What’s next (coming soon).” Treat that delivery label as an architecture constraint. Until the needed scoped-identity capability is available, entitled, documented, configured, and tested, bind unattended execution to an existing approved principal and narrower tool credentials or hold the use below the consequence threshold. A roadmap sentence cannot authorize production access. ^[2]

Google’s article describes current product direction and capabilities for a persistent coworker, but it likewise does not prove a buyer’s tenant has enabled them or that asset custody works as intended. Record announced, documented, entitled, configured, tested, and observed as separate states for both designs. A cross-cloud diagram that labels both as “agent identity” hides the operational difference the lifecycle process must manage. ^{[1] [2]}

Test the handoff between account and session

When a persistent coworker launches code, invokes an external runtime, or delegates to a temporary sub-agent, create a chain-of-authority receipt. Retain the durable actor, human or business sponsor, approved objective, session, selected tools, credentials and scopes, data shared, resources created, actions taken, exceptions, and termination result. Test a role change, sponsor departure, revoked share, expired secret, session retry, snapshot update, long-running job, tool denial, downstream asset creation, and emergency stop. Verify the action is attributed to the correct nonhuman actor without borrowing a person’s identity. ^{[1] [2]}

Offboarding must close both sides. Suspend new work; revoke directory, OAuth, tool, network, and secret access; settle or cancel running sessions; inventory mailbox, calendar, Drive, code, logs, and external assets; transfer or dispose of them under named custody; preserve required records; and read back that no approved execution path remains. A disabled Workspace account with live runtime credentials is incomplete. A terminated runtime with an active mailbox and shared files is also incomplete. ^{[1] [2]}

Approve architecture from lifecycle evidence

Use a persistent coworker when the business needs a durable, discoverable role and is prepared to own its communications and assets. Use a runtime identity when authority should be narrow, workload-bound, short-lived, and reconstructed from session evidence. Some designs need both, but the relationship should be explicit: which actor requests, which principal executes, which object owns the result, and which event revokes each layer. Measure orphaned assets, overbroad grants, unattributed actions, failed revocations, stale sessions, transfer time, and exceptions by identity type. ^{[1] [2]}

This comparison extends the existing Workspace custody briefing into an architecture decision between durable SaaS identity and runtime execution. It does not establish that either provider implements a buyer’s required identity assurance, credential isolation, retention, or exit controls. Current product documentation, tenant and cloud configuration, IAM records, logs, representative tests, provider commitments, and qualified architecture, security, privacy, records, HR, procurement, and legal review control. ^{[1] [2]}

Turn this source into a reviewable decision

For AI for CIOs, use this briefing as a dated decision record rather than a substitute for the source. Preserve Google Cloud, the exact URL, the October 19, 2026 review date, the supported facts above, the editorial interpretation, the limitations, and any buyer-specific evidence. Link that record to the decisions most directly affected: Enterprise AI platform architecture; Identity and agent access; Operations and incident intelligence; AI portfolio economics. State whether the source changes the scope, evidence requirement, control, sequence, or only the language used to describe the decision.

Before action, name the accountable owner, affected population and workflow, exact offering or configuration, source data and rights, human decision point, exception and appeal path, complete cost, expected benefit, failure and stop conditions, retained evidence, and next review date. Keep official facts, provider statements, buyer observations, representative tests, measured outcomes, editorial inferences, and unknowns visibly separate. Reopen the record when the source, offer, model, integration, data, policy, population, responsible person, or measured result changes.

Limitations and unknowns

Google and AWS are provider sources. Google’s October 8 announcement states features and product direction for persistent coworker agents; it does not prove entitlement, tenant configuration, identity assurance, data custody, or offboarding results. AWS’s September 18 article establishes stated current runtime behavior and expressly labels scoped identity for unattended agents and greater suspend/resume control as coming soon; those roadmap items must not be represented as shipped. Current documentation, contracts, tenant and cloud configuration, IAM and directory records, session and tool logs, representative lifecycle tests, and qualified technology, security, privacy, records, HR, procurement, and legal review control.