2026년 7월 27일, curl 유지 관리자인 Daniel Stenberg는 RFC 9421, HTTP 메시지 서명 (HTTP Message Signatures)에 대한 curl의 새롭게 병합된 실험적 지원에 대해 글을 작성했습니다. 이는 HTTP 요청 또는 응답의 선택된 구성 요소를 암호학적으로 서명하기 위한 IETF 표준입니다. 이 기능은 기본적으로 비활성화되어 있으며, 명시적인 빌드 타임 플래그(build-time flag) 뒤에 위치하며, 다가오는 curl 8.22.0에서도 여전히 실험적인 상태로 유지됩니다. Stenberg는 이것이 프로덕션(production) 환경에 준비되지 않았음을 명시했습니다.

그러한 주의는 새로운 암호 프로토콜 작업에 있어 올바른 태도이며, 이 표준은 어쨌든 진지하게 받아들일 가치가 있습니다. 왜냐하면 이 표준은 실제적인 질문에 답하기 때문입니다: 수신자가 관련 컨텍스트에 대해 신뢰하는 키 자료(key material)를 사용하여, 수신된 메시지가 포함된 구성 요소와 관련하여 서명된 것과 의미론적으로 동일한지 확인할 수 있는가?

저는 "서명됨(signed)"이라는 말이 쉽게 "승인됨(approved)"으로 들릴 수 있기 때문에 명세서를 면밀히 읽었습니다. RFC 9421은 더 좁은 메시지 계층(message-layer)의 주장을 합니다.

실제로 확립되는 것

RFC 9421은 송신자가 선택된 메시지 구성 요소인 메서드(method), 경로(path), 특정 헤더(headers), 그리고 콘텐츠 다이제스트(content digest)를 포함하고, 합의된 서명 알고리즘을 사용하여 이를 created 및 keyid와 같은 서명 파라미터에 바인딩할 수 있도록 합니다. 수신자가 이를 검증할 때, 다음 두 가지가 확립됩니다:

• 서명 또는 MAC(Message Authentication Code)이 해당 컨텍스트에 대해 검증자가 신뢰하는 키 자료 하에서 유효함
• 수신된 메시지가 포함된 구성 요소와 관련하여 서명된 메시지와 의미론적으로 동일함

그게 전부입니다. 해당 키를 특정 서비스, 조직 또는 개인에 바인딩(Binding)하는 작업은 표준의
_외부_에서 이루어집니다. — RFC 9421 §3.2는 검증자가 컨텍스트 내에서 키 자료의 신뢰성을 결정할 것을 명시적으로 요구하며, 이 표준은 둘 이상의 당사자가 동일한 공유 비밀(shared secret)을 보유할 수 있는 HMAC를 지원합니다. "서명은 누가 보냈는지를 증명한다"라는 말은 실제 명세(spec)가 규정하는 것보다 더 강력한 주장입니다.

또한,
커버된(covered)
구성 요소들만 서명되기 때문에, 서명되지 않은 필드 — 그리고 커버된 필드의 일부 변환된 형태 — 는 서명을 무효화하지 않고도 변경될 수 있습니다. 이 보증은 포괄적인 것이 아니라 범위가 지정(scoped)되어 있습니다.

범위가 지정되어 있기는 하지만, 이는 여전히 실질적인 격차를 해소합니다. 서비스 간 트래픽(service-to-service traffic), 웹훅(webhook) 전달, 그리고 TLS를 종료하는 중개자(intermediaries)를 통과하는 아키텍처의 경우, RFC 9421은 단일 전송 연결을 넘어 선택된 구성 요소에 대한 무결성(integrity)과 인증(authenticity)을 보존할 수 있습니다. 그 부분은 진정한 진전입니다.

확립되지 않는 것

검증된 서명이, 해당 키 보유자가 최근에 보낸 다른 모든 사항을 고려했을 때, 바로 이 시점에 이 특정 요청을 보낼
권한(authorized)
이 있었다는 것을 확립해주지는 않습니다. 그럴 수 없습니다. 검증은 한 번에 하나의 메시지에 대해 이루어지며, 권한 부여(authorization)는 주체(principal)의 상태, 현재 범위, 그리고 종종 그 이력에 관한 문제이기 때문입니다. 이 중 그 어떤 것도 단일 서명된 메시지의 바이트 내에 존재하지 않습니다.

실패 모드를 시뮬레이션해 보겠습니다: 어떤 서비스가 재고 수준을 읽기 위한 서명 키 (signing key)를 보유하고 있다고 가정합니다. 이 키가 유출되거나, 서비스가 침해당하거나, 혹은 운영자나 이를 오케스트레이션하는 에이전트에 의해 의도된 목적 이외의 작업을 수행하도록 요청받을 수 있습니다. 별도의 권한 부여 (authorization) 계층이 서비스의 허용된 범위 밖의 요청을 거부해야 함에도 불구하고, 모든 요청은 여전히 해당 키를 통해 암호학적으로 검증될 수 있습니다. 서명 검증 (Signature verification) 단독으로는, 별도로는 유효한 일련의 요청들이 목적을 변경했는지 또는 허용되지 않은 결과로 누적되었는지를 평가하지 못합니다. 그 확인 작업은 메시지당 한 번 발생하고 거기서 끝납니다.

표준에 대해 공정하게 말하자면, 애플리케이션이 검증 단계 상위에 상태 유지 제어 (stateful controls)를 추가하는 것을 막는 것은 아무것도 없습니다. RFC 9421은 추가적인 애플리케이션 요구 사항을 명시적으로 허용하며, 재전송 공격 방지 (replay protection)에 대해서도 논의합니다. 단지 표준 자체가 시퀀스 수준의 평가 (sequence-level evaluation)를 제공하지 않을 뿐이며, 그것은 다른 계층의 역할입니다.

개별적으로 유효하고 개별적으로 서명된 10개의 요청이 모여 데이터 유출 (data exfiltration), 권한 상승 (privilege-escalation) 체인, 또는 단일 요청으로는 절대 탐지되지 않을 자원 고갈 (resource-exhaustion) 공격을 구성할 수 있습니다. 서명 계층은 암호학적으로 유효한 10개의 메시지를 볼 뿐입니다. 그 위에는 이 10개의 메시지가 합쳐졌을 때 실제로 무엇을 했는지 묻는 상위 계층이 없습니다.

서명은 대상이 되는 구성 요소들을 인증합니다. 그것은 행위 — 또는 시퀀스 — 를 승인하는 것이 아닙니다.

동일한 경계, 한 단계 아래

이는 "Authorized but Composed" (DOI 10.5281/zenodo.21400261)의 논거 및 Hugging Face의 2026년 7월 보안 사고 공개에 관한 현장 노트에서 다룬 것과 동일한 구조적 경계입니다. 다만, 에이전트 결정 계층(agent-decision layer)에서 메시지 검증 계층(message-verification layer)으로 한 단계 내려왔을 뿐입니다. 해당 공개 내용은 시퀀스 재구성(sequence reconstruction)이 왜 중요한지에 대한 구체적인 사례를 제공합니다. 조사관들은 자율 캠페인이 전체적으로 무엇을 수행했는지 이해하기 위해 17,000개 이상의 기록된 이벤트를 분석했습니다. 이 공개 내용은 해당 이벤트들이 개별적으로 승인되었거나 정책 게이트(policy gates)를 통과했음을 입증하지는 않습니다. 대신 더 좁은 관점의 핵심을 보여줍니다. 즉, 자동화된 캠페인의 의미는 그 동작들이 하나의 시퀀스로 상관관계가 형성될 때 비로소 나타날 수 있다는 점입니다. 여기서 동일한 형태가 기계적으로 나타납니다. 메시지별 서명 확인(per-message signature check)은 개별적으로 유효한 요청들이 끊김 없이 이어지는 과정을 검증할 수 있지만, 그 요청들이 모여 아무도 허용하지 않았을 무언가를 구성하더라도 이를 막지 못합니다. 서명 검증(signature verification) 역시 시퀀스를 평가하지 않기 때문입니다.

에이전트 간(agent-to-agent) 및 에이전트 대 API(agent-to-API) 트래픽이 서명된 HTTP 요청으로 래핑되는 경우가 많아짐에 따라 — 에이전트 인력이 확장됨에 따라 가속화될 것으로 예상되는 진정으로 긍정적인 추세입니다 — 이러한 격차는 줄어들기는커녕 더욱 중대한 문제가 됩니다. 자신의 도구 호출(tool calls)을 직접 수행하는 자율 에이전트가 각 호출을 자신의 서비스 키로 성실히 서명한다면, 그 에이전트의 개별 요청은 모두 깔끔하게 검증되겠지만, 그 _누적된 궤적(accumulated trajectory)_은 아무도 승인하지 않은 곳으로 향하게 될 것입니다.

시사점 (The takeaway)

어떤 신뢰할 수 있는 키 자료(key material)가 서명 또는 MAC(Message Authentication Code)을 검증하는지, 그리고 포함된 구성 요소들이 여전히 검증 가능한지는 RFC 9421이 잘 답해주는 메시지 계층(message-layer)의 질문입니다. 요청 자체 — 또는 그 요청이 속한 시퀀스(sequence) — 가 실제로 권한 부여(authorized)되었는지 여부는 결정 계층(decision-layer)의 질문이며, 어떤 서명 체계(signature scheme)도 이를 해결할 수 없습니다. 왜냐하면 서명 체계는 애초에 그런 용도로 설계되지 않았기 때문입니다. 이 두 계층은 결합됩니다. 신뢰할 수 있는 키 하에서 포함된 구성 요소들을 검증한 다음, 해당 키 자료와 관련된 인증된 동작들이 사용 사례가 요구하는 세션(session)이나 주체(principal)를 가로질러 시간이 지남에 따라 어떻게 합산되는지를 평가해야 합니다. 두 번째 계층을 건너뛴다면, 매우 잘 인증된 사각지대(blind spot)를 마주하게 될 것입니다.

이 주장을 정확히 하자면, 여기서 과도하게 확장하는 것은 서명 전용 아키텍처가 저지르는 바로 그 실수가 될 것이기 때문입니다. 이것은 RFC 9421에 반대하는 논거가 아니며, curl의 구현이 안전하지 않거나 시기상조라는 주장도 아닙니다. 새로운 암호화 프로토콜 작업에 대해 운영 환경 준비성(production-readiness)을 경고한 Stenberg의 신중함은 올바른 판단입니다. 논거는 더 좁습니다. 메시지 계층의 검증은 권한 부여를 위해 필요하지만 충분하지는 않다는 것입니다. 검증기(verifier) 상단에 무언가가 위치하여, 해당 키 자료와 관련된 인증된 시퀀스가 무엇으로 구성되었는지 물어야 합니다. 이것은 결정 거버넌스(decision-governance)의 문제이지, 암호학(cryptography)의 문제가 아닙니다.

이 논거 뒤에 있는 구성 엔진(composition engine)은 오픈 소스입니다: pip install constitutional-agent. 만약 서명된 서비스 간(service-to-service) 또는 에이전트 대 API(agent-to-API) 트래픽을 구축하고 있으며, 서명 계층과 비교하여 세션 간 격차(cross-session gap)가 어디에 위치하는지 확인하고 싶다면, 무료 Governance Stress Test를 시도하거나 Enterprise Agent Architecture 프레임워크를 읽어보세요. 이 논거가 어디에서 무너진다고 생각하는지 알려주세요.

Composition preprint: [doi.org/10.5281/zenodo.21400261] · Enterprise Agent Architecture: [doi.org/10.5281/zenodo.21105314]