OneCLI: 팀 직원마다 샌드박스 에이전트를 주는 오픈소스 하네스

Who Should Read

사내 직원용 AI 에이전트를 도입하려는데 API 키와 권한 관리가 걱정인 플랫폼·보안 담당 개발자

Core Mechanics

• 에이전트가 비밀키를 못 본다
  • 모든 외부 요청은 Rust 게이트웨이를 거치며, 게이트웨이가 HTTPS 요청을 MITM(중간에서 가로채기)해 자격증명을 넣는다.
  • 에이전트는 Proxy-Authorization 헤더의 액세스 토큰으로 인증한다.
  • 샌드박스에서 나가는 유일한 길이 게이트웨이라 허용한 곳만 접근할 수 있다.
• 직원 1명당 에이전트 1개
• 워크스페이스 구성원마다 자기 샌드박스 에이전트를 받고, 대시보드나 Slack에서 쓴다.
  • 회사 IdP(인증 시스템)와 연동해 직원 신원으로 에이전트를 만든다.
  • 정책은 한 곳에서 관리하고 모든 에이전트에 적용된다.
• 위험한 작업은 사람 승인이 고정
• 이메일 발송, Linear 티켓 삭제, S3 버킷 비우기처럼 100% 통제가 필요한 작업에 대화창 안 승인을 건다.
  • 승인은 결정적(deterministic) 방식이라고 소개한다.
• 에이전트는 프롬프트가 아니라 지속되는 존재
• 자체 파일시스템과 셸이 있는 샌드박스, 대화, 메모리, 스킬, 스케줄을 갖는다.
  • 메모리는 플랫폼이 보관하고 사용자가 읽고 수정할 수 있다.
  • 에이전트가 일하는 중에 보낸 메시지는 큐에 쌓이지 않고 바로 방향을 바꾼다.

Community Reactions

• 정책 세분화와 프롬프트 인젝션 대응을 묻는 의견
  • 엔드포인트 아래 단계, 즉 메서드·경로·요청 필드·리소스 소유권·응답량까지 제한할 수 있는지 묻는 댓글이 여럿이었다.
  • 읽기와 쓰기가 같은 호스트를 쓰는 API에서 승인이 정확한 행동(수신자·저장소 등)에 묶이는지가 핵심이라는 의견도 있었다.
• 게이트웨이 장애 시 동작을 묻는 의견
  • 에이전트 이탈이 불가능한 강제 egress라면 게이트웨이가 죽을 때 fail closed가 된다는 장점이 있다는 의견이 있었다.
  • 에이전트가 직접 게이트웨이를 호출하는 구조라면 우회 경로가 없는지 점검해야 한다는 지적도 있었다.
• 주입 탐지 테스트에 대한 경험
  • 직접 공격 코퍼스 7세트를 만들어 측정해 봤더니 넓게 뽑은 세트는 48~54%, 인식 가능한 패턴을 없앤 세트는 6~13%였다는 경험이 있었다.
  • 그래서 메서드·경로·본문 매칭과 정확한 호출에 묶인 사람 승인 같은 결정적 방식이 더 믿을 만하다는 의견이었다.
• 정책 중앙화와 경쟁·라이선스 의견
  • 자기 코드베이스에서 시크릿 마스킹 목록 6개가 제각각이었고 17개 자격증명 형태 중 기준 목록은 10개만 잡았다는 경험이 있었다.
  • 비슷한 제품이 너무 많다는 피로감, Infisical·Nemesis8 같은 대안, ee 폴더가 안 보여 라이선스가 헷갈린다는 지적도 있었다.

How to Apply

• 내 에이전트 비밀키 노출 지점 점검하기
  • 지금 쓰는 에이전트 프롬프트·툴 설정·환경변수에 실제 API 키가 들어가는 곳을 목록으로 만든다.
  • 각 키를 모델이 볼 수 있는지 표시하고, 보이는 것부터 프록시 뒤로 옮길 후보로 정한다.
• 로컬에서 OneCLI 띄워 보기
  • 저장소를 클론하고 pnpm install, pnpm run setup을 실행한 뒤 localhost:10254에 접속한다.
  • 테스트 에이전트 하나에 읽기 전용 연결 하나만 부여해 동작을 확인한다.
• 위험 행동 목록과 승인 대상 정하기
  • 에이전트가 할 수 있는 쓰기·삭제·발송 동작을 모두 적는다.
  • 되돌릴 수 없는 동작은 사람 승인 대상으로 분류한다.
• 세부 정책 질문을 도입 전 체크리스트로 만들기
  • 메서드·경로·필드 단위 제한 가능 여부, 게이트웨이 장애 시 fail closed 여부, 감사 로그를 확인 항목으로 넣는다.
  • 문서나 Discord에서 답을 확인한 뒤 도입을 결정한다.

Try It

# Claude나 ChatGPT에 붙여넣기 (OneCLI 방식인 게이트웨이 자격증명 주입을 점검하는 간이 프롬프트)

우리 에이전트 시스템 설계를 아래에 적었다.
{{에이전트가 호출하는 외부 API 목록, 키 보관 위치, 승인 절차}}

다음 관점으로 점검해줘.
1. 모델 컨텍스트나 샌드박스에 실제 자격증명이 노출되는 곳
2. 모든 외부 요청을 하나의 게이트웨이로 강제할 수 있는지
3. 호스트 단위가 아니라 메서드·경로 단위 정책이 필요한 API
4. 사람 승인을 꼭 걸어야 하는 되돌릴 수 없는 행동
5. 게이트웨이 장애 시 fail closed가 되는지

표로 정리하고 우선순위를 매겨줘.

이어서 해 볼 것: 나온 항목 중 1번 위험이 큰 키 하나를 골라 프록시 주입 방식으로 바꾸는 계획을 세워 달라고 요청해 본다.

Terminology

관련 논문

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

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

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

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

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

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

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

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

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓

Related Resources

• https://github.com/onecli/onecli
• https://onecli.sh
• https://github.com/DeepBlueDynamics/nemesis8
• https://infisical.com/docs/documentation/platform/agent-prox...