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?
simfinii 10 hours ago [-]
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.
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!
simfinii 11 hours ago [-]
We actually account for this already! We allow developers to use alter to partition context memory based on end user + agent identity so the context leaks like the one you described can be fully prevented!
Amazing! Great to hear you've already thought about this
ptkachykby 1 hours ago [-]
You can add a tag to each memory indicating who wrote it, and then at read time filter the memories instead of putting them in the prompt.
I am the founder of Substrate, a project that lets you inspect what is in the memory and select what each agent sees.
Do you separate memory per user with your harness?
simfinii 47 minutes ago [-]
Yes we do. We separate based on both the end user identity and agent identity. Would love to see how your product could potentially work with alter
49 minutes ago [-]
mauvehed 45 minutes ago [-]
That website is literally a vibe-coded template.. How can we put any trust into the app itself?
simfinii 42 minutes ago [-]
We are in the process of getting SOC2 compliant. You can go through our trust page here: https://trust.alterauth.com/
We have also gotten pen tested 2 separate times and have found no issues. You can find the result of one of the pen tests on the trust center
avikonduru 10 hours ago [-]
How do you handle permissions when the downstream service only offers a shared API key? For example, two sales reps can use the same CRM endpoint but should only access their own accounts. Does Alter check record ownership, or does the developer still need to supply that logic?
simfinii 10 hours ago [-]
We allow end users to add API keys directly via the alter connect SDK. If the API key needs to be shared then developers can map it on their end using the grant ID abstraction that we provide. Feel free to go through the docs here: https://docs.alterauth.com/concepts/credentials/
911viper 7 hours ago [-]
[dead]
Rendered at 17:45:23 GMT+0000 (Coordinated Universal Time) with Vercel.
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...
I am the founder of Substrate, a project that lets you inspect what is in the memory and select what each agent sees.
Do you separate memory per user with your harness?
We have also gotten pen tested 2 separate times and have found no issues. You can find the result of one of the pen tests on the trust center