Dataverse MCP Server 발표를 기능으로 읽으면 핵심을 놓치게 됩니다. 이것을 경고로 읽어야 비로소 초점이 맞춰집니다.

Microsoft는 여러분에게 공손하게 말하고 있습니다. AI 에이전트가 여러분의 시스템 오브 레코드(system of record) 내부에서 안전하게 작동할지 여부를 결정하는 것은 플랫폼이 아니라, 바로 여러분이 정의한 계약이라는 것을요.

그 계약에는 Model Context Protocol 세계에 이름이 붙어 있습니다. 그것은 바로 툴 형태(tool shape)입니다. 그리고 이것은 올해 여러분이 내릴 가장 중요한 거버넌스 결정일 것이며, 아무도 이 회의를 잡지 않았을 것입니다.

실제로 바뀐 점

MCP 이전에는 에이전트가 Dataverse에 접근한다는 것은 쿼리를 구성하는 것을 의미했습니다. FetchXML, SQL 등 자연어로부터 조립할 수 있는 모든 것을요. 여러분은 LLM(대규모 언어 모델)이 접근 패턴을 작성하도록 신뢰했고, 그리고 그 결과 잘못된 부분을 잡아낼 보안 계층을 신뢰했습니다.

Model Context Protocol은 이를 뒤집습니다. 각 기능은 자체 설명적인 툴(tool)이 됩니다: name, description, 타입 지정된 inputSchema, 구조화된 결과, 그리고 해당 액션이 읽기 전용인지 파괴적인지 표시하는 행동 주석(behavioral annotations)을 갖춘 것입니다.

에이전트는 더 이상 임의의 쿼리를 작성하지 않습니다. 검증되고 스키마가 바운드된(schema-bound) 액션을 호출합니다. 메타데이터 검색, 레코드 읽기, CRUD, 프롬프트 및 지식 도구 등이 그것입니다.

이는 오류 표면적(error surface)과 공격 표면적(attack surface)을 동시에 좁힙니다. 하지만 오직 툴들이 단단하게 형태를 갖추었을 때만 가능합니다. 느슨하게 형태가 잡힌 툴은 여러분이 방금 제거한 모든 것을 되돌려줍니다.

MCP는 Anthropic의 오픈 프로토콜이며, Microsoft가 만든 것이 아닙니다. 이 선택 자체가 전체 전략이며, 이에 대해 다시 다루겠습니다. 요약하자면: 에이전트 UI(User Interface)는 상품화되고 있지만, 데이터 평면(data plane)은 그렇지 않습니다.

툴 형태는 마지막 방어선이 아니라 첫 번째 방어선입니다

여기 함정이 있습니다. 그리고 대부분의 팀이 빠지게 될 함정입니다.

사람들은

실질적인 기반은 여전히 Dataverse입니다. 보안 역할 (Security roles), 행 수준 보안 (Row-level security), 필드 보안 프로필 (Field Security Profiles)을 통한 열 수준 보안 (Column-level security) 등이 그것입니다. 이러한 메커니즘은 수년간 귀하의 데이터를 보호해 왔으며, 호출자가 에이전트(Agent)라고 해서 집행 계층 (Enforcement layer)으로서의 역할을 멈추지 않습니다.

하지만 이는 단 한 가지 조건 하에서만 작동합니다: 에이전트가 호출하는 사용자의 위임된 컨텍스트 (Delegated context) 내에서 실행되어야 한다는 점입니다.

이것이 전체 게임의 핵심을 한 문장으로 요약한 것입니다.

호출이 사용자의 신원 (Identity)을 전달할 때, 행 수준 및 열 수준 보안이 함께 이동합니다. 에이전트는 해당 사용자가 볼 수 있는 것과 정확히 동일한 것을 보게 됩니다. 반면, 호출이 광범위한 권한을 가진 서비스 주체 (Service principal) 하에서 실행되면, 모든 사용자별 제어 기능이 증발합니다. 에이전트는 앱 등록 (App registration)이 볼 수 있는 모든 것을 보게 되며, 이는 대개 너무 과도한 권한입니다.

이제 이 두 가지 실패 모드 (Failure modes)를 결합해 보겠습니다:

• 광범위한 형태의 툴 ("모든 쿼리 실행 가능")
• 관대한 권한을 가진 서비스 주체 하에서 실행

이 조합은 두 계층을 동시에 무너뜨립니다. 귀하는 LLM에게 시스템 기록 (System of record)의 열쇠를 넘겨준 것이며, 툴의 형태나 Dataverse 보안 그 어느 것도 이를 막아서지 못합니다. 이것이 지배적인 실패 모드이며, 데모에서는 나타나지 않습니다. 이는 6주 후 감사 (Audit) 과정에서 나타납니다.

프롬프트를 신뢰하는 것을 멈추십시오

예측 가능한 본능은 가드레일 (Guardrails)을 자연어로 작성하는 것입니다. "사용자가 소유한 레코드만 반환하십시오." "절대 삭제하지 마십시오." "민감한 열은 거부하십시오."와 같은 식입니다.

그러지 마십시오. 프롬프트 수준의 지침은 가이드일 뿐, 집행 수단이 아닙니다. 그것들은 구조적으로 우회 가능하며, 이를 제어 수단으로 취급하는 것이 바로 귀하의 시스템 프롬프트(System prompt)에는 관심도 없는 사람들에게 사고 경위를 설명하게 되는 지름길입니다.

신뢰할 수 있는 것은 두 가지뿐입니다: 툴 형태에서의 스키마 수준 제약 조건 (Schema-level constraints), 그리고 위임된 신원 하에서의 Dataverse 수준 집행입니다. 그 외의 모든 것은 제안일 뿐입니다.

결론은 냉혹합니다. 만약 어떤 통제 수단이 대화(talked out of)를 통해 무력화될 수 있다면, 그것은 통제 수단이 아닙니다.

아무도 예산을 책정하지 않은 새로운 위험 클래스

MCP는 공급망(supply chain)을 도입합니다. 툴(Tool)에는 정의(definition)가 있고, 정의에는 메타데이터(metadata)가 있으며, 이 메타데이터는 모델의 컨텍스트(context)로 흘러 들어갑니다. 이는 대부분의 Dataverse 팀이 모델링해 본 적 없는 새로운 공격 카테고리를 열어젖힙니다.

• 툴 포이즈닝 (Tool poisoning): 악의적이거나 부주의한 툴 정의가 작성자의 의도와 다른 방식으로 에이전트(agent)의 행동을 형성합니다.
• 툴 메타데이터를 통한 프롬프트 인젝션 (Prompt injection through tool metadata): description 필드는 단순한 장식이 아닙니다. 모델이 이를 읽으며, 그 안에 담긴 적대적인 콘텐츠는 행동을 재지정(redirect)할 수 있습니다.
• 혼동된 대리인 (Confused deputy): 요청이 허용하는 권한보다 더 큰 권한을 가진 에이전트가 타인을 대신하여 그 권한을 사용하도록 속임을 당하는 현상입니다.

모든 툴 정의와 모든 입력을 신뢰할 수 없는 것으로 취급하십시오. 인터넷상의 누구나 호출할 수 있는 공개 API 엔드포인트를 다루는 것과 동일한 방식으로 말입니다. 기능적으로 볼 때, 그것이 실제 상황에 더 가깝기 때문입니다.

경쟁적 관점에서의 읽기

이 부분이 이 사안을 단순한 운영 문제를 넘어 전략적인 문제로 만드는 지점입니다.

Microsoft는 Copilot 전용의 폐쇄된 정원(walled garden)을 구축할 수도 있었습니다. 하지만 그들은 그렇게 하지 않았습니다. 그들은 개방형 프로토콜(open protocol)을 표준으로 채택했으며, 이는 OpenAI, Claude, 그리고 여러분의 커스텀 에이전트가 모두 동일한 문을 통해 Dataverse에 도달할 수 있음을 의미합니다.

이것은 무언가를 그냥 내주는 것처럼 보일 수 있습니다. 하지만 그렇지 않습니다. 이는 락인(lock-in) 효과를 상위 계층으로 이동시키는 것입니다.

에이전트와 모델 계층은 교체 가능한 범용 제품(commodity)이 됩니다. 가치가 축적되는 자산은 Microsoft가 원하는 곳에 그대로 머물러 있습니다. 바로 테이블(tables), 비즈니스 로직(business logic), 신원을 위한 Entra, 거버넌스를 위한 Purview입니다. 에이전트 UI는 범용화하고, 데이터 플레인(data plane)을 소유하는 전략입니다.

만약 플랫폼에 대한 베팅을 하고 있다면, 이것이 바로 그 신호입니다. 특정 에이전트 런타임(agent runtime)에 과도하게 투자하지 마십시오. 모든 에이전트가 거쳐야만 하는 기질(substrate)에 투자하십시오. 신원(Identity)과 거버넌스가 적용된 데이터는 이번 분기에 승리하는 모델이 무엇이든 간에 그보다 더 오래 살아남을 것입니다.

실제로 활성화했을 때 무엇이 깨지는가

어려운 작업은 서버를 활성화하는 것이 아니었습니다. 그것은 스위치를 켜는 것뿐입니다.

진정한 어려움은 거의 모든 조직이 에이전트 소비 (agent consumption)를 고려하여 스키마 (schema)나 보안 모델 (security model)을 설계하지 않았다는 점에 있습니다. 기존의 테이블들은 보안 역할 (security role)을 가진 양식(form) 상의 인간을 가정했습니다. 하지만 이제 호출자는 당신이 노출하는 무엇이든 호출할 준비가 된, 지치지 않고 빠르며 때로는 환각 (hallucination)을 일으키는 프로세스입니다.

따라서 실제 프로젝트는 테이블별, 액션(action)별로 결정하는 과정입니다. 이 중 어떤 것이 에이전트가 호출할 수 있도록 허용되어야 하는가? 대부분은 그렇지 않아야 하며, 적어도 아직은, 특히 쓰기 (write) 작업에 대해서는 확실히 그렇습니다.

첫 다섯 단계

다음 단계들을 순서대로 수행하십시오. 각 단계는 이전 단계가 완료되었음을 전제로 합니다.

결론

Dataverse MCP Server는 진정으로 훌륭한 엔지니어링 결과물입니다. 또한 이는 대부분의 팀이 간과하고 있는 곳, 즉 툴 계약 (tool contract)과 그것이 실행되는 ID (identity)로 보안 경계 (security boundary)를 조용히 이동시킵니다.

구조를 견고하게 잡고 ID를 위임 (delegated)한다면, 대부분의 조직이 현재 운영하는 것보다 더 나은 심층 방어 (defense in depth)를 얻을 수 있습니다. 둘 중 하나라도 잘못된다면, 가드레일 (guardrails)이 꺼진 상태로 언어 모델 (language model)을 당신의 진실의 기록 (record of truth)에 직접 연결하게 되는 것입니다.

Microsoft는 이것이 무엇인지 알려주었습니다. 계약 (contract)을 정의하는 것은 당신의 몫입니다.

이 영역은 빠르게 진화하고 있습니다. 툴 카탈로그 이름, GA (General Availability) 대 프리뷰 (preview) 상태, 그리고 정확한 위임 (delegated) 대 서비스 주체 (service-principal) 전파 의미론 (semantics)은 이를 바탕으로 설계를 하기 전에 반드시 최신 Microsoft Learn 문서를 통해 확인해야 합니다. 아키텍처 원칙은 유효하지만, 정확한 조절 장치(knobs)들은 여전히 움직이고 있습니다.

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 벤더 중립적인 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 많은 내용은 az365.ai에서 확인하세요.