이 에이전트는 누가 만들었을까?

사용자 3.000명 규모의 한 고객 테넌트에서 첫 인벤토리를 만들었을 때 저희는 280개의 에이전트를 찾았습니다. 그중 170개는 아직 회사에 남아 있는 책임자가 더 이상 없었습니다. 이 에이전트를 만든 것은 악의를 가진 누군가가 아니라 무언가를 빨리 해결하고 싶었던 현업 부서들이었습니다. 10년 전, 오늘날까지 아무도 정리하지 않은 Service Principal이 생겨난 방식이 바로 이랬습니다. 에이전트는 이 패턴을 반복하고 있으며, 다만 더 빠르고 더 큰 규모로 반복합니다.

라이선스가 할 수 없는 것

E7은 E5, Copilot, Entra Suite, Agent 365를 하나로 묶습니다. 패키지에 무엇이 들어 있는지는 이미 충분히 설명되어 있습니다. 하지만 라이선스가 테넌트를 정리해 주지는 않습니다. 라이선스는 에이전트를 보고, 식별하고, 통제할 수 있는 도구를 줄 뿐입니다. 어떤 에이전트가 존재해야 하는지, 누가 그 에이전트를 책임지는지, 그 에이전트가 무엇에 접근해도 되는지는 라이선스가 결정하지 않습니다.

여기에 속도가 더해집니다. 오늘날 에이전트는 예전에 Excel 매크로가 생겨나던 곳, 즉 현업 부서에서 티켓 없이 빠르게 만들어집니다. 이는 의도된 일이고, 저희도 좋은 일이라고 생각합니다. 하지만 이는 디렉터리에서 사람이 아닌 계정의 수가 다른 어떤 그룹보다 빠르게 늘어난다는 뜻이기도 합니다.

레지스트리가 보여 주는 것과 보여 주지 않는 것

Agent 365는 Microsoft 365, Copilot Studio, Power Platform, Foundry의 에이전트를 한곳에 모읍니다. Defender for Endpoint는 여기에 더해 클라이언트에 로컬로 설치된 AI 에이전트와 그에 구성된 MCP 서버까지 찾아냅니다. 두 정보 모두 Advanced Hunting에 수집되어 KQL로 함께 분석할 수 있습니다. 말 그대로 Shadow AI입니다.

저희는 다음 쿼리로 실제로 어떤 에이전트가 호출되고 그 과정에서 어떤 도구를 사용하는지 살펴봅니다.

CloudAppEvents
| where ActionType in ("InvokeAgent", "InferenceCall", "ExecuteToolBySDK", "ExecuteToolByGateway")
| extend RawEventData_parsed = parse_json(RawEventData)
| extend
    Workload          = coalesce(tostring(RawEventData_parsed["Workload"]), "Unknown"),
    TargetAgentName   = coalesce(tostring(RawEventData_parsed["TargetAgentName"]), "Unknown"),
    AgentName         = coalesce(tostring(RawEventData_parsed["AgentName"]), "Unknown"),
    AgentBlueprintId  = coalesce(tostring(RawEventData_parsed["AgentBlueprintId"]), "Unknown"),
    PlatformAgentType = coalesce(
        tostring(RawEventData_parsed["PlatformAgentType"]),
        tostring(RawEventData_parsed["CopilotEventData"]["PlatformAgentType"]),
        "Unknown"
    )
| project-away RawEventData_parsed
| summarize count() by ActionType, Workload, TargetAgentName, PlatformAgentType, AgentName, AgentBlueprintId

한 가지 제약이 있습니다. 이 쿼리는 전체 그림의 일부만 보여 줍니다. 주로 Microsoft 자체 에이전트와 Microsoft 플랫폼 위에서 만들어진 에이전트입니다. 그 밖에서 돌아가는 것은 여기서 보이지 않습니다.

클라이언트의 로컬 에이전트에는 Defender for Endpoint Plan 2로 충분합니다.

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend AgentMetadata = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(AgentMetadata.vendor),
         Device = tostring(AgentMetadata.deviceName)
| summarize DeviceCount = dcount(Device) by Agent = Name, Vendor
| sort by DeviceCount desc

사용자를 대신해 동작하는 에이전트는 그 사용자의 권한을 물려받습니다. 그 사용자가 지나치게 넓게 공유된 SharePoint 라이브러리에 접근할 수 있다면 에이전트도 마찬가지입니다. 다만 에이전트는 어떤 사람보다 빠르고 철저할 뿐입니다.

자체 ID를 가진 자율 에이전트는 자체 권한으로 작업합니다. 이런 에이전트에는 회사 데이터에 접근하는 다른 모든 계정과 마찬가지로 책임자, 깔끔한 권한 프로필, 만료일이 필요합니다.

레지스트리는 무엇이 있는지 보여 줍니다. 그것이 있어야 하는지는 누군가가 평가해야 하며, 이 평가는 결코 끝나지 않습니다.

에이전트에게 필요한 것은 예외가 아니라 ID

Entra Agent ID로 만든 에이전트는 자체적으로 관리되는 ID를 받습니다. Agent Blueprints를 사용하면 에이전트가 존재하기도 전에 그 에이전트가 어떻게 구성되고 어떤 권한을 받을지 정할 수 있습니다. 그리고 Entra ID Governance를 통해 액세스 검토와 수명 주기 관리가 에이전트에도 적용됩니다. 생성, 승인, 책임자 지정, 정기 검토, 만료까지입니다.

Conditional Access는 에이전트 ID와 Blueprints에 적용할 수 있지만, 사람에게 적용할 때와 일대일로 같지는 않습니다. “모든 사용자”를 대상으로 하는 정책은 에이전트 계정을 포함하지 않으며, API 키로 접근하는 경우에는 Entra를 완전히 우회합니다. 정책에 의존하기 전에 이런 공백을 알고 있어야 합니다.

당연하게 들립니다. 하지만 실무에서는 안타깝게도 그렇지 않습니다. 저희는 이미 많은 테넌트에서 기존 앱 등록과 Service Principal만 해도 이것이 얼마나 어려운지 보고 있습니다. 방치된 Secret, 어느 테스트 단계에서 남은 권한, 이미 오래전에 다른 곳으로 옮겨 간 책임자. 에이전트는 더 많은 수로, 훨씬 더 많은 사람이 만들기 때문에 이 상황을 나아지게 하지 않습니다.

오늘 Service Principal을 통제하지 못하는 조직은 내일 에이전트도 통제하지 못할 것입니다.

거버넌스는 끝나지 않는 과제

매주 새로운 에이전트가 추가됩니다. 책임자는 역할을 바꾸거나 회사를 떠납니다. 권한은 늘어나고, Conditional Access 규칙에는 예외가 붙고, Sensitivity Label은 아무도 관리하지 않습니다. 이 중 어느 것도 Go-live가 있는 프로젝트가 아니라 운영입니다.

그리고 저희는 바로 그렇게 접근합니다. Managed Entra로 저희는 고객의 Entra ID를 완전히 코드로 운영합니다. 기술적인 세부 사항처럼 들리지만, 이것이 운영이 안정적으로 돌아가는 진짜 이유입니다.

많은 기업이 ITIL에 따른 깔끔한 변경 프로세스를 갖추고 있습니다. 티켓에는 무엇을 바꿔야 하는지 적혀 있고, 그다음 포털에서 클릭합니다. 그런데 정확히 그것만 바뀌었고 다른 것은 바뀌지 않았는지 누가 확인할까요?

저희는 설명이 아니라 변경 자체를 검토합니다. 규칙은 코드로 존재합니다. 무엇이 바뀌는지 사전에 명확하게 정해져 있습니다. 두 번째 사람이 정확히 그 내용을 승인하고, 오직 그것만 이름과 날짜와 함께 배포됩니다. 그래도 문제가 생기면 마지막으로 정상 작동하던 상태가 야간 작업이 아니라 몇 분 안에 복원됩니다.

예외도 같은 경로를 거칩니다. 고객에게 표준과 다른 설정이 필요하면, 그 예외는 Excel 목록이나 어느 관리자의 머릿속이 아니라 리포지토리에 기록됩니다. 예외는 눈에 보이고, 버전이 관리되며, 다른 모든 변경과 똑같이 검토됩니다. 그래서 몇 달에 걸쳐 베이스라인이 서서히 흐려지지 않고, 다음 감사 때 테넌트가 어떻게 구성되어 있고 누가 언제 무엇을 바꿨는지에 대한 증빙이 이미 준비되어 있습니다.

그리고 저희는 에이전트에 요구하는 것을 저희 스스로에게도 적용합니다. 저희의 자동화 역시 사람이 아닌 ID입니다. 이 자동화는 저장된 Secret 없이 페더레이션 ID를 통해 고객 테넌트에 로그인합니다. 권한은 분리되어 있습니다. 한 ID는 읽기와 계획만 할 수 있고, 다른 ID만 쓰기를 할 수 있습니다. 유출될 수 있는 비밀번호도, 언젠가 조용히 만료되는 인증서도 없습니다.

에이전트 자체에 대해서는 저희도 한창 작업 중입니다. Conditional Access, Access Review, Entitlement Management는 이미 코드로 운영하고 있습니다. 지금 만들고 있는 것은 ID, 권한, Conditional Access, 책임자, 만료일을 포함한 리포지토리 내 에이전트 템플릿, 그리고 커뮤니티의 Maester 검사 등을 활용한 방치된 에이전트 ID 자동 점검입니다. 에이전트가 수백 개에 이르면 이것이 파악과 희망 사이의 차이를 만듭니다.

Purview가 에이전트가 읽고 전달하는 데이터를 어떻게 보호하는지, 그리고 저희 CSOC가 에이전트의 활동을 어떻게 모니터링하는지는 AI 거버넌스에 관한 별도의 글에서 다룹니다.

그렇다면 Azure의 에이전트는?

Agent 365는 Microsoft Foundry에서 실행되는 에이전트도 봅니다. 하지만 누군가는 그 아래의 플랫폼, 즉 모델, 네트워크, 데이터 연결, 평가를 구축하고 운영해야 합니다. 이를 위해 저희는 AI Foundation을 완전히 코드로 구축했습니다. 그래서 새로운 AI 프로젝트는 모두 이전 프로젝트와 같은 가드레일을 갖추고 시작합니다. 자세한 내용은 세 가지 Foundation에 관한 저희 글 The Holy Trinity에서 볼 수 있습니다.

가장 중요한 것은 아래쪽과의 연결입니다. AI Foundation의 모든 에이전트는 나머지 환경과 같은 Entra 안에 자체 ID를 받고, 정확히 필요한 권한만 갖습니다. 사용자를 대신해 동작할 때는 그 사용자가 볼 수 있는 것만 봅니다. 그리고 검증할 수 있는 흔적을 남깁니다. 에이전트가 Microsoft 365가 아니라 Azure에서 실행된다는 이유만으로 별도 계정과 별도 예외를 둔 특별 경로는 없습니다.

내일 아침을 위한 세 가지 질문

현재 위치를 알고 싶다면 세 가지 질문으로 시작할 수 있습니다.

1. 활성 Owner나 Sponsor가 더 이상 없는 에이전트는 무엇인가?
2. 12개월보다 오래된 Secret을 가진 Service Principal은 무엇인가?
3. Entra가 아니라 API 키로 접근하는 에이전트는 무엇인가?

세 질문 모두에 빠르게 답할 수 있다면 대부분의 조직보다 앞서 있는 것입니다.

저희가 시작하는 지점

현재 상태에서 시작합니다. 에이전트는 이미 존재하기 때문입니다. 이틀간의 Agent 365 워크숍에서 저희는 여러분의 테넌트에서 어떤 에이전트가 돌아가고 있고 그것이 어디에서 왔는지 드러냅니다. 워크숍이 끝나면 여러분은 인벤토리, 리스크 현황, 그리고 책임이 명확한 거버넌스 계획을 갖게 됩니다.

결론

E7은 실제 문제를 다룹니다. 하지만 무엇이 돌아가고 있는지 보인다고 해서 그것을 통제하고 있다는 뜻은 아닙니다. 그러려면 누군가가 매일 들여다보고, ID를 관리하고, 권한을 줄이고, 에이전트가 어제와 갑자기 다르게 동작하면 알아차려야 합니다.

라이선스는 시작입니다. 결정은 운영이 합니다.

E7을 이미 사용 중이거나 여러분의 환경에서 에이전트가 늘어나는 것을 보고 계신가요? 그리고 누가 이것을 실제로 관리하고 있는지 궁금하신가요? 연락 주세요. 여러분의 환경에서 무엇이 돌아가고 있고 그중 무엇을 남겨도 되는지 함께 살펴보겠습니다. Microsoft가 지원 프로그램을 통해 시작을 지원합니다. 여러분에게 맞는지는 함께 확인하겠습니다.