Cordium: AI가 프로세스 비밀번호 없이 DB에 접근

Cordium 30초 요약

Cordium은 Octelium Labs, LLC가 공개한 무료 Apache-2.0 라이선스의 셀프 호스팅 샌드박스 플랫폼입니다. AI 워크로드가 실행 중인 프로세스 안으로 어떤 자격 증명도 들여보내지 않고 데이터베이스, SSH 서버, 내부 HTTP API, Kubernetes 클러스터에 접근할 수 있게 해주며, github.com/octelium/cordium 에 공개되어 있습니다 . Workspace라고 부르는 샌드박스는 인프라에 대한 실제 접근 권한을 얻지만, 원본 시크릿은 물리적으로 다른 곳에 남아 있습니다.

빠른 답변: Cordium은 Octelium Labs가 만든 오픈소스(Apache-2.0) 셀프 호스팅 샌드박스로, AI 에이전트가 자격 증명을 샌드박스 안으로 들여보내지 않고도 데이터베이스와 SSH 호스트에 접근할 수 있게 합니다. 시크릿은 Octelium ZTNA 프록시에 남아 있으며, 요청별 인가가 끝난 뒤에만 프로토콜 계층에서 주입됩니다. 최신 릴리스: v0.12.7, 2026년 6월 6일.

이 메커니즘이 Cordium을 단순한 코드 실행 샌드박스와 갈라놓습니다. API 키, 비밀번호, SSH 개인 키, kubeconfig를 에이전트 환경에 주입하는 대신, Cordium은 그 시크릿을 Octelium의 ID 인식 프록시에 보관하고 Workspace의 ID가 요청별 속성 기반 인가를 통과한 뒤에만 프로토콜 계층에서 주입합니다 . 실행 중인 코드는 원본 자격 증명을 받지 않습니다.

아직 초기 단계의 프로젝트입니다. 조사 시점의 최신 릴리스는 2026년 6월 6일자로 나온 v0.12.7이며, 저장소는 GitHub 스타가 약 42개 수준입니다. 최근 오픈소스로 공개되어 아직 채택을 넓혀가는 중입니다 . 코드베이스는 대략 TypeScript 55%, Go 45%로 구성되어 있습니다 .

그 밑에 깔린 보안 가정은 간단합니다. 오작동하거나 침해된 AI라도 애초에 물리적으로 갖고 있지 않은 자격 증명은 유출할 수 없습니다. 프롬프트 인젝션이 모델을 속이든, 모델이 단순히 지시를 벗어나든, 환경 변수나 키 파일, .env 안에 새어 나갈 키가 없습니다. 자격 증명은 프록시에 있고, 요청마다 게이트와 감사를 거칩니다 . 아래 섹션에서는 이 구조가 실제로 얼마나 버티는지 살펴봅니다.

비밀번호가 실행 중인 코드에 들어가지 않는 방식

Cordium은 시크릿과 세션을 분리하기 때문에 자격 증명이 실행 중인 코드로 들어가지 않습니다. Workspace는 ID 주장만 갖고, 원본 비밀번호는 Octelium 프록시에 남아 있다가 접근 게이트를 통과한 뒤 프로토콜 계층에서 주입됩니다 . 에이전트 프로세스는 시크릿을 읽거나 저장하거나 로그로 남기지 않습니다. 키가 아니라 살아 있는 소켓을 받아 연결을 열 뿐입니다.

일반적인 방식과 비교해보면 차이가 분명합니다. 코드가 Postgres와 통신하게 하려면 보통 비밀번호를 환경 변수, .env 파일, 또는 볼륨에 마운트한 키 파일로 넣습니다. 프로세스는 시작할 때 그것을 읽고 세션 내내 메모리에 들고 있습니다. 그 순간 시크릿은 프로세스 환경, 힙, 그리고 부주의한 연결 문자열이나 스택 트레이스를 통해 애플리케이션 로그에도 자주 남습니다. 자기 환경을 읽을 수 있는 코드 경로라면 무엇이든 그것을 빼낼 수 있고, 이것이 바로 자율 에이전트나 침해된 에이전트가 드러내는 실패 모드입니다.

Cordium의 흐름은 신뢰 경계를 뒤집습니다:

• Workspace는 자격 증명이 아니라 ID를 갖습니다. 인증은 OIDC assertion, OAuth2 client-credentials, bearer auth를 통한 워크로드 ID 페더레이션을 사용하므로, 에이전트나 CI/CD 작업은 환경 안에 정적 시크릿을 두지 않고 인증합니다 .
• 프록시가 시크릿을 보관합니다. 데이터베이스 비밀번호, SSH 개인 키, kubeconfig는 Octelium ID 인식 프록시에 있고 샌드박스 안에는 들어가지 않습니다 .
• 주입은 TCP/TLS/프로토콜 계층에서 일어납니다. 요청별 ABAC 검사가 통과되면, 프록시는 데이터베이스, SSH 서버, 내부 HTTP API, Kubernetes 클러스터, mTLS 보호 서비스 같은 업스트림 연결을 중개할 때 실제 자격 증명을 붙입니다 .
• 코드에는 작동하는 연결만 보입니다. AI는 일반적인 연결 호출을 보내고 사용할 수 있는 소켓을 돌려받습니다. 샌드박스 안에서는 데이터베이스가 “그냥 동작”하지만, 출력하거나 복사하거나 유출할 비밀번호는 없습니다.

프로토콜 계층 주입이 처음 들리는 것보다 더 중요한 이유가 여기에 있습니다. LLM 에이전트의 흔한 유출 경로, 즉 모델 출력, 설정 덤프를 유도하는 조작된 프롬프트, 사후 로그 스크래핑은 모두 캡처할 수 있는 인프로세스 시크릿이 있다고 가정합니다. Cordium에는 그런 것이 없습니다. 모델이 완전히 침해되어도 넘겨줄 것이 없습니다. 공격자가 원하는 대상이 애초에 모델이 제어하는 환경, 힙, 로그에 상주한 적이 없기 때문입니다 .

분명한 단서는 있습니다. 이 보장은 경계 자체만큼만 강합니다. 샌드박스가 프록시를 우회하는 네트워크 정책 빈틈을 통해 업스트림 서비스에 직접 닿을 수 있다면, 프로토콜 계층 주입은 더 이상 아무것도 보호하지 못합니다. 이 메커니즘은 인프로세스 시크릿을 없애지만, 네트워크 경로를 검증해야 할 필요까지 없애지는 않습니다. 다음 섹션의 게이팅 모델은 바로 그 부분을 강제하도록 구성되어 있습니다.

CEL과 OPA로 속성 기반 접근 제어하기

그 네트워크 경로를 관리하는 것이 바로 Cordium의 권한 부여 계층이다. 인프라 접근은 요청마다 L7을 인식하는 속성 기반 접근 제어(ABAC)로 결정되며, 하드코딩된 허용 목록이나 환경변수 권한에 박아 넣는 대신 CEL(Common Expression Language)로 policy-as-code를 작성하고 OPA(Open Policy Agent)를 통해 평가한다 . 프록시가 애플리케이션 계층을 이해하기 때문에, 정책은 단순히 "이 Workspace가 데이터베이스에 접근할 수 있는가"뿐 아니라 바로 그 순간에 이루어지는 특정 요청까지 제어할 수 있다.

기본 자세는 상시 권한 제로다. 악용될 수 있는 영구 권한이 남아 있지 않다 . 각 연결 시도는 발생하는 바로 그 시점의 현재 정책에 따라 평가되므로, 접근 권한을 철회하는 일은 자격 증명을 급히 교체하는 일이 아니라 정책을 수정하는 일이다. 신뢰할 수 없거나 모델이 생성한 코드를 실행할 수 있는 에이전트라면 이 점이 중요하다. 1분 전에 승인된 Workspace라도 다음 요청에서는 다시 확인되며, 정책 변경은 샌드박스를 재배포하거나 어떤 비밀값도 건드리지 않고 적용된다.

정책이 읽는 입력은 신원이며, Cordium은 폭넓은 신원 체계를 받아들인다. 사람에게는 모든 OIDC 또는 SAML 2.0 ID 공급자, GitHub OAuth2, 그리고 네이티브 FIDO2/WebAuthn, TOTP, TPM 2.0을 지원한다 . 사람이 아닌 호출자, 즉 이 트래픽의 대부분을 실제로 구동하는 에이전트와 CI/CD 작업에는 OIDC assertion을 통한 workload identity federation, OAuth2 client-credentials, bearer authentication을 지원한다 . 실무적으로 중요한 점은 빌드 파이프라인이나 자율 에이전트가 설정 파일에 정적 공유 비밀번호를 남기지 않고도 일급 신원으로 인증할 수 있다는 것이다. ABAC는 "누구인가"를 신뢰할 수 있을 때만 작동하며, 정적 비밀값은 프롬프트 인젝션이나 유출된 .env가 정확히 노리는 부분이다.

모든 권한 부여 결정은 관찰 가능하다. 각 요청은 OpenTelemetry 네이티브이며, 신원 라벨이 붙고, L7을 인식하는 구조화된 로그 레코드를 생성한다. Octelium 클러스터는 이를 내보내며 어떤 OTLP receiver로도 export할 수 있어, 별도의 감사 계층을 덧붙이지 않고도 SIEM과 로그 관리 연동이 가능하다 . 따라서 검토자는 어떤 신원이 어떤 정책 아래 어떤 서비스를 건드렸는지 요청 단위 추적 기록을 얻는다. 이는 사고 대응에도 유용하고, 이전 섹션의 네트워크 경계가 실제로 강제되고 있는지 확인하는 데도 유용하다.

한 가지 전제는 계속 염두에 두어야 한다. 이 전체 모델은 Octelium 프록시가 업스트림 서비스로 가는 유일한 경로이고, 그 정책이 올바르게 작성되어 있다는 가정에 기대고 있다. 여기서 살핀 릴리스는 2026년 6월 6일자 v0.12.7로 아직 초기 단계다 . 또한 적대적인 에이전트 동작 아래에서 CEL/OPA 강제가 얼마나 버티는지에 대한 독립적인 평가는 없다. ABAC는 상시 위험을 줄이지만, 정책을 제대로 작성해야 하는 운영자의 책임까지 없애지는 않는다.

Kubernetes에서의 배치와 Workspace 지속성

Cordium은 표준 Kubernetes 위에서만 실행된다. 도입해야 할 독점 제어 평면은 없다. 같은 선언형 모델은 로컬 개발용 단일 노드 VM부터 다중 노드 프로덕션 클러스터까지 확장되며, 클라우드에서도 완전한 온프레미스에서도 실행된다 . 이 선택은 운영상 의미가 있다. 이미 Kubernetes를 운영하는 팀은 별도의 오케스트레이션 계층이 아니라 Cordium의 기반을 그대로 받아들이며, 자격 증명을 보관하는 Octelium 프록시는 자신이 제어하는 Workspace와 나란히 배치된다.

격리는 rootless 중첩 컨테이너에서 나온다. 호스트는 바깥쪽 rootless 경계로 보호되고, Workspace 자체는 샌드박스 안에서 여전히 전체 root 권한을 제공한다 . 개발자에게 실제로 중요한 결과는 일반적인 빌드, 설치, 테스트 도구를 깨뜨리는 capability 제거가 없다는 점이다. 패키지 매니저, 컨테이너 빌드, 권한이 필요한 테스트 하네스가 보통의 머신에서처럼 동작하며, 더 가벼운 샌드박스에서 자주 필요한 우회 작업이 줄어든다.

Workspace는 선언형 YAML로 정의되며 여러 소스에서 빌드할 수 있으므로, 환경을 머신 간에 이식 가능하고 재현 가능하게 만들 수 있다.

• OCI 이미지 — 미리 빌드된 이미지를 Workspace 기반으로 가져온다.
• Dockerfile — 생성 시점에 명세에서 환경을 빌드한다.
• Git 저장소 — 저장소에서 직접 부트스트랩한다.
• Devcontainer 명세 — 로컬 에디터 컨테이너를 구동하는 동일한 정의를 재사용한다 .

수명주기는 암묵적이지 않고 명시적이다. Workspace는 세션을 넘어 살아남는 장기 실행 개발 또는 AI 환경인 persistent일 수도 있고, 작업마다 띄웠다가 종료 시 정리되는 ephemeral일 수도 있다. 영구 상태는 교체 가능한 CSI Kubernetes 네이티브 볼륨으로 뒷받침되므로, 스토리지는 별도 전용 계층이 아니라 클러스터의 기존 드라이버를 사용한다 . 자율 에이전트 워크로드라면 ephemeral 모드를 선택하는 것이 맞다. 각 작업이 새롭고 버릴 수 있는 환경을 받기 때문에, 에이전트가 상태를 망가뜨리거나 설치하면 안 되는 것을 설치하더라도 피해 범위를 제한할 수 있다.

실행 중인 Workspace에는 네 가지 ingress 표면, 즉 브라우저 터미널, SSH, CLI, gRPC API를 통해 접근할 수 있다 . 브라우저 터미널은 사람이 빠르게 확인하기에 적합하고, SSH와 CLI는 기존 개발자 워크플로에 맞으며, gRPC API는 에이전트와 CI/CD 파이프라인이 호출하는 프로그래밍 방식의 진입점이다. 이 모든 경로는 여전히 동일한 신원 인식 권한 부여의 적용을 받으므로, 어떤 ingress를 선택하더라도 앞서 설명한 자격 증명 격리 모델은 약해지지 않는다.

Cordium과 E2B, Daytona, AISI Inspect 비교

Cordium과 가장 가까운 도구들은 Cordium과는 다른 문제를 풉니다. 대부분의 샌드박스 도구는 실행을 격리하지만, Cordium은 자격 증명을 격리합니다. E2B와 Daytona는 클라우드에서 관리되고 빠르게 시작되는 샌드박스로, 일시적인 AI 도구 호출에 잘 맞습니다. 하지만 둘 다 실행 중인 프로세스에 시크릿, 즉 환경 변수, 키 파일, kubeconfig 등을 마운트하는 기존 방식을 따릅니다. Cordium은 바로 이 노출을 없애기 위해 시크릿을 신원 인식 프록시에 보관하도록 설계됐습니다 . 각 도구가 경계를 어디에 두는지를 알아야, Cordium과 경쟁하는지 아니면 함께 쌓아 쓸 수 있는지 판단할 수 있습니다.

영국 AI Security Institute의 Inspect 프레임워크는 겹침이 아니라 인접한 영역의 대표적인 예입니다. Inspect는 평가에 초점을 둔 프레임워크로, Docker, Kubernetes, Daytona, Modal, EC2, Proxmox 제공자 전반에서 에이전트 도구 실행을 샌드박싱합니다. 내장 Docker 지원에는 Docker Engine 24.0.7 이상이 필요합니다 . Inspect의 제어 기능은 안전하고 재현 가능한 평가에 맞춰져 있습니다. 전체 네트워크를 차단하는 network_mode: none 옵션과 함께, 읽기 파일 크기 100MB, 실행 출력 크기 10MB라는 기본 제한이 있습니다 . 이는 채점 대상 에이전트 실행을 가두기 위한 샌드박싱이지, 비밀번호를 숨긴 채 프로덕션 데이터베이스에 인가되고 감사 가능한 접근을 부여하기 위한 것은 아닙니다. 목표가 완전히 다릅니다.

Protect AI의 LLM Guard는 또 다른 계층에 있습니다. LLM 상호작용 보안을 위한 MIT 라이선스 툴킷으로, 입력/출력 정제, 데이터 유출 방지, 프롬프트 인젝션 저항성을 제공하며 전용 "Secrets" 스캐너도 포함합니다 . 하지만 이 스캐너는 모델 I/O 경계에서 작동합니다. 즉, 프롬프트와 완성 결과에서 유출된 자격 증명을 검사합니다. 반면 Cordium의 격리는 네트워크 프로토콜 계층에서 일어나며, 시크릿이 애초에 모델에 도달하기 전에 막습니다. 둘은 상호 보완적입니다. 출력 정제는 빠져나간 것을 잡고, 프로토콜 계층의 자격 증명 격리는 시크릿이 처음부터 도달 가능한 상태가 되지 않게 합니다.

이 표를 가로로 읽어 보면 각 도구의 위치는 일관됩니다. E2B와 Daytona는 시작 속도와 편의성을 최적화하지만 마운트된 시크릿 패턴을 그대로 물려받습니다. Inspect는 엄격한 리소스 제한과 선택적 네트워크 격리로 평가 환경의 containment를 최적화합니다. LLM Guard는 텍스트 경계 검사를 최적화합니다 . Cordium의 뚜렷한 선택은 자격 증명을 에이전트의 머신 밖으로 완전히 옮기고, 각 요청을 신원으로 통제하는 것입니다 . 그 대가는 성숙도입니다. v0.12.7에 스타가 대략 42개인 Cordium은 비교 대상인 기존 도구들보다 훨씬 젊습니다 .

OWASP LLM01과 인접 방어책

Cordium의 자격 증명 격리는 OWASP가 LLM01:2025 Prompt Injection에서 정리한 위협 중 한 부분에 대응한다. OWASP는 프롬프트 인젝션을 사용자 입력이나 외부 입력이 LLM의 동작을 의도치 않은 방식으로 바꾸는 현상으로 정의하며, 주요 피해로 민감 정보 노출, AI 인프라 및 시스템 프롬프트 유출, 무단 함수 호출, 연결된 시스템에서의 임의 명령 실행을 든다 . 이 항목이 포함된 OWASP Top 10 for LLM Applications 2025는 2024년 11월 17일에 발표됐다 . 중요한 점은 OWASP가 RAG와 파인튜닝만으로는 인젝션을 완전히 완화할 수 없다고 보고, 대신 최소 권한 접근, 외부 콘텐츠 분리, 입력/출력 필터링, 고위험 작업에 대한 사람의 승인 같은 엔지니어링 통제를 권고한다는 것이다.

"Prompt injection vulnerabilities are possible due to the nature of generative AI... mitigation requires constraining model behavior, restricting access by least privilege, and requiring human approval for privileged operations," — OWASP GenAI Security Project (source: LLM01:2025).

Cordium은 이 목록 중 최소 권한과 자격 증명 격리 영역에 들어맞지만, 인가된 에이전트가 합법적으로 가진 접근 권한으로 무엇을 할지 결정하는 의미 계층에는 아무것도 하지 않는다. 최근 연구 시스템 두 가지는 바로 그 공백을 겨냥하며, 둘 다 Cordium의 인프라 접근 방식과는 별개의 축에 있다.

• Cordon ("Semantic Transactions for Tool-Using LLM Agents," 2026년 6월 16일 제출)은 도구 사용 의도를 작업 수준 트랜잭션 경계로 감싸고, 계보 추적, 되돌릴 수 있는 로컬 상태, 단계적 외부 커밋을 적용한다. 위험이 포함된 워크플로 45개 중 45개에서 정책 위반 효과를 차단했다고 보고했으며, 기존 방어책 기반 어댑터는 45개 중 14개였다. 중간값 롤백 지연 시간은 4.17ms였다 .
• ClawGuard (2026년 4월 13일 제출)는 모든 도구 호출 경계에서 사용자가 확인한 규칙을 강제하며, 다섯 개 모델을 대상으로 AgentDojo, InjecAgent, ChatInject 전반에서 100% 방어 성공률을 보고했다 .

이들은 격리 샌드박스가 아니라 규칙 및 트랜잭션 계층의 통제책이다. 그리고 단일 벤더의 모든 벤치마크 수치와 마찬가지로, 이 숫자들은 독립 재현을 기다리는 저자 보고값이다. Protect AI의 MIT 라이선스 툴킷인 LLM Guard는 또 다른 계층에 위치하며, 프롬프트와 응답 텍스트를 스캔해 정제, 데이터 유출 방지, 전용 비밀 정보 스캐너 기능을 제공한다.

실무적으로 얻을 결론은 OWASP가 설명한 공격 표면을 단일 도구가 모두 포괄하지는 못한다는 점이다. Cordium은 자격 증명 계층을 지키고, ClawGuard와 Cordon은 도구 호출 및 의미 계층을 지키며, LLM Guard는 텍스트 입출력 경계를 지킨다. 이들은 경쟁하기보다 심층 방어로 조합된다. Cordium의 시크릿 없는 접근에 도구 호출 게이트와 출력 필터링을 함께 붙이면, 그중 어느 하나만 쓸 때보다 LLM01의 훨씬 넓은 범위를 덮을 수 있다.

v0.12.x 기준 Cordium: 성숙도와 운영 복잡성

Cordium은 초기 단계 프로젝트이며, 보안 주장은 독립 검증이 아니라 벤더가 제시한 내용이다. 최신 릴리스는 2026년 6월 6일자의 v0.12.7이고, GitHub 저장소는 대략 42개 스타 수준이다 . 최근 오픈소스화되어 아직 도입을 쌓아가는 도구다. 이 글을 쓰는 시점에는 제3자 레드팀 탈출 테스트, 중립적인 격리 강도 벤치마크, 샌드박스 탈출 평가가 공개되지 않았다. 시크릿 없는 보장은 아직 Octelium Labs 외부에서 측정된 적 없는 설계 의도로 보는 편이 맞다.

프로덕션 도입을 검토하는 사람에게는 이 공백이 중요하다. 프로토콜 계층 자격 증명 주입이 추가하는 오버헤드에 대한 중립적 측정도, 공개된 샌드박스 탈출 평가도, 운영자 오류 시 모델이 어떻게 약화되는지 보여주는 의도적으로 잘못 구성된 기준선과의 비교도 없다. 자격 증명이 없는 속성은 Octelium 프록시가 올바르게 구성되어 있고 Workspace가 업스트림 서비스에 직접 닿지 않는다는 조건에 전적으로 의존한다 . 네트워크 정책의 빈틈 하나나 프록시 오구성 하나만으로도 샌드박스가 게이트웨이를 우회해 격리를 무력화할 수 있지만, 검토한 자료에는 이 실패 모드에 대한 하드닝 가이드가 포함되어 있지 않았다.

비용은 양면적이다. 코어는 Apache-2.0이고 셀프 호스팅 방식이라 라이선스 비용은 없다 . 실제 비용은 운영에서 나온다. Kubernetes 기반 Octelium 클러스터를 운영하고 보호하는 일, CEL/OPA 정책을 최신 상태로 유지하는 일, 감사 파이프라인을 모니터링하는 일은 가벼운 엔지니어링 작업이 아니며, 이 비용은 공개 자료 어디에서도 정량화되어 있지 않다.

인용: AISI Inspect , LLM Guard .

결론은 이렇다. Cordium의 신원 기반, 시크릿 없는 모델은 에이전트 스택의 실제 공백을 메우는 분명히 유용한 기본 요소다. 하지만 v0.12.x 기준으로는 보장이 아니라 베팅에 가깝다. 중요하지 않은 인프라에서 파일럿으로 먼저 써 보고, 프록시 경계를 강제하는 네트워크 정책을 직접 검증하며, 도구 호출 게이팅과 출력 필터링을 함께 붙이는 것이 맞다. 독립적인 탈출 테스트와 오버헤드 수치가 나온 뒤 프로덕션 도입을 다시 검토하라.

자주 묻는 질문

Cordium은 무엇이고 누가 만들었나요?

Cordium은 Octelium Labs, LLC가 만든 무료 오픈소스(Apache-2.0) 셀프 호스팅 샌드박스 플랫폼으로, github.com/octelium/cordium에 공개되어 있습니다. Workspaces라고 부르는 이 샌드박스는 실행 중인 프로세스에 어떤 자격 증명도 들어가지 않은 상태에서 AI 에이전트나 개발자 코드가 실제 데이터베이스, SSH 호스트, API를 다룰 수 있게 해줍니다. Octelium의 제로 트러스트 네트워크 접근(ZTNA) 엔진 위에 구성되어 있으며, 최신 릴리스는 2026년 6월 6일자 v0.12.7입니다 .

Cordium은 어떻게 자격 증명이 AI 프로세스에 들어가지 않게 하나요?

Cordium은 원본 비밀값을 Octelium의 ID 인식 프록시에 보관하고, 요청별 권한 확인을 통과한 뒤에만 프로토콜 계층에서 주입합니다. Workspace 자체에는 ID 증명만 있을 뿐, 비밀번호, API 키, SSH 개인 키, kubeconfig는 절대 보관되지 않습니다. 권한 부여는 CEL(Common Expression Language)과 OPA(Open Policy Agent)로 정책 코드처럼 작성한 속성 기반 접근 제어(ABAC)로 실행되며, 기본적으로 상시 권한이 없도록 강제합니다 . 의도한 효과는 명확합니다. 침해되었거나 프롬프트 인젝션을 당한 에이전트도 자신이 사용하는 자격 증명을 볼 수 없습니다.

Cordium Workspaces는 어떤 인프라에 접근할 수 있나요?

Workspaces는 데이터베이스, SSH 서버, 내부 HTTP API, Kubernetes 클러스터, mTLS로 보호되는 서비스 등 Octelium 데이터 플레인이 프록시할 수 있는 모든 대상에 접근할 수 있습니다 . 각 연결은 고정된 사전 권한 부여가 아니라 L7 인식 ABAC 정책으로 요청마다 통제되며, 모든 요청은 OpenTelemetry 네이티브의 ID 기반 구조화 가시성으로 감사되어 SIEM과 로그 관리용 OTLP 수신기로 내보낼 수 있습니다. Workspace 자체에는 브라우저 터미널, SSH, CLI, gRPC API를 통해 접근합니다.

Cordium은 E2B나 Daytona와 어떻게 다른가요?

E2B와 Daytona는 일반적인 방식을 따릅니다. 자격 증명을 환경 변수, 키 파일, `.env` 마운트 형태로 샌드박스 환경에 주입하기 때문에 에이전트 프로세스가 이를 읽을 수 있습니다. Cordium은 이 방식을 바꿔 자격 증명을 프록시에 보관하고 프로토콜 계층에서 주입하므로, 프로세스 환경에는 절대 도달하지 않습니다 . 기능적으로 에이전트는 여전히 데이터베이스에 질의하거나 SSH 세션을 엽니다. 차이는 비밀값이 물리적으로 게이트웨이에 머물고, 요청별 권한 부여와 전체 감사가 함께 적용된다는 점입니다.

Cordium을 프로덕션에 써도 되나요?

신중하게 보면 아직은 아닙니다. 2026년 6월 기준 Cordium은 v0.12.7이며 GitHub 스타는 약 42개이고, 검토한 출처에서는 독립적인 보안 평가를 확인할 수 없습니다 . 이 아키텍처는 OWASP의 LLM01:2025 최소 권한 지침과 잘 맞습니다. LLM Applications 2025 Top 10은 2024년 11월 17일에 공개되었습니다 . 비밀값을 노출하지 않는 메커니즘도 원칙적으로 타당하지만, 성숙도는 아직 초기 단계입니다. 중요하지 않은 인프라에서 파일럿으로 검증하고, 외부 감사와 탈출 테스트 결과가 나오기 전까지는 비밀값 미노출 보장을 공급업체가 제시한 주장으로 다루는 편이 좋습니다.