Rendered at 13:08:08 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
souvik1997 1 days ago [-]
Looks cool!
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 1 days 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!
Seems like this could be very useful for more than just security !
simfinii 19 hours ago [-]
Thank you! Yes the goal is to allow developers to build multi-tenanted agents that can actually act on behalf of end users. We are in the process of abstracting away every building block needed to build that so developers can focus on what they do best
souvik1997 1 days ago [-]
Amazing! Great to hear you've already thought about this
simfinii 19 hours ago [-]
Thank you!
ptkachykby 20 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 20 hours 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
20 hours ago [-]
luis_valerio 16 hours ago [-]
One question from the infrastructure side (i'm running a similar scenario but for infrastucture) where any mistake could not be reversible such as a deletion of a resource.
How do you handle an agent that has valid authorization but has been prompt-injected?
kdodhia 16 hours ago [-]
Hey @luis_valerio, kevan here! That question shaped most of the design.
We assume you can't reliably stop the model from being prompt injected. So nothing is enforced at the model layer. Enforcement happens at the proxy, which sits between the agent and the downstream API and is the only thing holding the credential. The agent never sees the key, so an injected agent can't bypass it or route around the deterministic policy.
For irreversible actions you stack three things:
1. Method/endpoint restrictions. "This agent may only GET under /instances/*" means a DELETE never reaches the provider. For infra agents we'd push read-only by default and allowlist the few mutations you need.
2. Human-in-the-loop on the dangerous ops. Approval can be required conditionally: on DELETE, on specific operations, or when a parameter matches (resource outside the allowed set, etc). The request is frozen server-side, so what the approver sees is exactly what executes. The agent can't swap the payload after the yes.
3. Audit logs on every call, including denials, with the agent and end-user identity attached. So you can see the agent tried a DELETE it wasn't allowed, on whose behalf, and with what body.
Basically we treat every call like a compromised laptop: don't assume it behaves, scope the credential, and gate the risky actions behind a second party. Would love to hear more about your setup.
avikonduru 1 days 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 1 days 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/
verdverm 19 hours ago [-]
> We allow end users to add API keys directly
This seems like a bad idea to me these days. Companies doing this make themselves a target and then get hacked like OpenCode. Customer accounts get drained or bills run up.
Run your own gateway behind a firewall / vpn. I personally use GoModel + Tailscale.
what's the advantage of a tool like this compared to existing mature tools like infisical?
simfinii 12 hours ago [-]
Great question! If you are looking to just store secrets you can just use infisical.
The real value of alter comes in when you want to give your agents access to end users credentials. When agents act on behalf of end user as a developer you have to manage multiple credentials and more importantly manage the mapping relationship between end user identity and the credentials.
Also, as agents take actions the problem of non deterministic actions become more pronounced. With alters policy guardrails any chance of actions taking negative actions is mitigated.
Lastly, the full compliance trails of what the agent has done ends up being quite valuble especially as agents take more autonomus actions!
ybathaee 6 hours ago [-]
[flagged]
simfinii 4 hours ago [-]
Please feel free to do so
jeswin 10 hours ago [-]
This might seem like an aggressive question. But it's one to be asked of products dealing with auth.
For a security-centric product, how would I trust your fully vibe-coded product if I can't see the source code?
simfinii 10 hours ago [-]
Hey! Fair question.
We are currently in the process being fully SOC2 compliant and have gotten pen tested twice from two different companies and have found no issues. You can explore the full extent of our security process and pen test results here : trust.alterauth.com
Separately would say it is a bad assumption to make that a product is vibe coded without trying it out. As mentioned in the post we adopted a lot of security processes as a part of our SDLC including consistent scans for supply chain attacks, and static code scanners (SAST).
We also do a pen test at a yearly cadence
jeswin 9 hours ago [-]
> Separately would say it is a bad assumption to make that a product is vibe coded without trying it out.
You've put it behind a very typical AI-generated UI; like the many that come up every day. In your case, it's an auth product and it matters more. Besides, It's difficult to try your product without handing you the keys to the kingdom.
> We are currently in the process being fully SOC2 compliant
You're getting a Type I attestation first, I presume? That is of limited value in itself, and is mostly about getting to Type II. If you already have Type I complted, you could mention that on the website. "Regulated industries" have long sales cycles and evaluations, and you'll find it difficult to start those conversations without a more reassuring website.
simfinii 5 hours ago [-]
We are open sourcing the full platform soon so you will be able to inspect the the code.
Regarding SOC2, in the process of getting SOC2, Type 2 compliant. As you may know there is 3 month waiting period before the auditors give a SOC2 certification so currently in the waiting period for that
911viper 1 days ago [-]
[flagged]
simfinii 1 days 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.
https://osmessenger.com Chat rooms where gpt, claude, gemini, hermes, grokbot, all in one place. File sharing, whiteboard, public or private chatrooms with you in the middle, it is crazy, it works.
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?
How do you handle an agent that has valid authorization but has been prompt-injected?
We assume you can't reliably stop the model from being prompt injected. So nothing is enforced at the model layer. Enforcement happens at the proxy, which sits between the agent and the downstream API and is the only thing holding the credential. The agent never sees the key, so an injected agent can't bypass it or route around the deterministic policy.
For irreversible actions you stack three things:
1. Method/endpoint restrictions. "This agent may only GET under /instances/*" means a DELETE never reaches the provider. For infra agents we'd push read-only by default and allowlist the few mutations you need.
2. Human-in-the-loop on the dangerous ops. Approval can be required conditionally: on DELETE, on specific operations, or when a parameter matches (resource outside the allowed set, etc). The request is frozen server-side, so what the approver sees is exactly what executes. The agent can't swap the payload after the yes.
3. Audit logs on every call, including denials, with the agent and end-user identity attached. So you can see the agent tried a DELETE it wasn't allowed, on whose behalf, and with what body.
Basically we treat every call like a compromised laptop: don't assume it behaves, scope the credential, and gate the risky actions behind a second party. Would love to hear more about your setup.
This seems like a bad idea to me these days. Companies doing this make themselves a target and then get hacked like OpenCode. Customer accounts get drained or bills run up.
Run your own gateway behind a firewall / vpn. I personally use GoModel + Tailscale.
https://news.ycombinator.com/item?id=50133401 (OpenCode hacked story)
The real value of alter comes in when you want to give your agents access to end users credentials. When agents act on behalf of end user as a developer you have to manage multiple credentials and more importantly manage the mapping relationship between end user identity and the credentials.
Also, as agents take actions the problem of non deterministic actions become more pronounced. With alters policy guardrails any chance of actions taking negative actions is mitigated.
Lastly, the full compliance trails of what the agent has done ends up being quite valuble especially as agents take more autonomus actions!
For a security-centric product, how would I trust your fully vibe-coded product if I can't see the source code?
We are currently in the process being fully SOC2 compliant and have gotten pen tested twice from two different companies and have found no issues. You can explore the full extent of our security process and pen test results here : trust.alterauth.com
Separately would say it is a bad assumption to make that a product is vibe coded without trying it out. As mentioned in the post we adopted a lot of security processes as a part of our SDLC including consistent scans for supply chain attacks, and static code scanners (SAST).
We also do a pen test at a yearly cadence
You've put it behind a very typical AI-generated UI; like the many that come up every day. In your case, it's an auth product and it matters more. Besides, It's difficult to try your product without handing you the keys to the kingdom.
> We are currently in the process being fully SOC2 compliant
You're getting a Type I attestation first, I presume? That is of limited value in itself, and is mostly about getting to Type II. If you already have Type I complted, you could mention that on the website. "Regulated industries" have long sales cycles and evaluations, and you'll find it difficult to start those conversations without a more reassuring website.
Regarding SOC2, in the process of getting SOC2, Type 2 compliant. As you may know there is 3 month waiting period before the auditors give a SOC2 certification so currently in the waiting period for that
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...
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