요약
Alter는 여러 사용자가 쓰는 AI 에이전트의 외부 API 호출을 사람별 권한으로 통제합니다.
Alter는 와이 콤비네이터 2025년 여름 기수 스타트업으로, AI 에이전트용 특권 접근 관리(PAM, 민감한 권한 사용을 통제하는 도구)를 내세웁니다. 사용자는 각자 로그인해도 에이전트는 공유 키 하나로 외부 시스템에 접속하는 문제를 겨냥합니다.
왜 중요한가
- 창업자들은 사용자별 권한이 외부 시스템까지 이어져야 에이전트에 실제 업무를 맡길 수 있다고 봅니다.
- 개발자가 매번 직접 짜던 사용자별 인증·정책·감사 로그를 별도 제품으로 떼어 내자는 제안입니다.
핵심 내용
- 에이전트와 외부 API 사이의 프록시가 키를 보관하고 요청에 넣어 주므로 에이전트는 키를 보지 못합니다.
- 요청마다 정책을 검사하며 기본값은 거부이고, 매개변수 단위까지 규칙을 걸 수 있습니다.
- 위험한 호출은 지정된 승인자가 허락해야 실행되고, 모든 호출은 위변조를 확인할 수 있는 로그로 남습니다.
작성자 설명
Alter를 만드는 스리카르와 케반입니다.
슬랙용 사내 에이전트를 만들어 봤다면 겪었을 일입니다. 다들 자기 계정으로 로그인하지만, 에이전트는 공유 API 키 하나로 CRM이나 결제 시스템에 접속합니다. 그러면 에이전트는 그 키로 할 수 있는 일을 전부 할 수 있습니다.
Alter는 에이전트의 API 요청을 중계하며 자격 증명을 관리합니다. 행동마다 최종 사용자의 신원을 반영해 정책을 적용하고, 감사 로그를 남깁니다. 데모 영상은 https://www.youtube.com/watch?v=9ZqPU14ipGE 에 있습니다.
골드만삭스에서 일하던 저(스리카르)는 이런 기능을 직접 만드는 비용이 너무 크다는 걸 겪었습니다.
저희 팀은 Alter로 여럿이 함께 쓰는 OpenClaw를 만들었습니다(https://github.com/AlterAIDev/openclaw-alter-plugin). 여러 스타트업이 SRE·백오피스 에이전트를 만들었고, 한 방산 업체는 해병대용 폐쇄망 에이전트를 만들고 있습니다.
요금은 사용량 기반이며 요청 1만 건까지 무료입니다. 여러 사용자를 대신하는 에이전트의 권한을 지금 어떻게 다루는지 듣고 싶습니다.
HN 반응
- 소스도 못 보는 보안 제품을 어떻게 믿느냐는 지적에, 창업자는 침투 테스트 2회와 곧 할 오픈소스 공개로 답했습니다.
- 메모리를 통한 사용자 간 유출과 프롬프트 주입(악성 지시를 끼워 넣는 공격) 질문에는 메모리 분리와 프록시 차단을 내세웠습니다.
멋져 보이네요!
멀티 유저 에이전트 보안에서 제 생각에 아직 덜 다뤄지는 부분이 있는데, 권한이 높은 세션의 컨텍스트가 권한이 낮은 세션으로 "새어 나갈" 수 있다는 점입니다. 예를 들어 어떤 회사의 CEO가 공유 openclaw 에이전트를 쓰다가 그 에이전트가 민감한 데이터(가령 투자자와 주고받은 이메일)를 메모리에 기록했다고 해 보죠. 제가 이해하기로는 이건 Alter가 보호해 주지 않습니다. 그런 다음 외부 계약자가 같은 에이전트를 쓰면 그 메모리를 그대로 읽을 수 있게 됩니다. 이런 멀티 유저 용도에는 더 나은 에이전트 하네스가 필요해 보입니다. openclaw나 Claude Code 같은 표준 도구는 애초에 이런 용도로 설계되지 않았으니까요. 의견을 듣고 싶습니다!
이 부분은 이미 대응하고 있습니다! 개발자가 Alter로 최종 사용자와 에이전트 신원을 기준으로 컨텍스트 메모리를 분리할 수 있어서, 말씀하신 것 같은 컨텍스트 유출은 완전히 막을 수 있습니다!
더 궁금한 점이 있으시면 여기 문서를 참고해 주세요: https://docs.alterauth.com/guides/propagate-identity-to-memory/
보안 말고도 쓸모가 아주 많을 것 같네요!
감사합니다! 맞아요, 목표는 개발자가 실제로 최종 사용자를 대신해 행동하는 멀티 테넌트 에이전트를 만들 수 있게 하는 겁니다. 그걸 만드는 데 필요한 모든 구성 요소를 추상화하는 작업을 하고 있고, 그래서 개발자는 자기가 가장 잘하는 일에 집중할 수 있습니다.
대단하네요! 벌써 그 부분까지 생각해 두셨다니 반갑습니다.
감사합니다!
각 메모리에 작성자를 나타내는 태그를 달아 두고, 읽을 때 프롬프트에 그대로 넣지 말고 필터링하면 됩니다.
저는 Substrate라는 프로젝트를 만든 사람인데, 메모리에 무엇이 들어 있는지 들여다보고 각 에이전트에게 무엇을 보여 줄지 고를 수 있게 해 주는 도구입니다.
그쪽 하네스에서는 사용자별로 메모리를 분리하나요?
네, 분리합니다. 최종 사용자 신원과 에이전트 신원을 둘 다 기준으로 나눕니다. 그쪽 제품이 Alter와 어떻게 같이 동작할 수 있을지 꼭 보고 싶습니다.
인프라 쪽에서 질문 하나 드립니다(저도 비슷한 시나리오를 인프라 용도로 운영하고 있는데, 리소스 삭제처럼 한 번 실수하면 되돌릴 수 없는 경우가 있습니다).
유효한 권한을 가진 에이전트가 프롬프트 인젝션을 당했다면 어떻게 처리하나요?
안녕하세요 @luis_valerio, 케빈입니다! 설계의 대부분은 바로 그 질문에서 나왔습니다.
저희는 모델이 프롬프트 인젝션에 당하는 것을 확실하게 막을 수는 없다고 가정합니다. 그래서 모델 계층에서는 아무것도 강제하지 않습니다. 강제는 프록시에서 이뤄지는데, 프록시는 에이전트와 하위 API 사이에 있고 자격 증명을 쥐고 있는 유일한 존재입니다. 에이전트는 키를 아예 보지 못하니, 인젝션당한 에이전트라도 결정론적 정책을 우회하거나 돌아갈 수 없습니다.
되돌릴 수 없는 작업에는 세 가지를 겹쳐서 씁니다.
메서드/엔드포인트 제한. "이 에이전트는 /instances/* 아래에서 GET만 가능"이라고 하면 DELETE는 제공자에게 도달하지 못합니다. 인프라 에이전트라면 기본값을 읽기 전용으로 하고, 꼭 필요한 변경 작업만 허용 목록에 올리길 권합니다.
위험한 작업에 휴먼 인 더 루프 적용. 승인은 조건부로 요구할 수 있습니다. DELETE일 때, 특정 작업일 때, 또는 파라미터가 조건에 맞을 때(허용된 범위 밖의 리소스 등)가 그렇습니다. 요청은 서버 쪽에서 고정되므로 승인자가 본 내용이 그대로 실행됩니다. 에이전트가 승인을 받은 뒤에 페이로드를 바꿔치기할 수 없습니다.
거부된 호출을 포함한 모든 호출의 감사 로그. 에이전트와 최종 사용자 신원이 함께 기록됩니다. 그래서 에이전트가 허용되지 않은 DELETE를 시도했는지, 누구를 대신해서 어떤 본문으로 시도했는지 볼 수 있습니다.
기본적으로 저희는 모든 호출을 탈취당한 노트북처럼 다룹니다. 얌전하게 동작하리라 가정하지 않고, 자격 증명의 범위를 좁히고, 위험한 작업은 제3자의 확인 뒤로 막아 두는 겁니다. 그쪽 구성도 더 듣고 싶습니다.
하위 서비스가 공유 API 키만 제공하는 경우에는 권한을 어떻게 처리하나요? 예를 들어 영업 담당자 두 명이 같은 CRM 엔드포인트를 쓰지만 각자 자기 계정만 접근해야 한다고 해 봅시다. Alter가 레코드 소유권을 확인해 주나요, 아니면 그 로직은 여전히 개발자가 직접 넣어야 하나요?
저희는 최종 사용자가 alter connect SDK로 API 키를 직접 추가할 수 있게 합니다. API 키를 공유해야 한다면 저희가 제공하는 grant ID 추상화를 이용해 개발자 쪽에서 매핑하면 됩니다. 문서는 여기서 확인해 주세요: https://docs.alterauth.com/concepts/credentials/
요즘은 이게 나쁜 생각이라고 봅니다. 이렇게 하는 회사는 스스로 표적이 되고, 결국 OpenCode처럼 해킹당합니다. 고객 계정이 털리거나 요금 폭탄을 맞게 되죠.
게이트웨이는 직접 운영하면서 방화벽이나 VPN 뒤에 두세요. 저는 GoModel + Tailscale을 씁니다.
https://news.ycombinator.com/item?id=50133401 (OpenCode 해킹 기사)
infisical 같은 기존의 검증된 도구들과 비교하면 이런 도구는 뭐가 더 나은가요?
좋은 질문입니다! 그냥 시크릿을 저장하는 게 목적이라면 infisical을 쓰시면 됩니다.
Alter가 진짜 가치를 발휘하는 건 에이전트에게 최종 사용자의 자격 증명 접근 권한을 줘야 할 때입니다. 에이전트가 최종 사용자를 대신해 행동하면 개발자는 여러 자격 증명을 관리해야 하고, 더 중요하게는 최종 사용자 신원과 자격 증명 사이의 매핑 관계도 관리해야 합니다.
또 에이전트가 행동을 하다 보면 비결정론적인 동작의 문제가 더 두드러집니다. Alter의 정책 가드레일이 있으면 에이전트가 좋지 않은 행동을 할 가능성을 줄일 수 있습니다.
마지막으로, 에이전트가 무엇을 했는지 담긴 완전한 컴플라이언스 기록은 특히 에이전트가 더 자율적으로 행동할수록 상당히 가치가 커집니다!
[플래그됨]
그렇게 하셔도 됩니다.
공격적인 질문처럼 들릴 수도 있습니다. 하지만 인증을 다루는 제품에는 반드시 물어야 하는 질문입니다.
보안이 핵심인 제품인데, 소스 코드도 볼 수 없는 완전한 바이브 코딩 제품을 제가 어떻게 믿을 수 있죠?
안녕하세요! 타당한 질문입니다.
저희는 현재 SOC2 인증을 완전히 받기 위한 과정에 있고, 서로 다른 두 회사에서 모의 침투 테스트를 두 차례 받았는데 아무 문제도 발견되지 않았습니다. 보안 프로세스 전체와 모의 침투 테스트 결과는 trust.alterauth.com에서 확인하실 수 있습니다.
그리고 별도로 말씀드리면, 써 보지도 않고 바이브 코딩으로 만들었다고 단정하는 것은 잘못된 가정입니다. 글에서 말씀드렸듯이 저희는 SDLC의 일부로 공급망 공격에 대한 상시 스캔과 정적 코드 분석(SAST) 등 많은 보안 프로세스를 도입했습니다.
모의 침투 테스트도 매년 정기적으로 진행합니다.
매일 쏟아져 나오는 수많은 서비스처럼, 아주 전형적인 AI 생성 UI를 입히셨잖아요. 인증 제품이라면 그게 더 중요합니다. 게다가 "열쇠 꾸러미"를 통째로 넘기지 않고는 써 보기도 어렵습니다.
일단 Type I 인증부터 받으시겠죠? 그것만으로는 가치가 제한적이고, 대부분 Type II로 가기 위한 단계입니다. 이미 Type I을 마쳤다면 웹사이트에 적어 두세요. "규제 산업"은 영업 주기와 평가 기간이 길어서, 더 믿음직한 웹사이트가 없으면 그런 대화를 시작하기도 어려울 겁니다.
저희는 곧 플랫폼 전체를 오픈소스로 공개할 예정이라, 코드를 직접 확인하실 수 있게 됩니다.
SOC2는 현재 Type 2 인증을 받는 과정에 있습니다. 아시다시피 감사인이 SOC2 인증서를 발급하기까지 3개월의 대기 기간이 있는데, 지금은 그 대기 기간 중입니다.
https://osmessenger.com gpt, claude, gemini, hermes, grokbot이 한곳에 모인 채팅방입니다. 파일 공유, 화이트보드, 공개 또는 비공개 채팅방까지 있고, 여러분이 그 한가운데 있습니다. 말도 안 되게 좋은데, 실제로 됩니다.
HN을 주로 자기 작업물 홍보용으로 쓰지 말아 주세요. 가이드라인에 관련 내용이 있습니다. https://news.ycombinator.com/newsguidelines.html
저 웹사이트는 말 그대로 바이브 코딩으로 만든 템플릿이잖아요.. 그런데 앱 자체를 어떻게 믿으라는 거죠?
저희는 SOC2 인증을 받는 과정에 있습니다. 신뢰 페이지는 여기서 확인하실 수 있습니다: https://trust.alterauth.com/
모의 침투 테스트도 서로 다른 두 곳에서 두 차례 받았는데 문제는 발견되지 않았습니다. 그중 한 곳의 결과는 신뢰 센터에서 보실 수 있습니다.
ㅋㅋ 무례한 질문에 정중하게 답한 것뿐입니다. 거기에 LLM은 전혀 쓰지 않았어요.