Launch HN: Alter (YC S25) – 멀티유저 에이전트용 접근 제어

Who Should Read

여러 사용자 대신 외부 API를 호출하는 에이전트를 운영하며 키 관리와 권한 분리가 고민인 백엔드 개발자

Core Mechanics

• 에이전트에 내 키를 주지 않는다
  • Alter는 자격증명을 금고(Vault)에 한 번만 저장한다.
  • 요청이 지나갈 때 헤더에 주입하므로 프록시 호출은 코드에 키가 들어가지 않는다.
• 에이전트별 신원과 범위를 따로 준다
  • 에이전트마다 자기 키와 스코프를 갖는다.
  • 호출은 실제 사람까지 추적된다.
• 정책은 기본 거부, 파라미터 단위까지
  • 정책을 평가할 수 없으면 요청을 거부한다(fail-closed).
  • 위험한 호출은 지정된 사람의 승인을 기다린다.
• 모든 호출이 감사 로그에 남는다
  • 어떤 에이전트가 누구 권한으로 어떤 정책 아래 호출했는지 기록된다.
  • 승인자도 남고, 로그는 고객의 SIEM으로 스트리밍할 수 있다.
• SDK 한 번으로 140개 제공자를 다룬다
  • 저장·갱신·정책·감사를 SDK 호출 하나로 처리한다고 소개한다.
  • LangChain, MCP, AWS 연동을 제공한다.
• 메모리는 검증된 신원 기준으로 나눈다
  • 사용 사례 가이드에 메모리·세션·채널을 검증된 신원으로 키잉하라는 내용이 있다.
  • LLM이 주장하는 신원은 쓰지 않는다.
• SOC 2는 진행 중이다
  • 원문은 SOC 2 in progress라고 밝힌다.
  • 트러스트 센터에 모니터링 중인 통제와 12개월 내 외부 침투 테스트를 공개한다고 한다.

Community Reactions

• 상위 권한 세션의 맥락이 하위 권한 세션으로 샌다는 지적
  • CEO가 쓴 에이전트가 메모리에 투자자 이메일을 쓰면 계약자가 같은 메모리를 읽을 수 있다는 의견이 있었다.
  • 이 부분은 Alter가 보호하지 않는 것으로 이해한다는 댓글이다.
• 토큰은 (에이전트, 방) 쌍에 묶어야 한다는 경험
  • 사람과 봇이 한 방에 있는 시스템을 만들어 봤더니 에이전트 단위 토큰만으로는 부족했다는 경험이 나왔다.
  • 도구 출력·파일 핸들·메모리가 세션 이후에도 남아 다음 세션에 재생되므로 파생 상태를 어떻게 다루는지 묻는 질문이다.
• 프롬프트 인젝션 대응이 궁금하다는 질문
  • 인프라처럼 삭제가 되돌릴 수 없는 환경에서 권한이 유효한 에이전트가 인젝션당하면 어떻게 하느냐는 질문이다.
• 공유 API 키 환경에서 레코드 소유권은 누가 검사하냐는 질문
  • 두 영업 담당자가 같은 CRM 엔드포인트를 쓰되 자기 계정만 봐야 하는 경우를 예로 들었다.
  • 개발자가 로직을 따로 구현해야 하는지 묻는 질문이다.
• Infisical 같은 기존 도구와의 차이를 묻는 의견과 사이트 신뢰도 의문
  • 성숙한 시크릿 관리 도구 대비 장점이 무엇이냐는 질문이 있었다.
  • 사이트가 바이브 코딩 템플릿 같아 신뢰하기 어렵다는 비판도 있었다.

How to Apply

• 에이전트 키 사용 현황 30분 점검하기
  • 에이전트가 쓰는 API 키가 .env, 시스템 프롬프트, CI 설정에 흩어져 있는지 목록으로 만든다.
  • 여러 에이전트가 공유하는 과권한 키를 표시한다.
• 에이전트별 신원과 스코프 분리 설계하기
  • 에이전트마다 별도 자격증명과 최소 스코프를 정한다.
  • 환불·삭제 같은 위험 호출에는 사람 승인 단계를 둔다.
• 메모리와 세션을 검증된 신원으로 키잉하기
  • 메모리 저장 키를 LLM이 말한 사용자명이 아니라 인증 시스템의 사용자 ID로 바꾼다.
  • 권한이 다른 사용자 간에 메모리를 공유하지 않도록 분리한다.
• 감사 로그에 에이전트·사용자·승인자 남기기
  • 모든 외부 호출에 에이전트 ID, 대리 대상 사용자, 정책, 승인자를 기록한다.
  • 보안 심사에 낼 수 있도록 SIEM으로 내보낸다.

Try It

# Claude 또는 ChatGPT에 붙여넣기 (Alter 개념을 적용한 에이전트 권한 설계 점검용 간이 프롬프트)

나는 여러 사용자를 대신해 외부 API를 호출하는 에이전트 서비스를 운영한다. 아래 구조를 보고 권한 설계를 점검해줘.

{{에이전트 목록, 각 에이전트가 쓰는 API와 자격증명 보관 위치, 메모리 저장 방식}}

다음 기준으로 위험을 표로 정리해줘.
1. 여러 에이전트가 공유하는 키가 있는가
2. 에이전트별 최소 스코프로 나눌 수 있는가
3. 기본 거부 정책으로 바꿀 때 필요한 규칙은 무엇인가
4. 사람 승인이 필요한 호출은 무엇인가
5. 메모리가 사용자 신원별로 분리되어 있는가
6. 감사 로그에 에이전트, 사용자, 승인자가 남는가

이어서 해 볼 것: 가장 위험한 항목 하나를 골라 고치는 작업 목록을 만들어달라고 요청하기

Terminology

관련 논문

• Rust off Rails: 코드 없이 Markdown 60개로 만든 AI 에이전트용 웹 스택

  Markdown 규칙 60개로 에이전트가 Rust 웹앱을 짜게 한다는 프레임워크

• LayerFS: AI 코딩 에이전트를 위한 파일시스템

  에이전트마다 임시 Workspace를 마운트하고 결과만 커밋하는 파일시스템

• Claude로 코드의 공격 표면(attack surface) 줄이기

  Claude로 25개 오픈소스를 분석해 불필요하게 열린 코드 493건을 찾았다

• WhatsApp 도움말 페이지에 숨겨진 LLM 지시문: 규제기관을 추천하지 말라

  WhatsApp 도움말에 화면엔 안 보이는 AI 지시문 102개가 숨어 있었다

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

Related Resources

• https://alterauth.com/