Gemini Agents Enter the SCIM Directory: How to Configure Non-Human Users

Google's Gemini is appearing in Workspace with a new identity — no longer just a simple chat assistant, but a "coworker agent" with its own account and its own directory entry. This means that your SCIM sync pipeline will soon contain a batch of "users" that aren't people.

Non-Human Users Quietly Enter the Enterprise Directory

In the past, when we talked about AI assistants, we assumed they were just a feature module within some application. But Gemini coworker agents are positioned very differently: they are given a formal Workspace account and occupy an entry in the enterprise directory. From the perspective of the identity system, there's no essential difference between it and a newly onboarded employee — it has an account, an identifier, and needs to be assigned permissions.

This change seems minor, but its impact is profound. SCIM (System for Cross-domain Identity Management) was originally a provisioning protocol designed for human employees, yet now it has to carry an entirely new class of subjects. Your directory sync code needs to answer a question it was never designed to answer: when the "user" isn't a person, how should the provisioning logic work?

SCIM (System for Cross-domain Identity Management) is an open protocol standardized by the IETF for automating the synchronization of user identities and group information between different systems. Its most typical use case is: when an enterprise uses an identity provider (IdP) such as Okta or Azure AD as the authoritative identity source, SCIM automatically pushes operations like creating, updating, and disabling employee accounts to downstream applications such as Slack, Zoom, and Salesforce, avoiding manual account maintenance. SCIM defines standard User and Group resource models, along with REST-style endpoints (such as /Users and /Groups), supporting CRUD operations. Because it is oriented toward subjects like enterprise employees, its resource model and lifecycle assumptions (onboarding, transfer, offboarding) are by default bound to human accounts. When an agent appears as a directory entry, the SCIM protocol itself won't throw an error, but the semantic assumptions on the provisioning side begin to fail — and that is precisely the root of the problem discussed in this article.

How Agents Flow Into Your Applications

Gemini agents entering your applications still go through the standard directory sync channel. Workspace pushes the agent as a directory entry to your SCIM endpoint, and your application receives it just like an ordinary user — unless you've actively made a distinction.

The key lies in identification. Agent entries usually carry specific markers or attributes to indicate that they are not human accounts. If your provisioning code is completely unaware of this, it will treat them as ordinary employees: creating profiles, assigning default permissions, and including them in offboarding processes. Conversely, if you can correctly identify them, you can design a separate lifecycle management process for them.

According to Google's description, the agent has its own Workspace account and directory entry — this is the precondition for it to be synchronized via SCIM. In other words, this path is officially supported, not some kind of workaround.

In the AI context, an "agent" usually refers to a software entity capable of perceiving its environment, autonomously planning, and calling tools to execute multi-step tasks to achieve a goal, unlike traditional passive chatbots. The reason Gemini coworker agents are called "coworkers" is that they are designed to independently perform actions on behalf of a user or team within Workspace applications (such as Docs, Gmail, and Drive), for example organizing documents, drafting emails, and retrieving information across applications. To make these operations traceable within Workspace's permission and audit systems, Google assigns them formal accounts — equivalent to giving the agent a "corporate badge." This also explains why it enters the SCIM sync flow: only with an account can it be assigned access permissions, appear in shared objects, and leave auditable operation records. Understanding this point is crucial: the agent is not an anonymous invocation hidden behind some API key, but a first-class citizen in the identity system.

Several Decisions Your Provisioning Code Needs to Make for Agents

When an agent appears in the SCIM feed, your provisioning logic needs to make a series of explicit choices rather than letting default behavior decide for you.

Identity modeling: What kind of subject should the agent be created as in your system? Should it be treated as a special user, a service account, or an independent entity category? This determines the direction of all subsequent permission and audit logic.

Permission boundaries: What the agent can and cannot access needs to be explicitly declared. Applying the default permissions of human employees to agents may bring unexpected exposure surface.

Lifecycle: When should the agent be created, and when should it be disabled? It won't proactively resign like an employee, so disabling often needs to be triggered by policy rather than driven by events.

Audit attribution: Under whose name should the agent's operations be recorded? If mixed together with human users, retrospective tracing becomes difficult.

There are no universal answers to these questions, but each one is worth thinking through before integration.

There is a common pitfall in automated account provisioning: default behavior is often the most dangerous. Many SCIM implementations use a fallback logic of "unknown user = ordinary employee," automatically creating local profiles, adding to default groups, and granting generic permissions. For agents, this means they may quietly gain the same access scope as real employees in your system. A more prudent approach is to make explicit branches based on attributes in the SCIM entry (such as userType, externalId, or custom extensions): once identified as an agent, follow a separate account creation and authorization process. In addition, the disabling step also needs to be redesigned — human employee disabling is triggered by HR offboarding events, whereas agents have no natural "offboarding" event and must rely on a policy engine, expiration time, or usage monitoring to actively reclaim them; otherwise, a large number of "zombie agent" accounts will accumulate.

Why This Is Worth Planning for in Advance

Cramming agents into an identity system designed for humans looks like the easiest thing to do in the short term, but it may accumulate technical debt in the long term. The directory becomes increasingly mixed, permission audits become harder to explain, and as the number of agents grows, this chaos is amplified.

The more pragmatic approach is to establish the rules while there are still few agents: distinguish them by attributes, manage them by policy, and record them through a separate audit channel. That way, when Gemini agents truly enter enterprise applications at scale, your provisioning pipeline won't become the bottleneck.

One-line Summary

Gemini agents enter the Workspace directory with formal accounts, forcing SCIM provisioning logic to distinguish between humans and non-humans.

Paragraph Summary

Google positions Gemini coworker agents as "coworkers" with their own Workspace accounts and directory entries, enabling them to be synced like employees via the SCIM protocol into various enterprise applications. The article points out that this change brings a fundamental challenge in identity management: if provisioning logic designed for humans does not make distinctions, it will mistakenly treat agents as ordinary employees, leading to permission leakage, audit chaos, and directory clutter. To address this, provisioning code must make explicit decisions on four questions: what kind of subject the agent should be modeled as, where its permission boundaries lie, what triggers its lifecycle, and who owns its operation records. The author recommends establishing the rules while the number of agents is still small — distinguishing by attributes, managing by policy, and recording through a separate audit channel — to avoid technical debt being amplified with scale.