역량 기반 액세스 제어는 에이전트 도구 권한을 어떻게 제한하나요?

능력 기반 액세스 제어는 권한을 모든 도구 호출에 상속되는 암묵적 권한이 아니라, 리소스에 명시적으로 연결된 능력으로 만들어 에이전트의 권한을 제한합니다.

홈 서버에서는 한 에이전트가 백업 대상을 검사하고, 다른 에이전트가 하나의 서비스를 재시작하며, 세 번째 에이전트가 사진 폴더를 읽도록 하면서도 마스터 자격 증명을 공유하지 않을 수 있습니다.

능력은 권한을 특정 리소스에 연결합니다

능력 기반 액세스 제어는 객체를 식별하고 해당 객체에서 사용할 수 있는 권한을 포함하는 토큰 또는 참조로 권한을 나타냅니다.

seL4는 능력을 엔터티 또는 객체에 액세스할 수 있는 권한을 부여하는 위조 불가능한 토큰으로 설명합니다. 소유 여부는 인증 메커니즘의 일부입니다. seL4는 특정 커널 객체를 참조하는 능력을 통해 권한을 나타내며, seL4 능력 모델에서 리소스에 연결된 권한의 구체적인 예를 제공합니다.

홈 AI 에이전트의 경우 백업 도구에 전체 파일 시스템에 대한 암묵적 액세스 권한 대신 하나의 저장소에 대한 권한만 부여할 수 있습니다. 경로를 알고 있는 것만으로는 권한이 부여되지 않습니다.

소유는 암묵적 권한을 명시적 위임으로 대체합니다

기존 환경에서는 프로세스 자격 증명이나 광범위한 API 토큰을 통해 암묵적 권한이 제공되는 경우가 많습니다.

능력 시스템은 구성 요소가 실제로 보유한 참조를 통해 권한을 명시적으로 만듭니다.

seL4 capDL은 시스템의 어느 부분이 다른 부분에 대한 어떤 능력을 보유하는지 설명합니다. 이러한 분배가 액세스 제어 경계를 정의합니다. Wasmtime은 WASI 리소스를 위한 능력 중심 격리를 설명하며, Wasmtime 능력 보안 모델에서 명시적 소유가 광범위한 암묵적 액세스를 어떻게 대체할 수 있는지 보여줍니다.

따라서 사진 정리 하위 에이전트에는 가져오기 폴더에 대한 읽기 권한과 준비 영역에 대한 쓰기 권한만 부여하고, 보관 파일을 삭제할 권한은 부여하지 않을 수 있습니다.

권한은 리소스보다 더 좁게 설정할 수 있습니다

능력에는 참조된 객체에서 사용할 수 있는 작업을 제한하는 권한을 포함할 수 있습니다.

두 에이전트가 동일한 객체에 대한 능력을 보유하더라도 서로 다른 권한을 가질 수 있습니다.

seL4는 능력이 객체 참조와 허용되는 작업을 제어하는 액세스 권한을 함께 캡슐화한다고 설명합니다. Bytecode Alliance는 WASI를 능력 기반 보안을 중심으로 설명해 왔으며, WASI 능력 기반 보안에서 부여된 권한이 호스트 리소스 자체보다 더 좁을 수 있다는 개념을 뒷받침합니다.

모니터링 워크플로에는 상태를 읽을 권한만 부여하고, 유지 관리 워크플로에는 재시작 권한을 부여할 수 있습니다. 서비스는 동일하지만 사용할 수 있는 작업은 다릅니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

위임을 통해 하위 작업에 더 작은 능력을 전달할 수 있습니다

능력 시스템은 작업과 함께 권한을 전달할 수 있으므로 에이전트 분해 방식에 잘 맞습니다. 상위 에이전트는 마스터 자격 증명을 전달하는 대신 각 도우미에게 필요한 권한만 위임할 수 있습니다.

Cap'n Proto는 RPC 참조를 객체를 호출할 권한도 전달하는 참조로 모델링합니다. 참조를 전달하면 특정 능력이 전달됩니다. Cap’n Proto RPC는 객체 참조를 다른 구성 요소에 전달할 수 있는 능력으로 취급하며, Cap’n Proto 객체 능력에서 위임된 권한을 이해하는 데 유용한 모델을 제공합니다.

하나의 로그 디렉터리만 검사하도록 요청받은 도우미에는 해당 디렉터리에 대한 읽기 능력만 전달할 수 있습니다. 프롬프트에 다른 리소스가 언급되어 있더라도 요청만으로 권한을 확장할 수는 없습니다.

능력 메커니즘과 도구 범위는 서로 다른 계층입니다

도구 범위는 에이전트의 작업을 얼마나 좁게 제한할지에 대한 정책적 선택입니다.

능력 기반 액세스 제어는 해당 권한을 표현하고 강제하는 런타임 메커니즘입니다.

ZimaSpace의 홈 AI 에이전트 도구 범위 분석은 자율성이 높아질수록 작업, 리소스, 인수, 자격 증명의 범위를 좁혀야 하는 이유를 설명합니다. 현재 IETF 초안에서는 에이전트 토큰을 축소하는 작업을 통해 하위 에이전트에 위임되는 권한을 더 좁힐 수 있는 방안을 검토하고 있으며, 에이전트 토큰 축소 초안에서 위임 경계를 보여줍니다.

에이전트 로직이 실패하더라도 능력 강제는 여전히 중요합니다. ZimaSpace의 반복 도구 호출 루프 분석은 동작 실패와 권한 제한을 별개의 문제로 다뤄야 하는 이유를 보여줍니다.

취소와 레거시 API는 여전히 구현상의 경계로 남습니다

실제 시스템은 분실된 권한을 취소하고, 임시 액세스를 만료시키며, 사용자·역할 또는 전달자 토큰만 이해하는 서비스와 연동할 방법을 여전히 필요로 합니다.

seL4는 능력 파생 및 삭제 작업을 제공하지만, 취소 동작은 주변 아키텍처에 따라 달라집니다. cap-std 프로젝트는 외부 리소스를 암묵적 전역이 아닌 능력 값으로 노출하며, cap-std 능력 기반 API에서 레거시 API와 취소가 별도의 엔지니어링 과제라는 점도 보여줍니다.

NAS API를 감싼 능력 래퍼의 보안 수준은 그 뒤에 있는 게이트웨이의 보안 수준에 불과합니다. 모든 요청이 결국 제한 없는 관리자 토큰을 사용한다면, 겉으로 보이는 세분화된 권한은 그 경계 아래에서 사라질 수 있습니다.