미국 2026년 9월 18일 AI 브리핑: 에이전트의 권한·데이터·감사 레이어가 하나의 Control Plane으로 수렴한다
이번 증분의 핵심은 기업 AI의 병목이 모델 선택에서 권한·데이터 정책·도구 실행·감사로 이동하는 것이다. 독립 AI evaluator 시장은 'employee-like access' 수요와 이해상충 논쟁이 동시에 커지고, Databricks는 Apps·Unity Gateway·MCP·ABAC를 하나의 compliance plane으로 묶으며, Google Cloud는 IAM·Security Command Center 자체를 agent-callable MCP endpoint로 바꾸고 Agent Identity로 최소권한 실행을 강화하고 있다.
핵심 요약
조사 기준 시각: 한국시간 2026-09-18 22:38:39 KST (Asia/Seoul, UTC+09:00) / 미국 동부 2026-09-18 09:38:39 EDT (America/New_York, UTC-04:00) / 미국 서부 2026-09-18 06:38:39 PDT (America/Los_Angeles, UTC-07:00) / UTC 2026-09-18 13:38:39.
[확인] 지정 Google Drive 발행 폴더의 직전 브리핑은 gpt_20260918_213831_001.docx이며 유럽 AI 기업의 미국식 slowdown 비판, SK hynix Ventures, Angle Health를 다뤘다. 이번 실행에서는 Drive에서 METR Gray Swan independent evaluators, Databricks metastore ABAC Unity Gateway, Security Command Center MCP IAM remote MCP를 별도 검색했고 동일 사건을 핵심주제로 사용한 기존 문서를 확인하지 못했다. 이전 브리핑에서 이미 다룬 Anthropic AI R&D 속도, OpenAI misalignment reporting, Hacktron/Goodfire/Apollo, Qwen, Cooley, UN Data Commons 등은 반복하지 않았다.
[확인-1] 9월 18일 The Information은 Anthropic CEO Dario Amodei와 OpenAI CEO Sam Altman이 frontier lab 내부에 외부 evaluator를 상시적으로 두겠다는 방향을 지지하면서 AI safety auditor 시장이 빠르게 커지고 있다고 보도했다. Anthropic은 evaluator에게 ongoing, employee-like access를 제공하겠다는 방침을 제시했고 Microsoft CEO Satya Nadella도 independent evaluator embedding을 지지했다. The Information - AI Safety Push Sparks Demand for Watchdog Groups
[확인] 수요증가의 핵심 대상은 METR, Gray Swan, SecureBio, AVERI 같은 평가·감사조직이다. The Information은 Gray Swan이 $47.6M을 조달했고 연간반복매출(ARR)이 $10M을 넘겼다고 관계자를 인용해 보도했다. 다만 이 재무수치는 Gray Swan의 감사재무제표가 아니라 보도상 관계자 수치이므로 독립확정 실적으로 취급하지 않는다.
[확인-독립실증] METR는 2026년 3월 Anthropic 내부 agent-monitoring·security system 일부에 3주간 실질적 접근해 red-team을 수행했고 novel vulnerabilities를 찾았으며 일부는 이후 patch됐다고 밝혔다. Anthropic은 관련 내부시스템·정보·직원 접근을 제공했다. METR - Red-Teaming Anthropic's Internal Agent Monitoring Systems
[확인] METR의 2~3월 Frontier Risk Report에서는 Anthropic, Google, Meta, OpenAI가 평가기간 중 가장 강한 내부모델, raw chain-of-thought, non-public capability/monitoring/progress 정보를 제공했다. 즉 외부 evaluator가 단순 공개 benchmark가 아니라 내부 agent deployment risk를 검사하는 모델은 이미 pilot을 넘어 반복실험 단계에 있다. METR - Frontier Risk Report
[확인-독립성 논쟁] 반대편에서는 evaluator의 인적·자금 관계가 frontier labs와 충분히 분리됐는지가 쟁점이다. METR는 AI company나 그 임직원으로부터 평가대가를 받지 않는다고 설명하지만 model access와 token은 제공받는다. The Information은 METR와 Anthropic 간 personnel flow, Gray Swan cofounder Zico Kolter가 OpenAI board/safety committee 역할을 동시에 맡는 점 등을 이해상충 우려로 정리했다. Gray Swan은 Kolter가 OpenAI 및 경쟁고객 관련 상업논의에서 recuse한다고 밝혔다.
[확인-규제화] Illinois Public Act 104-0538은 2028년 1월 1일부터 대형 frontier developer가 매년 독립된 제3자에게 published safety/security policy 준수여부를 audit받도록 요구한다. 감사자는 일반적으로 인정되는 감사기준과 frontier-model safety technical expertise를 갖춰야 하며 개발사와 상호 financial interest가 있으면 안 된다. Illinois Public Act 104-0538
[확인-산업정책] OpenAI는 9월 9일 정책문서에서 California AB 1405의 AI-auditor standards와 SB 813의 independent safety assessment infrastructure를 지지했고, industry standards는 mandatory federal safeguards와 democratic oversight를 보완해야 한다고 밝혔다. OpenAI - The AI policy window is open
[추론] 이 시장의 본질은 benchmark vendor가 아니라 AI assurance institution의 탄생이다. 실제 가치가 있으려면 evaluator는 모델 snapshot만 시험하는 것이 아니라 training/eval/internal agent workflow, incident log, monitor effectiveness, access-control, response decision을 계속 볼 수 있어야 한다.
[추론] 따라서 새로운 핵심변수는 독립성과 접근권한의 동시확보다. 너무 멀리 떨어진 auditor는 필요한 내부 evidence를 못 보고, 너무 가까운 auditor는 이해상충 신뢰를 잃는다. 장기적으로는 auditor accreditation + conflict disclosure + access right + publication right + rotation + regulator backstop이 한 세트가 될 가능성이 높다.
[확인-반대근거] embedded evaluator가 있다고 해서 frontier lab의 모든 risk decision을 강제할 권한이 생기는 것은 아니다. 현재 많은 evaluator agreement는 lab이 제공하는 access 범위와 NDA에 의존하며, 공개여부도 case별 제한이 있다. Illinois audit requirement도 2028년부터 시행되므로 현재 모든 미국 frontier lab이 의무감사를 받고 있다는 뜻은 아니다.
[확인-2] Databricks는 9월 18일 compliance security profile이 활성화된 workspace에서 Databricks Apps를 기본적으로 켜기 시작했다. 전날인 9월 17일에는 Unity Catalog metastore-level ABAC가 Beta가 되어 row filter, column mask, GRANT, DENY를 metastore root에 정의하고 현재·미래 모든 catalog/object에 조직단위 정책으로 적용할 수 있게 했다. Databricks September 2026 Release Notes
[확인] Metastore-level ABAC는 정책을 catalog마다 복제하지 않고 한 번 정의해 전체 object hierarchy에 적용한다. tag-based policy는 catalog 이하 object의 governed tag를 매칭하며 네 가지 ABAC policy type 모두 metastore level에서 지원된다. Databricks - Metastore-level ABAC policies
[확인] 9월 16일에는 Unity Gateway API와 developer tools가 GA가 됐다. Model services, model-provider services, MCP services를 Terraform 1.132+, Databricks CLI 1.17+, Python/Go/Java/JavaScript SDK에서 CRUD할 수 있다. Unity Gateway는 model·MCP server·agent 사용의 security, access, cost를 중앙에서 관리하는 enterprise control plane으로 정의된다. Databricks - Unity Gateway release notes
[확인-MCP] 외부/self-hosted MCP server를 Unity Catalog securable인 MCP Service로 등록하면 모든 호출이 Unity Gateway를 통해 proxy되고 credential은 중앙관리돼 agent가 server token을 직접 보유하지 않는다. End user에게는 EXECUTE만 주고 USE CONNECTION을 주지 않아야 tool selection·service policy·auditing을 우회하지 않도록 할 수 있다. Databricks - Register an external MCP server
[확인] 이때 external MCP server의 tool allowlist, bearer token, OAuth M2M/U2M/DCR, per-user OAuth를 지원한다. 즉 MCP를 단순 connector가 아니라 data table과 유사한 governed securable로 취급한다는 점이 핵심이다.
[확인-다음변화] Databricks의 upcoming notes는 late September에 compliance workspaces에서 Apps user authorization을 자동활성화할 계획이며, 앱이 app-user identity로 resource를 대신 접근하면서 그 사용자의 기존 permission을 그대로 강제한다고 예고한다. 또한 Unity Gateway consumer access가 GA되면 model traffic이 늘 수 있어 admin에게 budget/rate-limit 또는 direct model access disable을 선행하라고 경고한다. Databricks - What's coming
[추론] 이 세 변화는 별개 release가 아니라 하나의 방향으로 읽힌다. User Identity → Databricks App → Unity Gateway → Model/MCP Service → Unity Catalog Data → Metastore ABAC → Audit/Budget를 동일 governance fabric으로 묶는 것이다.
[추론] 기업 agent가 위험한 이유는 prompt가 아니라 권한경로가 여러 시스템에 흩어져 있기 때문이다. Databricks는 앱, 데이터, 모델, external tool을 모두 securable과 policy object로 끌어들여 agent runtime을 data governance와 같은 plane에서 다루려 한다. 이는 agent deployment에서 shadow connector와 duplicated policy를 줄이는 구조다.
[확인-반대근거] 9월 18일 Apps default-on은 모든 compliance 기능이 이미 완성됐다는 의미가 아니다. Metastore ABAC는 Beta이고 user authorization은 late September 예정이며 consumer access GA도 upcoming이다. Unity Gateway가 모든 external SaaS authorization semantics를 자동검증하는 것도 아니므로 tool 자체의 business authorization과 downstream audit는 여전히 필요하다.
[확인-3] Google Cloud는 9월 16일 Security Command Center(SCC)에 remote MCP endpoints를 Preview로 추가해 LLM agent가 security finding 조사와 management-related task를 수행하도록 했다. SCC의 investigate endpoint는 findings/source/attack-path를 읽고 분석하는 toolset을 제공한다. Google Cloud - Security Command Center release notes SCC MCP reference
[확인] 별도 Security Center Management MCP endpoint는 security service configuration을 조회하는 read-only toolset을 제공한다. 기능은 Preview이며 MCP endpoint 자체가 모든 보안설정을 자유롭게 변경하도록 열려 있다는 뜻은 아니다. Security Center Management MCP reference
[확인-IAM] 이보다 앞선 9월 10일 Google Cloud IAM remote MCP server가 GA됐다. Gemini CLI, ChatGPT, Claude, custom app이 MCP를 통해 custom IAM role과 deny policy를 inspect/manage할 수 있다. 사용자는 roles/mcp.toolUser와 실제 IAM 변경에 필요한 Role Administrator·Deny Admin 권한을 별도로 가져야 한다. Google Cloud IAM release notes Use the IAM remote MCP server
[확인-Identity] Google Cloud MCP authentication 문서는 production agent에 인간 user credential을 그대로 쓰기보다 별도 agent/workload identity를 권장한다. Agent Identity는 SPIFFE 기반 strongly-attested cryptographic identity이며 service account와 달리 기본적으로 여러 workload가 공유하지 않고 impersonation을 허용하지 않으며 Google Cloud access token을 agent의 X.509 certificate에 cryptographically bind한다. Google Cloud - Authenticate to MCP servers
[확인-권한추천] Policy Assist remote MCP server는 9월 9일 Preview가 되어 external agent가 Gemini 기반 IAM role suggestion을 요청할 수 있다. Google은 managed MCP의 중앙 endpoint, fine-grained authorization, optional Model Armor, centralized audit logging을 제공하며 policy/tool/service/OAuth client 기준 IAM deny policy로 MCP 사용을 제한할 수 있다. Google Cloud - Policy Assist MCP
[확인-프로토콜] 9월 14일 Google Cloud MCP server fleet는 MCP Version 2026-07-28을 지원하기 시작했다. 이 버전은 HTTP remote MCP를 stateless core로 바꾸며 request가 필요한 context를 header와 _meta에 담아 세션 handshake 의존도를 줄인다. Google Cloud MCP release notes
[추론] Google의 방향은 cloud admin/security API 자체를 agent-callable control surface로 만드는 것이다. 과거 agent가 application business API만 호출했다면 이제 IAM policy, security finding, attack path, role suggestion도 자연어 agent workflow의 tool이 된다.
[추론] 따라서 핵심 보안원칙은 agent가 도구를 쓸 수 있다가 아니라 agent principal이 어떤 도구를 어떤 scope로 쓸 수 있는가다. 구조는 Agent Identity → MCP Tool Permission → Product-specific IAM Role → Tool Execution → Model Armor/Audit Log → Security Finding/Policy Change가 된다.
[추론] 이 구조가 확산되면 SOC·CloudSec·IAM operation에서 agent가 triage와 remedial action proposal을 처리하고 인간은 exception·high-impact approval을 맡을 수 있다. 반대로 잘못된 권한설계는 agent에게 IAM deny policy나 security control을 변경할 수 있는 매우 강한 lever를 줄 수 있으므로 identity와 tool-level deny가 prompt guardrail보다 우선한다.
[확인-반대근거] SCC MCP는 현재 Preview이고 management endpoint의 공개 toolset은 read-only다. IAM MCP가 GA여도 이를 사용하려면 별도 IAM admin permission이 필요하며 mcp.tools.call만으로 role/deny policy를 변경할 수 없다. Policy Assist는 suggestion 기능이므로 추천결과를 곧바로 자동승인하는 것은 least-privilege 원칙과 맞지 않는다.
핵심 사건 종합표
| 순위 | 분류 | 핵심 사건 | 최초 출처 | 연관 출처 체인 | 발생 시각과 미국 현지 날짜 | 핵심 사실 | 후속 전개 | 왜 중요한가 | 숨은 의미·비하인드 해석 | 담당자·관련 인물 | 수혜자 | 불리한 측 | 기술·사업 영향 | 다음 신호 | 신뢰도 | 검증 상태 | 원문 링크 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | AI Safety·Audit·Governance | Frontier labs가 embedded external evaluator를 확대하면서 AI safety auditor 시장과 독립성 논쟁이 동시에 부상 | The Information 9/18 + METR 실증 | Anthropic/OpenAI embedded-evaluator 제안 → METR internal monitoring red-team·Frontier Risk Report → Gray Swan/METR 수요 증가 → Illinois annual independent audit 법제화 → auditor independence·access-right 논쟁 | The Information 2026-09-18, 시각 미공개; 조사기준 09:38 EDT / 06:38 PDT | evaluator가 public benchmark를 넘어 lab 내부 model·CoT·monitor·incident process에 접근. Illinois는 2028년부터 대형 frontier developer 연례 독립감사 요구 | METR/Gray Swan/SecureBio/AVERI 등 전문기관·회계법인 진입 가능성, evaluator accreditation/standard 경쟁 | 모델안전이 self-report에서 assurance industry로 이동. 내부 evidence와 독립성의 균형이 핵심 | [추론] 장기 standard는 Access Right + Conflict Disclosure + Method Standard + Publication Right + Rotation + Regulator Backstop의 결합 | Dario Amodei, Sam Altman, Satya Nadella, METR, Gray Swan Matt Fredrikson/Zico Kolter, Miles Brundage | independent evaluators, enterprise risk teams, regulators, frontier labs with strong evidence systems | self-certification 중심 labs, access evidence가 약한 safety claims, 이해상충 관리가 약한 evaluator | audit/eval market, incident verification, safety evidence data room, evaluator access tooling 수요 확대 | auditor accreditation, cross-lab common standard, independence disclosure, mandatory deadlines, audit reports public scope | 매우 높음 | The Information 최신보도 + METR 1차 + Illinois 법령 + OpenAI 정책. Gray Swan ARR은 관계자 기반 보도수치 | The Information / METR Red Team / METR Risk Report / Illinois Law |
| 2 | Enterprise Agent·Data Governance·MCP | Databricks가 Apps·Unity Gateway·MCP·Metastore ABAC를 compliance control plane으로 수렴 | Databricks 9/18 release notes | Apps default-on(compliance) → 9/17 metastore ABAC → 9/16 Unity Gateway API GA → external MCP as Unity Catalog securable → late-Sep user authorization 예정 → consumer access GA 대비 budget/rate-limit 경고 | Apps 2026-09-18 시각 미공개; ABAC 9/17; Gateway API GA 9/16 | 정책을 metastore root에 한 번 정의해 future catalog까지 적용. Model/MCP/provider service를 CRUD·권한·비용관리. agent가 MCP token 직접 보유하지 않도록 gateway proxy 가능 | Apps가 user identity로 resource 접근하는 user authorization 예정, compliance workspace의 RBAC/metadata/secrets 확대 | agent runtime과 data governance가 별도 제품이 아니라 동일 policy graph로 통합 | [추론] Identity→App→Gateway→Model/MCP→Catalog→ABAC→Audit/Budget가 enterprise agent의 표준 control plane 후보 | Databricks platform/security/governance teams, enterprise admins, data governance teams | regulated enterprises, platform engineering, security/data governance, MCP operators | ad-hoc agent credentials, catalog별 복제정책, shadow MCP connectors | policy-as-code, centralized credentials, tool allowlist, data row/column control, AI spend governance 결합 | user authorization rollout, consumer access GA, secrets/RBAC default, external MCP incidents, cross-workspace governance | 매우 높음 | Databricks 공식 release/docs + 외부 release tracker 교차확인. 일부 핵심기능은 Beta/upcoming | Release Notes / ABAC / Unity Gateway / External MCP |
| 3 | Cloud Security·Agent Identity·MCP | Google Cloud가 IAM·SCC를 agent-callable remote MCP control surface로 확장 | Google Cloud 공식 release notes | Agent Identity GA 8/22 → Policy Analyzer/Troubleshooter MCP GA → Policy Assist MCP Preview 9/9 → IAM MCP GA 9/10 → MCP 2026-07-28 support 9/14 → SCC MCP Preview 9/16 | SCC 2026-09-16; IAM MCP GA 9/10; 조사기준 09:38 EDT / 06:38 PDT | AI app이 custom roles/deny policies inspect/manage 가능하되 MCP permission과 product IAM permission을 모두 요구. SCC investigate toolset이 findings/attack paths 조회 | Agent Identity로 strongly-attested principal, Model Armor·audit logging·IAM deny policy로 MCP governance | security/IAM 자체가 agent tool이 되면서 SOC/IAM automation의 execution layer가 열림 | [추론] prompt sandbox보다 principal/tool/scope가 보안의 최종 enforcement point. Agent Identity→MCP→IAM/SCC→Audit가 cloud agent-native security architecture | Google Cloud IAM/SCC/MCP teams, CloudSec·SOC·IAM admins, agent platform teams | enterprises with mature IAM/logging, security automation vendors, agent identity platforms | shared human credentials, broad service accounts, prompt-only guardrails | agentic SOC/IAM, separate cryptographic agent principal, tool-level deny, centralized MCP audit 확대 | SCC GA, write-capable security tools, approval workflow, incident metrics, cross-cloud agent identity standard, Model Armor adoption | 매우 높음 | Google Cloud 공식 docs/release notes + third-party release mirror. SCC는 Preview, management 공개 toolset은 read-only | SCC Release / IAM MCP / MCP Auth / Policy Assist |
1. Independent AI safety auditors — 연관 추적
① 최초 신호
[확인] Frontier labs가 model capability만 외부평가하는 방식에서 내부 agent use, monitoring, incident response, risk-governance process까지 외부 evaluator가 보는 방향으로 확장됐다. Anthropic과 OpenAI 지도부가 최근 permanent/embedded evaluator를 지지하면서 이 변화가 일회성 pilot을 넘어 제도화 단계로 이동했다.
② 공식 확인
[확인] METR는 Anthropic 내부 monitoring system red-team과 Anthropic·Google·Meta·OpenAI가 참여한 Frontier Risk Report를 통해 내부 model/CoT/non-public monitoring information까지 접근하는 evaluator 모델이 기술적으로 가능함을 이미 실증했다. METR Red Team METR Frontier Risk Report
③ 후속 기사와 반응
[확인] 9월 18일 The Information은 AI safety alarm 증가, 최근 agent hacking incidents, 법적 audit 요구가 METR·Gray Swan 등 평가기관 수요를 크게 끌어올리는 동시에 독립성 논쟁도 키운다고 보도했다. The Information
④ 담당자·연구자·개발자 발언
[확인] Dario Amodei는 외부 evaluator에게 ongoing, employee-like access가 필요하다고 주장했다. Gray Swan CEO Matt Fredrikson은 independent assessor가 lab이 특정 eval signal을 무시했을 때 그 판단이 합리적이었는지를 내부 evidence를 보고 검증해야 한다고 설명했다. METR는 평가대가를 AI company에서 받지 않는다는 정책을 공개한다.
⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서
[확인-한계] 이번 사건은 evaluator access agreement·법률·기관정책이 핵심이라 GitHub/Hugging Face artifact보다 METR 공식보고서와 법령, 정책문서가 우선근거다. public social debate에서는 regulator capture·effective altruism network·personnel movement를 둘러싼 비판이 있으나 계정별 의견을 사실로 일반화하지 않았다.
⑥ 실제 제품·기술·정책 변화
[확인] Illinois 법은 2028년부터 대형 frontier developer에 annual independent audit를 요구하고, financial-interest conflict를 금지한다. OpenAI는 California의 AI-auditor standards를 지지하며 federal mandatory safety rule과 industry standard의 병행을 제안한다. Illinois Law OpenAI Policy
⑦ 숨은 의미와 비하인드
[추론] AI safety auditor는 회계감사와 penetration testing 사이의 새 직업군에 가깝다. 필요한 competence가 model eval, cyber red-team, statistics, governance, evidence handling, incident forensics를 동시에 포함하기 때문이다.
[추론] 장기적 moat는 benchmark dataset이 아니라 lab 내부의 sensitive evidence를 안전하게 받아 검증하고 서로 다른 lab 결과를 공정하게 비교하는 methodology·access protocol·reputation이 된다. evaluator가 많아져도 누가 신뢰할 수 있는 auditor인가가 다시 인증시장으로 이어질 수 있다.
⑧ 반대 근거와 과장 가능성
[확인] 현재의 embedded-evaluator 약속이 법적 강제력을 가진 공통제도는 아니다. lab이 access scope를 제한할 수 있고 NDA로 public reporting이 제한될 수 있다. 인적 네트워크가 좁아 evaluator와 lab 사이 personnel overlap을 완전히 제거하기도 어렵다. 따라서 외부 evaluator를 둔다는 사실만으로 독립성이 보장되지 않는다.
⑨ 향후 예상되는 다음 행동과 확인해야 할 신호
evaluator accreditation, standardized conflict disclosure, auditor rotation, mandatory access rights, incident-report publication rights, audit evidence retention, Illinois 2028 implementation rules, California/federal audit standards, Big Four 회계법인의 AI safety 시장진입을 추적해야 한다.
2. Databricks의 agent/data unified control plane — 연관 추적
① 최초 신호
[확인] 기업 agent가 model뿐 아니라 databases, SaaS, MCP tools를 호출하면서 기존 data governance와 agent governance를 별도로 운영하면 identity·credential·policy가 중복된다. Databricks는 Unity Catalog governance를 model/tool runtime까지 확장하는 Unity Gateway를 중심으로 이 gap을 줄여왔다.
② 공식 확인
[확인] 9월 18일 compliance security profile workspace에서 Apps default-on, 9월 17일 metastore-level ABAC Beta, 9월 16일 Unity Gateway API/developer tools GA가 연속 발표됐다. September Release Notes
③ 후속 기사와 반응
[확인] Databricks 전문 release tracker Lakenaut도 metastore ABAC와 Unity Gateway API GA를 별도 release로 추적하고 있다. 대형 일반언론 보도는 이번 조사에서 확인되지 않았기 때문에 공식동작과 전문 release tracker를 중심으로 검증했다.
④ 담당자·연구자·개발자 발언
[확인-문서기반] Databricks는 Unity Gateway를 enterprise AI의 security/access/cost control plane으로 정의하고, ABAC는 organization-wide data-protection policy를 한 위치에서 적용하도록 설계했다고 설명한다. Upcoming note는 consumer model traffic 증가 전에 budget·rate-limit을 설정하라는 operational warning까지 제공한다.
⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서
[확인] 이번 변화는 API·CLI·Terraform·Python/Go/Java/JS SDK 버전과 함께 배포돼 infrastructure-as-code로 관리할 수 있다. 특정 GitHub commit을 핵심증거로 사용하지 않았고 public SNS 반응보다 현재 docs의 entitlement/credential semantics를 우선했다.
⑥ 실제 제품·기술·정책 변화
[확인] external MCP server를 Unity Catalog securable로 등록하면 agent가 직접 credential을 보유하지 않고 Unity Gateway가 호출을 proxy한다. Tool allowlist와 EXECUTE privilege를 사용하고 downstream connection privilege를 end-user에게 숨길 수 있다. Metastore ABAC는 미래 catalog/object에도 row/column/grant/deny 정책을 자동 확장한다. External MCP Metastore ABAC
⑦ 숨은 의미와 비하인드
[추론] MCP가 보편화될수록 connector의 수가 아니라 connector ownership·credential·tool scope·data scope가 핵심자산이 된다. Databricks는 이를 table governance와 동일한 catalog model로 흡수해 tool도 data object처럼 governance한다는 방향을 만든다.
[추론] 이 구조에서는 정책의 source of truth가 prompt가 아니라 catalog privilege와 gateway config다. 따라서 agent를 바꾸거나 foundation model을 교체해도 data/tool permission을 그대로 유지할 수 있어 model portability가 올라간다.
⑧ 반대 근거와 과장 가능성
[확인] ABAC는 Beta이고 Apps user authorization은 upcoming이다. external MCP server 내부에서 자체적으로 발생하는 business-logic abuse까지 Unity Gateway가 자동 방지하는 것은 아니다. 제공되는 managed credential도 downstream SaaS의 최소권한설계가 잘못돼 있으면 위험하다.
⑨ 향후 예상되는 다음 행동과 확인해야 할 신호
Apps user authorization 실제 rollout, model/MCP consumer access GA, MCP budgets/rate limits adoption, Unity Catalog secrets default-on, RBAC exclusive-role use, external MCP incident telemetry, tool-level ABAC/conditional grant의 확대를 확인해야 한다.
3. Google Cloud IAM·Security Command Center가 agent tool이 되는 단계 — 연관 추적
① 최초 신호
[확인] Google Cloud는 2026년 들어 managed remote MCP server를 50개 이상 service surface로 확대하고, Policy Troubleshooter/Analyzer와 Agent Identity를 먼저 내놓아 agent가 cloud-control-plane을 안전하게 호출할 기반을 만들었다.
② 공식 확인
[확인] IAM remote MCP server는 9월 10일 GA됐고, Security Command Center MCP endpoint는 9월 16일 Preview로 추가됐다. IAM MCP는 custom role·deny policy를 inspect/manage하고 SCC investigate tool은 findings·sources·attack paths를 조회한다. IAM Release Notes SCC Release Notes
③ 후속 기사와 반응
[확인] Google Cloud release mirror StackFeed도 SCC MCP release를 9월 16일 항목으로 추적한다. 대형 일반언론의 별도보도는 현재 확인되지 않아 제품동작은 Google Cloud 공식 reference를 기준으로 했다.
④ 담당자·연구자·개발자 발언
[확인-문서기반] Google은 production MCP client에 human credential 대신 separate agent/workload identity를 권장하고, agent identity에는 최소한의 permission만 부여하라고 명시한다. 특히 사용자의 credential을 쓰면 MCP action이 그 사용자로 attribution되고 사용자의 전체 permission을 agent가 그대로 상속한다고 경고한다.
⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서
[확인] MCP Version 2026-07-28의 stateless core 지원은 managed remote MCP를 load-balanced cloud service처럼 운영하기 쉽게 만든다. Google의 공개 MCP docs는 endpoint/tool schema를 직접 노출하며, 별도 public GitHub보다 service reference와 Cloud Audit Logs가 operational source of truth다.
⑥ 실제 제품·기술·정책 변화
[확인] Agent Identity는 SPIFFE 기반 cryptographic principal, auth manager는 OAuth/API key credential broker 역할을 한다. IAM MCP call에는 mcp.tools.call뿐 아니라 실제 resource action permission이 추가로 필요하고 Policy Assist에는 read-only suggestion 권한만 별도 부여할 수 있다. MCP Authentication IAM MCP Policy Assist
⑦ 숨은 의미와 비하인드
[추론] cloud security는 agent를 차단하는 보안에서 agent에게 보안운영 자체를 위임하되 cryptographic principal과 policy로 통제하는 보안으로 이동한다. 이는 human SRE/SOC가 console을 클릭하던 작업을 agent runbook으로 바꾸는 기반이다.
[추론] 가장 중요한 것은 Model Armor보다 IAM이다. prompt injection filter가 실패해도 agent principal에 read-only permission만 있으면 blast radius가 제한된다. 반대로 강한 model safety가 있어도 shared admin credential을 주면 단일 error가 cloud-wide policy change로 확대될 수 있다.
⑧ 반대 근거와 과장 가능성
[확인] SCC MCP는 Preview이며 current investigate toolset은 읽기/분석 중심이다. IAM MCP는 실제 admin role이 없으면 변경을 수행하지 못한다. Agent Identity 자체가 agent의 판단정확도를 보장하는 것도 아니다. 따라서 cryptographic identity는 authorization/control의 기반이지 semantic correctness의 보증은 아니다.
⑨ 향후 예상되는 다음 행동과 확인해야 할 신호
SCC write/remediation tools, high-impact action human approval, MCP tool-level IAM 조건식, agent identity cross-cloud federation, security incident attribution, Model Armor false-positive/false-negative telemetry, SOC runbook automation adoption을 추적해야 한다.
① 오늘의 핵심 흐름
이번 증분의 공통 흐름은 enterprise AI가 모델에서 control plane으로 이동한다는 것이다. AI safety에서는 외부 evaluator가 lab 내부 evidence를 검증하는 assurance plane이 생기고, Databricks는 data/model/MCP/app을 하나의 governance plane으로 묶으며, Google Cloud는 IAM/security 자체를 agent-callable control surface로 바꾸고 있다.
[추론] 세 사건을 합치면 Independent Assurance → Agent Identity → Policy/Entitlement → Tool Gateway → Data Access → Action → Audit/Incident Evidence → Policy Revision이라는 운영루프가 보인다. 모델은 교체 가능한 reasoning engine이고 장기 source of truth는 permission·evidence·audit graph가 된다.
② 새로운 출시·업데이트
오늘 가장 신선한 제품변화는 Databricks Apps의 compliance-profile default-on과 The Information이 포착한 embedded safety-evaluator 시장의 수요증가다. Google Cloud의 SCC MCP는 9월 16일, IAM MCP는 9월 10일 발표됐지만 지정 브리핑에서 아직 핵심으로 다루지 않았고 현재 agent-security architecture 변화와 직접 연결돼 누락보강했다. 새 사건이 없는 영역을 채우기 위해 이전 브리핑의 모델출시·투자·법률AI·광고·인프라 기사를 재사용하지 않았다.
③ 핵심기술·연구
핵심기술은 foundation-model benchmark가 아니라 세 종류의 권한기술이다. 첫째 evaluator에게 제한된 내부접근권을 주면서도 evidence와 독립성을 보존하는 audit architecture, 둘째 data/tool/model을 동일 securable graph로 만드는 policy engine, 셋째 agent마다 독립 cryptographic principal을 주고 MCP action을 resource-level IAM으로 검사하는 identity architecture다.
[추론] 차세대 agent stack의 reliability는 reasoning accuracy만 아니라 authorization accuracy, audit completeness, policy portability, incident reproducibility로 측정될 가능성이 높다.
④ 기업·담당자·조직 신호
Frontier lab은 safety team 외에 embedded external evaluator와 regulator-facing assurance function을 받아들일 압력을 받고 있다. Databricks는 data governance team과 AI platform team의 경계를 Unity Catalog/Gateway 아래에서 합치고 있다. Google Cloud는 IAM/SCC product team이 agent platform의 핵심 API provider가 되는 구조다. [추론] 조직적으로는 CISO·IAM·data governance·AI platform·internal audit가 같은 agent operating model에 참여해야 한다. AI center-of-excellence만으로 agent fleet의 권한과 evidence를 관리하기 어렵다.
⑤ SNS·YouTube에서 포착된 신호
이번 사건들은 공개 SNS보다 법령·제품 reference·기관보고서의 신뢰도가 훨씬 높았다. evaluator independence 논쟁은 social media에서 강하지만 특정 계정의 정치적 프레이밍을 사실로 채택하지 않았다. Databricks와 Google Cloud 변화도 marketing video가 아니라 release notes, exact permission, endpoint, credential semantics를 기준으로 검증했다. 직접 확인되지 않은 YouTube demo나 private community post는 제외했다.
⑥ 약한 신호와 향후 조짐
[추론] 첫째 AI auditor가 독립 profession으로 커지면 SOC 2 for frontier AI와 비슷한 반복감사·evidence-room 시장이 생길 수 있다. 둘째 MCP server가 enterprise standard가 될수록 단순 connector directory보다 identity+credential+tool policy+usage audit가 핵심 플랫폼가치가 된다.
[추론] 셋째 agent identity가 cloud-native primitive로 자리잡으면 service account와 user account 사이에 non-human autonomous principal이라는 별도 IAM category가 일반화될 수 있다. 이 경우 agent별 owner, purpose, lifetime, delegated-user scope, risk tier가 CMDB/IAM의 필수필드가 된다.
⑦ 과장·루머·주의 항목
Anthropic/OpenAI가 evaluator embedding을 지지한다고 해서 evaluator에게 veto권이나 전면공개권이 자동 부여되는 것은 아니다. Databricks의 compliance Apps·ABAC·Gateway 기능도 일부는 Beta/upcoming이다. Google Cloud SCC MCP가 나왔다고 agent가 cloud security setting을 마음대로 바꾸는 것도 아니다.
특히 MCP Tool User 권한과 실제 IAM/SCC resource permission은 별개이며, independent evaluator의 independent라는 명칭도 funding/personnel/access 조건을 확인하지 않으면 실제 독립성을 보장하지 않는다.
⑧ 사용자가 반드시 알아야 할 것
실전 agent 시스템에는 최소 다섯 registry가 필요하다. Agent Identity Registry는 agent principal·owner·lifetime, Tool Registry는 MCP/server/tool·credential·scope, Data Policy Registry는 row/column/ABAC, Action Policy Registry는 allow/deny/approval, Evidence Registry는 prompt보다 실제 tool call·policy decision·incident·human override를 저장해야 한다.
여기에 high-risk AI를 운영한다면 Independent Assurance Registry를 추가해 어떤 evaluator가 어떤 model/version/system에 어느 범위까지 접근했고 어떤 conflict·finding·remediation이 있었는지를 추적해야 한다. 이 구조가 갖춰져야 모델을 바꿔도 governance가 끊기지 않는다.
⑨ 누락 가능성과 탐색 한계
이번 조사는 The Information의 9월 18일 evaluator-market 보도, METR의 Anthropic red-team과 Frontier Risk Report, Illinois audit 법령, OpenAI 정책문서, Databricks September release/ABAC/Unity Gateway/MCP/upcoming docs, Google Cloud SCC/IAM/MCP/Agent Identity/Policy Assist docs를 직접 확인했다. Gray Swan ARR·funding 일부는 The Information이 관계자를 인용한 보도수치이며 독립 재무감사자료가 아니다. Databricks·Google Cloud enterprise 사용량과 실제 customer incident rate는 공개되지 않았다. evaluator의 private contract, NDA, lab internal evidence, private Slack/X/Threads, admin console tenant data에는 접근하지 않았고 확인한 것처럼 쓰지 않았다.
참고 자료와 작성 정보
조사·작성 기준 시각: 2026-09-18 22:38:39 KST / 2026-09-18 09:38:39 EDT / 2026-09-18 06:38:39 PDT / 2026-09-18 13:38:39 UTC. 주요 직접출처: The Information - AI Safety Auditors; METR Red Team; METR Frontier Risk Report; OpenAI AI Policy Window; Illinois Public Act 104-0538; Databricks September Releases; Databricks Metastore ABAC; Databricks Unity Gateway; Databricks External MCP; Databricks What's Coming; Google SCC Release Notes; Google SCC MCP; Google IAM Release Notes; Google IAM MCP; Google MCP Authentication; Google Policy Assist MCP. 이 브리핑은 AI의 도움으로 공개 자료를 조사·정리했습니다. 확인된 사실과 추론, 미확인 내용을 구분해 표시했습니다.
본문에서 연결한 참고 자료
- The Information - AI Safety Push Sparks Demand for Watchdog Groups
- METR - Red-Teaming Anthropic's Internal Agent Monitoring Systems
- METR - Frontier Risk Report
- Illinois Public Act 104-0538
- OpenAI - The AI policy window is open
- Databricks September 2026 Release Notes
- Databricks - Metastore-level ABAC policies
- Databricks - Unity Gateway release notes
- Databricks - Register an external MCP server
- Databricks - What's coming
- Google Cloud - Security Command Center release notes
- SCC MCP reference
- Security Center Management MCP reference
- Google Cloud IAM release notes
- Use the IAM remote MCP server
- Google Cloud - Authenticate to MCP servers
- Google Cloud - Policy Assist MCP
- Google Cloud MCP release notes