Alter, AI 에이전트마다 전용 키를 발급해 권한을 통제한다
Launch HN: Alter (YC S25) – Access control for multi-user agents
Alter는 여러 AI 에이전트가 하나의 과도한 권한 키를 공유하던 문제를 해결하는 권한 관리 플랫폼이다. 에이전트별 신원과 범위가 제한된 grant를 발급하고, 파라미터 단위의 기본 거부 정책과 위험한 호출에 대한 사람 승인을 적용한다. 모든 요청은 인증·인가·감사 로그를 거치며, 키나 grant를 즉시 폐기할 수 있다. 140개 서비스 연동과 LangChain, MCP, AWS 통합을 제공한다.
에이전트에게 당신의 키가 아니라, 에이전트 자신의 키를 쥐여주세요.
HN 토론
16- mauvehed
저 웹사이트는 말 그대로 바이브 코딩으로 만든 템플릿이네요.. 어떻게 이 앱 자체를 신뢰할 수 있을까요?
- 911viper
여기 souvik1997의 글과 같은 맥락인데요: 유출 문제는 공유 세션보다 공유 룸에서 더 심각해집니다. 여러 주체(사람들과 그들 각자의 에이전트)가 한 채널에 앉아 있으면, 대화 기록이 곧 권한 경계가 됩니다. 에이전트가 더 높은 권한의 턴에서 읽은 것은 무엇이든 그 룸의 이후 모든 턴의 컨텍스트에 남아 있게 되죠.
바로 그런 걸 만들면서 부딪힌 문제는, 사람과 봇이 동등한 주체인 룸에서는 토큰을 에이전트에 스코프할 수 없다는 점이었습니다. (에이전트, 룸) 쌍에 스코프해야 하고, 그다음엔 파생된 산출물을 어떻게 처리할지 결정해야 하죠. 도구 출력, 파일 핸들, 그리고 에이전트가 다시 기록하는 메모리 블롭은 모두 세션보다 오래 살아남아 다음 세션으로 재생됩니다.
그래서 파생 상태는 어떻게 처리하고 계신가요? 에이전트 메모리는 그것을 먹여준 세션들의 권한 교집합을 가진 새로운 주체인가요, 아니면 그냥 상속하고 모델이 오래된 컨텍스트에 따라 행동하지 않기를 믿는 건가요?
- souvik1997
멋져 보이네요!
멀티유저 에이전트 보안에서 제가 아직 충분히 탐구되지 않았다고 생각하는 측면 하나는, 더 높은 권한의 세션 컨텍스트가 어떻게 더 낮은 권한의 세션으로 "유출"될 수 있느냐는 점입니다. 예를 들어 회사의 CEO가 여러분의 공유 openclaw 에이전트를 사용하고, 그 에이전트가 민감한 데이터(예컨대 투자자 이메일)를 자기 메모리에 기록한다고 해봅시다. 제 이해로는 이것이 Alter로 보호되지 않습니다. 그러면 계약직 직원이 같은 에이전트를 사용해서 그 동일한 메모리를 읽을 수 있게 되죠. 이런 종류의 멀티유저 사용 사례에는 더 나은 에이전트 하네스가 필요하다고 생각합니다. openclaw나 claude code 같은 표준적인 것들은 애초에 그런 용도로 설계되지 않았으니까요. 의견을 듣고 싶네요!