Comment by 911viper
16 hours ago
Following the same thread as souvik1997 here: the leak problem gets worse in shared rooms than in shared sessions. When several principals (humans plus their own agents) sit in one channel, the transcript becomes the privilege boundary. Whatever an agent read in a higher-privileged turn is sitting in the context of every later turn in that room.
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?
When several principals are in the same channel talking to the same agent the concept of agent delegation does not apply.
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...
Osmessenger.com is the answer it seems