Trust3 에이전트 발견 가이드, 숨은 MCP 연결까지 추적

Trust3 AI가 2026년 5월 31일 A Complete Guide to Agent Discovery를 공개했습니다. 글은 agent discovery를 "기업 환경에서 작동하는 모든 AI agent, 각 agent가 닿을 수 있는 자원, agent를 만든 사람을 계속 inventory화하는 일"로 정의합니다. Trust3는 이 작업을 자사 Agent DOS 모델의 첫 축으로 놓습니다. 이름이 거창하지만, 출발점은 단순합니다. 조직이 존재를 모르는 agent에는 runtime guardrail, 감사 로그, kill switch, owner assignment를 붙일 수 없습니다.

이번 가이드는 새 모델이나 벤치마크 발표가 아닙니다. 그래도 AI 개발팀이 볼 이유가 있습니다. 2026년 들어 Microsoft Agent 365, ServiceNow AI Control Tower, Collibra AI Command Center, TrustLogix TrustAI 같은 제품은 모두 agent를 "관리 대상"으로 다룹니다. Trust3의 글은 그 앞 단계를 집요하게 봅니다. 보안팀의 registry에 들어온 agent만 보지 않습니다. Copilot Studio 고객지원 agent, Bedrock 내부 agent, Cursor·Claude Code의 MCP workflow, Databricks Mosaic 분석 agent가 어디에 숨어 있는지 묻습니다.

Trust3가 제시한 문제는 procurement나 change management를 통과하지 않는 agent입니다. 전통적인 애플리케이션은 새 배포, 네트워크 변경, vendor onboarding, credential 발급 같은 지점에서 보안팀이 볼 기회가 있었습니다. Trust3 field guide는 agent에는 그런 choke point가 거의 없다고 씁니다. 데이터 과학자는 Copilot Studio 안에서 오후에 agent를 만들 수 있고, 엔지니어는 AWS console에서 Bedrock agent를 띄울 수 있으며, 개발자는 로컬 IDE에서 MCP server를 붙여 내부 시스템을 호출할 수 있습니다. 이 경우 첫 발견 시점이 incident review나 regulator 질문이 되기 쉽습니다.

가이드가 요구하는 inventory 항목은 꽤 구체적입니다. 각 agent에는 service principal, application registration, token 같은 identity가 있고, 책임지는 human owner가 있어야 합니다. platform of origin도 필요합니다. Bedrock, Databricks Mosaic, Copilot Studio, LangGraph, custom Python은 제공하는 logging과 policy surface가 다릅니다. tool bindings에는 MCP server, internal API, plugin, function 권한이 들어갑니다. data reach는 table, dataset, file store, knowledge base 단위로 봐야 합니다. multi-agent 구조에서는 A2A relationships, 즉 어떤 agent가 어떤 agent를 호출하는지도 기록해야 합니다.

Trust3가 말하는 discovery 방식은 세 갈래입니다. 첫째는 platform API입니다. 이미 Bedrock, Databricks, Copilot Studio 같은 곳에 올라간 agent는 해당 platform의 API와 configuration에서 찾을 수 있습니다. 둘째는 development environment입니다. custom agent는 platform API에 없으므로 repository, CI pipeline, container image에서 agent code와 tool definition을 찾아야 합니다. 셋째는 runtime traffic입니다. agent가 MCP server나 internal API를 호출하면 network와 identity signal이 남습니다. Trust3는 이 egress 쪽 관측이 다른 inventory source가 놓친 agent를 잡는 failure case라고 설명합니다.

이 구분은 개발자에게 직접적인 작업 목록으로 바뀝니다. agent project를 만들 때 owner, service identity, allowed tools, MCP servers, data resources, deployment stage를 코드와 함께 남겨야 합니다. 팀이 LangGraph나 custom Python으로 내부 agent를 만들고, 로컬 .env에 token을 넣고, MCP config만 문서 없이 공유하면 platform API discovery에는 잡히지 않습니다. 반대로 repo scan과 runtime egress가 붙으면 "어느 agent가 왜 Jira와 customer table을 동시에 호출했는가"를 사후 추적할 가능성이 생깁니다.

Trust3의 Agent Discovery product page는 field guide보다 제품 언어가 강합니다. 이 페이지는 CloudTrail logs, platform APIs, SDK activity, audit trails를 한 control plane으로 가져온다고 설명합니다. inventory record에는 platform, owner, identity, data access, Trust Score, status가 들어갑니다. status는 registered, unowned, shadow AI 같은 상태를 구분합니다. 보안팀이 agent를 수동 spreadsheet로 모으는 방식으로는 이 속도를 따라가기 어렵다는 주장입니다.

Trust Score 부분도 숫자로 제시됩니다. Trust3는 각 agent에 0부터 100까지 posture 점수를 붙이고, 네 가지 weighted dimensions를 사용한다고 설명합니다. policy compliance가 35%, scope adherence가 25%, security posture가 25%, behavioral baseline이 15%입니다. 이 수치는 독립 검증된 업계 표준이 아니라 Trust3 제품의 scoring model입니다. 그래도 어떤 변수를 점수화하려는지는 선명합니다. agent가 선언한 목적을 벗어났는지, credential이 과도한지, 행동이 평소 baseline에서 벗어났는지, active policy를 위반했는지를 보겠다는 뜻입니다.

여기서 MCP가 별도 위험 항목으로 올라옵니다. Trust3 guide는 tool bindings를 agent의 blast radius가 있는 곳이라고 설명합니다. MCP server가 email, issue tracker, database, browser, code repository를 열어주면 agent 이름보다 연결된 tool이 더 중요해집니다. 보안팀이 "Copilot Studio agent 12개"만 세면 부족합니다. 각 agent가 어떤 MCP server를 호출하고, 그 MCP server가 어떤 credential로 어떤 API를 호출하며, agent끼리 A2A로 서로를 부르는지까지 봐야 실제 권한 지도를 만들 수 있습니다.

이 관점은 최근 Microsoft Agent 365와도 닿아 있습니다. Microsoft는 Agent 365에서 registry, shadow agent discovery, Entra, Defender, Purview를 agent management surface로 묶습니다. Trust3는 특정 productivity suite가 아니라 platform API, development scan, runtime traffic을 discovery source로 묶습니다. 둘 다 agent를 사람이나 앱처럼 inventory화하려는 방향입니다. 차이는 출발점입니다. Microsoft는 Microsoft 365 tenant와 enterprise identity에서 강하고, Trust3는 agent가 여러 platform과 custom code에 흩어지는 상황을 전면에 둡니다.

Okta도 CISO용 agent security 질문에서 비슷한 문제를 다룹니다. Okta의 글은 agent를 SaaS, browser, endpoint, agentic AI ecosystem 전반에서 발견할 능력이 필요하다고 설명합니다. Straiker Discover AI 같은 경쟁 제품도 AI agent inventory, misconfiguration, risky permissions, unsafe MCP integrations를 내세웁니다. vendor 이름은 다르지만 공통된 사건은 하나입니다. AI agent가 "모델 호출 코드"에서 "새 non-human identity와 tool chain"으로 바뀌면서, 기존 asset inventory와 IAM 도구가 agent semantics를 충분히 이해하지 못하는 빈칸이 생겼습니다.

표준과 compliance 연결도 이번 가이드의 한 축입니다. Trust3는 discovery가 NIST AI RMF의 Map function, ISO/IEC 42001의 AI system inventory와 ownership documentation에 연결된다고 정리합니다. EU AI Act Article 11과 Annex IV, SOC 2와 ISO 27001의 asset inventory, ISO/IEC 42005 impact assessment도 같은 표에 넣었습니다. 이 목록은 마케팅 문장처럼 보일 수 있지만, audit 현장에서는 꽤 실무적입니다. "우리 회사에 어떤 AI agent가 있고, 누가 소유하며, 어떤 데이터와 도구를 쓰는가"를 설명하지 못하면 정책 문서는 빈칸으로 남습니다.

제품팀이 주의할 부분도 있습니다. 첫째, discovery는 detection product 하나로 끝나지 않습니다. platform API가 정확해도 custom agent와 로컬 coding agent는 놓칠 수 있습니다. repo scan이 좋아도 runtime에서 새 MCP binding이 붙으면 drift가 생깁니다. runtime egress를 봐도 encrypted traffic, shared credential, human-on-behalf-of-agent 패턴은 attribution을 어렵게 만듭니다. Trust3 guide가 세 source를 함께 쓰라고 한 이유는 한 source로 충분하지 않기 때문입니다.

둘째, agent와 script의 경계가 운영 정책을 흔듭니다. Trust3 FAQ는 fixed steps를 실행하는 것은 script이고, goal을 받아 plan하고 tool을 호출하며 다음 step을 runtime에 선택하면 agent라고 구분합니다. 실제 codebase에서는 이 경계가 흐려집니다. cron job이 LLM을 한 번 호출해 SQL을 만들면 agent입니까. Slack bot이 사용자의 request를 받아 tool을 세 개 호출하면 agent입니까. 이 질문에 답하지 못하면 inventory 기준이 팀마다 달라지고, security exception도 일관성을 잃습니다.

셋째, decommissioning이 별도 단계로 들어갑니다. Trust3 guide는 retired agent의 credential이 revoke됐는지, MCP connection이 닫혔는지, service identity의 live traffic이 사라졌는지 확인해야 한다고 적습니다. 개발팀은 기능을 끄면 끝났다고 생각하기 쉽습니다. 하지만 agent는 token, webhook, scheduled task, MCP config, vector store, audit log, A2A peer를 남길 수 있습니다. 문서상 retired와 runtime상 retired가 다르면 다음 audit에서 문제로 돌아옵니다.

한국 개발팀에는 두 가지 실무 질문이 남습니다. 첫째, 지금 agent를 어디에 기록하고 있습니까. Jira ticket, README, cloud console tag, IAM service account name, MCP config file, CI output이 서로 흩어져 있다면 discovery는 사람이 기억하는 수준에 머뭅니다. 둘째, agent가 사용할 수 있는 tool과 data reach를 누가 승인합니까. approval이 없는 상태에서 개발자가 MCP server를 추가하면, 모델 prompt보다 credential scope가 사고의 원인이 됩니다.

Trust3의 field guide는 vendor가 쓴 글이므로 그대로 표준처럼 받아들이면 안 됩니다. Trust Score의 실제 정확도, platform connector의 coverage, runtime egress attribution 품질, custom code scan의 false positive는 각 조직이 검증해야 합니다. 그러나 guide가 던진 질문은 유효합니다. agent governance는 "정책을 만들었다"에서 끝나지 않고, "실제로 어떤 agent가 오늘 어떤 identity로 어떤 tool을 호출했는가"를 답할 수 있어야 시작됩니다.

이번 뉴스를 agent control plane 경쟁 안에 놓고 보면 방향은 분명합니다. kill switch, policy enforcement, observability, audit replay는 모두 발견 가능한 inventory를 전제로 합니다. Trust3는 그 첫 줄을 agent discovery라고 부릅니다. 개발팀이 지금 할 일은 새 보안 도구 이름을 외우는 것이 아닙니다. agent를 만들 때 owner, identity, MCP binding, data reach, A2A 관계, lifecycle stage를 배포 산출물로 남기는 습관을 만드는 일입니다. 그 기록이 없으면 다음에 필요한 것은 더 똑똑한 모델이 아니라, "누가 이 agent를 만들었는지"를 찾는 incident meeting이 됩니다.