Claude의 Microsoft 365 권한이 달라졌다면 확인할 것들

Claude에 Microsoft 365를 다시 연결했더니 예전에는 없던 쓰기 권한이 보인다. 그런데 Teams에서 보던 파일은 Claude에서 찾지 못한다. 두 현상은 같은 문제일까? 권한 요청과 실제 승인, 도구 설정, 파일 위치를 나눠 봐야 답이 나온다.

쓰기 권한은 연결 기능이 확장되며 추가됐다

클코단에서는 Claude 연동을 재확인하다 권한 목록이 달라진 경험이 공유됐다. 이전에는 읽기 위주였는데 쓰기 항목이 나타났고, Teams 파일과 관련해 기대했던 읽기 항목은 보이지 않았다는 이야기다. 최초 MCP 승인 방식이 영향을 줬을 가능성도 제기됐다. 다만 당시와 현재의 승인 기록이 없어 원인을 특정할 수는 없다.

확인되는 변화는 있다. Anthropic의 2026년 7월 7일 릴리스 노트는 Microsoft 365 커넥터에 쓰기 도구가 추가됐다고 밝혔다. 현재 설정 문서에 따르면 새 권한 묶음에는 Mail.Send, Mail.ReadWrite, Calendars.ReadWrite, Files.ReadWrite.All 등이 포함된다. Microsoft Entra 관리자가 갱신된 권한을 다시 승인해야 쓰기 도구를 사용할 수 있다.

새 쓰기 항목이 보인다는 관찰은 제품 기능 확장과 부합한다. 그렇다고 특정 계정의 과거 승인 내역까지 확인된 것은 아니다. (support.claude.com)

요청된 권한과 실제로 쓸 수 있는 도구는 다르다

동의 화면은 앱이 요청하는 범위를 보여준다. 실제 접근을 판단하려면 Entra에 승인된 권한과 Claude에서 켜진 도구를 별도로 확인해야 한다. Anthropic에 따르면 이 커넥터는 사용자 위임 권한으로 작동한다. 사용자가 원래 열 수 없는 Microsoft 365 자료를 커넥터가 대신 열어 주지는 않는다. 다만 Files.ReadWrite.All처럼 넓어 보이는 항목은 사용자가 접근 가능한 파일에 대한 쓰기 범위를 뜻한다. 승인 전에 업무상 필요한지 검토할 이유가 있다. (support.claude.com)

관리자는 Microsoft Entra 관리 센터의 Enterprise apps → All applications → 해당 앱 → Permissions에서 승인 내역을 볼 수 있다. Microsoft 문서는 조직 전체에 적용된 Admin consent와 개별 User consent를 구분해 확인하도록 안내한다. 그다음 Claude의 커넥터 설정에서 쓰기 도구가 허용됐는지 살펴야 한다. Anthropic은 기존 조직의 쓰기 도구가 기본적으로 차단되며, Teams 메시지 쓰기 도구는 각각 따로 활성화해야 한다고 명시한다. 승인 화면에 쓰기 권한이 있다는 이유만으로 Claude가 곧바로 메시지를 보내거나 파일을 수정할 수 있다고 판단하면 안 된다. (learn.microsoft.com)

실사용 반응에서도 관리자 승인을 마쳤는데 쓰기 도구가 나타나지 않아 혼란스럽다는 의견이 있었다. 반대로 설정을 마친 뒤 기능을 사용했다는 반응도 있다. 권한 승인과 도구 활성화를 한 단계로 취급해서는 안 되는 이유다. 다만 개별 사례만으로 모든 계정에서 같은 오류가 난다고 볼 수는 없다. (reddit.com)

Teams에서 보이는 파일이 검색되지 않는 이유

‘Teams 파일’은 한 저장소를 가리키지 않는다. Microsoft에 따르면 채널에서 공유한 파일은 해당 팀의 SharePoint 사이트에, 개인 채팅에서 공유한 파일은 공유자의 OneDrive에 저장된다. Teams의 메시지를 읽는 권한과 그 메시지에 연결된 파일을 읽는 권한도 같은 항목이 아니다. Anthropic의 권한 안내에는 채팅용 Chat.Read, 파일용 Files.Read·Files.Read.All, SharePoint용 Sites.Read.All이 구분돼 있다. (learn.microsoft.com)

파일이 빠졌다면 원래 공유된 장소부터 확인해야 한다. 채널 파일인지 개인 채팅의 공유 파일인지에 따라 점검할 저장소가 달라진다. 이어 같은 계정으로 SharePoint나 OneDrive에서 파일을 열 수 있는지, Entra에 필요한 읽기 권한이 승인돼 있는지 확인할 수 있다. Anthropic 문서는 SharePoint 검색에 Sites.Read.All이 필요하다고 설명한다. 다만 방에서 관찰된 ‘읽기 항목이 사라짐’이 어떤 정확한 권한 이름이나 화면을 뜻하는지는 확인되지 않았다. (support.claude.com)

PowerShell 직접 접근은 별도 권한 경로다

클코단에서는 Teams 파일에 접근하기 위해 PowerShell로 별도 구성을 했다는 경험도 나왔다. 재현 가능한 확인 경로는 Microsoft Graph 문서에 있다. 관리자와 협의해 Graph PowerShell에 필요한 위임 권한으로 로그인한다. 그런 뒤 팀 ID와 채널 ID를 넣어 Get-MgTeamChannelFileFolder -TeamId $teamId -ChannelId $channelId를 실행하면 채널 파일 폴더의 위치 정보를 얻는다. Microsoft는 이 API의 최소 위임 권한으로 Files.Read.All을 제시한다. 폴더의 자식 항목을 조회하는 Get-MgDriveItemChild는 다음 단계에 쓸 수 있다. (learn.microsoft.com)

입력은 접근 권한이 있는 팀·채널의 식별자다. 첫 산출물은 파일 내용이 아니라 저장 위치의 메타데이터다. 이 절차는 Claude 커넥터를 고치는 명령이 아니라 Graph로 직접 읽는 경로가 되는지 확인하는 별도 테스트다. Graph에서는 접근되는데 Claude에서만 실패한다면 커넥터의 승인·도구·검색 경로를 좁혀 볼 수 있다. 둘 다 실패한다면 파일 공유 권한이나 계정 접근부터 다시 확인해야 한다. (learn.microsoft.com)

접속 제한과 권한 문제는 다른 증거를 남긴다

방에서는 Microsoft 정책 변화와 DNS 제한도 가능한 원인으로 거론됐다. 하지만 가능성을 곧바로 원인으로 확정할 수는 없다. Microsoft는 Microsoft 365 서비스에 필요한 네트워크 엔드포인트를 공개하고, DNS·프록시·방화벽 경로를 점검하는 연결성 테스트를 제공한다. 로그인 자체나 여러 Microsoft 365 서비스의 연결이 함께 실패한다면 네트워크 점검이 권한 목록 비교보다 먼저일 수 있다. 반면 로그인은 되고 특정 파일만 빠진다면 파일 위치와 공유 권한부터 보는 편이 문제를 더 좁힌다. (learn.microsoft.com)

개인 개발자나 작은 팀에도 이 구분은 중요하다. 관리자에게 막연히 ‘권한을 더 열어 달라’고 요청하는 대신 요청된 범위·승인된 범위·활성화된 도구와 실패한 파일의 저장 위치를 각각 전달할 수 있다. 이번 권한 변화에서 확인된 제품 차원의 설명은 쓰기 기능 추가다. 남은 쟁점은 해당 조직에서 어떤 승인이 바뀌었고, 찾지 못한 파일이 실제로 어디에 저장돼 있느냐다. (support.claude.com)