지난 30년 동안 수학적 확률은 공격자에게 유리했습니다. 공격자는 단 하나의 버그만 있으면 됩니다. 반면 당신은 지친 SOC(Security Operations Center)와 더 적은 예산으로 모든 것을 영원히 방어해야 합니다. 이제 양측 모두 AI 승수(AI multiplier)를 얻게 되었으며, 유일하게 중요한 질문은 누가 먼저, 그리고 더 크게 이를 확보하느냐입니다. OpenAI의 해답은 훔칠 가치가 있는 디자인 패턴입니다. 프롬프트(Prompt)에서 의도를 읽는 것을 멈추고, 사용자로부터 의도를 읽으십시오.

문제점: 가드레일(Guardrails)은 의도가 아닌 형태를 기준으로 결정된다

이는 프런티어 모델(Frontier model)을 상대로 방어 작업을 수행하는 사람이라면 누구나 이미 알고 있는 실패 모드입니다. 당신이 패치가 유효한지 확인하기 위해 발표된 CVE로부터 개념 증명(PoC, Proof-of-Concept)을 구축하도록 모델에 요청한다고 가정해 봅시다. 당신은 해당 시스템의 소유자이며, 수정 사항을 확인하고 있습니다. 하지만 모델은 익스플로잇(Exploit) 작성을 도와줄 수 없다고 말합니다.

모델은 당신의 진심을 읽는 것이 아니라, 당신의 토큰(Token)을 읽고 있기 때문입니다. "이 CVE에 대한 PoC를 작성하라"는 토큰 시퀀스는 당신이 수정을 확인하는 방어자인지, 아니면 무기를 만드는 공격자인지에 관계없이 동일합니다. 분류기(Classifier)는 요청의 형태를 보고, 그 형태는 동일합니다.

따라서 해결책은 더 똑똑한 분류기를 만드는 것이 아닙니다. 더 똑똑한 분류기라 할지라도 여전히 프롬프트에만 의존할 수밖에 없으며, 프롬프트에는 의도가 담겨 있지 않습니다. 해결책은 신뢰 신호(Trust signal)를 프롬프트가 아닌 인증된 주체(Authenticated principal)로 옮기는 것입니다.

레이어 1: 신뢰 신호는 요청이 아닌 신원에 존재한다

OpenAI의 사이버를 위한 신뢰할 수 있는 액세스(Trusted Access for Cyber) 프로그램의 핵심적인 움직임은 신원 및 신뢰 프레임워크(Identity-and-trust framework)입니다. 당신은 사람을 검증하고, 해당 계정에 검증된 신뢰 신호를 부여하며, 해당 주체에 대한 거부 경계(Refusal boundary)를 이동시킵니다. 동일한 모델이지만, 당신이 누구임을 증명했느냐에 따라 마찰(Friction)의 정도가 달라집니다.

아키텍처 측면에서 이는 API 경로 대신 모델 동작에 적용된 클레임 기반 권한 부여(Claims-based authorization)에 불과합니다. OAuth 토큰의 스코프(Scope)와 유사하게 생각하면 되는데, 다만 그 스코프가 어떤 엔드포인트에 접근할 수 있는지를 제어하는 것이 아니라 안전 계층(Safety layer)이 얼마나 허용적인지를 제어한다는 점이 다릅니다.

액세스 레벨          거부 태세(Refusal posture)    대상
GPT-5.5 (기본값)     표준 보호 조치(Standard safeguards)    일반 용도

...

이 시스템이 작동하는 핵심은 누군가가 탈옥(jailbreak) 방법을 찾아냈기 때문이 아니라, 신뢰(trust)가 이동함에 따라 경계선이 함께 이동한다는 점입니다. 동일한 기본 엔진을 사용하되, 주체(principal)가 보유한 권한(claim)에 따라 세 가지 동작이 제어됩니다.

Layer 2: 높은 신뢰 계층을 피싱 방지 인증(phishing-resistant auth)에 결합하기

여기서 설계 과정에서 필연적으로 발생하는 주의사항이 있습니다. 인증된 계정이 더 낮은 거부 경계(refusal boundary)를 갖게 되는 순간, 해당 계정은 가장 가치 있는 핵심 자산(crown jewel)이 됩니다. 다른 자격 증명은 거절할 만한 요청에 대해 '예'라고 답한다는 점 때문에, 바로 그 점이 해당 자격 증명을 훔칠 가치가 있게 만듭니다.

OpenAI의 해답이자 올바른 해결책은, 가장 허용 범위가 넓은 계층(most permissive tier)에 피싱 방지 인증(phishing-resistant authentication)을 의무화하는 것입니다. 실질적으로 이는 FIDO2/WebAuthn을 의미하며, 여기서는 인증기(authenticator)가 오리진(origin)에 결합되어 있어 피싱할 수 있는 공유 비밀(shared secret)이 존재하지 않습니다. 사이버 허용 모델(cyber-permissive model)의 관문을 통과하는 자격 증명에 있어서, 재사용 가능한 비밀번호나 운영자가 소리 내어 읽도록 속임수를 쓸 수 있는 TOTP 코드는 충분하지 않습니다.

만약 직접 이와 유사한 시스템을 설계하고 있다면, 규칙은 간단합니다. 인증의 강도는 해당 인증이 해제하는 계층의 허용 범위(permissiveness)에 맞춰 확장되어야 합니다. 마찰이 적은 읽기 전용 계층(low-friction read-only tier)은 일반적인 SSO를 사용할 수 있습니다. 하지만 실시간 타겟 검증 체인(live-target validation chains)을 구축하는 계층은 하드웨어 기반의 오리진 결합형 인증기(hardware-backed, origin-bound authenticator)를 사용해야 하며, 그렇지 않다면 출시해서는 안 됩니다.

[default]   "CVE-XXXX에 대한 PoC를 생성해줘"  -> 플래그 지정(flagged), 리다이렉트(redirected)

[TAC]       동일한 요청, 검증된 계정 -> PoC 생성
...

Layer 3: 승인한 후에도 모니터링을 지속하기

거부 경계(refusal boundary)를 낮추는 것이 불을 끄는 것(보안을 해제하는 것)과 같지는 않습니다. 더 많은 요청을 허용하는 계층은 더 많은 것을 감시해야 합니다. 전방에서는 더 강력한 계정 검증을, 후방에서는 오용 모니터링(misuse monitoring)을 수행해야 합니다.

이것이 중요한 이유는 권한(lane)을 부여하는 순간 위협 모델(threat model)이 변화하기 때문입니다. 승인된 레드팀(red team) 작업을 수행 중인 검증된 계정과, 방금 탈취된 검증된 계정은 요청이 발생하는 시점에는 동일해 보입니다. 둘 다 올바른 클레임(claim)을 보유하고 있기 때문입니다. 이 둘을 구분하는 것은 행동(behavioral) 측면이므로, 모니터링 또한 행동 기반이어야 합니다. 높은 권한을 가진 요청의 빈도, 타겟 범위(target scope)의 이탈, 계정에 설정된 워크플로우(workflow)와 일치하지 않는 요청 등이 그 예입니다.

여기서의 디자인 패턴은 신뢰할 수 있는 계층(trusted tier) 자체에 적용되는 '침해 가정(assume-breach)' 모델입니다. 여러분이 그들을 검증하고 무장시켰더라도 여전히 계측(instrument)해야 합니다. 왜냐하면 방금 여러분이 가치 있게 만든 자격 증명(credential)이야말로 누군가가 가장 필사적으로 훔치려 할 자격 증명이기 때문입니다.

주의사항 / 예외 사례 (Gotchas / edge cases)

이러한 방향으로 구축할 때 발목을 잡을 수 있는 몇 가지 사항이 있습니다.

검증(vetting)이 승부의 핵심입니다. 신원 기반 거부 계층(identity-gated permission system)의 강도는 신원을 발급하는 프로세스의 강도와 정확히 일치합니다. 검증이 허술하다면, 유입 과정을 속이는 누구에게나 빠른 통로(fast lane)를 만들어준 셈이 됩니다.

계층 확산(Tier sprawl)은 실제로 발생합니다. 3개의 계층은 파악하기 쉽습니다. 하지만 범위가 중첩된 12개의 계층은 누구도 논리적으로 추론할 수 없는 '권한 수프(permission soup)'가 되며, 계층 사이의 간극이 공격 표면(attack surface)이 됩니다.

허용적(Permissive)이라는 것이 더 똑똑하다는 의미는 아닙니다. OpenAI는 첫 번째 GPT-5.5-Cyber 프리뷰가 순수 능력(raw capability) 면에서 베이스 모델을 능가하도록 설계된 것이 아님을 명시했습니다. 이는 더 강력해지기 위해서가 아니라, 더 허용적으로 작동하도록 훈련된 것입니다. 이 둘을 혼동하면, 단순히 거부를 멈췄다는 이유만으로 높은 계층의 출력을 과도하게 신뢰하게 될 것입니다.

마무리 (Wrapping up)

이 패턴은 이식 가능합니다. 동일한 요청이 한 주체(principal)에게는 정당하고 다른 주체에게는 악의적인, 이중 용도(dual-use) 판단을 내려야 하는 모든 시스템은 요청에서 의도를 점치려 노력하는 대신, 주체에 연결된 검증된 클레임(verified claim)을 기반으로 게이팅(gating)을 시작할 수 있습니다. 인간을 검증하십시오. 높은 계층을 하드웨어 인증(hardware auth)에 결합하십시오. 권한을 부여한 후에는 모니터링하십시오. 이것은 보도 자료가 아니라, 실제로 배포 가능한 아키텍처입니다.

저는 우리가 보통 반대 방향에서 다루는 다회차 경계 침식 공격 (multi-turn boundary-erosion attacks)에 이것이 어떻게 매핑되는지를 포함하여, 전체적인 분석 내용을 ToxSec Substack에 작성했습니다.

ToxSec는 AWS와 NSA에서 실무 경험을 쌓은 미 해병대 (USMC) 베테랑이자 보안 엔지니어에 의해 운영됩니다. 그는 CISSP 인증을 보유하고 있으며, 사이버 보안 공학 (Cybersecurity Engineering) 석사 학위를 가지고 있습니다. 그는 보안 취약점 (security vulnerabilities), 공격 체인 (attack chains), 그리고 방어자가 실제로 이해해야 하는 도구들을 다룹니다.