Samsung SDS

AI Agent 시대, 계정 관리를 다시 설계해야 하는 이유

에이전트가 업무 시스템을 다루기 시작하면, 사람 계정에 맞춰 만든 통제만으로는 누가 실행했고 어떤 권한을 썼는지 설명하기 어려워집니다. 이번 글에서는 에이전트의 신원과 권한, 생애주기를 운영에서 어떻게 관리할지 살펴봅니다.

고객 문의를 분류해 우선 대응이 필요한 고객에게 안내 메일을 보내는 업무가 있다고 해 보겠습니다. 에이전트는 고객 데이터베이스와 상담 이력을 조회하고, 내용을 분석해 안내 문구를 쓴 뒤 메일 시스템에 발송을 요청합니다. 직원이 여러 화면을 오가며 하던 일을 에이전트가 한 번에 이어서 처리합니다.

그런데 안내 메일이 엉뚱한 고객에게 나갔다고 해 봅시다. 기록을 열어 보면 요청한 직원의 이름만 남아 있습니다. 고객 데이터를 조회하고 메일을 보낸 것은 에이전트인데, 어느 에이전트가 어떤 권한으로 어떤 시스템을 썼는지는 기록에서 찾을 수 없습니다. 기록만으로 원인을 확인하기 어려워 개발 담당자와 함께 실행 과정과 연동 설정을 다시 살펴봐야 합니다. 관련 로그가 충분하지 않으면 어느 단계에서 문제가 생겼는지 특정하기도 어렵습니다.

[그림 1] 직원 요청부터 오발송까지, 실행 기록의 빈틈 (출처: 삼성SDS)

요청한 직원은 남지만, 실행한 에이전트는 보이지 않습니다 예시 업무 · 고객 문의를 분류해 우선 대응이 필요한 고객에게 안내 메일 보내기

실제로 일어난 일

1. 1. 작업 요청 : "우선 대응 고객에게 안내 메일 보내 줘"
2. 2. 데이터 조회 : 고객 DB와 상담 이력 조회, *에이전트가 한 번에 이어서 처리(2번~4번)
3. 3. 분석·작성 : 문의 내용 분석, 안내 문구 작성
4. 4. 발송 요청 : 메일 시스템에 발송 요청
5. 5. 오발송 : 엉뚱한 고객에게 안내 메일 발송

기록에 남은 것

1. 1. 요청한 직원 이름 기록됨
2. 2. 어느 에이전트가 기록 없음
3. 3. 어떤 권한으로 기록 없음
4. 4. 어떤 시스템을 썼는지 기록 없음
5. 5. 기록만으로는 원인 확인 어려움

1편에서는 사람이 로그인한 뒤 그 계정이 회사 안에서 어디까지 접근할 수 있는지를 다뤘습니다. 이번에는 시스템에 접근하는 주체를 에이전트로 바꿔 봅니다. 질문은 ‘이 에이전트의 신원과 권한은 누가 책임지는가’입니다.

1. 에이전트는 답변 뒤의 업무 처리까지 맡습니다

질문에 답하는 AI 도구를 쓸 때는 실제 시스템에서 처리하는 일을 사람이 맡는 경우가 많았습니다. 에이전트는 목표를 받으면 필요한 정보를 찾고 업무 시스템을 직접 호출합니다. 앞의 고객 안내 업무에서는 데이터베이스 조회, 내용 분석, 문구 작성, 메일 발송 요청이 이어집니다. 단계마다 사용하는 시스템과 권한도 달라집니다.

Gartner는 2028년까지 기업용 소프트웨어 애플리케이션의 33%에 에이전트형 AI가 포함될 것으로 전망했습니다. 2024년에는 1% 미만이었습니다. 같은 발표에서 에이전트형 AI 프로젝트의 40% 이상이 비용 증가, 불분명한 사업 가치, 미흡한 위험 통제 때문에 2027년 말까지 취소될 것으로 내다봤습니다.^[1] 위험 통제가 취소 사유로 꼽혔다는 것은, 통제 없이 에이전트를 늘리면 프로젝트가 중간에 멈출 수 있다는 경고로 읽힙니다.

에이전트가 처리한 최종 결과만 남아서는 실행 과정을 되짚기 어렵습니다. 누가 요청했는지, 어느 에이전트가 실행했는지, 어떤 계정이나 토큰을 썼는지, 어떤 시스템과 데이터에 접근했는지, 무엇을 했고 승인을 거쳤는지를 각 시스템의 기록에서 서로 연결해 추적할 수 있어야 합니다.

2. 위험은 에이전트가 쓰는 권한에서 시작됩니다

에이전트는 회사가 내준 권한으로 일합니다. 고객 데이터를 조회하고 메일을 보내는 동작도 정상 권한으로 처리됩니다. 권한이 탈취되면 공격자는 시스템의 취약점을 뚫지 않고도 데이터에 접근할 수 있습니다. 권한이 처음부터 넓게 잡혀 있었다면 피해 범위도 그만큼 커집니다. 정상 권한으로 접근한 기록만으로는 공격인지 가려내기 어렵습니다.

권한이 악용되는 경로는 여러 가지입니다. 에이전트가 읽는 문서나 웹페이지에 지시를 숨겨 동작을 바꾸는 프롬프트 인젝션, API 키나 토큰 탈취, 연결된 외부 도구나 플러그인(MCP 서버 등)의 취약점, 업무에 필요 없는 권한까지 열어 둔 설정이 대표적입니다. 입력 검증, 연결 도구 점검, 계정·권한 관리는 서로 맞물려 있지만 각각 다른 통제가 필요합니다.

국제 보안 단체 OWASP가 2026년 8월 발표한 LLM 애플리케이션 10대 위험(Top 10 for LLM Applications 2026)은 프롬프트 인젝션을 첫 번째 항목(LLM01)으로, 과도한 에이전시(Excessive Agency)를 세 번째 항목(LLM03)으로 분류했습니다. 과도한 에이전시는 에이전트에 필요 이상의 기능이나 권한을 주거나, 영향이 큰 작업을 확인 없이 실행하게 둘 때 생깁니다.^[2] 앞서 2025년 12월 발표된 에이전트 애플리케이션 10대 위험(Top 10 for Agentic Applications 2026)도 목표 탈취, 도구 오용, 신원·권한 오남용, 기억·문맥 오염을 위험 항목으로 다룹니다.^[3]

권한은 업무 단위로 나눠 최소 권한으로 줘야 합니다. 조회 권한은 필요한 데이터와 범위로 제한하고, 메일 발송이나 데이터 변경에는 대상과 승인 조건을 따로 둡니다. 관리자 권한은 별도 역할로 분리하고 사용 기간을 제한합니다. OWASP도 영향이 큰 작업에는 사람의 승인을 두고, 에이전트가 하위 시스템에 보내는 요청을 보안 정책에 따라 검증하라고 권고합니다.^[2] 조회 권한과 변경 권한을 처음부터 하나로 묶으면 나중에 나누기 어렵습니다.

3. 이미 발급된 토큰은 쓸 때마다 MFA를 거치지 않습니다

사람 계정에는 비밀번호와 함께 일회용 인증번호, 휴대폰 승인, 생체인증, 보안키를 적용할 수 있습니다. 에이전트는 휴대폰 승인을 누를 수도, 보안키를 꽂을 수도 없습니다. 사람용 절차를 그대로 적용하면 자동화가 멈추거나, 개발 과정에서 인증을 우회하는 구조가 생기기 쉽습니다.

서비스끼리 연결된 경로도 살펴봐야 합니다. 외부 서비스가 회사 업무 시스템에 접근할 때는 OAuth 토큰 같은 인증 정보를 쓰는 경우가 많습니다. 처음 연동을 승인할 때 담당자가 MFA를 거쳤더라도, 그 뒤 토큰이 쓰일 때마다 MFA가 다시 요구되지는 않습니다. 토큰이 유출되면 일반적인 사용자 로그인 MFA만으로 이미 발급된 토큰의 사용을 막기 어렵습니다.

2025년 8월 Salesloft Drift 사건이 한 사례입니다. Drift는 Salesloft가 운영하는 마케팅용 채팅 서비스로, 기업 웹사이트 방문자와 대화하는 AI 챗봇 기능을 갖추고 있습니다. Google 위협 인텔리전스 그룹(GTIG)에 따르면 공격자는 Drift와 Salesforce 연동에 발급된 OAuth 토큰을 탈취해 이르면 8월 8일부터 적어도 8월 18일까지 여러 기업의 Salesforce 환경에서 데이터를 대량으로 빼냈습니다. GTIG는 공격자의 주된 목적을 인증 정보 수집으로 평가했습니다. 공격자는 빼낸 데이터를 뒤져 AWS 접속 키, 비밀번호, Snowflake 관련 토큰 같은 인증 정보를 찾으려 했습니다.^[4] 미국 금융산업규제기구(FINRA)는 이 공격에 영향을 받은 조직이 700곳 이상이라고 설명했습니다.^[5] 이 숫자는 영향을 받은 조직의 수로, 700곳 모두에서 데이터 반출이 확인됐다는 뜻은 아닙니다. FINRA에 따르면 유출된 데이터의 범위도 조직마다 달랐습니다.

GTIG와 FINRA의 분석에서 AI 기능이 공격의 원인으로 지목되지는 않았습니다. 두 자료가 확인한 경로는 Drift와 Salesforce 연동에 발급된 OAuth 토큰을 공격자가 탈취해 그대로 쓴 것입니다. FINRA는 공격자가 이 토큰으로 기존 MFA를 우회했다고 설명합니다.^[5] 여기서 우회는 MFA를 깨뜨렸다는 뜻이 아니라, 이미 발급된 토큰을 써서 로그인과 MFA 단계를 거치지 않았다는 뜻입니다. 에이전트도 업무 시스템에 연결되는 순간 토큰과 인증 정보를 갖게 되고, 그 인증 정보는 같은 방식으로 노출될 수 있습니다.

대응은 연결을 끊고 토큰을 회수하는 데서 시작됐습니다. 8월 20일 Salesloft는 Salesforce와 함께 Drift 앱의 활성 액세스 토큰과 갱신 토큰(refresh token)을 모두 무효화했습니다. 8월 28일에는 'Drift Email' 연동 토큰도 탈취됐다는 사실이 추가로 확인됐습니다. 공격자는 8월 9일 이 토큰으로, Drift와 연동하도록 설정해 둔 극소수 Google Workspace 계정의 메일에 접근했습니다.^[4] GTIG는 이번 침해가 Salesforce 연동에만 그치지 않는다며, Drift에 저장되거나 연결된 인증 토큰은 모두 유출됐을 수 있다고 보고 대응하라고 안내했습니다. 연동 앱의 권한 범위를 최소로 줄이고 세션 유효 시간을 제한하라는 권고도 냈습니다.^[4] 외부 서비스를 연결한 뒤에도 토큰의 권한과 유효 기간을 계속 관리하고 사용하지 않는 연결은 해제해야 합니다.

[그림 2] Drift–Salesforce 연동 토큰 탈취와 대응 (출처: 삼성SDS)

연동 토큰이 유출되면, 사용자 MFA만으로 막기 어렵습니다

사람이 로그인할 때

• 직원
• 아이디· 비밀번호
• MFA : 휴대폰 승인·보안키
• Salesforce : 기업의 CRM 업무 시스템
• 정상 접속

달취한 토큰을 사용할 때

• 공격자
• Drift 연동 OAuth 토큰 : 처음 연통 승인 시 말금된 토큰
• 사용자 로그인 없이 추가 MFA 없음
• Salesforce : 기업의 CRM 업무 시스템
• 데이터 대량 반출

처음 연동 승인 때 MFA를 거쳐도, 발급된 토큰 사용 때마다 MFA를 다시 묻지는 않습니다. 대응: 권한 최소화 · 토큰 만료 설정 · 탈취 토큰 무효화 에이전트별 고유 신원과 짧은 수명의 인증정보도 검토합니다.

에이전트의 인증 정보가 노출될 수 있다는 지적이 새로 나온 것은 아닙니다. 미국 국립표준기술연구소(NIST)는 2020년 제로 트러스트 아키텍처 지침(SP 800-207) 5.7절에서 AI를 비롯한 소프트웨어 기반 에이전트가 기업 네트워크의 보안 관리 업무를 수행할 때 사람보다 낮은 수준의 인증(예: MFA 대신 API 키)을 사용할 수 있다고 설명합니다. 공격자가 에이전트의 인증 정보를 얻으면 해당 에이전트를 사칭할 수 있다는 위험도 지적합니다.^[6]

이 위험을 줄이는 방법으로 워크로드 아이덴티티(Workload Identity)가 쓰입니다. SPIFFE는 서버나 에이전트 같은 프로그램마다 짧은 기간 동안 유효한 인증서나 토큰을 발급해 서로의 신원을 확인하도록 하는 공개 표준입니다. 이 신원 확인과 별도로, 각 프로그램이 어떤 데이터와 기능에 접근할 수 있는지는 권한 정책으로 정해야 합니다.^[7] 여러 시스템에서 하나의 인증 정보를 오래 돌려 쓰는 방식보다 신원별로 만료와 회수 시점을 관리하기 쉽습니다. 에이전트마다 신원과 권한을 따로 두는 설계도 이 원리에서 출발할 수 있습니다.

4. 인증 다음에는 생애주기를 관리해야 합니다

인증을 설계했다고 관리가 끝나지는 않습니다. 에이전트는 만들어지고 권한을 받아 일하다가, 설정이나 담당자가 바뀌고 언젠가 멈춥니다. 프로젝트가 끝났는데 인증 정보가 살아 있거나 담당자가 바뀌었는데 책임자 정보가 그대로면, 아무도 관리하지 않는 에이전트가 계속 시스템에 접근할 수 있습니다.

관리는 등록에서 시작됩니다. 등록 단계에서 답할 질문은 다섯 가지입니다. 무엇을 위해 만들었는지, 누가 책임지는지, 어떤 시스템과 데이터에 어떤 인증 방식으로 접근하는지, 권한이 언제까지 필요한지, 실행 결과를 어떤 기록으로 설명할지입니다. 답이 비어 있으면 운영 중에 무엇을 기준으로 점검할지 정하기 어려우니, 권한을 늘리기 전에 이 정보부터 채워야 합니다.

[그림 3] 에이전트 등록 정보와 운영 중 관리 공백 (출처: 삼성SDS)

에이전트 관리는 등록에서 시작됩니다 등록할 때 다섯 가지 질문에 답해 두어야, 운영 중 무엇을 점검할지 기준이 생깁니다

에이전트 등록 카드 - 등록 단계에서 답할 질문

• 1. 목적 : 무엇을 위해 만들었나요?
• 2. 책임자 : 누가 책임지나요?
• 3. 접근 대상 ·인증 방식 : 어떤 시스템과 데이터에, 어떤 인증 방식으로 접근하나요?
• 4 권한 기한 : 권한이 언제까지 필요한가요?
• 5. 실행 기록 : 실행 결과를 어떤 기록으로 설명할 수 있나요?

운영하면서 관리 공백이 생기는 시점

• 1. 등록 : 에이전트들 만들고 등록 - 등록 카드 작성 → 이후 운영 중 점검 기준이 됨
• 2. 운영 :권한을 받아 업무 수행 - 시스템과 데이터에 접근해 업무 처리
• 3. 변경 : 설정·담당자가 바뀜 - 담당자가 바뀌었는데 책임자 정보는 그대로
• 4. 종료 : 프로젝트 종료·중지 - 프로젝트가 끝났는데 인증 정보는 살아 있음

답이 비어 있으면 운영 중 무엇을 기준으로 점검할지 정하기 어렵습니다. 권한을 늘리기 전에 이 정보부터 채웁니다. 아무도 관리하지 않는 에이전트가 계속 시스템에 접근할 수 있습니다

앱에 부여된 권한을 따로 점검해야 하는 이유는 Microsoft 사례에서 볼 수 있습니다. Microsoft는 2024년 1월 러시아 정부 지원 조직으로 지목한 Midnight Blizzard의 침입을 공개했습니다. 공격자는 여러 계정에 흔히 쓰이는 비밀번호를 하나씩 대입하는 방식(password spray)으로 오래된 비운영 테스트 계정에 침입했습니다. 이 계정에는 MFA가 적용돼 있지 않았습니다. 공격자는 이 접근을 발판으로 Microsoft 사내 환경에서 높은 권한을 가진 오래된 테스트용 OAuth 앱을 장악했습니다. 이어 악성 OAuth 앱을 만들어 메일함 접근 권한을 부여하고 Microsoft 사내 메일 계정에 접근했습니다.^[8]

이 사례에서 에이전트와 닮은 대상은 테스트용 OAuth 앱입니다. 사람이 로그인해 쓰는 계정이 아니었지만 사내 환경에 높은 권한을 가진 채 남아 있었고, 공격자는 이 앱을 거쳐 권한을 넓혔습니다. Microsoft는 OAuth 앱을 악용하면 처음 침해한 계정에 대한 접근을 잃더라도 앱을 통한 접근은 유지될 수 있다고 설명했습니다.^[8] 사람 계정의 비밀번호를 바꾸고 MFA를 적용하는 조치와 별개로, 앱과 에이전트에 이미 부여된 권한도 점검해야 합니다.

사람 계정에는 입사와 퇴사, 부서 이동처럼 권한을 다시 확인할 계기가 있습니다. 테스트용 앱이나 에이전트에는 그런 계기가 저절로 생기지 않습니다. 만든 사람이 챙기지 않으면 권한은 그대로 남습니다. 등록 때 정한 만료일, 담당자 변경, 프로젝트 종료, 장기 미사용을 점검 시점으로 삼고, 필요가 끝난 접근은 회수하도록 절차를 정해 두어야 합니다.

5. 에이전트도 기존 계정 관리 절차에 등록해야 합니다

에이전트마다 신원을 부여하고, 업무에 필요한 권한과 인증 정보의 만료·회수 기준을 정해야 합니다. 개발자 개인 계정이나 공용 키에 연결해 두면 어느 에이전트가 어떤 권한을 쓰는지 구분하기 어렵고, 담당자가 바뀌었을 때 회수해야 할 접근을 파악하기도 어렵습니다. 담당자 개인에게 관리를 맡겨 두기보다, 회사가 이미 운영하는 등록·인증·권한 관리 절차에 에이전트를 포함해야 합니다.

이러한 계정 관리를 지원하는 삼성SDS SingleID는 임직원과 관계사·협력사 사용자를 대상으로 통합인증(SSO), 복합인증(MFA), 계정 라이프사이클 관리 기능을 제공합니다.^[9] 에이전트가 업무 시스템을 직접 사용하는 환경에 맞춰, 사람 계정의 인증과 권한을 관리해 온 범위를 AI 에이전트의 신원과 접근 권한까지 넓혀가고 있습니다.

계정과 권한 관리는 ‘누가 어떤 권한으로 접근하는가’를 다룹니다. 에이전트를 안전하게 운영하려면 프롬프트 인젝션 방어, 연결된 외부 도구의 보안, 데이터 유출 방지, 업무 결과 검증도 함께 마련해야 합니다. 영향이 큰 작업은 실행 전에 사람이 확인하는 절차도 필요합니다.^[2][3] 도입 단계에서 계정·권한 관리와 입력·도구·실행 결과에 대한 보안 통제를 각각 누가 담당하고 어떻게 연계할지 정해 두어야 운영 중 관리 공백을 줄일 수 있습니다.

6. 목록부터 만들고 위험이 큰 에이전트부터 점검합니다

모든 에이전트를 한 번에 관리 체계에 올리기는 어렵습니다. 먼저 개발 환경과 운영 환경에서 쓰는 에이전트, 외부 서비스 연결을 찾아 목록을 만듭니다. 목록에는 목적, 책임자, 연결 시스템, 인증 방식, 권한, 만료일을 적습니다. 점검은 고객·인사·재무 데이터에 접근하거나, 외부로 메일을 보내거나, 관리자·운영 시스템에 닿는 에이전트부터 합니다.

그 다음 개인 계정이나 공용 키를 쓰는 에이전트를 찾아 고유한 신원으로 옮기고 책임자를 지정합니다. 위험이 큰 에이전트는 조회·발송·변경·관리자 권한을 나눕니다. 프로젝트가 끝났거나 담당자가 바뀌었거나 오래 쓰지 않은 에이전트는 인증 정보를 회수하거나 새로 발급합니다. 세밀한 권한 설정이 어려운 오래된 시스템에는 조회 전용 권한, 접속 IP 제한, 짧은 만료 주기 같은 보완책을 적용할 수 있습니다.

등록 절차를 너무 무겁게 만들면 현업은 관리 체계 밖에서 에이전트를 만듭니다. 처음에는 목적, 책임자, 접근 대상, 만료일을 확인하고 이미 운영 중인 에이전트와 연결을 목록에 넣는 일부터 시작하는 편이 현실적입니다. 앞에서 말한 다섯 가지 질문 중 나머지는 목록을 만든 뒤 채워도 늦지 않습니다.

네 가지 점검부터 시작합니다

처음의 고객 안내 메일 이야기로 돌아가 보겠습니다. 메일이 잘못 나갔을 때 누가 요청했고 어느 에이전트가 어떤 권한으로 어떤 데이터를 조회했는지 기록에서 바로 찾을 수 있다면, 개발 담당자를 찾아다닐 필요가 없습니다. 그 상태를 만들려면 다음 네 가지부터 점검해야 합니다.

1. 개발·운영 환경의 에이전트와 외부 서비스 연결을 목록으로 만들고 책임자를 지정합니다.
2. 개인 계정이나 공용 키에 연결된 에이전트를 찾아 고유한 신원으로 분리합니다. 실행 기록에 요청한 직원과 실행한 에이전트를 나눠 남기려면 이 작업이 먼저입니다.
3. 만료일이 없거나 더는 필요 없는 토큰과 인증 정보를 찾아 사용 기한을 정하거나 회수합니다.
4. 위험이 큰 에이전트의 조회·발송·변경·관리자 권한이 한데 묶여 있는지 확인하고 필요한 범위로 나눕니다.

네 가지 점검은 새 인증 기술을 들이기 전에 시작할 수 있습니다. 업무를 에이전트에 맡겨도 그 에이전트에 접근을 허용하고 관리할 책임은 회사에 남습니다. 그 책임을 누가 맡을지 정하는 일이 에이전트 계정 관리의 출발점입니다.

References

• Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," 2025.6.25. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
• OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026, 2026.8.3. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
• OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, 2025.12.9. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• Google Threat Intelligence Group, "Widespread Data Theft Targets Salesforce Instances via Salesloft Drift," 2025.8.27 (8.28 업데이트). https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift
• FINRA, "Cybersecurity Alert – Salesloft Drift AI Supply Chain Attack." https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack
• NIST, Special Publication 800-207: Zero Trust Architecture, 2020.8. https://csrc.nist.gov/pubs/sp/800/207/final
• SPIFFE, "SPIFFE Overview." https://spiffe.io/docs/latest/spiffe-about/overview/
• Microsoft Threat Intelligence, "Midnight Blizzard: Guidance for responders on nation-state attack," 2024.1.25. https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/
• 삼성SDS, "SingleID – 하이브리드 업무 환경에서 보안강화를 위한 통합인증 및 계정관리 서비스" https://www.samsungsds.com/kr/security-singleid/singleid.html

FAQ