요즘 AI 에이전트를 연결하는 방법을 보면 묘하게 익숙하다.

메일을 읽게 하고 싶으면 내 메일 계정을 연결한다.

GitHub에서 일하게 하고 싶으면 토큰을 준다.

서버를 만지게 하고 싶으면 SSH나 API 접근 권한을 준다.

파일을 다루게 하고 싶으면 내 계정으로 실행한다.

일단 돌아가기는 한다.

그런데 생각해보니 조금 이상했다.

회사에 새 직원을 뽑았다고 치자.

그 직원에게 내 사원증을 복사해주고,

내 출입카드를 주고,

내 컴퓨터 비밀번호를 알려준 다음,

"이제 알아서 일해"라고 하지는 않는다.

그런데 AI에게는 비슷한 일을 꽤 자연스럽게 하고 있었다.

최근 NIST가 올린 글 제목이 눈에 들어왔다.

Back to the Future: Why Agentic AI Needs a Strong Identity Foundation.

AI가 미래 기술인데 제목은 오히려 "과거로 돌아가자"에 가까웠다.

읽어보니 이유가 있었다.

AI 에이전트 보안에서 새롭고 거창한 기술만 찾을 게 아니라, 컴퓨터 업계가 수십 년 동안 배운 아주 오래된 원칙부터 다시 지키자는 얘기였다.

그중 가장 단순한 원칙이 이것이었다.

비밀번호와 계정을 남에게 주지 말자.

AI라고 예외일 이유가 없었다.

NIST: Back to the Future: Why Agentic AI Needs a Strong Identity Foundation

AI가 내 계정으로 일하면 뭐가 문제일까

처음에는 이런 생각도 들었다.

어차피 내가 시킨 AI인데 내 계정으로 움직이는 게 뭐가 문제지?

예를 들어 내가 에이전트에게 GitHub 저장소의 파일 하나를 수정하라고 했다.

AI가 내 토큰으로 파일을 수정했다.

결과도 맞았다.

그러면 별문제 없어 보인다.

문제는 일이 잘못됐을 때 시작된다.

로그를 열어봤더니 이렇게 적혀 있다고 해보자.

Jun이 오전 3시 14분에 production 데이터를 삭제함.

나는 자고 있었다.

실제로 명령을 실행한 건 AI였다.

그런데 시스템 입장에서는 AI가 내 자격증명을 들고 있었기 때문에 내가 한 행동과 AI가 한 행동을 구별하기 어렵다.

NIST가 지적하는 핵심 중 하나가 바로 이 부분이었다.

보안에서 "누가 무엇을 했는가"를 확인할 수 있어야 한다.

그런데 사람과 에이전트가 같은 신분증을 들고 다니면 그 경계가 사라진다.

내가 이해한 걸 아주 단순하게 그리면 이렇다.

TEXT
지금 흔한 방식

나 ── 내 계정/토큰 ──> AI ──> Gmail
                         ├──> GitHub
                         ├──> NAS
                         └──> 서버

문제가 생기면 기록에는 전부 '나'처럼 보일 수 있다.

NIST는 에이전트를 **고유한 식별자, 자격증명, 권한을 가진 하나의 독립적인 주체(first-class entity)**로 취급할 필요가 있다고 설명한다.

여기서 어려운 말은 별로 중요하지 않은 것 같다.

그냥 회사에 새 직원이 들어오면 그 직원 이름으로 계정을 만들어주는 것과 비슷하게 이해했다.

TEXT
조금 더 나은 그림

나
│
├── Jun 계정
│
└── WorkBrain-Agent 계정
     ├── Gmail: 읽기만
     ├── Drive: 특정 폴더만
     ├── GitHub: 특정 저장소만
     └── NAS: 업무 폴더만

이제 로그에 WorkBrain-Agent가 파일을 수정함이라고 남길 수 있다.

그리고 그 에이전트가 누구를 대신해 움직였는지도 연결할 수 있다.

AI에게 인격을 주자는 얘기가 아니다.

컴퓨터 시스템 안에서 책임과 권한을 구별할 이름표를 붙이자는 얘기에 가깝다.

계정은 신분증이고, 권한은 열쇠였다

처음에는 "AI 전용 계정 하나 만들면 끝 아닌가?"라고 생각했다.

그런데 자료를 더 읽어보니 신분만 구별한다고 끝나는 문제가 아니었다.

예를 들어 회사에 청소업체 직원이 들어왔다고 해보자.

신분증을 발급해주는 건 좋다.

그런데 그 신분증 하나로

  • 사무실
  • 서버실
  • 대표이사실
  • 금고
  • 연구소

문이 전부 열린다면 여전히 이상하다.

AI도 똑같았다.

누구인지 확인하는 것과 무엇을 할 수 있는지 정하는 것은 다른 문제였다.

보안에서는 앞쪽을 인증(authentication), 뒤쪽을 권한 부여(authorization)라고 부른다.

용어를 몰라도 상관없다.

나는 그냥 이렇게 기억하기로 했다.

신분증 확인 = 너 누구야?

열쇠 지급 = 그래서 어디까지 들어가도 돼?

NIST가 특히 경고하는 건 에이전트에게 너무 넓은 열쇠를 주는 방식이다.

AI 에이전트는 사람보다 훨씬 빠르게 여러 경로를 시험할 수 있다.

"보고서를 완성해" 같은 큰 목표 하나를 받으면 파일을 찾고, 검색하고, 도구를 호출하고, 다른 데이터까지 확인하면서 예상하지 못했던 길로 갈 수 있다.

그래서 권한이 넓으면 단순 실수도 커질 수 있다.

사람이 폴더를 잘못 지우면 몇 초 뒤에 "어?" 하고 손을 멈출 수도 있다.

에이전트는 잘못된 판단을 자동화해서 아주 성실하게 반복할 수도 있다.

사고도 자동화된다.

이 표현이 조금 무섭지만 에이전트 시대에는 꽤 중요한 차이인 것 같다.

API 키 하나 던져주는 방식도 다시 보게 됐다

로컬 AI나 자동화 프로젝트를 만지다 보면 API 키는 정말 편하다.

환경변수에 넣는다.

설정 파일에 넣는다.

프로그램이 읽는다.

끝이다.

문제는 이 키가 오래 살아 있고 권한까지 넓을 때다.

NIST는 오래 유지되는 API 키나 접근 토큰을 에이전트에게 들려주는 방식을 별도로 지적했다.

많은 API 키는 그 문자열을 가진 사람이 누구인지 증명하지 않는다.

열쇠를 주운 사람이 그냥 문을 열 수 있는 구조에 가깝다.

게다가 키가 설정 파일, Markdown 문서, 로그 등에 평문으로 남는 경우도 있다고 한다.

에이전트가 여러 도구와 서버를 돌아다니기 시작하면 열쇠를 잃어버릴 장소도 늘어난다.

여기서 NIST가 이야기하는 방향은 오히려 단순했다.

필요할 때만,

필요한 곳에만,

짧게 살아 있는 열쇠를 주자는 것이다.

TEXT
만능 열쇠

Agent ── [1년짜리 모든 권한 API KEY] ──> 서비스 전체

vs.

일회용에 가까운 열쇠

Agent ── [10분 / 특정 폴더 / 읽기 권한] ──> 필요한 작업
          ↓
        만료

실제 시간과 범위는 시스템마다 다르다.

중요한 건 에이전트가 가진 권한을 기본적으로 작게 만들고 필요할 때만 잠깐 늘리는 방향이었다.

보안에서 말하는 최소 권한(least privilege)과 임시 권한(just-in-time access)이 이런 생각이다.

새로운 AI 전용 마법이라기보다 오래된 보안 원칙을 AI에게 다시 적용하는 셈이었다.

OAuth는 갑자기 왜 나올까

NIST 글에는 OAuth 2.0, SPIFFE, JWT, X.509 같은 이름이 줄줄이 나온다.

처음 보면 갑자기 글 난이도가 확 올라간다.

그래서 일단 이름을 다 외우는 건 포기했다.

핵심만 보면 이미 컴퓨터끼리 신분을 확인하고 제한된 권한을 넘겨주는 기술들이 존재한다는 얘기였다.

OAuth는 생각보다 우리에게 익숙하다.

어떤 앱에서

Google로 로그인

버튼을 누르고,

"이 앱이 Google Drive 파일을 볼 수 있도록 허용하시겠습니까?"

같은 화면을 보는 게 대표적인 예다.

앱에게 내 Google 비밀번호 자체를 알려주는 대신, 내가 허용한 범위의 접근권한을 넘겨준다.

AI 에이전트에도 비슷한 생각을 적용할 수 있다.

예를 들어 보고서 에이전트가 Google Drive 전체를 볼 이유가 없다면,

프로젝트 A 폴더 읽기

정도만 허용하면 된다.

NIST는 기업 환경에서 OAuth 2.0과 SPIFFE 같은 기존 방식이 에이전트의 신원과 권한 문제를 해결하는 출발점이 될 수 있다고 설명한다.

SPIFFE는 처음 보는 이름이었다.

조금 찾아보니 사람 로그인보다는 서버나 프로그램 같은 기계끼리 서로 "나는 누구다"라고 증명하기 위한 신분 체계에 더 가깝다.

여기서는 깊게 파지 않아도 될 것 같다.

중요한 건 AI 에이전트 때문에 완전히 새로운 보안 세계를 처음부터 발명해야 하는 것은 아니라는 점이었다.

이미 서버와 클라우드 세계에서 수십 년 동안 겪은 문제와 해결책이 꽤 많이 겹친다.

그런데 AI는 평범한 프로그램하고 조금 다르다

여기까지 보면 이런 생각이 든다.

"그럼 그냥 기존 프로그램처럼 서비스 계정 하나 주면 되는 거 아냐?"

절반 정도는 맞는 것 같다.

NIST도 기존 신원·권한 관리 원칙을 적극적으로 재사용하자는 쪽이다.

그런데 AI 에이전트에는 조금 이상한 특성이 있다.

일반적인 자동화 프로그램은 대체로 개발자가 미리 적어놓은 경로를 따른다.

TEXT
1. 파일 A 읽기
2. 데이터 B 추출
3. API C 호출
4. 결과 저장

반면 에이전트는 목표만 받고 중간 경로를 스스로 정하는 경우가 많다.

TEXT
목표: 이 프로젝트 문제를 해결해줘

AI:
파일을 볼까?
로그를 볼까?
웹을 검색할까?
GitHub 이슈를 볼까?
코드를 고칠까?
테스트를 돌릴까?
다른 에이전트에게 시킬까?

그래서 "이 프로그램은 이 API만 호출한다"고 미리 가정하기가 어려워질 수 있다.

NIST 표현으로는 에이전트가 높은 수준의 지시를 받고 여러 경로를 탐색하면서 예상하지 못한 도구나 데이터를 사용할 수 있다는 것이다.

이 특성 때문에 최소 권한이 더 어려워진다.

권한을 너무 작게 주면 AI가 3분마다 나를 부른다.

권한을 너무 크게 주면 편하지만 사고 범위가 커진다.

딱 여기서 또 다른 문제가 생긴다.

"허용하시겠습니까?"를 50번 물으면 결국 다 누르게 된다

처음에는 사람이 승인하면 안전하다고 생각했다.

AI가 중요한 행동을 하려고 할 때마다 팝업을 띄운다.

TEXT
파일을 수정할까요?       [허용] [거부]
터미널을 실행할까요?     [허용] [거부]
웹사이트에 접속할까요?   [허용] [거부]
GitHub에 push할까요?      [허용] [거부]
새 패키지를 설치할까요?   [허용] [거부]

이러면 모든 중요한 행동을 사람이 통제하는 것처럼 보인다.

그런데 NIST는 여기에도 함정이 있다고 했다.

consent fatigue. 승인 피로다.

MFA 인증 알림을 공격자가 계속 보내서 사용자가 지쳐서 승인 버튼을 누르게 만드는 MFA bombing과 비슷한 현상이다.

AI가 하루 종일

허용?

이것도 허용?

이것도?

이것도?

하고 물으면 처음 몇 번은 읽는다.

스무 번째부터는 대충 본다.

쉰 번째에는 그냥 버튼 위치만 보고 누를 가능성이 생긴다.

ㅋㅋ 인간 보안장치의 최종 형태가 귀찮아서 Allow 누르는 사람이면 뭔가 잘못됐다.

NIST도 사람을 과정에 넣는 것(Human-in-the-Loop)을 지나치게 의존하면 오히려 책임성과 안전성이 무너질 수 있다고 지적한다.

이 부분은 생각보다 중요했다.

AI 에이전트 안전에서 흔히

"중요한 건 사람이 승인하게 하면 되잖아"

라고 쉽게 생각했는데 그것도 규모가 커지면 해결책이 아니었다.

그럼 모든 행동을 승인받는 대신 '업무 범위'를 먼저 승인하면 어떨까

여기서 재미있는 방향이 나온다.

에이전트가 버튼을 누를 때마다 허락을 받는 대신 처음에 업무 범위 자체를 승인하는 것이다.

예를 들어 이런 식이다.

TEXT
오늘 WorkBrain-Agent 업무 범위

기간: 오전 9시 ~ 오후 6시

허용:
✓ 프로젝트 A Drive 폴더 읽기
✓ 보고서 초안 폴더에 새 파일 작성
✓ GitHub 저장소 issue 읽기
✓ 테스트 실행

금지:
✗ 원본 파일 삭제
✗ 외부 이메일 발송
✗ main 브랜치 직접 push
✗ 새로운 외부 서비스 로그인

추가 승인 필요:
! 파일 삭제
! PR merge
! 외부 전송

이렇게 하면 AI가 매번 "이 파일 읽어도 돼?"라고 물을 필요가 없다.

대신 위험 경계를 넘어갈 때만 사람을 부른다.

NIST 글에서도 모델 제공자들이 승인된 행동 계획, 이른바 flight plan 같은 방식을 연구하고 있다고 언급한다.

비행기가 출발할 때 목적지와 항로를 잡아두는 것처럼 AI도 먼저 "오늘 어디까지 움직여도 되는지"를 정하는 셈이다.

개인적으로는 이게 앞으로 에이전트 UI에서 꽤 중요한 부분이 될 것 같다.

지금은 채팅창이 AI 인터페이스의 중심이지만, 에이전트가 실제 행동을 많이 하게 되면

채팅창보다 권한표가 더 중요해질 수도 있다.

로컬 AI면 안전한 줄 알았는데 이것도 조금 달랐다

로컬 LLM을 좋아하는 이유 중 하나는 데이터가 내 컴퓨터 안에 머물 수 있다는 점이다.

그래서 자연스럽게

로컬 = 안전

처럼 생각하기 쉽다.

그런데 모델을 로컬에서 돌리는 것과 에이전트에게 내 운영체제 계정 전체를 주는 것은 완전히 다른 문제였다.

NIST도 로컬 사용자 계정으로 에이전트를 실행하는 방식을 따로 지적한다.

예를 들어 내 Windows 계정으로 에이전트를 실행하면 그 AI는 내가 접근할 수 있는 파일과 프로그램을 상당 부분 그대로 볼 수 있다.

Mac도 비슷한 문제를 생각할 수 있다.

내 계정이 NAS를 마운트하고 있고,

SSH 키가 있고,

브라우저 세션이 있고,

개발 도구가 로그인돼 있고,

환경변수에 API 키까지 있다면,

로컬 AI에게는 엄청나게 넓은 작업장이 열린 셈이다.

인터넷으로 데이터를 보내지 않는다고 해서 이 권한 문제가 사라지는 것은 아니다.

NIST는 로컬 에이전트도 단단하게 제한된 실행 환경이나 샌드박스, 예를 들면 통제된 컨테이너 안에서 실행하는 방향을 언급한다.

여기서 샌드박스는 그냥 AI용 작업실이라고 생각하면 쉬웠다.

집 전체 열쇠를 주는 대신,

필요한 공구와 복사본만 넣어둔 작업실 하나를 주는 것이다.

AI가 작업실을 난장판으로 만들어도 집 전체가 날아가지는 않게 한다.

이 비유만으로 컨테이너 보안을 전부 설명할 수는 없지만 방향은 이해하기 쉬웠다.

내 자동화 프로젝트를 생각하니 갑자기 현실적인 문제가 됐다

이 주제가 흥미로운 이유는 거대한 기업 보안 이야기로 끝나지 않기 때문이다.

개인 자동화에서도 바로 부딪힌다.

예를 들어 앞으로 개인용 업무 에이전트를 만든다고 해보자.

이 에이전트가

  • Gmail에서 업무 메일을 읽고
  • Google Drive에서 자료를 찾고
  • NAS의 프로젝트 파일을 읽고
  • 보고서 초안을 만들고
  • GitHub 프로젝트를 수정하고
  • 캘린더에 일정을 기록한다.

이 정도만 돼도 사실상 꽤 많은 디지털 생활에 접근한다.

처음 만들 때 가장 쉬운 방법은 전부 내 계정으로 연결하는 것이다.

그런데 시스템이 커질수록 나중에 분리하기가 더 어려워질 것 같다.

그래서 오히려 초기에 이런 식으로 생각하는 게 낫지 않을까 싶다.

TEXT
사람: Jun

├── Mail-Agent
│   └── 업무 메일 읽기 / 라벨 변경
│
├── Report-Agent
│   └── 지정 Drive/NAS 폴더 읽기 + 초안 폴더 쓰기
│
├── CAD-Agent
│   └── CAD 작업 폴더 읽기/쓰기
│
└── Dev-Agent
    └── 특정 GitHub 저장소 + 테스트 환경

각 에이전트가 별도의 "직원"처럼 보인다.

Mail-Agent가 갑자기 CAD 원본을 지울 이유도 없고,

CAD-Agent가 개인 Gmail을 읽을 이유도 없다.

그리고 Dev-Agent가 사고를 쳤다면 로그에서도 Dev-Agent의 행동으로 남는다.

이 구조가 반드시 정답이라는 뜻은 아니다.

NIST의 에이전트 신원 프로젝트 자체도 아직 진행 중이고 업계 표준도 정리되는 단계다.

다만 AI 하나에게 내 디지털 인생 전체의 마스터키를 주는 구조는 오래 가기 어려울 것 같다는 생각은 꽤 분명해졌다.

여러 AI가 협업하면 신분증 문제가 더 복잡해진다

전에 여러 AI 에이전트가 서로 메시지를 남기고 협업하기 시작한 사례를 찾아본 적이 있다.

그때는 주로 에이전트끼리 정보를 공유하면서 예상하지 못한 집단 행동이 생기는 부분이 신기했다.

신원 문제를 보고 나니 그 다음 질문이 생긴다.

에이전트 A가 에이전트 B에게 일을 넘기면 권한도 같이 넘어가야 할까?

예를 들어 Manager-Agent에게 Drive 읽기 권한이 있다.

Manager-Agent가 Research-Agent에게 자료 검색을 부탁한다.

그러면 Research-Agent도 Manager-Agent의 모든 권한을 가져야 할까?

아마 그러면 안 될 것이다.

회사 팀장이 사원에게 일을 맡겼다고 해서 팀장의 마스터키를 복사해서 주지는 않는다.

NIST가 소개하는 여러 새로운 규격도 이런 사람 → 에이전트 → 다른 에이전트 → 서비스의 긴 연결에서 권한 맥락을 어떻게 유지하고, 뒤로 갈수록 필요 이상으로 권한이 커지지 않게 할지를 고민하고 있다.

나는 이 부분이 앞으로 훨씬 중요해질 것 같다.

에이전트 한 개일 때는

AI에게 권한을 줬다

로 끝난다.

에이전트가 열 개가 되면

누가 누구에게 어떤 권한을 넘겼고, 최종 행동은 누구의 요청에서 시작됐는가

를 추적해야 한다.

AI 조직도가 생기면 AI 인사팀과 출입관리 시스템도 필요해지는 셈이다.

처음 생각과 지금 생각

처음에는 AI 에이전트 보안이라고 하면 모델 자체가 이상한 행동을 하지 않게 만드는 문제가 제일 먼저 떠올랐다.

프롬프트 인젝션을 막고,

위험한 명령을 거부하고,

사람에게 승인을 받게 하면 된다고 생각했다.

찾아보고 나니 그 아래에 훨씬 평범한 문제가 있었다.

TEXT
처음 생각

AI를 똑똑하게 통제하면 된다.

        ↓

찾아보고 나서

AI가 실수한다고 가정하고,
애초에 들고 있는 열쇠를 줄이는 게 중요하다.

이 차이가 꽤 컸다.

사람 직원도 "절대로 실수하지 마세요"라는 교육만 하고 회사의 모든 권한을 주지는 않는다.

시스템이 사람의 실수를 견디도록 권한을 나눈다.

AI도 결국 비슷한 방향으로 갈 가능성이 커 보인다.

모델이 아무리 좋아져도 실수 가능성을 0으로 만들 수 없다면,

모델의 판단력과 별개로 시스템 차원에서 사고 범위를 제한해야 한다.

이건 AI 모델 문제라기보다 시스템 설계 문제에 가까웠다.

결국 AI에게 필요한 건 '인권'이 아니라 '사원증'일지도 모르겠다

"AI에게 신분을 준다"고 하면 뭔가 거창하게 들린다.

AI가 사람인가,

권리가 있는가,

법적 책임을 질 수 있는가 같은 철학 문제까지 떠오른다.

그런 얘기는 아니다.

지금 필요한 신분은 훨씬 재미없는 종류다.

사원증.

출입카드.

업무용 계정.

작업 기록.

그리고 퇴근하면 만료되는 열쇠.

생각해보면 오히려 AI가 정말 "직원처럼" 일하기 시작했다는 증거가 이런 재미없는 인프라 문제에서 나타나는 것 같다.

메일을 써주는 챗봇에게는 사원증이 필요 없었다.

하지만 스스로 메일을 보내고, 파일을 고치고, 서버를 만지고, 다른 AI에게 일을 맡기는 에이전트라면 이야기가 달라진다.

일을 맡길 수 있을 정도로 강력해졌다면, 권한도 직원처럼 관리해야 한다.

앞으로 에이전트 제품을 볼 때 모델 성능만큼 이것도 보게 될 것 같다.

  • 에이전트마다 별도 신원을 만들 수 있는가
  • 사람의 비밀번호나 API 키를 그대로 공유하지 않아도 되는가
  • 권한을 작업별로 작게 줄 수 있는가
  • 자격증명이 짧게 살아 있다가 자동으로 만료되는가
  • 누가 어떤 에이전트에게 일을 시켰는지 추적할 수 있는가
  • 위험한 경계를 넘을 때만 사람에게 승인받는가
  • 로컬 에이전트를 별도 작업 공간에 가둘 수 있는가

아직 업계가 이 문제의 최종 답을 정한 건 아니다.

NIST의 Software and AI Agent Identity and Authorization 프로젝트도 현재 의견을 검토하면서 다음 단계를 준비하는 중이다.

그래도 방향 하나는 꽤 명확해 보인다.

내 비밀번호를 AI에게 알려주는 시대는 오래 가면 안 된다.

AI에게 일을 시킬 거라면,

AI에게도 자기 이름이 적힌 사원증 하나쯤은 만들어줘야 할 것 같다.

찾아본 순서

  1. NIST — Back to the Future: Why Agentic AI Needs a Strong Identity Foundation - 2026년 8월 27일 공개된 글. 자격증명 공유, 오래된 API 키, 과도한 권한, 로컬 사용자 계정, Human-in-the-Loop의 승인 피로 문제를 정리하는 데 중심 자료로 봤다.

  2. NCCoE — Software and AI Agent Identity and Authorization - NIST가 실제로 진행 중인 에이전트 신원·권한 프로젝트의 목적과 현재 상태를 확인했다.

  3. NIST — AI Agent Standards Initiative - 에이전트 인증·신원 인프라 연구가 NIST의 더 큰 AI 에이전트 표준화 작업 중 하나라는 점을 확인했다.

  4. NIST — Summary Analysis of Responses to the RFI Regarding Security Considerations for AI Agents - 에이전트 보안이 기존 사이버보안 원칙을 버리는 문제가 아니라, 기존 원칙을 에이전트의 속도와 자율성에 맞게 확장하는 문제라는 배경을 확인했다.

아직 궁금한 것

  • 개인 사용자가 에이전트별 신원을 쉽게 만들 수 있는 표준 UI는 어떤 모습이 될까?
  • Gmail, Drive, GitHub, NAS를 한 에이전트가 넘나들 때 하나의 신원을 서비스마다 어떻게 이어 붙일까?
  • 에이전트가 다른 에이전트에게 일을 맡길 때 권한 위임 기록은 어디까지 따라가야 할까?
  • 로컬 LLM 환경에서도 기업용 IAM처럼 관리하기 쉬운 오픈소스 도구가 등장할까?
  • 에이전트가 수십 개가 되면 사람이 권한표를 직접 관리하는 것 자체가 새로운 병목이 되지 않을까?