AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계
AI 에이전트가 도구를 쓰기 전 필요한 신원, 범위가 좁은 권한, 도구별 승인 제어, 감사 로그, 철회와 복구 흐름을 Android 폰 에이전트 기준으로 설명합니다.
- AI 에이전트 신원은 사용자의 계정을 그대로 복사하는 개념이 아니라, 특정 세션에서 누구의 요청을 받아 어떤 범위로 행동하는지 구분하는 실행 주체입니다.
- AI 에이전트 권한은 신원, 정책, 도구 활성화, Android 권한, 대상 확인, 작업 승인을 통과하며 좁아져야 합니다.
- 에이전트 감사 로그에는 성공한 작업뿐 아니라 거부, 부분 실패, 승인 대기, 실제 관찰된 결과까지 남아야 나중에 범위 조정과 복구가 가능합니다.
- 현재 공개된 FoneClaw는 전역 승인 모드, 도구별 제어, 권한 복구, 실패 처리를 통해 지원되는 Android 작업의 도구 경계를 더 구체적으로 다룹니다.
도구를 쓰기 전에 AI 에이전트 신원이 필요한 이유
사용자가 폰 에이전트에게 “회의가 끝나면 팀에 20분 늦는다고 알려 줘”라고 말하는 순간, 단순한 문장 작성보다 많은 일이 시작됩니다. 에이전트는 캘린더를 확인하고, 현재 시간이나 이동 상황을 참고하고, 메시지 초안을 만들고, 전송 전 사용자 확인을 기다릴 수 있습니다. 이때 첫 질문은 모델이 얼마나 똑똑한가가 아니라 “누가 어떤 세션에서 누구를 대신해 행동하는가”입니다. 이것이 AI 에이전트 신원의 출발점입니다.
신원은 사용자, 에이전트, 세션, 위임된 권한, 대상 신원을 연결합니다. 사용자는 요청을 맡긴 주체이고, 에이전트는 도구를 호출하려는 실행 주체이며, 세션은 이번 작업이 언제 어떤 맥락에서 시작됐는지 보여 줍니다. 위임된 권한은 사용자가 이번 작업에 맡긴 범위이고, 대상 신원은 메시지 수신자, 일정, 앱 계정, 파일처럼 작업이 향하는 대상입니다. 로그인에 성공했다는 사실만으로 이 모든 범위가 정해지지는 않습니다.
NVIDIA의 자율 에이전트 거버넌스 안내는 표시 계층과 관리형 실행을 분리하고, 신원, 서명된 정책, 사람 검토, 중앙 로그, 철회, 지속 확인을 다루는 설계 방식을 설명합니다. 폰 에이전트에서도 원리는 같습니다. 사용자가 직접 앱을 열어 보낸 메시지와, 에이전트가 초안을 만들고 사용자가 승인한 메시지는 나중에 다르게 이해되어야 합니다. 재시도나 기기 간 이어받기가 있어도 누가 어떤 범위로 행동했는지 남아야 권한과 감사 로그가 의미를 갖습니다.
신원을 좁고 취소 가능한 권한으로 바꾸는 법
AI 에이전트 권한은 하나의 큰 허가가 아니라 여러 단계를 지나며 좁아지는 구조가 되어야 합니다. 첫 단계는 신원입니다. 이번 요청이 어느 사용자와 어느 세션에서 시작됐는지 확인합니다. 두 번째는 정책입니다. 이 에이전트가 특정 도구 범주를 쓸 수 있는지, 시간이나 대상 제한이 있는지 판단합니다. 세 번째는 도구 활성화입니다. 해당 도구가 런타임에서 켜져 있는지 확인합니다.
그다음 Android 권한이 옵니다. 위치, 알림, 연락처, 마이크, 파일처럼 기기 기능에 접근하려면 Android의 권한 흐름을 따라야 합니다. 하지만 Android 권한은 업무상 승인과 다릅니다. 위치 권한이 있다는 것은 위치를 읽을 수 있다는 뜻이지, 그 위치를 특정 사람에게 보내도 된다는 뜻은 아닙니다. 그래서 대상 확인과 작업 승인이 별도 단계로 필요합니다. 대상이 맞는지, 내용이 맞는지, 외부 결과가 생기는지 사용자가 확인할 수 있어야 합니다.
NVIDIA의 보안 중심 AI 에이전트 배포 안내는 접근 제어, 임의 코드 실행, 네트워크 외부 전송, 평문 비밀 값 같은 반복 실패를 짚고, 모델 바깥의 결정적 제어와 최소 권한 도구를 권합니다. Android 폰에서는 이 원칙을 도구 정책, 권한 요청, 대상 확인, 승인 화면, 철회 경로로 바꿔 적용해야 합니다. 샌드박스와 폰 권한의 차이를 더 넓게 보려면 AI 에이전트 샌드박스와 폰 권한: 안전한 에이전트에도 경계가 필요한 이유가 이 구분을 이어서 설명합니다.
도구 호출 경계에서 결정하고 기록할 것
도구별 승인 제어가 실용적이려면 도구 호출 경계에서 무엇을 결정하고 무엇을 기록할지 정해야 합니다. 낮은 위험의 읽기 작업부터 보겠습니다. 사용자가 “다음 일정 제목만 확인해 줘”라고 말하면 에이전트는 캘린더 관련 읽기 도구를 고를 수 있습니다. 기록에는 사용자 요청, 선택한 도구, 요청 범위, 정책 결과, Android 권한 상태, 관찰된 결과가 남아야 합니다. 읽은 값 전체를 길게 저장하기보다 “일정 제목 확인 성공”처럼 목적에 맞는 최소 근거가 더 적합할 수 있습니다.
결과가 생기는 쓰기 작업은 더 많은 기록이 필요합니다. “팀에 늦는다고 보내 줘”라는 요청에서는 메시지 앱, 수신자, 초안 내용, 전송 전 승인 여부, 사용자가 수정했는지, 실제 전송 결과가 기록되어야 합니다. 계획한 작업과 관찰된 결과도 분리해야 합니다. 모델이 “전송할 계획”을 세운 것과 Android 앱이 실제로 전송 완료 상태를 보여 준 것은 다릅니다.
도구 경계에서 남겨야 할 필드는 간단한 형식으로 정리할 수 있습니다. 요청 id, 실행 신원, 세션, 선택한 도구, 대상, 입력 요약, 정책 판단, 승인 상태, 실행 결과, 거부 이유, 실패 이유, 복구 선택지입니다. 성공만 기록하면 위험을 볼 수 없습니다. 거부, 부분 실패, 권한 부족, 사용자 취소도 남아야 다음에 범위를 좁히거나 도구를 끌 수 있습니다. 스킬 단위의 실행 중 검사를 더 깊게 보고 싶다면 AI 에이전트 스킬 보안: 검사 통과보다 실행 중 권한 확인이 중요한 이유가 도구 호출 경계를 스킬 보안 관점에서 이어 줍니다.
기업 샌드박스 제어와 Android 폰 제어는 다른 계층입니다
기업 AI 에이전트 보안과 Android 폰 에이전트 보안은 같은 원칙을 공유하지만 같은 제어 계층은 아닙니다. 기업 환경에서는 관리형 실행, 외부 네트워크 제한, 비밀 값 관리, 서명된 정책, 중앙 로그가 중요한 축입니다. Android 폰에서는 앱 권한, 화면 상태, 사용자의 즉시 승인, 대상 앱 동작, 기기 권한 복구가 더 직접적인 문제가 됩니다.
| 제어 영역 | 기업 에이전트에서 주로 보는 것 | Android 폰 에이전트에서 주로 보는 것 |
|---|---|---|
| 실행 환경 | 관리형 작업 공간, 샌드박스, VM, 컨테이너 | 사용자 기기, Android 앱 상태, 지원 도구 런타임 |
| 네트워크 | 기본 차단 외부 연결, 허용 목록, 비밀 값 처리 | 앱별 연결, 계정 세션, 기기 네트워크 상태 |
| 권한 | 역할, 정책, 자격 증명 범위 | Android 권한, 도구 활성화, 대상 승인 |
| 검토 | 사람 검토, 서명된 정책, 중앙 로그 | 화면에서 확인하는 승인, 도구 실행 승인, 결과 표시, 실패 후 복구 경로 |
| 철회 | 자격 증명 교체, 정책 철회, 세션 종료 | 도구 끄기, 권한 철회, 승인 모드 변경, 앱 권한 회수 |
이 차이를 혼동하면 제품 설계가 과장됩니다. Android 권한을 기업 샌드박스라고 부르면 기기 권한의 의미가 커져 보이고, 기업 환경의 설계 방식을 그대로 폰 앱 기능처럼 말하면 실제 사용자 제어가 흐려집니다. 기업 배포 보안의 깊은 비교는 기업 AI 에이전트 보안: 로컬 우선 휴대폰 에이전트를 평가하는 방법에서 이어서 볼 수 있습니다. 이 글의 핵심은 기업 제어와 Android 제어가 서로 보완될 수 있지만 같은 계층은 아니라는 점입니다.
FoneClaw의 전역 승인 모드와 도구별 제어
FoneClaw에서 우리는 AI 에이전트 신원과 권한을 Android 도구 호출 경계에서 다룹니다. 구성된 호환 모델은 사용자의 요청을 이해하고 계획합니다. FoneClaw는 지원되는 Android 도구를 호출하며, 전역 승인 모드와 도구별 제어를 통해 실행 범위를 정합니다. 사용자가 원하는 것은 추상적인 보안 문구가 아니라 “이 도구가 켜져 있는지, 어떤 작업이 승인되는지, 실패했을 때 어디서 복구할 수 있는지”입니다.
현재 공개된 FoneClaw는 도구별 관리, 승인 방식 조정, 권한 복구, 실패 처리를 강화했습니다. 전역 도구 승인 모드는 세 가지입니다. 자동 승인은 허용된 흐름에서 마찰을 줄이는 모드입니다. 도구 정책 따르기는 도구의 위험도와 승인 정책을 따르는 균형형 모드입니다. 전체 거부는 도구 실행을 막고 사용자가 더 엄격한 상태에서 확인할 수 있게 하는 모드입니다.
이 세 모드는 어느 하나가 모든 사용자에게 항상 맞는 답이라는 뜻이 아닙니다. 낮은 위험 읽기 작업과 외부 결과가 생기는 작업은 다른 정책이 필요합니다. 그래서 현재 FoneClaw의 도구별 검색, 활성화 제어, 승인 방식 조정이 중요합니다. 사용자는 도구를 찾고, 켜거나 끄고, 특정 도구의 승인 방식을 조정할 수 있습니다. 권한이 필요한 순간에는 필요한 설정을 안내받고, 실패하면 더 명확한 실패 처리로 다음 행동을 결정하게 됩니다.
FoneClaw 기능 소개에서 볼 수 있듯이 FoneClaw는 100개 이상의 내장 도구로 Android 작업을 다룹니다. 도구에는 작업 성격에 맞는 위험도와 승인 흐름이 적용됩니다. FoneClaw의 전체 의도-실행 구조가 필요하다면 AI 에이전트 폰 제어란 무엇인가: 안드로이드 폰 에이전트가 실제로 해야 할 일에서 지원 Android 작업과 보이는 결과, 권한 흐름을 더 넓게 볼 수 있습니다.
일상적인 폰 에이전트 작업의 승인 기준표
도구별 승인 제어는 범주 이름만으로 끝나지 않습니다. 같은 커뮤니케이션 영역이라도 메시지 초안 생성과 실제 전송은 위험이 다릅니다. 같은 위치 영역이라도 현재 위치를 화면에 보여 주는 것과 그 위치를 외부로 공유하는 것은 다릅니다. 도구의 위험도와 승인 방식은 출발점이고, 실제 대상과 내용이 최종 판단을 바꿉니다.
| 작업 유형 | 예시 | 권한 판단 | 권장 승인 감각 | 감사 로그에 남길 것 |
|---|---|---|---|---|
| 낮은 위험 읽기 | 현재 화면 읽기, 앱 상태 확인 | 도구 활성화와 최소 화면 접근 확인 | 정책에 따라 자동 또는 도구 정책 적용 | 요청, 도구, 읽은 범위 요약, 결과 |
| 기기 제어 | 앱 열기, 설정 화면 이동, 타이머 준비 | Android 상태와 사용자 맥락 확인 | 대상 앱이나 상태 변화가 보이도록 처리 | 실행 전 상태, 대상, 관찰된 결과 |
| 커뮤니케이션 | 메시지 초안, 이메일 초안, 전송 | 수신자와 내용 검증 | 전송처럼 외부 결과가 생기면 명시적 승인 | 수신자 요약, 승인 상태, 전송 결과 |
| 민감한 읽기 | 위치, 메일, 계정 관련 정보 | Android 권한과 목적 제한 확인 | 사용자가 이해할 수 있는 범위 안내 | 접근 목적, 범위, 거부 또는 허용 결과 |
| 외부 효과 | 게시, 공유, 삭제, 구매 흐름 | 대상, 결과, 되돌릴 수 있는지 확인 | 높은 위험은 승인 방식 조정 또는 전체 거부 운용 고려 | 최종 내용, 사용자 확인, 실패와 복구 옵션 |
| 플러그인 기반 작업 | 신뢰된 플러그인 워크플로 | 내장 도구와 다른 경로로 검토 | 설치와 실행 경계를 분리 | 플러그인 제안, 활성화 상태, 호출 결과 |
이 표는 모든 상황에 고정되는 규칙이 아니라 판단을 돕는 기준입니다. 실제 위험은 도구 이름, 사용자 목적, 대상, 데이터 민감도, 되돌릴 수 있는지에 따라 달라집니다. 중요한 것은 모델 답변이 “괜찮다”고 말하는 순간이 아니라, 런타임이 도구 경계에서 정책과 상태를 확인하는 순간입니다. 이 지점에서 승인과 감사가 분리되어 있어야 나중에 책임과 복구를 확인할 수 있습니다.
실패하거나 범위가 바뀔 때 감사, 철회, 복구하기
에이전트 접근 권한을 취소하는 방법은 한 가지가 아닙니다. 작업을 멈추는 것, 도구를 끄는 것, 전역 도구 승인 모드를 전체 거부로 바꾸는 것, Android 권한을 회수하는 것, 세션을 종료하는 것, 외부 자격 증명을 교체하는 것은 서로 다른 철회 지점입니다. 좋은 거버넌스 안내는 이 지점을 한 화면에서 모두 같은 말로 뭉개지 않습니다.
감사 로그에는 성공한 작업만 남기면 부족합니다. 거부된 도구 호출, 권한 거부, 사용자 취소, 부분 완료, 잘못된 대상 수정, 관찰된 결과 불일치가 남아야 합니다. 예를 들어 에이전트가 메시지를 준비했지만 사용자가 전송하지 않았다면 “실패”가 아니라 “초안 생성 후 사용자 취소”로 기록되는 편이 낫습니다. 이 구분이 있어야 다음에 해당 도구를 끌지, 승인을 강화할지, 사용자에게 더 분명한 대상 확인을 보여 줄지 결정할 수 있습니다.
현재 FoneClaw의 권한 복구와 실패 처리 개선은 이 운영 흐름을 더 실용적으로 만듭니다. 권한이 부족하면 필요한 권한을 안내하고, 작업이 중간에 멈추면 사용자가 다시 시도할지, 범위를 좁힐지, 도구를 끌지 판단할 수 있어야 합니다. 외부 결과가 이미 생긴 작업은 완벽하게 되돌릴 수 없을 수 있으므로, 복구는 되돌림 약속이 아니라 근거와 다음 행동을 분명히 하는 과정입니다. 최종 기준은 단순합니다. AI 에이전트 신원은 누가 행동했는지 보여 주고, 권한은 어디까지 할 수 있는지 제한하며, 감사 로그는 사용자가 다음 결정을 내릴 수 있게 해야 합니다.