An AI Coworker With an Email Address Needs a Real Identity Lifecycle
Once an AI agent has its own email address, calendar, storage, and directory entry, it is no longer just a feature. It is a non-human identity operating inside the business.
That identity can receive messages, be added to workspaces, appear in document history, retain context, and interact with employees and outside parties. The capability is useful. It can also inherit permissions, relationships, and institutional trust in ways that are difficult to see if the organization manages it like a chatbot rather than an account.
Google Cloud’s new Gemini coworker agents make that distinction concrete. The practical lesson for operating businesses is straightforward: give every persistent AI agent an identity lifecycle with a named owner, approved purpose, limited authority, visible labeling, monitoring, renewal, suspension, and offboarding.
What changed
Documented fact: On October 8, Google Cloud announced a universal Gemini agent for work. Google says it can answer questions, perform knowledge work, create media, write and run code, schedule tasks, respond to events, use tools, and connect to business systems.
The identity change: Google says organizations can create persistent “coworker agents” with their own Workspace accounts, email addresses, calendars, Drive storage, and company-directory presence. The agents operate under their own names rather than a person’s identity. They can be added to Chat spaces, mentioned in documents, post work to a group, and appear in version history.
Independent reporting: Reuters reported on October 8 that the Gemini agent connects to business systems and returns work in documents, email, and developer environments. Reuters also reported that coworker agents can have their own email addresses and access only the information provided to them. Financial-services and legal versions are in preview, with government, healthcare, and retail versions planned.
Availability matters: The Verge reported that the universal agent is available to enterprise customers in private preview. That means the announcement describes a developing enterprise product, not a generally available operating standard every business can deploy today.
Vendor-described controls, not independent assurance: Google says each agent receives a cryptographically attested identity, least-privilege permissions, fine-grained authorization, agent-attributed audit logs, sandboxing, policy enforcement through an Agent Gateway, and real-time observability. Google also says the agent can route work across Gemini and Anthropic Claude models.
Those are important design commitments. The sources reviewed do not independently test their effectiveness, describe the administrative effort required, or establish how consistently third-party connectors propagate the agent identity and policy.
Still unresolved: The public materials do not fully explain account licensing, mailbox and calendar retention after deletion, external-email controls, recovery procedures, legal hold and eDiscovery behavior, delegated administration, directory labeling standards, alias reuse, or the offboarding sequence for persistent and temporary sub-agents. They also do not establish how permissions and data-handling terms change when work is routed among different underlying models.
An AI identity is not an employee—and should not borrow one
A named agent can make automation more accountable because its work can be separated from the person who requested it. That is better than having a shared automation act through an employee’s mailbox or a generic service account no one owns.
But the identity must remain unmistakably non-human. Customers, suppliers, employees, and auditors should be able to tell when they are interacting with an AI agent, who owns it, and how to reach a responsible person. The agent should not gain authority merely because its directory profile resembles a colleague’s.
The distinction affects business-system design. A human employee account carries assumptions about judgment, employment policy, supervision, and responsibility. An agent account should instead carry explicit machine-enforceable boundaries: which workflows it supports, which data it can see, which messages it may send, which actions require validation, and where a person must approve the result.
Build an identity record before creating the account
Every persistent agent should have a registry entry containing:
- Business owner: the leader accountable for the workflow and outcome.
- Technical owner: the person responsible for configuration, integrations, access, monitoring, and recovery.
- Approved purpose: the specific process, users, and result the agent is permitted to support.
- Identity type: persistent coworker, temporary sub-agent, workflow service identity, or user-delegated assistant.
- Systems and data: approved applications, repositories, mailboxes, calendars, files, records, connectors, and environments.
- Allowed actions: read, draft, recommend, create, update, send, publish, approve, or execute.
- Prohibited actions: explicit systems, fields, recipients, transactions, and decisions the agent must never touch.
- Validation and approvals: deterministic checks and named human gates required before consequential actions.
- Retention: how long mail, files, memory, logs, and generated records remain available.
- Review and expiration: the next access review, renewal criteria, and automatic suspension date.
This is the agent equivalent of a job description, access request, system inventory, and control plan. It should exist before the email address does.
Controls for an AI mailbox and directory presence
1. Make the identity visibly non-human
Use a naming convention such as “Agent — Order Exception Coordinator” rather than a realistic person’s name. Label the directory profile, email signature, chat presence, and external messages as AI-assisted or AI-operated. Include the owning team and a monitored human escalation route.
Do not allow the account to imply a title, credential, certification, or decision authority it does not possess.
2. Control who can contact it
Begin with approved internal groups. Add external senders only when the workflow requires them. Use domain allowlists, message-size limits, attachment controls, malware scanning, and quarantine rules. Treat inbound email, calendar invitations, document comments, and chat messages as untrusted instructions.
An external sender should not be able to change the agent’s purpose, approve a payment, disclose another customer’s information, or invite the agent into a new system simply by asking.
3. Separate reading, drafting, and sending
Reading a message is not the same as replying. Drafting a response is not the same as sending it. Sending an internal status update is not the same as making a contractual promise to a customer or supplier.
Set permissions at those boundaries. High-impact messages—pricing commitments, product substitutions, delivery promises, employment communications, legal statements, payment instructions, and public claims—should pass through human approval controls.
4. Validate business facts outside the model
Before the agent communicates or acts, validate order status, inventory, prices, credit limits, customer identity, shipment dates, approval thresholds, product compatibility, certifications, and account standing against authoritative systems.
A model’s confidence or fluent explanation is not proof. Deterministic validation should fail closed when required data is missing, stale, contradictory, or outside tolerance.
5. Apply least privilege to shared spaces
If the agent can be added to a chat, Drive folder, project, calendar, customer account, or repository, define who may add it and what happens when membership changes. Do not rely on every employee to understand the downstream access created by one share action.
Use approved workspace templates, restricted sharing groups, sensitive-content labels, and policy checks. Review inherited permissions and links, not only permissions assigned directly to the account.
6. Keep the requester separate from the approver
A person who asks the agent to perform work should not automatically approve the result. Separate initiation, validation, approval, and execution where the workflow affects money, customers, safety, regulated data, production systems, or public communications.
This preserves accountability without making every low-risk task slow. Routine drafts and summaries can flow quickly; consequential commitments receive a visible gate.
7. Attribute every action to the agent and the human context
Log the agent identity, requesting person or trigger, model, instructions, data sources, tools, recipients, affected records, validation results, approvals, final action, and outcome. If the agent delegates to sub-agents, preserve that chain.
Agent-only attribution is not enough. The business must also know who created the agent, who changed its configuration, who invoked it, and who approved the action.
8. Monitor the relationship graph
An agent can accumulate access as people add it to groups, folders, calendars, projects, and customer threads. Monitor new memberships, external recipients, forwarding, shared links, mailbox rules, tool registrations, OAuth grants, bulk exports, after-hours activity, and changes to its owner or policy.
Assign an operations owner for workflow exceptions and a security owner for identity anomalies. Alerts without named response ownership are only noise.
Offboarding is part of deployment
A persistent AI identity can retain email, files, calendar entries, memory, credentials, relationships, and work in progress. Turning off the model does not necessarily remove those artifacts or stop connected automations.
The offboarding workflow should:
- stop new tasks and inbound triggers;
- revoke tokens, keys, connectors, delegated access, and active sessions;
- remove the agent from groups, shared drives, calendars, projects, and external systems;
- quarantine or reassign unfinished work to a named person;
- preserve records required for audit, customers, contracts, legal hold, or incident investigation;
- disable external sending and forwarding;
- archive or delete memory according to policy;
- notify affected teams and external partners when necessary; and
- verify that no temporary sub-agent or derivative credential remains active.
Test that sequence before production. A reliable AI incident-response plan needs an immediate suspension path as well as an orderly retirement path.
Practical examples
eCommerce: A returns agent can own a clearly labeled mailbox, collect photos, verify order records, and draft a resolution. Refunds above a threshold, warranty exceptions, replacement substitutions, and suspected fraud route to people.
Industrial distribution: A sourcing agent can receive supplier availability updates and prepare comparisons. It cannot change an approved vendor, accept contract terms, or place a purchase order without rule checks and accountable approval.
Manufacturing: A maintenance coordinator agent can gather work-order history, schedule a technician, and assemble the diagnostic record. It cannot release equipment, change a safety procedure, or close regulated maintenance work.
Marketing: An events agent can maintain a calendar, draft briefs, and coordinate internal participants. It cannot grant usage rights, approve claims, send mass external email, or publish without the established review process.
Review the provider—and the operating design
A vendor and model risk review should examine identity attestation, access propagation, logs, retention, legal hold, directory behavior, external communication controls, connector policy, model routing, data processing, regional storage, administrator roles, suspension, export, and contract exit.
The provider’s controls are only one layer. The operating business still decides why the agent exists, which account it receives, which people can invoke it, which records it can affect, who approves consequential work, and who answers when something goes wrong.
The management question
Before giving an AI coworker an email address, ask: Can we identify its owner, purpose, permissions, correspondents, data, approvals, actions, records, expiration, and complete offboarding path?
If the answer is yes, a dedicated identity can make AI work more visible and accountable. If the answer is no, the business is creating a new colleague-shaped access path without a manager.
