AI 에이전트 신원·권한·감사 로그: 작업 기록의 다섯 가지 필드

검토자가 따라갈 수 있는 작업 기록 만들기

AI 에이전트의 신원·권한·감사 로그를 검토할 때는 누가 요청했는지부터 실제 결과까지 하나의 작업으로 연결하세요. 로그인 성공, 권한 부여, 승인, 실행 시도와 완료는 서로 다른 상태입니다. 다음은 실제 시스템에서 추출한 로그가 아니라 검토자가 직접 작성할 수 있는 예시 기록입니다. 팀원이 업무 문서 한 건의 요점을 읽고 답장 문안만 준비하도록 요청했다고 가정합니다. 상대에게 보내는 일은 포함되지 않습니다.

이 다섯 필드는 서로 다른 질문에 답합니다. 요청자는 일을 시작한 사람이고 실행 신원은 도구에 접근한 주체입니다. 자격 증명은 그 주체를 인증하는 수단이며 참조값만 남겨도 됩니다. 허용 범위는 할 수 있는 일을 제한하고 승인은 특정 요청에 대한 판단을 나타냅니다. 결과 기록은 계획한 일과 실제로 확인된 일을 구분합니다. 채팅에 적힌 에이전트 이름이나 API 키 하나로 이 관계를 모두 설명할 수는 없습니다.

문서 읽기와 문안 작성에는 같은 요청 식별자 아래 서로 다른 작업 식별자를 붙일 수 있습니다. 예를 들어 ‘요청 01’에 ‘문서 읽기 01’과 ‘문안 작성 02’를 연결합니다. 읽기는 성공했지만 문안 작성이 실패했다면 각 단계의 상태를 따로 남기세요. 문안이 준비됐더라도 전송 시도는 없었다고 구분해야 합니다. 이 식별자는 설명용 수동 기록 방식이며 특정 제품의 자동 출력 형식을 뜻하지 않습니다.

감사 근거에는 문서 전문 대신 대상 문서의 참조와 결과 위치를 남깁니다. 요청 시각, 승인 시각, 시도 시각을 구분하고 적용한 시간대도 적으면 다른 기록과 비교하기 쉽습니다. 검토자가 증거를 볼 수 없다면 성공으로 채우기보다 확인하지 못한 부분을 명시하세요. 기록의 접근 권한과 보관 기간은 조직의 실제 정책에 맞춰 정해야 합니다.

작업 범위가 바뀌면 기록도 구분하세요. 문안만 준비하던 요청에 ‘이제 보내 달라’는 지시가 추가됐다면 새 행동과 그 대상·승인 판단을 연결해야 합니다. 읽기 승인을 전송 승인으로 재사용하지 않습니다. 승인된 문안과 나중에 수정된 문안이 다르다면 어느 내용을 실행했는지도 확인할 수 있어야 합니다.

기업 에이전트의 신원과 권한 범위 정하기

Microsoft Entra의 에이전트 권한 안내는 사용자를 대신하는 위임 권한과 애플리케이션 자체에 부여되는 권한을 구분합니다. 위임 방식에서는 사용자 권한과 부여된 범위가 함께 작용합니다. 사용자 없이 작동하는 애플리케이션 권한은 관리자가 부여합니다. 어느 방식이든 로그인이나 동의가 이루어졌다는 사실이 이후의 모든 문서 수정과 메일 전송을 승인한다는 뜻은 아닙니다.

이 구분은 Microsoft Entra의 권한 체계를 설명합니다. 다른 에이전트나 휴대폰 앱에서 같은 신원 객체와 관리 절차가 제공된다고 확대하지 마세요. Entra에서는 높은 권한의 역할과 API 권한에 제한이 있으므로, 일반 관리자 역할을 편의상 부여하는 대신 해당 리소스와 에이전트에 허용되는 범위를 확인해야 합니다.

예시의 문서 읽기 작업에는 그 문서가 속한 리소스에 필요한 읽기 권한을 먼저 찾습니다. Azure 리소스 역할, 디렉터리 역할, Microsoft Graph 권한은 적용 대상이 다릅니다. 디렉터리를 관리할 수 있다는 사실이 특정 업무 문서 읽기에 필요한 권한 설명을 대신하지는 않습니다. 자격 증명에 연결된 허용 범위와 에이전트에 맡긴 작업 범위를 각각 기록하세요.

문안을 작성할 목적인데 문서 수정이나 메일 전송 권한까지 필요하다고 판단했으면 그 이유를 별도로 검토합니다. 현재 작업이 읽기만 요구한다면 쓰기 권한은 제외하는 것이 출발점입니다. 기존 연결 계정에 넓은 권한이 있어도 이번 요청에서 무엇을 허용했는지는 다시 정해야 합니다. 접근할 수 있다는 사실과 그 접근을 이 요청에 사용할 수 있다는 판단은 다릅니다.

접근이 거부됐을 때도 원인을 나누세요. 실행 신원을 인증하지 못한 것인지, 리소스 권한이 부족한 것인지, 특정 행동이 정책상 허용되지 않은 것인지 확인합니다. 세 경우를 모두 ‘권한 부족’으로 묶어 관리자 권한을 추가하면 최소 권한 판단이 사라집니다. 담당자가 확인한 원인과 필요한 변경만 기록하고 다시 검토하세요.

요청자, 실행 신원, 승인자가 언제나 같은 사람인 것도 아닙니다. 담당 소유자와 필요할 경우 후원·관리 책임자를 연결하고, 조직 정책에 따른 재검토 시점이나 만료 조건을 확인하세요. 퇴사·역할 변경 때도 어느 권한을 회수할지 찾을 수 있어야 합니다. 조직 차원의 평가 기준은 기업 AI 에이전트 보안: 로컬 우선 휴대폰 에이전트를 평가하는 방법에서 더 넓게 다룹니다.

신원 기록과 실제 작업 결과 따로 모으기

Microsoft Entra의 에이전트 로그인·감사 기록 안내에 따르면 감사 이벤트의 agentType과 blueprintId는 에이전트 및 설계 원형과 관련된 주체·대상을 연결하는 데 쓰입니다. 설계 원형 활동은 애플리케이션 이벤트, 에이전트 신원 활동은 서비스 주체 이벤트, 에이전트 사용자 계정 활동은 사용자 이벤트로 나타날 수 있습니다.

필요한 조회 권한이 있는 담당자는 Entra ID의 모니터링 및 상태 → 로그인 로그에서 에이전트 필터를 사용할 수 있습니다. 이 조회에는 최소한 Reports Reader 역할이 필요합니다. 공식 안내에 설명된 Microsoft Graph 에이전트 로그 조회는 /beta 경로를 사용합니다. 해당 조회 경로와 실제 환경의 제공 조건을 확인하고 운영 절차에 적용하세요.

로그인 성공이나 신원 생성 기록은 접근 경로를 설명하지만 특정 문서가 바뀌었거나 답장이 실제로 전송됐다는 증거는 아닙니다. 그 결과는 문서 저장 이력이나 메일 앱의 전송 상태처럼 대상 애플리케이션에서 따로 확인합니다. 요청 식별자, 실행 신원, 대상 리소스와 시각을 대조해 신원 기록과 업무 동작을 연결하세요.

문서 읽기와 답장 문안 예시에서는 먼저 요청 01의 실행 신원과 승인 범위를 확인합니다. 이어 관련 신원 이벤트와 문서 읽기 결과를 비교하고 문안 결과의 참조를 찾습니다. 모든 시스템이 동일한 요청 식별자를 자동으로 남긴다고 가정하지 마세요. 식별자가 연결되지 않으면 어떤 정보로 대응시켰는지와 남은 불확실성을 수동 기록에 적습니다.

시각이 비슷하다는 이유만으로 두 이벤트가 같은 작업이라고 확정해서는 안 됩니다. 같은 에이전트가 여러 문서를 처리했다면 대상 문서와 작업 식별자를 함께 봐야 합니다. 로그인만 확인되고 대상 앱의 결과가 없다면 완료 상태는 아직 확인되지 않은 것입니다. 필요한 기록에 접근할 수 없는 경우도 ‘결과 없음’과 ‘조회할 수 없음’을 구분하세요.

반대로 대상 앱에 변경이 보이더라도 어떤 요청이 만든 결과인지는 별도 질문입니다. 다른 사용자나 이전 시도가 같은 문서를 바꿨을 수 있으므로 결과 식별자와 실행 주체를 대조하세요. 연결 근거가 부족하면 해당 변경을 에이전트의 성공으로 확정하지 않습니다. 확인 가능한 증거와 아직 필요한 증거를 함께 남깁니다.

각 기록의 보존 기간과 열람 권한은 운영 정책에 따라 정합니다. 로그인 로그에 모든 업무 동작이 자동으로 담기거나 기록을 모으기만 하면 변조 방지와 규정 준수가 보장된다고 가정하지 마세요. 검토자는 근거의 출처, 접근 가능 여부와 실제 결과를 함께 확인해야 합니다.

성공·거부·승인 대기·부분 실패를 따로 기록하기

다음 네 예는 실제 관찰 결과가 아니라 자신의 작업에 적용할 수 있는 제안된 기록 방식입니다. 각 예에서 허용 범위, 실제 시도, 관찰된 결과와 다음 조치를 분리합니다. 승인 완료를 실행 완료로 바꾸거나 오류 응답을 대상이 변경되지 않았다는 증거로 바꾸지 않는 것이 핵심입니다.

읽기 작업이 성공한 경우

‘요청 01 / 실행 신원 01 / 지정 문서 읽기 허용 / 접근 승인 확인 / 읽기 결과 참조 확인’처럼 연결합니다. 대상 문서가 요청한 문서인지와 읽기 결과를 확인한 시각을 남기세요. 답장 문안도 준비됐다면 별도 단계로 기록하고 전송 요청은 없었다고 적습니다. 읽기 성공을 문서 수정이나 메일 전송 성공으로 확대하지 않습니다.

쓰기 작업이 승인 대기인 경우

일정 생성에 필요한 내용을 모았지만 승인 판단이 남았다면 ‘입력 준비 완료 / 승인 대기 / 실행 미시도’로 기록할 수 있습니다. 누가 어떤 대상과 내용을 검토해야 하는지도 연결하세요. 승인 화면이 있다는 것만으로 승인자가 수락했다고 적지 않습니다. 대기 중 요청 내용이 바뀌었다면 최종 내용을 다시 확인하고 실제 승인 판단이 어느 내용에 해당하는지 구분합니다.

행동이 거부된 경우

문서 수정이 허용 범위 밖이라 거부됐다면 정책 판단과 거부된 단계를 남깁니다. 대상 문서를 직접 확인해 변경이 없었다면 그 확인 근거도 연결하세요. 확인하지 못했다면 ‘거부됨 / 대상 상태 미확인’으로 남겨야 합니다. 거부는 작업 실패의 한 상태이며, 편의를 위해 더 넓은 권한을 즉시 부여할 이유가 되지는 않습니다.

일부만 완료됐거나 쓰기 결과가 불확실한 경우

문서는 읽었지만 문안 작성이 실패했다면 읽기 성공과 작성 실패를 나눕니다. 쓰기 요청을 보낸 뒤 응답을 받지 못한 경우에는 ‘시도됨 / 응답 불확실 / 대상 확인 필요’로 기록하세요. 대상 앱에 결과가 이미 생겼을 수 있으므로 같은 쓰기를 바로 반복하지 않습니다. 생성된 항목이 있으면 식별자와 내용을 비교하고, 없거나 확인되지 않으면 그 상태에 맞춰 다음 조치를 정합니다.

여러 결과를 한 줄의 ‘실패’로 묶으면 재시도 범위를 정하기 어렵습니다. 완료한 단계는 유지하고 미완료 단계만 검토하세요. 나중에 대상 결과를 확인했다면 기존 기록을 조용히 성공으로 바꾸기보다 확인 시각과 추가 근거를 연결합니다. 최초 판단과 후속 확인을 함께 볼 수 있어야 검토자가 당시의 불확실성까지 이해할 수 있습니다.

같은 질문을 Android 휴대폰 작업에 적용하기

저희 FoneClaw에서는 이 다섯 가지 질문을 휴대폰 작업을 검토하는 점검표로 사용할 수 있습니다. 이는 기업용 감사 로그 내보내기 형식이 아니라 사용자가 요청과 결과를 구분하기 위한 수동 기록 예시입니다. Microsoft Entra 신원과 휴대폰 도구 제어는 별도 체계로 확인합니다.

‘현재 배터리와 절전 모드 상태를 알려 줘’라는 요청이라면 요청자, 사용 중인 앱·모델 설정, 활성화된 도구, 실제 승인 정책과 반환 결과를 연결합니다. device_battery_status는 설정을 바꾸지 않는 읽기 작업입니다. 기본 자동 승인 분류가 있어도 실제 동작은 전역 승인 모드와 도구별 재정의 설정의 영향을 받으므로 확인한 정책을 기록하세요.

캘린더 일정 생성은 결과가 남는 별도 작업입니다. 예를 들어 ‘10월 8일 오후 3시부터 3시 30분까지 회의, 10분 전 알림’처럼 요청했다고 가정합니다. 연도와 기기 시간대, 대상 캘린더를 확인하고 부족한 시간·알림 정보는 실행 전에 묻습니다. calendar_create_event의 기본 승인 요구와 실제 적용 정책도 확인하세요. 요청이 구체적이라는 사실만으로 이미 승인되거나 저장됐다고 보지 않습니다.

생성 뒤에는 반환된 actualStart와 actualEnd를 기준으로 실제 생성 시간을 확인합니다. Android 캘린더에서 제목, 대상 캘린더, 시작·종료 시간과 알림도 대조하세요. 요청한 시간과 실제 결과가 다르면 차이를 기록하고 수정 여부를 판단합니다. 완료 응답만 보고 같은 일정을 추가로 만드는 재시도는 피하세요. 지원 범위는 FoneClaw 기능 안내에서 확인할 수 있습니다.

Android 권한, FoneClaw 도구 활성화, 모델 제공자 자격 증명은 서로 다른 설정입니다. 휴대폰에서 작업해도 구성한 온라인 모델이 전달된 맥락을 처리할 수 있으며, 로컬 작업 기록만으로 제공자의 데이터 처리를 설명할 수는 없습니다. 스킬이 추가된다면 설치와 실행 중 확인을 나누세요. 관련 방법은 AI 에이전트 스킬 보안: 검사 통과보다 실행 중 권한 확인이 중요한 이유에서 이어집니다.

거부 동작을 확인하고 불필요한 접근 철회하기

권한을 줄였다면 예상한 거부가 실제로 일어나는지도 살펴야 합니다. FoneClaw의 배터리 상태 확인 도구를 끄고 같은 읽기 요청을 해 보는 것은 사용자가 수행할 수 있는 제안된 점검입니다. 특정 기기에서 이미 관찰한 결과를 뜻하지 않습니다. 변경 전 도구 상태와 정책을 적고 외부 결과가 생기지 않는 읽기 요청으로 시작하세요.

기대하는 관찰은 해당 도구의 새로운 기기 조회 결과가 제공되지 않는 것입니다. 모델이 일반적인 배터리 설명을 하거나 이전 값을 언급한 것을 현재 기기 조회 성공으로 판단하지 마세요. 도구 상태, 실행 시도와 반환 결과를 구분해 기록합니다. 예상과 다르면 같은 요청을 반복하기보다 어떤 도구가 사용됐는지와 활성화·승인 설정을 확인하고, 필요 없는 접근은 비활성 상태로 둡니다.

기업 환경에서는 더 이상 쓰지 않는 에이전트 신원과 연결 권한을 회수하고 노출된 자격 증명은 교체합니다. 휴대폰에서는 필요 없는 도구, Android 권한, 연결 계정과 도구별 승인 재정의를 각각 검토하세요. 한 설정을 바꿨다고 다른 계층의 접근까지 모두 철회됐다고 가정하지 않습니다. 담당자는 변경한 범위와 확인하지 못한 연결을 남겨야 합니다.

미래 접근을 막는 것과 이미 완료된 쓰기를 되돌리는 것은 다릅니다. 캘린더 접근을 철회해도 생성된 일정이 자동 삭제됐다고 볼 수 없습니다. 쓰기가 중간에 멈췄다면 대상 앱의 결과부터 확인하고, 항목이 남아 있으면 필요한 정리나 수정 작업을 별도로 판단하세요. 재시도 전에는 대상과 기존 결과를 대조해 중복 생성 가능성을 줄입니다.

철회 점검을 위해 권한을 다시 켜야 한다면 그 목적과 범위를 먼저 정하세요. 이전의 넓은 설정을 그대로 복구하기보다 다음 작업에 필요한 도구와 접근만 선택합니다. 점검 뒤 최종 설정과 남아 있는 예외를 확인하면 임시로 허용한 접근이 계속 유지되는 일을 줄일 수 있습니다.

기록을 읽을 수 있는 사람, 보관 위치와 조직 정책에 따른 보존·삭제도 확인합니다. 추천 정보나 저장된 맥락이 다음 요청에 영향을 줄 수 있는 경우는 AI 에이전트 메모리 오염: 휴대폰 Ask AI 버튼과 추천 보안에서 별도로 다룹니다. 마지막에는 철회한 접근, 남아 있는 대상 결과, 다음 검토 담당자와 미확인 사항을 연결해 사후 검토를 마무리하세요.