Alter gibt KI-Agenten eigene Schlüssel statt deiner
Launch HN: Alter (YC S25) – Access control for multi-user agents
Alter (YC S25) setzt eine Autorisierungsschicht zwischen KI-Agenten und APIs: Jeder Agent erhält eine eigene Identität und eng begrenzte Grants statt eines geteilten, überprivilegierten Schlüssels. Die Plattform prüft Identität, Scope und Rate-Limits, protokolliert jeden Aufruf und erzwingt Default-Deny-Policies bis auf Parameter-Ebene. Ein SDK-Aufruf übernimmt Speicherung, Refresh, Policy und Audit für 140 Anbieter, mit Integrationen für LangChain, MCP und AWS. SOC 2 ist in Arbeit.
Ohne Alter liegt derselbe Admin-Schlüssel für die Produktion bei allen 14 Agenten, und niemand kann sagen, welcher Agent was im Namen welches Nutzers getan hat.
- mauvehed
Diese Website ist buchstäblich ein vibe-codiertes Template.. Wie können wir der App selbst irgendein Vertrauen entgegenbringen?
- 911viper
Dem gleichen Gedankengang wie souvik1997 hier folgend: Das Leak-Problem wird in gemeinsam genutzten Räumen schlimmer als in gemeinsam genutzten Sitzungen. Wenn mehrere Principals (Menschen plus ihre eigenen Agenten) in einem Kanal sitzen, wird das Transkript zur Privilegiengrenze. Was auch immer ein Agent in einem Zug mit höheren Privilegien gelesen hat, sitzt im Kontext jedes späteren Zugs in diesem Raum.
Was uns beim Bau genau dessen begegnet ist, in Räumen, in denen Menschen und Bots Peers sind: Man kann ein Token nicht auf einen Agenten beschränken, man muss es auf ein (Agent, Raum)-Paar beschränken und dann entscheiden, was mit den abgeleiteten Artefakten passiert. Tool-Output, File-Handles und der Memory-Blob, den der Agent zurückschreibt, überleben alle die Sitzung und werden in die nächste hineingespielt.
Wie geht ihr also mit abgeleitetem Zustand um? Ist Agenten-Memory ein neuer Principal, der die Schnittmenge der Rechte der Sitzungen hält, die ihn gespeist haben, oder erbt er einfach und ihr verlasst euch darauf, dass das Modell nicht auf veralteten Kontext reagiert?
- souvik1997
Sieht cool aus!
Ein Aspekt der Sicherheit von Multi-User-Agenten, der meiner Meinung nach zu wenig erforscht ist, ist, wie Kontext aus einer Sitzung mit höheren Privilegien in eine Sitzung mit niedrigeren Privilegien „leaken“ könnte. Angenommen, der CEO eines Unternehmens nutzt euren gemeinsam genutzten openclaw-Agenten und der Agent schreibt sensible Daten (zum Beispiel Investor-E-Mails) in sein Memory. Meines Wissens ist das nicht durch Alter geschützt. Dann nutzt ein Contractor denselben Agenten und kann dasselbe Memory lesen. Mir scheint, dass ein besseres Agenten-Harness für diese Art von Multi-User-Anwendungsfall benötigt wird; die Standard-Harnesses wie openclaw und claude code sind einfach nicht dafür ausgelegt. Würde gerne eure Gedanken hören!