OpenClaw makes it easy to build personal AI agents that connect to your applications, retrieve information, and take actions on your behalf.
But what happens when you want to deploy the same agent across an entire organization?
Imagine an OpenClaw agent in your company’s Slack workspace. Alice asks it to find a document in her Google Drive. Bob asks it to create a GitHub issue. Carol asks it to schedule a meeting using her calendar.
All three requests go through the same agent, but each should execute with a different user’s permissions.
The agent needs to know who is making the request, which accounts that person has connected, what they’re authorized to do, and what additional restrictions apply to the agent itself.
This is fundamentally a delegated authorization problem.
We’ve built and open-sourced an OpenClaw plugin for Alter that makes these controls available to shared agents. Here is a walkthrough of what that looks like in action if you are interested.
It allows multiple users to interact with the same OpenClaw deployment while keeping their identities, connected accounts, permissions, memory, and audit records separate.
The problem with shared agents
Most personal agents start with a simple credential model. A user connects their applications, and the agent uses those connections to perform tasks.
That works reasonably well when the agent serves one person.
It becomes more complicated when the same agent serves an entire team.
A shared service account could give the agent access to company systems, but it doesn’t represent the authority of the person making each request. Everyone effectively uses the same set of permissions, regardless of what they’re individually allowed to access.
This creates several problems.
First, access is no longer tied to the requesting user. An agent may have access to information the user should never see.
Second, provider credentials become shared infrastructure. Revoking one employee’s access may require changing credentials used by everyone else.
Third, actions become difficult to attribute. An audit log might show that the agent sent an email, but not which employee authorized it.
There is also a separate problem with memory and context. An agent serving multiple users needs to avoid mixing their private information.
The underlying issue is that an agent has its own identity, but it also acts on behalf of users with different permissions.
Authorization needs to account for both.
How Alter makes OpenClaw multi-user
The Alter plugin connects OpenClaw to Alter’s identity, credential management, and authorization infrastructure.
Instead of giving the agent shared access to enterprise applications, each user signs in and connects their own accounts.
Consider Alice and Bob using the same OpenClaw agent in Slack.
Alice signs in through her organization’s identity provider and connects her Gmail and Google Calendar. Bob signs in separately and connects his GitHub account.
When Alice asks the agent to search her email, the plugin identifies Alice as the requester and uses her delegated Gmail connection.
When Bob asks the same agent to create a GitHub issue, it uses Bob’s GitHub connection instead.
Neither user can access the other’s connections simply because they’re interacting with the same agent.
The plugin handles this through Alter’s authorization flow:
Identify the user. The plugin resolves the requester’s chat identity to a verified Alter user. Authentication is handled through the organization’s configured identity provider.
Resolve delegated access. The plugin finds the connected account and grant belonging to that user.
Evaluate authorization. The API request passes through Alter, where applicable permissions and runtime policies are enforced.
Execute the request. Alter uses the credential stored in its vault to call the provider. The underlying OAuth token is never returned to OpenClaw.
Record the action. The request is associated with the user and agent, providing an audit trail of what happened.
This allows one agent to serve multiple people without every developer having to implement identity mapping, OAuth credential management, delegated permissions, and auditing independently.
Runtime policies for actions agents take
Delegated access answers whose permissions an agent is using. It doesn’t completely answer what the agent should be allowed to do with those permissions.
A user might have access to send emails, modify documents, or create GitHub issues. That doesn’t necessarily mean their AI agent should have unrestricted authority to perform those actions.
With Alter, administrators and end users can define policies that narrow the agent’s access.
For example, an organization could allow an agent to read Gmail while restricting outbound messages to approved domains. It could require human approval before sending an email or modifying a connected system.
These policies are evaluated at the API layer, outside the agent’s model.
This separation matters because agents make decisions dynamically. They can encounter instructions in emails, documents, repositories, and other untrusted material that influence what actions they attempt.
A system prompt telling an agent not to perform an unauthorized action is not an enforcement boundary.
An authorization layer that rejects the corresponding API request is.
Contextual risk assessment with Jev
Some actions are difficult to evaluate using deterministic rules alone.
A request may be permitted by the user’s existing permissions but still be unusual or sensitive in context.
Alter also supports Jev, an AI-powered runtime risk review capability, through its policy engine.
For supported, classified non-read API operations, Jev can assess contextual risk and require human approval when a configured threshold is met.
For example, an organization might use Jev to assess whether a financial operation appears unusually large for the account or whether a requested destructive action warrants additional review.
Jev operates alongside deterministic access policies. It cannot override an explicit denial or expand the authority granted to the agent.
Because supported OpenClaw tool requests are routed through Alter, configured Jev policies can participate in their authorization decisions without embedding a separate risk-review system in the agent itself.
This provides a way to combine traditional access control with contextual evaluation while keeping enforcement outside the model.
Giving users control through Alter Wallet
When an agent takes actions on behalf of a user, that user should be able to inspect and manage its access.
Alter Wallet provides that interface.
Each user can see their connected accounts, revoke access, inspect their activity history, manage personal restrictions, and approve actions requiring human authorization.
For example, if Alice asks OpenClaw to send an email, an appropriately configured approval policy can hold the request until Alice approves it in her Wallet.
Bob cannot approve Alice’s action simply because he is interacting with the same agent.
Administrators can also enforce organization-wide policies independently of the restrictions set by individual users.
This makes delegated access a relationship users and administrators can manage, rather than an implicit capability hidden inside an agent’s configuration.
Keeping memory separate across users
Application permissions are only one part of multi-user isolation.
A shared agent may also store preferences, past interactions, and other information to help with future tasks.
The plugin provides identity-scoped memory tools that associate stored memories with each verified user.
This makes it possible for the agent to remember information independently for Alice and Bob without using a single shared memory store for both.
There is an important distinction between stored memory isolation and conversation isolation.
If Alice asks a question in a public Slack channel, the agent’s response is still visible to everyone in that channel. The model also shares the conversation context for that channel.
Private interactions should therefore use separately scoped direct-message sessions in OpenClaw. The plugin provides per-user memory tools, while the deployment must be configured to isolate private conversations appropriately.
Both boundaries matter when building agents intended for multiple users.
Getting started
The Alter OpenClaw plugin is available on GitHub under the MIT license.
It includes tools for Gmail, Google Calendar, Google Drive, Slack, GitHub, Linear, Notion, and other supported integrations.
You can install it into an existing OpenClaw deployment:
openclaw plugins install @alter-ai/openclaw-pluginFrom there, configure your Alter application, identity provider, OAuth integrations, and runtime policies.
The repository includes an operator setup guide and a reference deployment for running shared agents through Slack or Discord.
The plugin is currently an early 0.x release. Before connecting production data, review its documented security limitations, configure server-side approval requirements for write-capable grants, and verify user-session isolation. In particular, the server-side policy must enforce approval before execution; the plugin’s current post-execution check is not a substitute for that control.
Building agents for an entire organization
As AI agents become more useful, they’ll increasingly need to operate across the applications and workflows that employees already use.
But an agent deployed across an organization cannot simply be given unrestricted access to every connected system.
It needs to act with the authority of the user making each request, enforce policies on the actions it takes, protect credentials, and maintain accountability.
That’s the infrastructure we’re building at Alter.
The OpenClaw plugin is an open-source example of how these capabilities can be integrated into an existing agent framework, without requiring developers to rebuild the underlying identity and authorization systems themselves.
One agent can serve an entire team, while every user retains their own permissions, connected accounts, and control over what the agent does on their behalf.
If you’re building shared agents for an organization, we’d love for you to try it.
Explore the open-source OpenClaw plugin, check it out in action or sign up for Alter, and browse our documentation and examples.
We’re also personally helping teams integrate Alter into their agents. If you’re interested, book time with us here.