Formal이 클라우드 코딩 에이전트에 OIDC로 읽기 전용 운영 접근을 연다

Hacker News4일 전조회 1

시크릿을 없애는 것을 제품 철학으로 내건 보안 스타트업 Formal이 클라우드 코딩 에이전트에 운영 환경 접근 권한을 주는 방식을 공개했다. 핵심은 정적 API 키나 비밀번호를 에이전트에 심는 대신, 에이전트 플랫폼이 발급하는 OIDC 토큰으로 신원을 증명하게 하는 것이다. 회사 소속 소프트웨어 엔지니어 Aditya Saligrama가 2026년 10월 23일자 글로 정리했다.

OIDC 인증 흐름 자체는 업계 표준을 따른다. 워크로드는 실행 환경(환경변수이거나 클라우드 메타데이터 엔드포인트 호출)에서 단기 JWT를 받아 relying party에 bearer 토큰으로 제시한다. 받는 쪽은 IdP의 `.well-known/openid-configuration`에서 JWKS를 가져와 서명을 검증하고, 토큰의 클레임을 확인해 들어온 요청을 특정 머신 아이덴티티로 매핑한다. 토큰에는 보통 audience 클레임을 걸어 다른 서비스로 재사용되는 것을 막는다.

Formal은 여기에 몇 가지를 얹었다. 통합별로 CEL 조건을 지정해 조건이 참일 때만 인증이 통과되게 했고, OIDC 클레임 필드를 권한(Permissions)의 입력으로 노출해 제어 평면 API 요청 단위로 세밀한 인가 규칙을 세울 수 있게 했다. `CreateFederationToken` 엔드포인트는 원본 OIDC 클레임을 담은 단기 Connector 액세스 토큰을 돌려주므로, 워크로드가 직접 자격증명을 보관하지 않고도 Connector를 자격증명 주입 프록시처럼 쓸 수 있다. SPIFFE 워크로드도 별도 취급 없이 동작하며, SPIRE가 발급한 JWT-SVID를 검증해 SPIFFE ID를 정책과 권한의 입력으로 쓴다. Formal Endpoint와 Kubernetes Egress Agent 인증에도 같은 방식이 적용된다.

신원은 두 겹으로 다뤄진다. OIDC 통합 하나는 기본적으로 머신 사용자 하나에 대응하는데, 많은 워크로드가 자기 자신을 위해서만 움직이지는 않는다는 점을 반영해 특정 토큰 클레임을 사람 신원으로 해석하도록 선택 설정할 수 있다. 이 사람 정보는 로그와 정책 입력에 함께 등장한다. 다만 두 신원의 신뢰 수준은 다르다. 머신 신원은 Formal이 암호학적으로 검증하지만, 인간 신원은 해당 워크로드의 주장일 뿐이므로 고객이 그 시스템을 신뢰하겠다고 명시적으로 설정해야 성립한다.

이 구조는 원래 다른 용도를 위해 만들어졌다. BI 도구와 데이터 소스 사이의 DB 트래픽을 통제하는 고객들이 대표적이다. Metabase 같은 도구는 DB 하나당 자격증명 하나만 쓸 수 있지만, 고객은 로그인한 사람에 따라 서로 다른 통제를 적용하고 싶어 한다. 그래서 만든 것이 최종 사용자 신원 전파였고, 이 패턴이 팀 단위로 공유되며 Slack이나 Linear, GitHub에서 누구나 띄울 수 있는 멀티플레이어 클라우드 에이전트와 거의 그대로 맞아떨어졌다. 에이전트 플랫폼이 사람마다 별도 자격증명을 발급할 수는 없지만, 어느 세션인지, 어느 저장소에서 작업 중인지, 누가 시작했는지를 서명된 토큰으로 주장할 수는 있기 때문이다.

Formal은 자사 운영 환경에서 먼저 이 방식을 적용했다. 프로덕션 데이터베이스와 S3 버킷, 로그 클러스터 앞에 Connector를 두고 개발자 노트북에서 도는 코딩 에이전트 사용을 Formal Endpoint로 감시·통제하고 있다. 운영 테넌트의 제어 평면은 Terraform으로 관리되는데, Terraform Cloud가 제어 평면에 인증하는 방식을 장기 API 키에서 OIDC로 바꾼 것이 내부 첫 적용 사례 중 하나였다.

구체적인 효과는 제품 분석 작업에서 드러난다. 운영 DB 일부는 분석용 DB로 복제되는데, 신규 제품 객체의 도입률을 재려면 실제 고객의 DB 레코드까지 봐야 한다. 예전에는 엔지니어가 SQL을 직접 짜서 돌리고 결과를 CSV로 내려 에이전트 컨텍스트에 붙여넣는 수작업이 필요했다. SQL 작성과 결과 해석은 에이전트가 더 잘하지만 안전하게 권한을 줄 방법이 없었기 때문이다. OIDC가 들어오면서 에이전트 세션 자체를 하나의 신원으로 취급할 수 있게 됐고, 에이전트가 사람 소유자에게 운영 DB 단기 접근 승인을 요청하는 흐름을 만들었다.

개발자 입장에서 달라지는 것은 권한 부여의 단위다. 저장소나 CI 파이프라인에 장기 키를 심는 대신, 어느 에이전트가 어느 저장소에서 누구의 요청으로 움직이는지를 정책 조건으로 삼아 읽기 전용 접근을 열어줄 수 있다. 접근 기록은 세션과 실행자 단위로 남으므로 사후 감사도 쉬워진다.

주의할 전제도 분명하다. 사람 신원은 암호학적으로 증명되는 값이 아니라 에이전트 플랫폼의 주장이므로, 그 플랫폼을 신뢰하도록 설정하는 순간 그 주장의 정확성에 의존하게 된다. 또한 이 글이 다루는 사례는 운영 데이터에 대한 통제된 읽기 접근 쪽에 무게가 실려 있고, 승인 요청에서 실제 권한 발급까지 이어지는 세부 절차는 원문에서 완전히 설명되지 않는다.