AI 에이전트를 제대로 쓰기 시작하면 바로 부딪히는 문제가 있다.
"외부 API를 어떻게 붙일 것인가"
Gmail, Slack, GitHub, 각종 LLM API…
결국 전부 인증이 필요하다.
기존 방식 (문제의 시작)
대부분 이렇게 한다.
.env
API_KEY=xxxxx-> 에이전트에게 그대로 넘긴다
이게 왜 위험하냐
- 로그에 찍힘
- 프롬프트 인젝션에 털림
- 메모리에 남음
- 의도치 않은 요청 실행
한 번 넘긴 키는 통제 불가능
OneCLI의 접근
OneCLI는 이걸 완전히 뒤집는다.
"에이전트는 API 키를 절대 보지 못한다"
핵심 구조
Agent → OneCLI Gateway → External API동작 흐름
- 에이전트가 HTTP 요청 생성
- OneCLI Gateway로 보냄
- 규칙 검증
- 시크릿 주입
- 외부 API 호출
- 응답 반환
-> 중요한 포인트
에이전트는 끝까지 API 키를 모른다
아키텍처 (진짜 핵심)
1. Secret Vault
- AES-256-GCM 암호화
- 중앙 저장소
👉 키를 안전하게 보관
2. HTTP MITM Gateway
- 모든 요청 가로챔
- 필요한 순간에만 키 주입
-> 실행 시점 통제
3. Rule Engine
이게 핵심이다.
- host 기반
- path 기반
- method 기반
- agent 기반
왜 이게 중요하냐
기존 시크릿 매니저
저장 = 안전
사용 = 위험OneCLI
저장 = 안전
사용 = 통제됨-> 핵심 차이
"언제 어떻게 쓰이는가"까지 관리한다
규칙 예시
Gmail 삭제 막기
DELETE /gmail/*
→ 차단Slack 메시지 제한
POST /chat.postMessage
→ 시간당 10회-> 더 중요한 사실
규칙은 시크릿 주입 전에 실행된다
즉,
- 막힌 요청 → 키 접근도 못함
- 완전 차단 가능
MCP 대신 다른 선택
OneCLI 팀은 MCP를 이렇게 본다.
- 컨텍스트 낭비
- 지연 증가
- 인증 관리 복잡
그래서 선택한 방향
"CLI + HTTP + Gateway"
-> 철학
skill + cli > mcp왜 이게 큰 변화냐
기존:
- API 키 = 권한 + 실행
- 에이전트 = 모든 권한 보유
OneCLI:
- API 키 = 서버에 있음
- 에이전트 = 요청만 함
-> 구조가 완전히 바뀜
실무에서 좋은 점
1. API 키 유출 방지
- 에이전트에 안 줌
2. 정책 기반 제어
- 특정 행동 차단 가능
3. 중앙 관리
- 키 관리 단일화
4. 자동화 친화적
- CLI + JSON 출력 지원
현실적인 단점
이건 냉정하게 봐야 한다.
1. 프록시 기반 구조
- HTTPS MITM 필요
- 인증서 설정 필요
2. 아직 초기 단계
- 일부 기능 미완성
- 정책 기능 확장 중
3. 인프라 복잡도 증가
- 게이트웨이 운영 필요
- 네트워크 경로 변경 필요
한줄 정리
OneCLI는 "API 키를 주지 않고도 API를 쓰게 만든다"
진짜 핵심 (중요)
이건 시크릿 매니저가 아니다.
"에이전트 권한 통제 시스템"
개인적인 생각
이 방향은 거의 필수다.
앞으로 흐름은 이렇게 된다.
AI → 판단 → API 호출 → 실행문제는 항상 하나였다.
"이 AI에게 어디까지 권한을 줄 것인가"
OneCLI는 그 답을 이렇게 낸다.
권한은 주되, 키는 주지 않는다
마무리
지금은 초기 프로젝트다.
하지만 방향은 굉장히 명확하다.
프롬프트가 아니라, 인프라로 AI를 통제한다
무엇이든 필요한 것을 합니다. https://mint-middle-1e5.notion.site/2b7655e8316980ad9422d96a6f3947de