From 490fcab89f60547740b4c8eb7073ded9af60d601 Mon Sep 17 00:00:00 2001
From: daeungo1 <daeungo@microsoft.com>
Date: Wed, 7 Oct 2026 14:05:23 +0900
Subject: [PATCH] docs(docs): reframe frontier agent research around CUA trend
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- position dots and Muse as reference designs beyond screen-level CUA
- add API, structured browser, and pixel CUA action comparison
- map Foundry Browser Automation and computer use preview tools
- add screen action guidance, rollout stage, and checklist items

📝 - Generated by Copilot

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../frontier-agent/azure-readiness/index.md   | 118 +++++++++++++++---
 .../images/azure-frontier-agent-mapping.svg   |   3 +
 .../frontier-agent/index.md                   | 116 +++++++++++++----
 .../frontier-agent/meta-muse/index.md         |   3 +
 .../frontier-agent/openai-dots/index.md       |   4 +-
 5 files changed, 201 insertions(+), 43 deletions(-)

diff --git a/docs/services/application-development/frontier-agent/azure-readiness/index.md b/docs/services/application-development/frontier-agent/azure-readiness/index.md
index fbdfcfc..5fa214f 100644
--- a/docs/services/application-development/frontier-agent/azure-readiness/index.md
+++ b/docs/services/application-development/frontier-agent/azure-readiness/index.md
@@ -1,15 +1,15 @@
 ---
 title: "Agent 서비스 준비: Frontier Agent 패턴을 Azure에 매핑하기"
-description: dots와 Muse의 여섯 구성 요소를 Foundry hosted agent, routines, memory, toolbox 승인, Prompt Shields, Entra Agent ID, Agent 365에 대응시키고, 플랫폼이 제공하는 부분과 직접 설계할 제어면을 구분해 단계별 도입 순서를 제안합니다.
+description: dots와 Muse의 여섯 구성 요소를 Foundry hosted agent, routines, memory, toolbox 승인, Browser Automation과 computer use 도구, Prompt Shields, Entra Agent ID, Agent 365에 대응시키고, 플랫폼이 제공하는 부분과 직접 설계할 제어면을 구분해 단계별 도입 순서를 제안합니다.
 document_type: research
 topic_order: 3
 services: [application-development, microsoft-foundry, microsoft-entra-id]
-technologies: [mcp]
+technologies: [mcp, computer-use]
 tags: [design, secure, evaluate, ai-agents]
 status: current
 verification_status: verified
 published_at: 2026-09-30
-sources_checked_at: 2026-09-30
+sources_checked_at: 2026-10-07
 official_sources:
   - title: What are hosted agents?
     url: https://learn.microsoft.com/azure/foundry/agents/concepts/hosted-agents
@@ -23,6 +23,10 @@ official_sources:
     url: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/toolbox
   - title: Using function tools with human in the loop approvals
     url: https://learn.microsoft.com/agent-framework/agents/tools/tool-approval
+  - title: Use the computer use tool for agents (preview)
+    url: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use
+  - title: Automate browser tasks with the Browser Automation tool (preview)
+    url: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation
   - title: Prompt Shields in Microsoft Foundry
     url: https://learn.microsoft.com/azure/foundry/openai/concepts/content-filter-prompt-shields
   - title: What is the Microsoft agent identity platform
@@ -37,7 +41,8 @@ official_sources:
 
 # Agent 서비스 준비: Frontier Agent 패턴을 Azure에 매핑하기
 
-**조사 기준일: 2026-09-30.** [dots](../openai-dots/index.md)와
+**조사 기준일: 2026-09-30. 화면 조작 도구 보강: 2026-10-07.**
+[dots](../openai-dots/index.md)와
 [Muse](../meta-muse/index.md)는 소비자·업무용 완제품이다. 우리가 준비하는 Agent
 서비스는 대개 조직의 데이터와 시스템 위에서 동작하는 **자체 에이전트**다. 두 제품이
 보여 준 설계를 그대로 복제할 수는 없지만, 같은 여섯 구성 요소를 Azure에서 어떻게
@@ -47,13 +52,15 @@ official_sources:
 
 - frontier agent의 여섯 구성 요소 가운데 Azure 플랫폼이 이미 제공하는 것은 무엇인가?
 - 플랫폼이 제공하지 않아 **직접 설계해야 하는 부분**은 어디인가?
+- API가 없는 시스템을 다루는 화면 조작(CUA)은 어떤 도구로, 어떤 순서로 도입하는가?
 - 어떤 순서로 도입해야 위험을 통제하면서 가치를 빨리 확인할 수 있는가?
 
 ## 조사 범위와 방법
 
 - Microsoft Learn에서 Foundry Agent Service의 hosted agent, routines, reminder tool,
-  memory, toolbox와 도구 승인, Prompt Shields, Microsoft Entra Agent ID, Microsoft
-  Agent 365 문서를 검색하고 원문 전체를 확인했다.
+  memory, toolbox와 도구 승인, Browser Automation과 computer use 도구, Prompt
+  Shields, Microsoft Entra Agent ID, Microsoft Agent 365 문서를 검색하고 원문
+  전체를 확인했다.
 - 각 문서의 preview 표시, 제한, 지역, 전제 조건을 표에 함께 적었다.
 - 실제 배포나 성능 측정은 하지 않았다. 권장 구성은 공식 문서의 기능 범위에 이
   리서치의 설계 판단을 더한 것이며, 판단에 해당하는 부분은 “권고”로 구분한다.
@@ -62,7 +69,8 @@ official_sources:
 
 | 구성 요소 | dots·Muse의 구현 | Azure에서 확인한 기능 | 직접 설계할 부분 |
 |---|---|---|---|
-| 전용 실행 환경 | 사용자·dot별 지속 클라우드 컴퓨터와 브라우저 | Foundry hosted agent의 세션별 VM 격리 sandbox, `$HOME`·`/files` 지속, state store | 세션을 넘는 사용자 단위 작업 공간 설계, 브라우저 실행 환경(이 리서치 범위 밖) |
+| 전용 실행 환경 | 사용자·dot별 지속 클라우드 컴퓨터와 브라우저 | Foundry hosted agent의 세션별 VM 격리 sandbox, `$HOME`·`/files` 지속, state store | 세션을 넘는 사용자 단위 작업 공간 설계 |
+| 화면 조작 | dots의 자체 브라우저, Muse의 accessibility tree 기반 브라우저 sub-agent와 사용자 조작 인계 | Browser Automation 도구(preview, DOM 기반, Playwright Workspaces, Live View·Take control), computer use 도구(preview, 스크린샷 기반) | API 우선 경로 선택, computer use 실행 루프와 sandbox, safety check를 승인 흐름에 연결 |
 | 상시 실행과 선제성 | 24/7 동작, 읽기 전용 proactive research, 이벤트 기반 후속 작업 | routines(schedule, timer, GitHub issue, Teams 메시지), reminder tool(preview), Responses background 모드 | 읽기 전용 선제 작업과 쓰기 작업의 실행 경로 분리 |
 | 연결 | Plugin 4,000개 이상, connector와 SKILL | Toolbox MCP endpoint, Toolbox의 통합 인증 | 업무 시스템별 읽기·쓰기 권한 분리와 도구 위험 등급 |
 | 기억과 개인화 | 피드백 학습, 편집 가능한 Memory 파일 | Foundry memory(preview): 프로필·대화 요약·절차 기억, 항목 CRUD, TTL | 사용자에게 기억을 보여 주고 지우는 UI, memory 오염 대응 |
@@ -70,7 +78,7 @@ official_sources:
 | 투명성과 통제 | Activity View, 활동 로그, 승인 카드, 목표 화면 | Application Insights 자동 연결과 OpenTelemetry trace, Agent 365 registry | 사용자용 활동 로그·승인 UI와 행동 감사 기록 |
 | 에이전트 신원 | specialist dots의 조직 부여 신원·자격 증명 | 에이전트별 Microsoft Entra ID(agent identity), OBO, Entra Agent ID, Agent 365 | 에이전트별 최소 권한 RBAC와 수명 주기 정책 |
 
-![채널에서 들어온 요청을 Foundry hosted agent가 세션별 VM 격리 sandbox에서 처리하고, 모든 도구 호출과 외부 행동은 직접 구축하는 제어면의 정책·승인 서비스, 자격 증명 경계, egress 제어, 행동 감사 기록을 거쳐 Toolbox, Foundry 모델, Azure 리소스, 외부 SaaS에 도달한다. 하단에는 Application Insights, Microsoft Entra Agent ID, Microsoft Agent 365로 구성된 관측과 거버넌스 계층이 있다](../images/azure-frontier-agent-mapping.svg)
+![채널에서 들어온 요청을 Foundry hosted agent가 세션별 VM 격리 sandbox에서 처리하고, 모든 도구 호출과 외부 행동은 직접 구축하는 제어면의 정책·승인 서비스, 자격 증명 경계, egress 제어, 행동 감사 기록을 거쳐 Toolbox, Foundry 모델, Azure 리소스, 외부 SaaS, Browser Automation과 computer use 같은 화면 조작 도구에 도달한다. 하단에는 Application Insights, Microsoft Entra Agent ID, Microsoft Agent 365로 구성된 관측과 거버넌스 계층이 있다](../images/azure-frontier-agent-mapping.svg)
 
 *그림 1. 이 리서치가 제안하는 Azure 참조 구성. 파란색은 Microsoft Learn에서 확인한
 플랫폼 기능, 점선 주황색은 직접 설계해야 하는 영역이다.*
@@ -156,6 +164,51 @@ endpoint**로 연결한다. Toolbox에는 Code Interpreter, Web Search, Azure AI
 OpenAPI, MCP, A2A, Skills 같은 Foundry 관리 도구가 포함되며, OAuth identity
 passthrough, agent identity, 키 기반 인증을 한곳에서 처리한다.
 
+### 화면 조작: Browser Automation과 computer use
+
+API가 없는 시스템을 다뤄야 할 때 Foundry는 두 가지 화면 조작 도구를 제공한다.
+둘 다 **preview**다. [computer use 문서][computer-use]의 비교를 기준으로 정리하면
+다음과 같다.
+
+| 항목 | [Browser Automation][browser-automation] | [computer use][computer-use] |
+|---|---|---|
+| 화면 인식 | HTML·XML 페이지를 DOM으로 해석 | 스크린샷의 원시 픽셀 |
+| 행동 방식 | 모델이 제시한 브라우저 동작 목록 | 가상 키보드와 마우스 |
+| 대상 | 브라우저 | 컴퓨터와 브라우저(데스크톱 앱 포함) |
+| 모델 | 모든 GPT 모델 | `computer-use-preview` 모델만, 별도 접근 신청 필요 |
+| 실행 환경 | Playwright Workspaces의 관리형 원격 브라우저(Playwright 리소스와 연결 필요) | 별도 리소스는 필요 없지만, 애플리케이션이 sandbox와 실행 루프를 직접 구성 |
+| 사람 개입 | Live View로 실시간 확인, Take control로 사람이 세션에 개입 | `pending_safety_checks`가 오면 최종 사용자 확인 후 `acknowledged_safety_checks`로 진행 |
+| 지역 | australiaeast, eastasia, eastus, japaneast, switzerlandnorth, westeurope, westus3 | eastus2, swedencentral, southindia |
+
+**Browser Automation**은 Foundry 에이전트가 Playwright Workspaces가 제공하는 관리형
+브라우저 세션에서 페이지를 탐색하고, 요소를 찾고, 입력하는 MCP 도구다. Toolbox에
+추가해 여러 에이전트에서 재사용할 수 있다. 문서는 Live View, 스크린샷 기록, 실행
+요약, trace를 확인·운영 검토 수단으로 제시한다. 동시에 **자격 증명 입력, 결제 같은 민감한 행동을
+요구하는 페이지는 피하고 신뢰하는 사이트에서만 쓰라**는 제한을 명시한다. 페이지
+변경과 JavaScript 비중이 큰 SPA에서 실패할 수 있다는 점도 적혀 있다.
+
+**computer use**는 모델이 행동을 제안할 뿐 기기를 직접 제어하지 않는다.
+애플리케이션이 요청받은 클릭·입력·스크롤을 실행하고, 갱신된 스크린샷을 다시 보내는
+루프(screenshot → action → screenshot)를 구현해야 한다. 서비스는 다음 상황에서
+`pending_safety_checks`를 반환한다.
+
+- 스크린샷에 모델의 행동을 바꾸려는 악성 지시가 있을 때(`malicious_instructions`)
+- 현재 도메인이 대화 맥락과 무관할 때(`irrelevant_domain`)
+- 민감한 도메인에 있을 때(`sensitive_domain`). 이때는 최종 사용자가 행동을 계속
+  지켜보는 “watch mode” 구현을 요구한다.
+
+문서는 민감한 데이터나 중요 리소스에 접근할 수 없는 VM에서만 쓰라고 경고한다.
+
+dots와 Muse의 설계와 비교하면 차이가 분명하다.
+
+- Muse는 브라우저 로그인 정보를 모델 밖 보안 저장소에서 주입하고 결제에 일회용
+  카드를 쓴다. 반면 Browser Automation 문서는 자격 증명·결제 페이지를 피하라고
+  안내한다. **로그인과 결제를 에이전트에 맡기는 기능은 Azure 도구만으로 채워지지
+  않는다.**
+- Muse의 사용자 조작 인계와 Browser Automation의 Take control은 같은 방향의 기능이다.
+- computer use의 safety check는 Muse의 분류기 층에 해당하지만, 진행 여부를 사용자에게
+  묻고 기록하는 흐름은 애플리케이션이 만든다.
+
 ### 신원: agent identity, Entra Agent ID, Agent 365
 
 - 각 hosted agent는 배포 시 전용 Microsoft Entra ID(agent identity)를 자동으로 받는다.
@@ -242,19 +295,38 @@ Muse는 분류기를 한 층으로만 보고, 분류기를 통과한 공격도 
   목적지와 요청을 검사하는 egress 통제는 이 고객 네트워크 경로에 직접 구성하는 것을
   권고한다.
 
+### 화면 조작 경로의 선택과 통제
+
+화면 조작은 가장 강력하지만 가장 위험한 행동 수단이다. 다음을 권고한다.
+
+1. **API → 브라우저 자동화 → computer use 순서로 경로를 고른다.** 같은 작업을 API나
+   MCP 도구로 할 수 있으면 화면 조작을 쓰지 않는다. 브라우저 안의 작업이면 DOM을
+   해석하는 Browser Automation을, 데스크톱 앱이나 DOM을 쓸 수 없는 화면만 computer
+   use로 처리한다.
+2. **computer use의 safety check를 정책·승인 서비스의 입력으로 연결한다.**
+   `pending_safety_checks`를 받으면 자동으로 확인 처리하지 말고, 승인 UI로 사용자에게
+   행동과 사유를 보여 준 뒤 결과를 감사 기록에 남긴다.
+3. **화면 조작 sandbox는 업무 데이터와 분리한다.** computer use는 민감 데이터와 중요
+   리소스에 접근할 수 없는 VM에서 실행하고, 그 VM의 아웃바운드도 egress 제어를
+   거치게 한다.
+4. **로그인·결제 화면은 에이전트에 맡기지 않는다.** Azure 도구에는 dots·Muse식
+   비밀번호 주입이나 일회용 결제 수단이 없다. 이런 단계는 사람에게 넘기거나(Take
+   control), 별도 자격 증명 경계를 설계한 뒤에만 자동화한다.
+
 ## 권고: 단계별 도입 순서
 
 | 단계 | 목표 | 핵심 구성 | 넘어가는 조건 |
 |---|---|---|---|
 | 0. 읽기 전용 비서 | 선제 조사의 가치 검증 | hosted agent, 읽기 전용 Toolbox 도구, schedule routine, Application Insights | 사용자가 유용하다고 판단한 알림 비율과 오탐 비율을 측정 |
 | 1. 승인 기반 실행 | 쓰기 행동의 안전한 도입 | 정책·승인 서비스, 채널 승인 UI, Prompt Shields, 행동 감사 기록 | 승인 요청 대비 거부율, 승인 피로 지표, 차단 사유 분포 확인 |
-| 2. 기억과 개인화 | 반복 설명 제거 | Foundry memory(preview), 기억 열람·삭제 UI, reminder tool(preview) | 기억 품질 평가와 memory 오염 시나리오 적대적 테스트 통과 |
-| 3. 전담 에이전트 | 조직 업무를 맡는 specialist 에이전트 | agent identity별 최소 권한 RBAC, Entra Agent ID, egress 통제 | 업무 책임·도구·검토 방식을 업무 담당자와 문서로 합의 |
-| 4. 거버넌스 통합 | 조직 전체의 에이전트 관리 | Microsoft Agent 365 registry, Purview, Defender | 자체·외부 에이전트를 같은 registry에서 관찰 |
+| 2. API 없는 시스템 연결 | 레거시 포털·웹 업무 처리 | Browser Automation(preview), Take control, 필요 시 sandbox VM의 computer use(preview) | 화면 변경 시 실패율, safety check 발생 빈도와 사용자 확인 흐름 검증 |
+| 3. 기억과 개인화 | 반복 설명 제거 | Foundry memory(preview), 기억 열람·삭제 UI, reminder tool(preview) | 기억 품질 평가와 memory 오염 시나리오 적대적 테스트 통과 |
+| 4. 전담 에이전트 | 조직 업무를 맡는 specialist 에이전트 | agent identity별 최소 권한 RBAC, Entra Agent ID, egress 통제 | 업무 책임·도구·검토 방식을 업무 담당자와 문서로 합의 |
+| 5. 거버넌스 통합 | 조직 전체의 에이전트 관리 | Microsoft Agent 365 registry, Purview, Defender | 자체·외부 에이전트를 같은 registry에서 관찰 |
 
 각 단계는 이전 단계의 제어면을 유지한 채 권한을 넓힌다. 특히 1단계의 정책·승인
-서비스를 건너뛰고 2단계 이후 기능을 먼저 붙이면, 기억과 선제 실행이 합쳐져 위험이 가장
-큰 조합이 된다.
+서비스를 건너뛰고 화면 조작이나 기억 기능을 먼저 붙이면, 비신뢰 콘텐츠 노출과 선제
+실행이 합쳐져 위험이 가장 큰 조합이 된다.
 
 ## 도입 전 점검표
 
@@ -268,13 +340,21 @@ Muse는 분류기를 한 층으로만 보고, 분류기를 통과한 공격도 
       적용했다.
 - [ ] 아웃바운드 트래픽이 고객 VNet 경로의 검사 지점을 통과한다.
 - [ ] 사용자가 활동 로그를 보고, 작업을 중단하고, 기억을 삭제할 수 있다.
-- [ ] preview 기능(memory, reminder tool, Spotlighting)의 사용 범위와 대체 방안을 정했다.
-- [ ] Routines를 쓸 프로젝트가 미지원 지역이나 CMK 요구 대상이 아닌지 확인했다.
+- [ ] 화면 조작은 API로 처리할 수 없는 작업에만 쓰며, computer use의 safety check는
+      자동 확인하지 않고 사용자 승인 흐름으로 보낸다.
+- [ ] computer use를 실행하는 VM에는 민감 데이터와 중요 리소스에 대한 접근이 없다.
+- [ ] preview 기능(memory, reminder tool, Spotlighting, Browser Automation, computer use)의
+      사용 범위와 대체 방안을 정했다.
+- [ ] Routines, Browser Automation, computer use를 쓸 프로젝트가 각 기능의 지원 지역에
+      있는지, Routines의 CMK 제한에 걸리지 않는지 확인했다.
 
 ## 한계
 
-- 브라우저를 직접 조작하는 computer use 기능, 결제 보호, 사용자 비밀번호 주입처럼
-  dots와 Muse가 제공하는 일부 기능은 이번 조사에서 Azure 대응 기능을 확인하지 않았다.
+- 사용자 비밀번호를 모델 밖에서 주입하는 기능과 결제 보호(일회용 카드 등)는 이번
+  조사에서 Azure 대응 기능을 확인하지 못했다. Browser Automation 문서는 오히려
+  자격 증명·결제 페이지를 피하라고 안내한다.
+- Browser Automation과 computer use는 문서 기준으로만 비교했고 실제 성공률, 지연,
+  비용은 측정하지 않았다.
 - Preview 기능은 동작과 제한이 바뀔 수 있다. 적용 전 해당 문서를 다시 확인해야 한다.
 - 정책·승인 서비스와 egress 검사의 구체적 구현(제품 선택, 성능, 비용)은 다루지 않았다.
   이는 후속 가이드나 실습에서 검증할 과제다.
@@ -290,6 +370,8 @@ Muse는 분류기를 한 층으로만 보고, 분류기를 통과한 공격도 
 | [Memory in Microsoft Foundry Agent Service (preview)][memory] | 기억 유형, 관리 기능, 보안 위험, 한도와 제한 |
 | [Create and manage a toolbox in Foundry][toolbox] | `require_approval` 설정과 런타임 집행 책임 |
 | [Using function tools with human in the loop approvals][tool-approval] | Agent Framework의 승인 함수와 human-in-the-loop 흐름 |
+| [Use the computer use tool for agents (preview)][computer-use] | 실행 루프, safety check 유형과 처리, sandbox 권고, 지역, Browser Automation과의 비교 |
+| [Automate browser tasks with the Browser Automation tool (preview)][browser-automation] | Playwright Workspaces 기반 동작, Live View·Take control, 지역, 제한 |
 | [Prompt Shields in Microsoft Foundry][prompt-shields] | 공격 유형, 개입 지점, Spotlighting 제한 |
 | [What is the Microsoft agent identity platform][agent-id] | 신원 구성, 인증 방식, 외부 플랫폼 연동, Agent 365 요구 조건 |
 | [Overview of Microsoft Agent 365][agent-365] | observe, govern, secure 범위와 GA 시점 |
@@ -302,6 +384,8 @@ Muse는 분류기를 한 층으로만 보고, 분류기를 통과한 공격도 
 [memory]: https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory
 [toolbox]: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/toolbox
 [tool-approval]: https://learn.microsoft.com/agent-framework/agents/tools/tool-approval
+[computer-use]: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use
+[browser-automation]: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation
 [prompt-shields]: https://learn.microsoft.com/azure/foundry/openai/concepts/content-filter-prompt-shields
 [agent-id]: https://learn.microsoft.com/entra/agent-id/what-is-agent-id-platform
 [agent-365]: https://learn.microsoft.com/microsoft-agent-365/overview
diff --git a/docs/services/application-development/frontier-agent/images/azure-frontier-agent-mapping.svg b/docs/services/application-development/frontier-agent/images/azure-frontier-agent-mapping.svg
index 4487e62..4e614c4 100644
--- a/docs/services/application-development/frontier-agent/images/azure-frontier-agent-mapping.svg
+++ b/docs/services/application-development/frontier-agent/images/azure-frontier-agent-mapping.svg
@@ -101,6 +101,9 @@
   <text x="1002" y="280" class="s" text-anchor="middle">agent identity RBAC</text>
   <text x="1002" y="325" class="b" text-anchor="middle">외부 SaaS</text>
   <text x="1002" y="345" class="s" text-anchor="middle">OAuth passthrough</text>
+  <text x="1002" y="390" class="b" text-anchor="middle">화면 조작 (preview)</text>
+  <text x="1002" y="410" class="s" text-anchor="middle">Browser Automation</text>
+  <text x="1002" y="428" class="s" text-anchor="middle">computer use</text>
 
   <!-- arrows -->
   <line x1="192" y1="270" x2="218" y2="270" stroke="#374151" stroke-width="2" marker-start="url(#arrow)" marker-end="url(#arrow)"/>
diff --git a/docs/services/application-development/frontier-agent/index.md b/docs/services/application-development/frontier-agent/index.md
index eb9a5e0..870a2c7 100644
--- a/docs/services/application-development/frontier-agent/index.md
+++ b/docs/services/application-development/frontier-agent/index.md
@@ -1,6 +1,6 @@
 ---
-title: "Frontier Agent 리서치: OpenAI dots와 Meta Muse로 본 상시 동작형 에이전트"
-description: OpenAI dots와 Meta Muse를 기준으로 전용 컴퓨터, 상시 실행, 분리된 제어면을 갖춘 frontier agent의 구조를 정리하고 Agent 서비스 준비에 필요한 시사점을 도출합니다.
+title: "Frontier Agent 리서치: OpenAI dots와 Meta Muse로 본 CUA의 다음 단계"
+description: OpenAI dots와 Meta Muse를 화면 조작 CUA가 전용 컴퓨터·상시 실행·분리된 제어면을 갖춘 상시 동작형 에이전트로 넘어가는 흐름의 레퍼런스 설계로 분석하고, Agent 서비스 준비에 필요한 시사점을 도출합니다.
 document_type: research
 services: [application-development]
 technologies: [computer-use, mcp]
@@ -8,7 +8,7 @@ tags: [design, evaluate, ai-agents]
 status: current
 verification_status: verified
 published_at: 2026-09-30
-sources_checked_at: 2026-09-30
+sources_checked_at: 2026-10-07
 official_sources:
   - title: Introducing dots
     url: https://openai.com/index/introducing-dots/
@@ -24,14 +24,18 @@ official_sources:
     url: https://learn.microsoft.com/azure/foundry/agents/concepts/hosted-agents
   - title: Overview of Microsoft Agent 365
     url: https://learn.microsoft.com/microsoft-agent-365/overview
+  - title: Use the computer use tool for agents (preview)
+    url: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use
+  - title: Automate browser tasks with the Browser Automation tool (preview)
+    url: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation
 ---
 
-# Frontier Agent 리서치: OpenAI dots와 Meta Muse로 본 상시 동작형 에이전트
+# Frontier Agent 리서치: OpenAI dots와 Meta Muse로 본 CUA의 다음 단계
 
-**조사 기준일: 2026-09-30.** 2026년 9월, OpenAI와 Meta는 거의 같은 시기에
-대화형 비서를 넘어서는 개인 에이전트를 공개했다. Meta는 2026-09-08에
-[Muse][muse]를, OpenAI는 2026-09-29에 [dots][dots]를 발표했다. 두 제품은 이름과
-대상 사용자가 다르지만 구조는 놀라울 만큼 닮았다.
+**조사 기준일: 2026-09-30. CUA 관점 보강: 2026-10-07.** 2026년 9월, OpenAI와
+Meta는 거의 같은 시기에 대화형 비서를 넘어서는 개인 에이전트를 공개했다. Meta는
+2026-09-08에 [Muse][muse]를, OpenAI는 2026-09-29에 [dots][dots]를 발표했다. 두
+제품은 이름과 대상 사용자가 다르지만 구조는 놀라울 만큼 닮았다.
 
 - 사용자마다 **전용 클라우드 컴퓨터와 브라우저**를 준다.
 - 사용자가 앱을 닫아도 **백그라운드에서 계속 일하고 먼저 말을 건다**.
@@ -44,15 +48,66 @@ Meta는 Muse를 “move with the frontier”하는 제품이라고 표현한다.
 frontier agent는 이런 공개 표현에서 따온 **분석용 용어**이며 두 회사가 정의한
 공식 제품 분류가 아니다.
 
+!!! note "이 문서에서 dots와 Muse를 보는 관점"
+    두 제품은 화면을 보고 마우스·키보드로 조작하는 **CUA(Computer-Using Agent)
+    자체의 모범 사례라기보다**, CUA를 하나의 행동 수단으로 포함하면서 실행 환경,
+    상시 실행, 통제 계층까지 갖춘 **상시 동작형 에이전트의 레퍼런스 설계**다.
+    두 제품 모두 출시 직후이고 공개 자료는 각 회사의 주장이므로, 검증된
+    BP(best practice)가 아니라 설계 방향을 비교하는 기준으로 사용한다.
+
 ## 30초 요약
 
 | 질문 | 핵심 판단 |
 |---|---|
 | frontier agent는 무엇이 다른가 | 한 번의 요청에 답하는 챗봇이 아니라, 목표를 받아 **자기 컴퓨터에서 계속 일하는** 에이전트다. 실행 환경, 상시 실행, 기억, 연결, 제어면, 투명성 여섯 요소를 함께 갖춘다. |
+| CUA와의 관계 | CUA가 “화면을 어떻게 조작하는가”의 문제라면, frontier agent는 “어디서, 언제, 어떤 권한으로, 무엇을 막으며 조작하는가”까지 포함한다. 두 제품 모두 **API·connector를 먼저 쓰고 브라우저 조작은 보조 수단**으로 둔다. |
 | dots와 Muse의 공통점 | 사용자별 격리된 클라우드 컴퓨터, 선제적 백그라운드 작업, 모델에 비밀을 보여 주지 않는 자격 증명 처리, 에이전트가 끌 수 없는 별도 행동 검사, 활동 기록과 승인 UI. |
 | 가장 큰 차이 | dots는 업무 협업(Slack·Teams, specialist dots, Microsoft Agent 365 연동 계획)을, Muse는 개인 생활(WhatsApp, 쇼핑, 일회용 카드)을 우선한다. Meta는 VM 내부 격리 구조를 커널 수준까지 공개했다. |
 | 기술적 핵심 | 모델을 믿는 것이 아니라 **모델이 공격받았다고 가정하는 시스템 설계**다. 제안은 에이전트가, 허가는 에이전트 밖의 정책 엔진이 한다. |
-| 우리에게 주는 시사점 | Azure에서는 Foundry hosted agent가 격리 실행·세션 상태·에이전트 신원을 제공하지만, 도구 승인의 **집행**과 egress 검사 같은 제어면은 우리가 설계해야 한다. |
+| 우리에게 주는 시사점 | Azure에서는 Foundry hosted agent가 격리 실행·세션 상태·에이전트 신원을, Browser Automation과 computer use 도구(모두 preview)가 화면 조작 수단을 제공한다. 하지만 도구 승인의 **집행**과 egress 검사 같은 제어면은 우리가 설계해야 한다. |
+
+## CUA 트렌드에서의 위치
+
+### 관심의 이동: 조작 기술에서 운영 모델로
+
+CUA 모델 자체는 행동을 **제안**할 뿐이다. Microsoft Learn의 [Foundry computer use
+도구][computer-use] 문서는 이 구조를 분명히 보여 준다.
+
+- 도구는 기기를 직접 제어하지 않는다. 애플리케이션이 모델이 요청한 행동(클릭,
+  입력, 스크롤)을 실행하고, 갱신된 스크린샷을 다시 보내는 루프를 직접 구현한다.
+- 민감한 데이터나 중요 리소스에 접근할 수 없는 VM이나 sandbox에서 실행하라고
+  경고하며, prompt injection을 포함한 보안·개인정보 위험이 크다고 명시한다.
+- 악성 지시, 작업과 무관한 도메인, 민감한 도메인이 감지되면 `pending_safety_checks`를
+  반환하고, 애플리케이션은 최종 사용자의 확인을 받은 뒤에만 진행해야 한다.
+
+즉 **실행 환경, 행동 실행, 사용자 승인은 모두 애플리케이션의 몫**으로 남는다. dots와
+Muse는 바로 이 빈자리를 제품 수준으로 채운 사례다. 사용자별 격리 컴퓨터를 상시
+운영하고, 비밀번호를 모델 밖에서 처리하고, 에이전트가 끌 수 없는 검사 계층과
+사용자가 조작을 넘겨받는 기능을 붙였다. 그래서 두 제품은 CUA의 경쟁 기술이 아니라
+**CUA를 안전하게 운영하는 방법에 대한 답**으로 읽는 편이 정확하다.
+
+### 에이전트가 행동하는 세 가지 방식
+
+에이전트가 실제 시스템에서 행동하는 방식은 화면을 얼마나 직접 다루는지에 따라
+세 단계로 나눌 수 있다. 이 분류는 이 리서치가 비교를 위해 정리한 것이다.
+
+| 방식 | 대상을 인식하는 방법 | 행동하는 방법 | 장점 | 약점 |
+|---|---|---|---|---|
+| ① API·connector | 구조화된 응답 | 정해진 API·CLI·MCP 도구 호출 | 정확하고 빠르며 권한을 세밀하게 나누기 쉽다 | API가 없는 시스템에는 쓸 수 없다 |
+| ② 구조 기반 브라우저 자동화 | DOM 또는 accessibility tree | 모델이 고른 브라우저 동작 목록 | 대부분의 웹 화면을 다루면서 픽셀보다 해석이 명확하다 | 브라우저 밖은 다룰 수 없고 화면 변경에 취약하다 |
+| ③ 픽셀 기반 CUA | 스크린샷 원시 픽셀 | 가상 마우스와 키보드 | 데스크톱 앱까지 포함해 사람이 쓰는 거의 모든 UI를 다룬다 | 느리고, 실패와 prompt injection 위험이 가장 크다 |
+
+| 방식 | dots | Muse | Azure에서 대응하는 기능 |
+|---|---|---|---|
+| ① API·connector | Plugin으로 4,000개가 넘는 앱에 연결 | connector, CLI, SKILL. 필요하면 connector를 직접 작성 | Toolbox MCP endpoint(OpenAPI, MCP 등) |
+| ② 구조 기반 브라우저 자동화 | 자체 브라우저 사용. 화면 인식 방식은 공개되지 않음 | 브라우저 sub-agent가 원시 DOM이 아닌 **accessibility tree snapshot**만 보고, JavaScript 실행·DevTools를 막음 | [Browser Automation 도구][browser-automation](preview): DOM 해석, Playwright Workspaces의 관리형 브라우저 |
+| ③ 픽셀 기반 CUA | 자체 클라우드 컴퓨터에서 작업하고, 사용자가 허용하면 노트북에도 연결. 화면 인식·조작 방식은 공개되지 않음 | 공개 자료에서 픽셀 기반 데스크톱 조작은 확인되지 않음 | [computer use 도구][computer-use](preview): `computer-use-preview` 모델, 스크린샷 기반 |
+
+두 제품이 공개한 범위에서 공통으로 보이는 원칙은 **“API로 할 수 있으면 API로, 안
+되면 브라우저로”**다. 특히 Muse는 브라우저 에이전트에게 원시 DOM 대신 accessibility
+tree snapshot만 보여 줘서, 에이전트가 관찰할 수 있는 범위 자체를 줄이는 쪽을
+택했다. Azure 도구로 같은 순서를 구현하는 방법은 [Azure 매핑
+문서](azure-readiness/index.md)에서 다룬다.
 
 ## Frontier agent의 여섯 구성 요소
 
@@ -93,38 +148,45 @@ frontier agent는 이런 공개 표현에서 따온 **분석용 용어**이며 
 2. [Meta Muse 해부](meta-muse/index.md): Muse Secure VM의 두 보안 도메인,
    Sentinel, tainted egress, 브라우저 sub-agent, 결제 보호
 3. [Agent 서비스 준비: Azure 매핑](azure-readiness/index.md): Foundry hosted
-   agent, Entra Agent ID, Agent 365로 같은 구조를 구성할 때의 제공 범위와
-   직접 설계할 부분
+   agent, Browser Automation과 computer use 도구, Entra Agent ID, Agent 365로
+   같은 구조를 구성할 때의 제공 범위와 직접 설계할 부분
 
 ## Agent 서비스 준비 관점의 핵심 시사점
 
-두 제품이 공개한 설계에서 우리 서비스에 바로 적용할 수 있는 원칙은 다섯
+두 제품이 공개한 설계에서 우리 서비스에 바로 적용할 수 있는 원칙은 여섯
 가지다.
 
-1. 제안과 허가를 분리한다. 모델이 다음 행동을 제안하면, 모델이 수정할 수
+1. 행동 수단은 API부터 고른다. API·connector로 할 수 있는 일은 API로 하고,
+   브라우저 자동화와 픽셀 기반 CUA는 API가 없는 시스템에만 쓴다.
+2. 제안과 허가를 분리한다. 모델이 다음 행동을 제안하면, 모델이 수정할 수
    없는 위치의 정책 엔진이 허가·거부·사용자 확인 중 하나를 결정한다.
-2. 비밀은 모델 context에 넣지 않는다. 로그인과 토큰 주입은 모델을 멈추거나
+3. 비밀은 모델 context에 넣지 않는다. 로그인과 토큰 주입은 모델을 멈추거나
    경계 밖에서 대체하는 방식으로 처리한다.
-3. 선제 작업은 읽기 전용으로 시작한다. 백그라운드 조사는 쓰기 권한 없이
+4. 선제 작업은 읽기 전용으로 시작한다. 백그라운드 조사는 쓰기 권한 없이
    메모를 남기고, 실제 행동은 일반 승인 규칙을 다시 거친다.
-4. 승인 피로를 설계 대상으로 본다. 되돌리기 어려운 행동만 멈추고, 승인은
+5. 승인 피로를 설계 대상으로 본다. 되돌리기 어려운 행동만 멈추고, 승인은
    대상·범위·기간이 묶인 권한(capability)으로 발급한다.
-5. 보이지 않는 작업은 보이게 만든다. 활동 로그, 목표 화면, 편집 가능한
-   메모리가 신뢰의 근거가 된다.
+6. 보이지 않는 작업은 보이게 만든다. 활동 로그, 목표 화면, 편집 가능한
+   메모리, 사람이 조작을 넘겨받는 기능이 신뢰의 근거가 된다.
 
 Azure에서 이 원칙을 구현할 때 [Foundry hosted agent][hosted-agents]는 세션별
 VM 격리 sandbox, 지속 파일 시스템, 에이전트별 Microsoft Entra ID를 제공한다.
-[Microsoft Agent 365][agent-365]는 조직 안의 에이전트를 관찰·통제·보호하는
-관리 계층이다. 반면 행동 승인을 집행하는 정책 서비스와 egress 검사 계층은
-플랫폼 기능만으로 완성되지 않는다. 자세한 대응 관계와 단계별 도입 순서는
-[Azure 매핑 문서](azure-readiness/index.md)에서 정리한다.
+화면 조작 수단으로는 [Browser Automation][browser-automation]과 [computer
+use][computer-use] 도구가 있으며 둘 다 preview다. [Microsoft Agent
+365][agent-365]는 조직 안의 에이전트를 관찰·통제·보호하는 관리 계층이다. 반면
+행동 승인을 집행하는 정책 서비스와 egress 검사 계층은 플랫폼 기능만으로
+완성되지 않는다. 자세한 대응 관계와 단계별 도입 순서는 [Azure 매핑
+문서](azure-readiness/index.md)에서 정리한다.
 
 ## 조사 범위와 한계
 
-- 기준일은 2026-09-30이다. 두 제품은 출시 직후이며 기능, 요금, 제공 지역은
-  빠르게 바뀔 수 있다.
+- 기준일은 2026-09-30이며, CUA 관점 비교와 Azure 화면 조작 도구는 2026-10-07에
+  보강했다. 두 제품은 출시 직후이며 기능, 요금, 제공 지역은 빠르게 바뀔 수 있다.
 - 제품 동작과 보안 구조는 **각 회사가 공개한 자료의 주장**이다. 이
   리서치는 두 제품을 직접 실행하거나 보안 주장을 독립적으로 검증하지 않았다.
+  따라서 두 제품을 검증된 모범 사례가 아니라 레퍼런스 설계로 다룬다.
+- dots는 화면을 인식하고 조작하는 방식을 공개하지 않았다. 행동 방식 비교표의
+  dots 항목은 공개된 범위만 적었다.
 - 모델 성능, 가격, 벤치마크 수치는 다루지 않는다. 언론 보도와 제3자 요약은
   근거에서 제외하고 각 회사의 공식 페이지만 사용했다.
 - Azure 기능은 Microsoft Learn 원문으로 확인했으며, preview 기능은 문서에
@@ -138,9 +200,11 @@ VM 격리 sandbox, 지속 파일 시스템, 에이전트별 Microsoft Entra ID
 | [How we build safety, security, and privacy into dots][dots-safety] | Auto-review, secure sign-in, proactive research, 행동 규칙 |
 | [Muse 제품 페이지][muse] | Muse Secure VM, connector, 승인과 감사 추적, 요금 방식 |
 | [How We Designed Muse][muse-design] | 대화 모델, 선제 메시지, 결정적 UI, Artifacts |
-| [How We Built Safety Into Muse][muse-security] | VM 내부 격리, Sentinel, 모델 이름, 결제 보호 |
+| [How We Built Safety Into Muse][muse-security] | VM 내부 격리, Sentinel, 모델 이름, 브라우저 sub-agent, 결제 보호 |
 | [What are hosted agents?][hosted-agents] | Foundry hosted agent의 격리 모델과 에이전트 신원 |
 | [Overview of Microsoft Agent 365][agent-365] | Agent 365의 observe, govern, secure 범위 |
+| [Use the computer use tool for agents (preview)][computer-use] | 픽셀 기반 CUA의 실행 루프, sandbox 권고, safety check 처리 |
+| [Automate browser tasks with the Browser Automation tool (preview)][browser-automation] | DOM 기반 브라우저 자동화와 computer use의 차이 |
 
 [dots]: https://openai.com/index/introducing-dots/
 [dots-safety]: https://openai.com/index/how-we-build-safety-security-and-privacy-into-dots/
@@ -149,3 +213,5 @@ VM 격리 sandbox, 지속 파일 시스템, 에이전트별 Microsoft Entra ID
 [muse-security]: https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
 [hosted-agents]: https://learn.microsoft.com/azure/foundry/agents/concepts/hosted-agents
 [agent-365]: https://learn.microsoft.com/microsoft-agent-365/overview
+[computer-use]: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use
+[browser-automation]: https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation
diff --git a/docs/services/application-development/frontier-agent/meta-muse/index.md b/docs/services/application-development/frontier-agent/meta-muse/index.md
index ff1bcf5..bf6d70b 100644
--- a/docs/services/application-development/frontier-agent/meta-muse/index.md
+++ b/docs/services/application-development/frontier-agent/meta-muse/index.md
@@ -254,6 +254,9 @@ Foundry에서는 document attack을 **사용자 입력과 도구 응답** 두 
 - 작업마다 전용 **브라우저 sub-agent**를 쓴다. sub-agent는 원시 DOM이 아닌
   **accessibility tree snapshot**만 본다. 페이지에서 JavaScript를 실행할 수 없고,
   브라우저 프로세스에서 명령을 실행할 수 없으며, DevTools도 비활성화되어 있다.
+  스크린샷 픽셀을 보고 마우스·키보드를 움직이는 CUA라기보다 **구조 기반 브라우저
+  자동화**에 가깝고, 에이전트가 관찰할 수 있는 정보 자체를 좁힌 설계다. 행동 방식
+  비교는 [개요 문서](../index.md)의 CUA 트렌드 섹션에서 다룬다.
 - 사용자가 브라우저를 넘겨받았거나 보안 저장소가 양식을 채우는 동안 에이전트는
   일시 정지되어 아무 행동도 할 수 없다.
 - 별도 분류기군이 작업과 무관한 개인정보 유출, DOM 속 prompt injection,
diff --git a/docs/services/application-development/frontier-agent/openai-dots/index.md b/docs/services/application-development/frontier-agent/openai-dots/index.md
index 78b148b..8653a43 100644
--- a/docs/services/application-development/frontier-agent/openai-dots/index.md
+++ b/docs/services/application-development/frontier-agent/openai-dots/index.md
@@ -99,7 +99,9 @@ OpenAI는 GPT-6 Astra가 사용자의 목표를 이해하고, 요청 범위 안
 | 통제 시스템 분리 | 코드 실행 환경은 작업을 조율하고 안전 장치를 집행하는 시스템과 분리. dot은 이 접근으로 안전 시스템을 바꾸거나 필수 검사를 끌 수 없음 |
 | 사용자 기기 | 사용자가 컴퓨터를 연결해도 로컬 sandbox와 행동 검사가 계속 적용 |
 
-사용자는 언제든 dot의 컴퓨터를 열어 작업을 확인할 수 있다. 가장 중요한 설계는
+사용자는 언제든 dot의 컴퓨터를 열어 작업을 확인할 수 있다. 다만 dot이 화면을
+스크린샷 픽셀로 인식하는지, DOM 같은 구조로 인식하는지는 공개되지 않았다. 행동 방식
+비교는 [개요 문서](../index.md)의 CUA 트렌드 섹션에서 다룬다. 가장 중요한 설계는
 마지막에서 두 번째 행이다. **에이전트가 코드를 실행하는 곳과 에이전트를
 감시하는 곳을 분리**했기 때문에, dot이 실수하거나 조작당해도 검사 장치 자체는
 그대로 남는다.