당신의 에이전트는 신뢰의 문제가 아니라 권한의 문제를 가지고 있습니다

하나의 에이전트가 다른 에이전트를 대신하여 행동하게 할 때 — 작업을 수락하거나, 도구(tool)를 호출하거나, 잔액을 소비하거나, 제3자에게 업무를 넘길 때 — 당신이 본능적으로 던지는 질문은 이것을 신뢰할 수 있는가? 입니다. 그 질문에는 좋은 답이 없습니다. 검사(inspection)를 통해서는 신뢰에 도달할 수 없습니다. 잘못된 행동을 하려는 유능한 시스템은 당신이 실행할 수 있는 모든 검사를 통과할 것이며, 선량한 시스템이라 할지라도 당신이 상상하지 못한 입력값을 처음 만나는 순간 당신을 놀라게 할 것입니다. 검사를 통한 신뢰(Trust-by-inspection)는 제자리걸음일 뿐입니다.

답을 얻을 수 있는 질문은 다른 질문입니다: 만약 내가 이 대상을 신뢰한 것이 잘못된 것으로 판명된다면, 이 대상이 무엇을 할 수 있는가? 이것은 문제의 프레임을 검사(inspection)에서 경계 설정(bounding)으로 재구성합니다. 에이전트의 의도를 인증하려고 노력하는 대신, 그 폭발 반경(blast radius)의 크기를 측정하기 시작하는 것입니다. 검증(Vetting)은 당신이 부여하는 권한(grant)의 속성이 되며, 권한을 부여받는 대상의 속성이 아니게 됩니다.

이것이 올바른 방향이며, 이 방향으로 나아가는 거의 모든 사람은 한 단계 일찍 멈춰버립니다.

범위 설정(Scoping)은 결승선처럼 느껴집니다

"폭발 반경을 제한하라"는 질문에 대한 표준적인 답변은 권한의 범위를 설정(scope)하는 것입니다. 대리인(delegate)에게 전체 권한을 넘기지 마십시오. 대신 해당 작업을 수행하는 데 필요한 가장 좁은 범위의 능력(capability)만을 부여하십시오. 계정 전체가 아닌 단 하나의 버킷(bucket)만 읽을 수 있는 토큰(token)을 부여하십시오. 국고를 이동하는 것이 아니라 단 하나의 송장(invoice)만 결제할 수 있는 권한을 부여하십시오. 만약 대리인이 침해되더라도, 그 피해는 대리인이 무엇을 하기로 결정했는지와 상관없이 당신이 설정한 범위 내로 제한됩니다.

권한을 그것이 발행된 특정 요청(request)에 결합(binding)함으로써 이를 더욱 강화할 수 있습니다. 요청에 결합되지 않은 범위 제한 토큰은 그저 수명이 짧은 마스터키(skeleton key)일 뿐입니다. 소유자는 이를 다른 대상에 대해 재사용(replay)하거나, 당신이 허가하지 않은 용도로 사용할 누군가에게 옆으로 넘겨줄 수 있습니다. 권한을 요청의 해시(hash) — 즉, 이 동작, 이 인자(arguments), 이 대상 — 에 결합하십시오. 그러면 "B가 토큰을 보유하고 있다"는 문장은 마침내 "B가 _이 한 가지 일_을 할 수 있는 권한을 보유하고 있다"로 바뀝니다. 동일한 재시도가 재사용(replay)되지 않도록 논스(nonce)를 추가하면, 신선도(freshness) 문제의 구멍도 메워집니다.

이 시점에서 설계는 완성된 것처럼 느껴집니다. 모든 권한 부여(grant)는 범위가 좁고, 요청에 묶여 있으며, 신선하고(fresh), 루트 권한자인 당신의 서명으로 거슬러 올라갑니다. 이러한 권한 부여 중 하나를 받는 리소스(resource)는 이를 로컬에서 확인할 수 있습니다. 이 권한 부여가 내 앞에 있는 요청을 커버하는가? 그리고 서명 체인이 내가 실제로 신뢰하는 주체(principal)에서 끝나는가? 두 조건이 모두 충족되면 승인합니다. 하나라도 실패하면 거부합니다. 어떤 중간자(middleman)도 신뢰의 싱크(trust sink)가 될 수 없습니다. 리소스는 로컬에서 확인된 _당신_을 신뢰하며, 중간에 있는 위임 서비스(delegation service)는 단지 발행 인터페이스(minting interface)일 뿐입니다.

깔끔한 모델입니다. 그리고 가장 완벽해 보이는 바로 그 지점에 틈이 존재합니다.

도달 가능성(Reachability)은 감쇠(attenuation)가 아닙니다

로컬 검사가 실제로 검증하는 속성은 다음과 같습니다. 당신의 서명에 뿌리를 둔 어떤 유효한 권한 부여 체인이 이 요청을 승인한다. 이를 **도달 가능성 (reachability)**이라고 부릅시다. 즉, 해당 동작이 정당한 단계들을 거쳐 당신의 권한으로부터 도달 가능하다는 것입니다.

당신이 구매했다고 생각하는 속성은 다음과 같습니다. 행사된 권한이 해당 작업을 수행할 수 있는 가장 좁은 권한이었다는 것, 즉 당신이 신중하게 범위를 지정한 감쇠된(attenuated) 권한이라는 것입니다. 이를 **감쇠 (attenuation)**라고 부릅시다.

이 두 가지는 동일한 속성이 아니며, 주체(principal)가 당신에게 뿌리를 둔 두 개 이상의 권한 부여를 보유하는 순간 분리됩니다.

차근차근 따라가 봅시다. 당신은 B에게 한 가지 작업을 위한 좁은 범위의 권한 부여를 위임합니다. 이와 별개로 — 지난주에, 관련 없는 다른 작업을 위해 — 당신은 B에게 더 넓은 범위의 권한 부여에도 서명했습니다. 둘 다 실제 권한입니다. 둘 다 당신에게 거슬러 올라갑니다. 이제 B는 좁은 권한 부여가 커버하도록 의도되지 않은 무언가를 하려고 합니다. B는 무엇인가를 위조하거나 범위를 탈출할 필요가 없습니다. 그저 더 넓은 권한 부여를 제시할 뿐입니다. 그 권한 부여는 요청을 커버합니다. 그것은 당신의 서명으로 거슬러 올라갑니다. 모든 단계의 로컬 검사는 깔끔하게 통과합니다. 그리고 당신이 B가 사용하고 있다고 생각했던 좁고 감쇠된 권한 부여는 검토조차 되지 않습니다. 그것은 두 개의 문 중 하나였을 뿐이며, B는 다른 문으로 걸어 들어간 것입니다.

"요청을 충족하고 A로 추적된다"는 그 어떤 조건도 이를 잡아낼 수 없습니다. 왜냐하면 해당 검증 과정에서 거짓(false)인 것이 아무것도 없기 때문입니다. 리소스(Resource)는 하나의 체인을 보고 이를 검증합니다. 리소스가 볼 수 없는 것은 B가 가진 권한 부여(Grants)의 전체 지갑, 즉 대안적인 경로들입니다. 당신의 권한 감쇠(Attenuating) 단계는 그것이 해당 동작으로 가는 유일한 경로 위에 있을 때만 지지력을 가집니다. 더 넓은 범위의 형제 권한 부여(Sibling grant)가 존재하는 즉시, 좁은 범위의 권한은 장식에 불과해집니다. 그것은 아무것도 제한하지 못하는 제약 조건이 됩니다. 왜냐하면 그것이 막으려 했던 대상이 우회할 수 있는 다른 길을 가지고 있기 때문입니다.

이는 코드가 어떻게 작동하든 상관없이 통과되는 죽은 단위 테스트(Dead unit test)와 같은 형태입니다. 권한 부여는 제어 장치처럼 보입니다. 모든 검증을 통과합니다. 하지만 그것을 제거해도 아무것도 변하지 않습니다. 그것이 차단하려 했던 권한에 도달할 수 있는 경로가 여전히 존재하기 때문입니다. 우회할 수 있는 경계(Bound)는 경계가 아닙니다.

경계 설정(Bounding)은 대안 경로를 차단하는 것이다

이 문제를 도달 가능성 대 감쇠(Reachability-vs-attenuation)의 관점으로 바라보게 되면, 해결책은 더 이상 "범위를 더 좁게 설정하기(Scope harder)"가 아니게 됩니다. 권한 부여의 범위를 더 좁게 설정하는 것은 그 옆에 더 넓은 범위의 권한 부여가 놓여 있다면 아무런 효과가 없기 때문입니다. 대신 해결책은 "제약 조건이 유일한 경로가 되도록 만들기"가 됩니다.

세 가지 조치가 이를 가능하게 합니다.

문맥(Context) 간에 권한 부여가 대체 불가능하도록 만드십시오. B가 하나의 권한 부여를 다른 것으로 교체할 수 있었던 이유는, 권한 부여가 요청을 충족하고 당신에게 추적되는 한 서로 교체 가능했기 때문입니다. 이를 깨뜨려야 합니다. 각 권한 부여가 생성되는 순간, 그것을 위임 문맥(Delegation context) — 즉 목적, 의도된 대상, 속해 있는 작업 — 에 결속시키십시오. 지난주 작업을 위해 발행된 권한 부여는 이번 요청을 단순히 충족하지 못하게 됩니다. 이는 만료되었기 때문이 아니라, 이 문에 맞지 않는 잘못된 열쇠이기 때문입니다. 이렇게 하면 대체(Substitution)가 불가능해지며, 여러 경로가 당신이 의도했던 단 하나의 경로로 수렴됩니다.

한계(Ceiling)를 생산자(Producer)가 아닌 소비자(Consumer) 측에 설정하십시오. 위임 대상(Delegate)이 스스로의 범위(Scope)를 선언하게 만드는 것, 즉 "이것이 내가 필요한 전부입니다"라고 말하는 명세(Manifest)를 허용하고 싶은 유혹이 생길 수 있습니다. 하지만 스스로 선언된 경계는 경계를 제한받는 당사자가 자신의 한계를 설명하는 것에 불과하며, 그 선언을 정직하게 확장하는 것은 그대로 통과되어 버립니다. 만약 위임 대상의 명세가 다음 버전에서 셸(Shell) 도구를 포함하도록 확장된다면, "선언된 것만 호출하라"고 강제하는 런타임(Runtime)은 그 셸을 충실히 허용할 것입니다. 권한 상승이 몰래 이루어진 것이 아니라, "선언"되었기 때문입니다. 지속 가능한 한계란 위임자(Delegator)가 역할(Role)에 대해 설정하는 것입니다. 즉, "데이터 분석(Data-analysis)" 역할을 수행하는 무엇이든 만질 수 있는 범위를 당신의 의도에 따라 고정하고, 위임 대상의 어떤 버전이 무엇을 요구하느냐와는 무관하게 유지하는 것입니다. 그렇게 되면 셸에 대한 요청은 거부됩니다. 위임 대상이 자신을 어떻게 설명하든, 해당 역할에는 애초에 그 권한이 없었기 때문입니다.

경계를 이름이 아닌 바이트(Bytes)에 고정하십시오. "이 승인이 완료되었습니다"라는 사실을 수정 후에도 살아남는 식별자(Identifier)에 연결하지 말고, 승인된 내용 그 자체의 콘텐츠 해시(Content Hash) — 즉 요청, 범위, 컨텍스트 — 에 연결하십시오. 이제 아주 작은 변경이라도 발생하면 일치 여부가 깨지며, 시스템은 안전하게 차단(Fail closed)됩니다. 재검증(Re-validation)은 매 업데이트마다 기억해서 수행해야 하는 작업이 아니라 자동으로 이루어집니다. 변경된 승인은 이미 다른 승인이기 때문에, 다시 승인을 얻어야만 하기 때문입니다.

원칙

위임된 권한은 해당 동작에 도달하는 모든 경로가 제약 조건(Constraint)을 통과할 때만 경계가 설정됩니다. 승인 범위가 좁아 보인다고 해서 설정되는 것이 아닙니다. 그 권한이 당신으로부터 거슬러 올라간다고 해서 설정되는 것도 아닙니다. 각 단계(Hop)가 로컬에서 확인된다고 해서 설정되는 것도 아닙니다. 그것들은 모두 단일 체인(Single chain)의 속성일 뿐이며, 경계 설정은 위임 대상이 제시할 수 있는 체인들의 **전체 그래프(Whole graph)**에 대한 속성입니다.

그렇기 때문에 "이 에이전트를 신뢰할 수 있는가"는 잘못된 질문이며, "내가 틀렸을 때 이 에이전트가 무엇을 할 수 있는가"가 올바른 질문입니다. 하지만 이는 두 번째 질문을 끝까지 밀고 나갔을 때만 유효합니다. 폭발 반경 (Blast radius)의 크기를 측정한다는 것은 단순히 눈앞에 놓인 권한 (Grant)의 범위를 정하는 것 이상의 의미를 갖습니다. 그것은 당신의 세심한 제약 조건이 결코 닿지 않는 경로를 통해 동일한 동작에 도달할 수 있는 다른 권한, 더 느슨한 형제 권한, 대체 가능한 키 (Substitutable key), 고정되지 않은 이름 (Un-pinned name) 등이 존재하지 않음을 증명하는 것을 의미합니다. 이러한 것들을 모두 차단해야만 비로소 좁게 설정된 권한이 당신이 의도한 의미를 갖게 됩니다. 만약 하나라도 열려 있다면, 당신은 권한 (Authority)을 제한한 것이 아니라 단지 기술했을 뿐이며, 그동안 에이전트는 당신이 회수했다고 생각한 권한을 조용히 계속 유지하고 있었을 것입니다.