Bitwarden AI 코딩 에이전트: 안전한 Vault 접근 및 공유

Claude Code, Codex 또는 Cursor를 사용하여 실제 API를 다루는 작업을 하고 있다면, 자격 증명(Credential) 관리는 빠르게 위험해집니다. API 키를 채팅창에 붙여넣는 것은 모델을 영구적인 컨텍스트(Context)에 노출시키는 것이며, .env 파일에 두는 것은 에이전트가 bash를 통해 읽고 외부로 유출할 수 있는 비밀(Secret)을 생성하는 것입니다. 더 안전한 패턴은 비밀을 모델에 주지 않고, 필요한 하위 프로세스에 실행 시점(Runtime)에만 주입하는 것입니다. Bitwarden의 오픈 소스 프로젝트인 Agent Access를 오늘 바로 경험해 보세요. 이 프로젝트는 이 문제를 해결하기 위해 자격 증명 공유 프로토콜, CLI (aac), 그리고 Rust + Python SDK를 제공합니다. 이는 사용자의 비밀번호 관리자(Password Manager)와 원격 프로세스(AI 에이전트, CI runner 또는 스크립트) 사이에 암호화된 터널을 구축합니다. 소비자 프로세스는 Vault 전체를 볼 수 없으며, 범위가 지정된 도메인 또는 Vault 항목에 필요한 비밀만을 가져옵니다. 이 글에서는 Agent Access를 설치하고, aac connect 및 aac run 명령어를 사용하며, Claude Code, Codex, Cursor 워크플로우에 어떻게 통합하는지 살펴보고, "AI 에이전트 API 자격 증명을 안전하게 보호하는 방법" 글에 나온 자격 증명 위생(Credential Hygiene) 원칙을 실습해 보겠습니다.

Agent Access란 무엇인가요? Agent Access는 Bitwarden에서 개발했지만, 다른 비밀번호 관리자들도 채택할 수 있도록 오픈 설계(Open Design)된 프로토콜 및 레퍼런스 구현체입니다. 작동 모델은 다음과 같습니다: 제공자(Provider)가 연결 요청을 대기합니다. 소비자(Consumer)—에이전트, 스크립트 또는 CI job—가 제공자에 연결합니다. 소비자는 도메인 또는 Vault 항목 ID로 자격 증명을 요청합니다. 제공자는 무엇을 반환할지 결정합니다. 소비자는 Vault 전체를 절대 볼 수 없습니다. CLI 도구인 aac는 Noise 프로토콜을 사용하여 종단 간 암호화(End-to-End Encryption)된 터널을 구축합니다. 제공자는 소비자가 자격 증명으로 무엇을 하는지 알 수 없으며, 소비자 또한 Vault의 나머지 부분을 볼 수 없습니다. 감사 로그(Audit Trails)는 양측 모두에 기록됩니다.

참고: Agent Access는 현재 초기 프리뷰(Early Preview) 단계입니다. 프로젝트 README에는 API와 프로토콜이 변경될 수 있다고 명시되어 있습니다.

또한 민감한 자격 증명(Credentials)을 LLM(Large Language Models)이나 AI 도구에 직접 입력하는 것은 권장되지 않습니다. 따라서 가장 안전한 실무 패턴은 다음과 같습니다: aac run을 사용하여 비밀(Secret)을 오직 하위 프로세스의 환경 변수(Environment Variable)로만 전달하고, 모델의 컨텍스트 창(Context Window)에는 절대 포함하지 마십시오. 2026년에 이것이 왜 중요할까요? AI 코딩 도구들은 이제 단순히 제안을 생성하는 것에 그치지 않습니다. Claude Code, Codex, Cursor 및 유사한 도구들은 저장소(Repository)를 읽고, 테스트를 실행하며, API에 요청을 보내고, CI/CD 프로세스에 관여하며, 배포 스크립트를 트리거합니다. 이들 중 상당수는 API 키, 토큰 또는 비밀번호를 필요로 합니다. Postman의 API 키 유출 사건은 인간의 실수만으로도 자격 증명 위생(Credential Hygiene)을 확장하는 것이 얼마나 어려운지를 보여주었습니다. 인간과 AI 도구의 조합은 더 많은 리스크를 생성합니다. 올바른 접근 방식은 "도구를 더 많이 신뢰하는 것"이 아니라, "도구에 비밀을 더 적게 주는 것"입니다. Agent Access는 이 모델을 프로토콜 수준에서 구현합니다: 자격 증명은 범위가 지정(Scoped)되고, 전송 중에 암호화되며, 실행 시점에 가져오고, 프로세스가 종료되면 환경에서 사라집니다. API 키 관리 도구들이 더 넓은 도구 생태계를 포괄한다면, Agent Access는 특히 AI 도구와 개발자 워크플로우(Workflow)를 위해 설계된 레이어를 제공합니다. 설치 방법은 플랫폼에 따라 aac 바이너리를 다운로드하십시오.

macOS Apple Silicon
curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz && sudo mv aac /usr/local/bin/

macOS Intel
curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz && sudo mv aac /usr/local/bin/

Linux x86_64
curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz && sudo mv aac /usr/local/bin/

Windows x86_64
최신 릴리스 페이지에서 aac-windows-x86_64.zip 파일을 다운로드하여 PATH 내의 디렉토리에 압축을 푸십시오.

설치 확인:
aac --help

Bitwarden CLI (bw)가 PATH에 있다면, aac는 이를 기본 자격 증명 제공자(Credential Provider)로 사용합니다.

테스트를 위해 데모 제공자(demo provider)를 사용할 수 있습니다: aac connect --provider example --domain test.com --output json

빠른 시작: 자격 증명(credential) 매칭 및 가져오기
첫 번째 터미널에서, Vault 접근 권한이 있는 머신에서 리스너(listener)를 시작하세요: aac listen
이 명령은 매칭 토큰(matching token)을 생성합니다.
두 번째 터미널 또는 원격 소비자(consumer) 머신에서 연결하여 특정 도메인에 대한 자격 증명을 요청하세요: aac connect --token <matching-token> --domain github.com --output json

출력 예시:

{ "credential" : { "notes" : null , "password" : "alligator5" , "totp" : null , "uri" : "https://github.com" , "username" : "example" }, "domain" : "github.com" , "success" : true }

스크립트에서 이 JSON을 파싱할 수 있습니다:
aac connect --token "$AAC_TOKEN" --domain github.com --output json | jq -r '.credential.password'

도메인 대신 Vault 아이템 ID로 가져오려면:
aac connect --id <vault-item-id> --output json
--id와 --domain은 함께 사용할 수 없습니다. 하나만 선택하세요. Vault 아이템에 TOTP가 구성되어 있다면 동일한 응답 내에 반환됩니다.

가장 중요한 패턴: aac run을 이용한 환경 주입 (Environment Injection)
aac connect는 JSON 출력을 직접 처리해야 하는 스크립트에 적합합니다. AI 도구와 함께 사용할 때 더 안전한 패턴은 aac run을 사용하는 것입니다.
aac run은 자격 증명을 가져오고, 선택된 필드를 환경 변수(environment variables)로 변환하며, 하위 프로세스(sub-process)를 해당 환경에서 실행합니다. 비밀 정보(secret)를 stdout에 쓰거나 디스크에 저장하지 않습니다.

특정 필드만 주입하기:
aac run --domain example.com \ --env DB_PASSWORD=password \ --env DB_USER=username \ -- psql

모든 필드를 AAC_ 접두사와 함께 주입하기:
aac run --domain example.com --env-all -- ./deploy.sh

기본 모든 필드 외에 사용자 정의 변수 이름 지정하기:
aac run --domain example.com \ --env-all \ --env CUSTOM_PW=password \ -- ./deploy.sh

사용 가능한 필드:
username, password, totp, uri, notes, domain, credential_id

이것이 AI 도구에 권장되는 사용 방식입니다.

모델은 비밀(secret)을 보지 못합니다. 오직 다음 명령어를 실행하는 스크립트만을 봅: aac run --domain api.stripe.com --env-all -- ./deploy.sh. 만약 도구가 나중에 $STRIPE_API_KEY 값을 읽으려고 시도한다면, 해당 값은 오직 하위 프로세스(sub-process) 범위 내에만 존재합니다. 이러한 격리 원칙(isolation principle)은 "AI 에이전트의 API 자격 증명(credentials)을 어떻게 안전하게 보호할 것인가"라는 글에서 다룬 모델의 실질적인 구현입니다. CLI가 충분하지 않은 경우, Python 및 Rust SDK를 사용하여 애플리케이션에 Agent Access를 내장할 수 있습니다.

Python
from agent_access import RemoteClient
client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")
cred = client.request_credential("example.com")
print(cred.username, cred.password)
client.close()

Python 모듈은 PyO3를 기반으로 합니다. 무거운 작업은 Rust 측에서 처리되며, 내부적으로 동일한 Noise 프로토콜을 사용합니다.

Rust
Rust SDK는 동일한 RemoteClient 인터페이스를 라이브러리로 제공합니다. 참조 예제는 저장소의 examples/rust-remote/ 아래에 있습니다. Rust SDK는 다음과 같은 경우에 더 적합합니다: 자체 소비자 프로세스를 Rust로 작성하는 경우, CLI 도구를 개발하는 경우, CI 러너(runner) 또는 컴파일된 바이너리(binary)를 배포하려는 경우.

API 도구를 제공하는 팀에게 이 모델은 HashiCorp Vault 또는 Azure Key Vault 통합과 병행하여 사용되는 위치에 자리 잡습니다. Agent Access는 기업용 비밀 저장소(secret vaults)를 대체하는 것이 아니라, 개발자 노트북이나 CI 러너와 같이 더 좁은 범위의 워크플로우를 목표로 합니다.

AI 코딩 도구와의 통합

Claude Code
배포 스크립트를 aac run으로 감싸세요:

# deploy.sh
#!/usr/bin/env bash
aac run --domain prod.example.com --env-all -- ./run-deploy.sh

실행 권한을 부여합니다: chmod +x deploy.sh
Claude Code 워크플로우가 직접 ./deploy.sh를 호출하도록 설정하세요. 모델은 스크립트만 실행할 뿐이며, 자격 증명을 요청하거나 볼 필요가 없습니다.
Claude Code의 GitHub Actions 통합에서도 동일한 패턴이 적용됩니다: 러너(runner)에 aac를 설치하고, 러너를 제공자와 매칭한 뒤, 작업(job) 내에서 aac run을 통해 포괄적인 자격 증명을 주입합니다.

OpenAI Codex
Codex CLI에 대해서도 동일한 접근 방식을 사용하세요.

모델이 호출하는 명령은 실제 비밀(secret)이 아닌 래퍼 스크립트(wrapper script)만을 봅니다:

# test-api.sh
#!/usr/bin/env bash
aac run --domain staging.example.com \
  --env API_TOKEN = password \
  -- npm run test :api

Codex는 이 스크립트를 호출하며, 토큰은 모델의 컨텍스트(context)에 들어가지 않습니다. Codex의 더 넓은 사용 사례에 대해서는 휴대폰으로 Codex 문서를 확인하실 수 있습니다.

Cursor

Cursor의 터미널 명령 및 Composer 워크플로에서도 동일한 래핑(wrapping)이 작동합니다:

aac run --domain dev.example.com --env-all -- npm run e2e

Cursor는 일반적으로 로컬 개발 머신에서 실행되므로, 프로바이더 리스너(provider listener) 또한 동일한 머신에 있을 수 있습니다.

OpenClaw

Agent Access는 저장소에 SKILL.md를 포함하는 공식 OpenClaw 스킬(skill)을 제공합니다. OpenClaw 스타일의 스킬을 사용하는 팀에게 이것은 가장 준비된 통합 방식입니다. 스킬은 프로토콜 구조를 알고 있으며, 자격 증명(credentials)을 받아 관련 하위 도구로 전달합니다. 이 생태계의 더 광범위한 자격 증명 관리를 위해서는 OpenClaw API 키 가이드를 사용할 수 있습니다.

보안 모델

Agent Access의 보안 모델을 세 가지 측면에서 살펴보십시오.

1. 종단 간 암호화 (End-to-end encryption): 소비자(consumer)와 프로바이더(provider) 사이의 트래픽은 Noise 프로토콜 프레임워크로 암호화됩니다. 이는 WireGuard 및 Signal에서 사용하는 핸드셰이크(handshake) 제품군입니다.
2. 범위가 제한된 자격 증명 (Scoped credentials): 소비자는 요청한 도메인 또는 Vault 항목 ID에 대해서만 자격 증명을 받습니다. Vault를 목록화하거나 모든 비밀을 볼 수는 없습니다.
3. 기본적으로 비밀이 디스크에 기록되지 않음: aac run은 비밀을 환경 변수(environment variable)로서 오직 하위 프로세스(sub-process)에만 전달합니다:

aac run --domain example.com --env API_KEY = password -- npm test

이 모델에서는: .env 파일이 생성되지 않고, stdout에 비밀이 기록되지 않으며, 셸 히스토리(shell history)에 값이 남지 않고, 프로세스가 종료되면 환경 변수도 사라집니다.

Agent Access가 보호하지 않는 상황

Agent Access가 모든 것을 해결해주지는 않습니다. 주의해야 할 사항은 다음과 같습니다:

• 보안이 침해된 소비자 프로세스: 중개자(intermediary) 또는 하위 프로세스가 악의적이라면 범위가 제한된 자격 증명이라도 유출될 수 있습니다.
• 보안이 침해된 프로바이더: Bitwarden Vault가 탈취된 경우, 이 계층은 도움이 되지 않습니다.

LLM 문맥 (Context)에 붙여넣는 비밀 정보: API 키를 채팅창에 복사하면 프로토콜이 당신을 보호할 수 없습니다. 규칙은 간단합니다: 비밀 정보를 모델이 아닌, 필요한 하위 프로세스에만 전달하십시오.

실용적인 CI 패턴: 도구가 코드를 작성하고, Apidog가 테스트합니다. 대부분의 팀에게 적용 가능한 루프는 다음과 같습니다:

1. AI 도구가 코드 변경을 수행합니다. Claude Code, Codex 또는 Cursor가 API를 수정하는 PR (Pull Request)을 생성합니다.
2. CI 테스트가 실행됩니다.
3. Runner가 aac run을 통해 API 키를 가져와 스테이징 (Staging) 환경을 대상으로 테스트를 실행합니다.
4. Apidog가 계약 (Contract)을 검증합니다. Apidog는 별도의 CI 단계로 OpenAPI 계약 테스트를 실행합니다.

예시 CI 단계:
aac run --domain staging.example.com \ --env API_TOKEN = password \ -- npm run test :contract

결과: 도구는 코드를 생성하고, Apidog는 계약을 검증하며, API 키는 모델이나 평문 (Plain text) 파일에 입력되지 않습니다. AI 도구가 API를 호출할 때의 테스트 전략에 대해서는 "AI 도구를 호출하는 인공지능 도구 테스트하기"를 참조하십시오.

제한 사항 및 주의 사항

• 얼리 프리뷰 (Early Preview): API와 프로토콜은 변경될 수 있습니다. 프로덕션 (Production) 워크플로우를 v0 프로토콜에 연결하기 전에 변경 비용을 고려하십시오.
• 기본 제공자: Bitwarden CLI (bw)가 필요합니다. 먼저 Bitwarden CLI를 설치하거나 테스트 시 --provider example을 사용하십시오.
• 설정 파일 없음: 반복적인 호출을 위해 작은 래퍼 (Wrapper) 스크립트를 작성해야 합니다.
• LLM 프롬프트에 비밀 정보를 붙여넣지 마십시오: Agent Access가 설치되어 있더라도 이 실수는 당신을 취약하게 만듭니다.

자주 묻는 질문 (FAQ)
Agent Access는 무료인가요?
네. CLI, SDK 및 프로토콜은 Bitwarden GitHub 조직 아래에서 오픈 소스로 제공됩니다. Bitwarden을 Vault로 사용하는 경우, Bitwarden 플랜은 별개의 문제입니다.

Bitwarden 이외의 비밀번호 관리자와도 작동하나요?
프로토콜은 벤더 중립적 (Vendor-agnostic)으로 설계되었습니다. 레퍼런스 구현은 Bitwarden 지원 및 예시 제공자와 함께 제공됩니다. 다른 제공자들도 시간이 지남에 따라 자체적인 통합 기능을 제공할 것으로 기대됩니다.

비밀번호 관리자 없이 사용할 수 있나요?

테스트를 위해서는 다음과 같이 사용할 수 있습니다: aac connect --provider example --domain test.com --output json. 프로덕션(Production) 환경에서는 실제 제공자(Provider)가 필요합니다. 소비자(Consumer)가 프로세스의 네트워크 액세스가 필요한가요? 네, 그렇습니다. 소비자는 제공자의 리스너(Listener)에 도달할 수 있어야 합니다. 리스너와 소비자가 동일한 머신에 있다면 로컬 연결로 충분합니다. .env 파일과의 차이점은 무엇인가요? .env 파일은 디스크에 남아 있어 실수로 리포지토리(Repo)에 추가될 수 있으며, 도구가 실행하는 명령들에 의해 읽힐 수 있습니다. 반면 aac run은 비밀(Secret)을 오직 하위 프로세스(Subprocess)의 환경 변수로만 전달합니다: aac run --domain example.com --env API_KEY=password -- node script.js. 하위 프로세스가 종료되면 비밀은 범위(Scope)를 벗어납니다. HashiCorp Vault나 AWS Secrets Manager를 대체할까요? 아니요. 엔터프라이즈 비밀 저장소(Secret Vaults)는 확장 가능한 서비스 간 비밀 관리를 위한 여전히 올바른 도구입니다. Agent Access는 개발자 머신, AI 도구 워크플로우, 그리고 CI 러너(Runner) 사이의 공백을 메우는 데 더 집중합니다. Anthropic, OpenAI 또는 다른 도구 판매업체들이 이를 직접 통합할까요? 발표된