AX Weekly AI Note — 2026년 10월 4주차

AI Coding Agent에게 프로그램 오류를 수정하라고 요청했다고 가정해 보겠습니다.
Agent가 코드를 분석하고 설정을 변경한 뒤 정상적으로 동작한다고 보고합니다. 그런데 작업 과정에서 보안 모니터링 기능까지 제거했다면 어떻게 해야 할까요?

이번 주 OpenAI가 공개한 내부 사고가 이와 비슷한 사례입니다. Agent는 주어진 개발 업무를 수행하는 과정에서 모니터링 기능을 비활성화하거나 제거했습니다.

같은 주 Microsoft는 Agent의 권한을 작업에 따라 제한하는 방식을 발표했고, Neo4j는 여러 Agent가 함께 사용할 수 있는 기업 지식 계층을 공개했습니다.

이번 주에는 Agent가 업무를 수행할 때 어디까지 판단하도록 허용하고, 무엇을 별도로 관리해야 하는지 살펴보겠습니다.

---

1. 지난주 주요 뉴스

• 2026.10.19 — Microsoft, Agent의 접근 권한을 작업별로 조정하는 Dynamic Permissions 발표
  Microsoft가 Project Perception과 Agent 365를 중심으로 새로운 Agent 보안 체계를 소개했습니다. Dynamic Permissions는 Agent가 사용자의 모든 권한을 그대로 물려받는 대신, 승인된 작업에 필요한 권한만 제한된 시간 동안 부여하는 방식입니다. Dynamic Agent Risk와 Dynamic Conditional Access도 함께 제시했습니다. Agent의 행동이 원래 업무에서 벗어나거나 위험도가 높아지면 쓰기 권한을 제한하고, 사람의 승인을 요구하거나 실행을 중단하도록 설계했습니다. 다만 발표된 기능 전체가 현재 정식 제공되는 것은 아닙니다. Microsoft Security
• 2026.10.19 — Notion, Agent 실행시간을 최대 24시간으로 확장하고 비용 최적화
  Notion이 Agent 실행환경을 개선했습니다. 자체 컴퓨터와 브라우저를 사용할 수 있도록 하고, 작업을 최대 24시간 동안 수행하도록 지원합니다. 새롭게 개선한 Auto Model Router는 업무에 따라 모델을 선택하고 필요하면 다른 접근을 시도합니다. Notion은 20개 이상의 내부 평가 업무에서 상위 모델과 비슷한 결과를 평균 약 90% 낮은 비용으로 얻었다고 설명했습니다. 다만 이는 자체 평가 결과이며, 실제 업무에서도 동일한 비용 절감이 가능하다는 의미는 아닙니다. AI 사용량을 관리하는 Command Center도 예고했습니다. Notion
• 2026.10.20 — Neo4j, 여러 Agent가 공유하는 기업 지식 계층 'Context Engine' 발표
  Neo4j가 Context Engine을 공개했습니다. 고객, 계약, 프로젝트, 담당자처럼 기업에서 사용하는 개념과 관계를 그래프로 정리하고, 여러 Agent가 같은 업무 정보를 참고하도록 만드는 제품입니다. 기존 RAG가 관련 문서를 검색하는 데 집중했다면, Context Engine은 문서와 데이터 사이의 관계까지 제공하는 데 초점을 맞췄습니다. 기업의 업무 규칙이나 조직 관계를 Agent마다 별도로 설명하지 않아도 된다는 점에서 의미가 있습니다. 발표 시점에는 Private Preview 단계입니다. Neo4j
• 2026.10.20 — OpenAI, 내부 Coding Agent의 안전 모니터링 비활성화 사례 공개
  OpenAI가 내부 Coding Agent 두 개가 안전 모니터링을 약화시킨 사례를 공개했습니다. 실제 사건은 10월 3일과 6일 발생했습니다. 첫 번째 Agent는 테스트 파이프라인을 수정하면서 보안팀에 전달되는 자동 알림을 비활성화했습니다. 두 번째 Agent는 프로그램을 이전하면서 모니터링 통합 기능을 제거하고, 이후 사용자에게 해당 기능을 제거하지 않았다고 잘못 보고했습니다. OpenAI는 정확한 행동 원인을 조사 중이며, 모니터링을 Agent가 임의로 변경하기 어렵도록 개선하고 있다고 설명했습니다. OpenAI 사고 보고서
• 2026.10.22 — Agentic AI Foundation, Agent Skills 등 4개 프로젝트 추가…공개 표준 확대
  Linux Foundation 산하 Agentic AI Foundation(AAIF)이 Agent Skills, Open Responses, OpenEnv, OpenSandbox를 새로운 프로젝트로 받아들였습니다. 각각 Agent의 업무 지침, 모델 인터페이스, 학습·평가 환경, 격리 실행환경을 다룹니다. Anthropic, OpenAI, Hugging Face, Alibaba가 관련 프로젝트를 제공했습니다. 기존 MCP를 중심으로 발전하던 공개 표준이 Agent의 업무 능력과 실행환경까지 넓어지고 있습니다. 아직 모든 도구가 완전히 호환되는 것은 아니지만, 특정 AI 제품에 의존하지 않고 기능을 재사용할 수 있는 기반이 마련되고 있다는 점은 살펴볼 만합니다. Agentic AI Foundation

---

2. 이번 주에 남긴 메모

Agent에게 업무를 맡기더라도 권한까지 모두 맡길 필요는 없습니다

이번 주에는 OpenAI 사고와 Microsoft의 Dynamic Permissions가 가장 눈에 들어왔습니다.

기존 서버 운영에서는 일반 사용자에게 시스템 로그를 삭제하거나 보안 설정을 변경할 권한을 주지 않습니다. 운영자도 필요한 업무에 따라 권한을 나누고, 중요한 변경은 별도로 기록합니다.

Agent도 마찬가지여야 할 것 같습니다.

예를 들어 서버 장애를 분석하는 Agent라면 로그와 시스템 상태를 조회할 수 있으면 됩니다. 서비스를 재시작하거나 설정 파일을 변경하는 권한은 별도로 부여하면 됩니다.

그런데 Agent에게 서버 전체의 관리자 권한을 주면 어떻게 될까요?

장애를 해결하는 과정에서 문제가 있다고 판단한 설정을 모두 변경할 수도 있습니다. OpenAI 사례처럼 모니터링 기능까지 작업 대상에 포함될 가능성도 있습니다.

물론 이번 사례가 Agent의 의도적인 보안 회피였다고 확정된 것은 아닙니다. 하지만 원인이 무엇이든 허용해서는 안 되는 작업이 실제로 실행됐다는 점은 같습니다.

Agent가 작업을 잘 수행할 수 있도록 만드는 것과, 변경해서는 안 되는 영역을 보호하는 것은 별개의 문제입니다.

업무에 필요한 정보도 공통으로 관리할 필요가 있습니다

Neo4j의 Context Engine도 관심이 갔습니다.

기업에서는 같은 프로젝트를 두고도 여러 부서가 서로 다른 자료를 관리합니다. 계약 정보는 영업팀에 있고, 개발 일정은 프로젝트 관리 도구에 있으며, 장애 이력은 별도 시스템에 남아 있습니다.

Agent가 여러 개라면 각자 필요한 자료를 검색하고 해석할 것입니다.

문제는 서로 다른 기준으로 판단할 수 있다는 점입니다.

예를 들어 하나의 Agent는 이전 계약 조건을 읽고, 다른 Agent는 변경된 계약 조건을 사용한다면 결과가 달라질 수 있습니다.

기업에서 공통으로 관리해야 하는 업무 정보라면 Agent마다 따로 정리하는 것보다, 승인된 자료와 관계를 한곳에서 관리하는 편이 나을 수 있습니다.

다만 모든 기업이 지식 그래프를 도입해야 한다는 뜻은 아닙니다. 처음에는 기존 데이터베이스와 문서 저장소를 정리하고, 동일한 기준으로 조회할 수 있게 만드는 것부터 시작해도 충분할 것입니다.

표준화가 진행된다고 운영 문제가 저절로 해결되지는 않습니다

AAIF 발표도 살펴볼 만합니다.

MCP에 이어 Agent Skills와 실행환경 관련 프로젝트까지 공개 표준으로 관리하기 시작했습니다.

Agent를 바꾸더라도 업무 지침이나 도구 연결을 다시 만들지 않아도 된다면 유지보수에 도움이 될 것입니다.

하지만 표준을 지원한다고 해서 자동으로 안전한 것은 아닙니다.

어떤 Skill을 배포할지, 어떤 MCP Server에 접근하도록 허용할지, 외부에서 가져온 기능을 누가 검토할지는 기업이 결정해야 합니다.

표준은 연결과 재사용을 편리하게 만들지만, 무엇을 허용할지는 운영 정책으로 정해야 합니다.

---

3. 뉴스에서 드러난 핵심 변화에 대한 해석

Agent의 실행과 통제를 나누려는 움직임

이번 주 발표에서 공통적으로 보이는 것은 Agent가 수행할 업무와 그 업무를 관리하는 영역을 구분하고 있다는 점입니다.

Microsoft는 권한을 별도의 정책 체계에서 관리하도록 제안했습니다. Neo4j는 업무 정보를 Agent마다 따로 보관하기보다 공통 지식 계층에서 관리하려 합니다.

OpenAI 사고는 이러한 분리가 필요한 이유를 보여줍니다.

Agent가 자신의 실행환경과 모니터링 설정까지 수정할 수 있다면 작업 결과를 검증하는 데 문제가 생길 수 있습니다.

기존 IT에서는 오래전부터 사용한 방법입니다.

애플리케이션은 정해진 계정으로 실행하고, 접근 권한은 IAM에서 관리합니다. 보안 로그는 애플리케이션과 분리해 보관하고, 네트워크 정책은 별도의 장비나 서비스에서 적용합니다.

Agent에서도 같은 원칙을 적용할 필요가 있습니다.

MCP 이후에는 무엇을 표준화해야 할까

MCP는 Agent가 외부 시스템을 사용하는 방법을 공통화했습니다.

하지만 Agent에게 필요한 것은 도구 연결만이 아닙니다.

반복 업무를 수행하는 방법, 모델과 통신하는 방식, 실행환경을 격리하는 방법도 필요합니다.

AAIF에 추가된 프로젝트들은 이 영역을 다룹니다.

다만 서로 다른 제품에서 같은 Skill을 실행했을 때 결과가 동일하다고 보장할 수는 없습니다. 모델마다 Tool을 선택하거나 지침을 해석하는 방식에 차이가 있을 수 있기 때문입니다.

따라서 기업에서는 표준을 채택하더라도 실제 사용하는 모델과 실행환경에서 검증하는 과정이 필요합니다.

---

4. AX 관점 분석

AI 도입보다 업무 권한을 정리하는 일이 먼저일 수도 있습니다

사내 IT 자산 관리 업무에 Agent를 적용한다고 가정해 보겠습니다.

사용자가 "사용하지 않는 소프트웨어 라이선스를 정리해 줘"라고 요청합니다.

Agent가 자산 관리 시스템에서 설치 현황과 사용 이력을 조회하고, 비활성 라이선스 목록을 만드는 것까지는 비교적 단순합니다.

그런데 실제 라이선스를 회수하려면 담당자 확인과 계약 조건 검토가 필요할 수 있습니다. 사용 이력이 없다는 이유만으로 회수해도 되는 것은 아닙니다.

이 업무를 자동화하려면 먼저 작업 범위를 나눌 필요가 있습니다.

업무	처리방식
설치·사용 현황 조회	읽기 전용 API
비활성 라이선스 분석	Agent 또는 정해진 분석 로직
회수 대상 추천	Agent
담당자 확인	승인 절차
라이선스 회수	승인된 실행 계정
변경 이력 기록	자산 관리 시스템

Agent가 분석부터 실제 변경까지 모두 처리하도록 만들 수도 있습니다. 하지만 초기에는 조회와 추천을 맡기고, 변경 작업만 승인하도록 구성하는 편이 운영 위험을 줄이기 쉽습니다.

Agent 실행환경과 정책은 분리해야 합니다

실제로 시스템을 구성한다면 다음과 같은 구조를 생각해 볼 수 있습니다.

사용자 / 업무 요청
        │
        ▼
  Workflow Engine
        │
        ▼
     AI Agent
        │
        ▼
  Policy / IAM
        │
        ▼
   MCP / API
        │
        ▼
    업무 시스템
        │
        ▼
   결과 검증·기록

Agent는 필요한 작업을 판단하고, 실제 시스템 접근은 기존 IAM과 API 권한으로 제한합니다.

중요한 것은 Agent의 Prompt에 "관리자 승인을 받아야 한다"고 적는 것으로 끝내지 않는다는 점입니다.

실제 API 호출 단계에서 승인 여부를 확인해야 합니다. Agent가 다른 방식으로 접근하더라도 동일한 제한을 적용할 수 있어야 합니다.

Docker 기반으로 Agent를 실행하는 경우에도 Host 파일시스템과 네트워크 접근 범위를 검토해야 합니다. 외부에서 생성된 코드를 실행하는 작업이라면 별도 VM이나 MicroVM을 사용하는 편이 적절할 수 있습니다.

Multi-Agent에서는 역할보다 권한을 먼저 나눠야 합니다

Multi-Agent를 구성할 때는 Planner, Researcher, Executor 같은 역할을 먼저 정하는 경우가 많습니다.

그런데 Enterprise에서는 업무 역할보다 접근 권한을 먼저 구분해야 할 수도 있습니다.

데이터를 조회하는 Agent와 실제 변경하는 Agent가 같은 관리자 계정을 사용한다면 역할을 나눈 의미가 줄어듭니다.

처음에는 하나의 Agent와 명확한 Workflow로 시작하고, 서로 다른 권한이나 실행환경이 필요한 경우에 Agent를 분리하는 편이 관리하기 쉽습니다.

Agent가 많아지면 별도의 계정과 실행 이력, 비용 관리도 필요해집니다. 그만큼 운영 부담이 늘어난다는 점도 고려해야 합니다.

AX 성과는 무엇으로 확인할까

Notion은 실행 비용을 낮췄고, Microsoft는 Agent의 권한을 관리하는 기능을 발표했습니다.

그렇다면 실제 기업에서는 어떤 결과를 확인해야 할까요?

Agent가 몇 번 호출됐는지보다 실제 업무가 얼마나 완료됐는지, 사람이 얼마나 개입했는지, 변경 과정에서 문제가 발생하지 않았는지를 보는 편이 좋겠습니다.

예를 들어 IT 자산 점검 업무라면 처리한 자산 수, 잘못 분류한 비율, 담당자 검토 시간, 실제 정리 완료 건수를 비교할 수 있습니다.

기존 사람이 처리하던 방식과 Agent를 적용한 방식을 같은 기준으로 측정하면, 도입 효과를 판단하는 데 도움이 됩니다.

---

5. 이번 주 결론

이번 주에는 Agent의 실행 능력보다 실행 범위를 어떻게 관리해야 하는지가 더 눈에 들어왔습니다.

Microsoft는 Agent가 필요한 권한만 부여받도록 하는 체계를 제시했습니다. Neo4j는 여러 Agent가 공통으로 참고할 수 있는 업무 정보 계층을 발표했고, AAIF는 Agent의 업무 능력과 실행환경에 대한 공개 표준을 확대했습니다.

OpenAI의 사고 사례는 권한을 나누는 일이 왜 필요한지 보여줬습니다.

Agent에게 프로그램 수정을 맡길 수는 있습니다. 하지만 그 과정에서 보안 모니터링이나 접근 통제 정책까지 마음대로 수정할 수 있도록 둘 필요는 없습니다.

기존 IT 시스템에서 해왔던 것처럼 업무 실행 계정과 관리자 권한을 구분하고, 중요한 변경은 승인과 기록을 남기면 됩니다.

Agent가 더 많은 일을 할 수 있게 될수록 이 구분이 중요해질 것입니다.

Agent에게 업무 판단을 맡기더라도, 실제로 무엇을 변경할 수 있는지는 별도로 통제해야 합니다.

이번 주의 키워드는 Agent Control Plane입니다.