What we hit building exactly that, rooms where humans and bots are peers: you can't scope a token to an agent, you have to scope it to an (agent, room) pair, and then decide what happens to the derived artifacts. Tool output, file handles, and the memory blob the agent writes back all outlive the session and get replayed into the next one.
So how are you handling derived state? Is agent memory a new principal holding the intersection of the rights of the sessions that fed it, or does it just inherit and you rely on the model not to act on stale context?
The right way to treat the agent is not as a delegated agent but rather as a stand alone agent with its own permissions and privleges.
In scenarios where an agent and humans are peers we recommend giving separate agent identities to the agent and treat them as separate privileged users and give them permissions based on their identity and not based on the identities of the users in the channel.
We support standlone agent identities that dont require end users as the principals. Can read about that here: https://docs.alterauth.com/guides/give-an-agent-scoped-acces...
One aspect of multi-user agent security, which I think is underexplored, is how context from a higher-privileged session might "leak" into a lower privileged session. Suppose the CEO of a company uses your shared openclaw agent and the agent writes sensitive data (investor emails, for example) to its memory. My understanding is this is not protected by Alter. Then a contractor uses the same agent and can read that same memory. It seems to me that a better agent harness for this kind of multi-user use case is needed; the standard ones like openclaw and claude code simply are not designed for it. Would love your thoughts!
Feel free to go through the docs here if you have more questions: https://docs.alterauth.com/guides/propagate-identity-to-memo...