홈 AI 서버에서 사용자별 도구 권한은 어떻게 작동하나요?

홈 AI 서버는 신뢰할 수 있는 사용자 신원이 실행 계층까지 전달되고, 결과에 영향을 미치는 모든 도구 호출이 실행 전에 정책에 따라 검사될 때 사용자마다 서로 다른 도구 권한을 적용할 수 있습니다.

언어 모델이 권한 부여 시스템이 되어서는 안 됩니다. 모델은 “문을 잠금 해제해” 또는 “이 파일을 삭제해”와 같은 작업을 제안할 수 있지만, 별도의 정책 계층이 현재 인증된 사용자가 이 맥락에서 지금 해당 리소스에 대해 해당 도구를 호출할 수 있는지 결정해야 합니다.

인증은 사용자를 식별하지만, 권한 부여는 에이전트 실행을 따라야 합니다

로그인은 요청을 시작한 사람이 누구인지 증명합니다. 그런 다음 해당 신원은 채팅 세션, 플래너, 하위 에이전트 호출, 검색, 도구 실행기를 거쳐 계속 전달되어야 합니다. 하위 구성 요소가 자연어 지시만 받는다면, 부모가 온도 조절기를 변경해 달라고 요청한 것인지 같은 단어가 우연히 포함된 게스트 프롬프트인지 구분할 수 없습니다.

사용자 권한 전달에 관한 AWS 보안 아키텍처는 권한 부여 컨텍스트를 프롬프트에서 재구성하는 대신 에이전트 요청과 함께 전달해야 하는 데이터로 취급합니다. 홈 서버 버전은 더 단순할 수 있지만, 신원에서 실행까지 이어지는 동일한 신뢰 체인이 필요합니다.

모델이 텍스트를 바탕으로 자체 사용자 ID, 역할 또는 가구 그룹을 선택하도록 두지 마세요. 이러한 속성은 인증된 세션이나 신뢰할 수 있는 신원 서비스에서 제공되어야 합니다. 컨텍스트가 없으면 강력한 공유 계정으로 대체하지 말고 기본적으로 거부해야 합니다.

최소 권한은 도구 카탈로그를 사용자별 기능으로 바꿉니다

서버는 수십 개의 도구를 제공할 수 있지만, 각 사용자는 그중 일부만 볼 수 있어야 합니다. 예를 들어 자녀는 식료품 항목을 추가할 수 있지만 방화벽 규칙을 변경할 수 없어야 하고, 게스트는 조명을 제어할 수 있지만 캘린더를 읽을 수 없어야 하며, 관리자는 저장소를 관리할 수 있더라도 파괴적인 작업을 수행하기 전에는 확인이 필요할 수 있습니다. 따라서 권한은 신원, 도구, 리소스, 작업을 함께 기준으로 정해야 합니다.

Microsoft의 2026년 최소 권한 도구 바인딩 분석은 에이전트 신원과 도구 액세스의 범위를 좁게 설정해야 하며, 재사용 가능한 광범위한 자격 증명을 부여해서는 안 된다고 설명합니다. 이는 홈 AI 서버에도 그대로 적용됩니다. 에이전트에는 가구 전체의 마스터 토큰이 아니라 요청된 작업에 필요한 최소한의 기능만 제공해야 합니다.

기능 기반 도구 액세스에 관한 관련 ZimaSpace 문서는 이러한 기능 경계를 살펴봅니다. 사용자별 권한 부여는 여기에 또 다른 차원을 더합니다. 동일한 도구라도 사람에 따라 서로 다른 리소스 범위나 승인 요건으로 제공될 수 있습니다.

정책은 계획이 생성될 때뿐 아니라 실행 시점에도 평가되어야 합니다

에이전트 계획은 계획이 제안된 당시의 조건이 사라진 뒤에도 남아 있을 수 있습니다. 모델이 추론하는 동안 사용자의 역할이 변경되거나, 기기가 보호 모드로 전환되거나, 승인 기간이 만료될 수 있습니다. 따라서 도구 실행기는 부작용이 발생하기 직전에 최신 정책 결정을 확인해야 합니다.

2026년 액세스 제어 프레임워크인 SEAgent는 도구를 사용하는 에이전트의 권한 상승과 혼동된 대리인 행위를 방지하기 위해 강제적 에이전트 액세스 제어를 적용합니다. 이 연구는 중요한 아키텍처 원칙을 뒷받침합니다. 프롬프트 지시는 권고 사항일 뿐이며, 외부 권한 검사는 모델이 호출을 고집하더라도 금지된 작업을 거부할 수 있어야 합니다.

위험이 다르면 읽기, 쓰기, 실행, 위임 권한을 분리하세요. 온도 조절기 상태를 읽을 수 있다고 해서 일정을 변경할 권한까지 있는 것은 아닙니다. 파일을 생성할 수 있다고 해서 백업을 삭제할 권한이 있는 것도 아닙니다. 세분화된 작업 권한은 정책을 감사하기 쉽게 만들고 잘못된 계획의 피해 범위를 줄입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

권한 테스트는 경계를 무너뜨리려는 시도를 해야 합니다

의미 있는 홈 테스트에서는 여러 신원과 적대적인 프롬프트를 사용해야 합니다. 게스트 계정으로 관리자 전용 도구를 호출해 보고, 한 가족 구성원이 정상적인 검색 도구를 통해 다른 사람의 비공개 파일을 가져오도록 시도하며, 권한을 철회한 뒤 지연된 워크플로를 실행해 보세요. 예상 결과는 부작용이 발생하기 전에 결정적으로 거부되는 것입니다.

AgentGuard는 도구를 사용하는 에이전트를 위해 속성 기반 도구 정책을 제안하며, 런타임 정책이 사용자, 리소스, 컨텍스트, 요청된 작업을 결합할 수 있음을 보여 줍니다. 이는 하나의 고정된 “관리자/사용자” 플래그보다 가정 환경을 더 잘 반영합니다. 방, 기기, 데이터 분류, 시간, 승인 상태가 모두 중요할 수 있기 때문입니다.

거부된 도구가 사용 가능한 자격 증명을 절대 받지 않고, 허용된 도구가 승인된 리소스에서만 작동하며, 감사 로그에 요청을 시작한 사용자가 기록되고, 다음 실행 검사에서 권한 철회가 적용될 때만 시스템을 사용자별로 안전하다고 부를 수 있습니다. 유일한 보호 장치가 “이 도구를 사용하지 마세요”라는 시스템 프롬프트뿐이라면, 서버에는 행동 지침은 있지만 강제 가능한 권한 격리는 없는 것입니다.