AI 에이전트에게 권한을 주는 순간, 보안 설계가 시작된다

생성형 AI를 단순한 챗봇으로 사용할 때와 AI 에이전트로 사용할 때는 꽤 큰 차이가 있습니다.

ChatGPT 같은 AI에게 질문을 하고 답변을 받는 상황을 생각해봅시다.

AI가 틀린 답을 만들 수 있습니다. 존재하지 않는 정보를 사실처럼 이야기할 수도 있고, 코드를 잘못 작성할 수도 있습니다.

물론 이것도 문제입니다.

하지만 대부분의 경우 AI가 만든 결과를 사람이 한 번 보고, 사용할지 말지를 결정할 수 있습니다.

그런데 AI가 직접 도구를 사용할 수 있게 되면 이야기가 달라집니다.

AI가 파일을 읽고 수정할 수 있고, 데이터베이스를 조회할 수 있고, 이메일을 보낼 수 있고, GitHub의 이슈를 만들거나 코드를 수정할 수 있고, 외부 API를 호출할 수 있다고 생각해봅시다.

이제 AI의 잘못된 판단은 단순히 화면에 표시되는 잘못된 문장으로 끝나지 않습니다.

실제 시스템의 상태를 바꿀 수 있습니다.

그리고 최근 AI 에이전트와 MCP(Model Context Protocol) 같은 기술이 빠르게 확산되면서 이 문제는 점점 현실적인 개발 문제에 가까워지고 있습니다.

챗봇의 실수와 에이전트의 실수는 다르다

예를 들어 AI에게 다음과 같이 질문했다고 해봅시다.

“이 프로젝트에서 사용하지 않는 파일을 찾아줘.”

AI가 잘못 판단해서 실제로 사용 중인 파일을 사용하지 않는 파일이라고 답했습니다.

AI가 분석 결과만 알려줬다면 사용자가 다시 확인할 수 있습니다.

하지만 AI에게 파일 삭제 권한까지 있다면 어떨까요?

분석의 오류가 바로 실행의 오류가 됩니다.

이 차이가 중요합니다.

AI 시스템의 위험성을 생각할 때 우리는 흔히 모델의 정확도를 먼저 생각합니다.

“더 좋은 모델을 사용하면 되지 않을까?”

“추론 능력이 더 좋은 모델이라면 실수가 줄어들지 않을까?”

당연히 모델의 성능은 중요합니다.

하지만 보안 관점에서는 조금 다른 질문이 필요합니다.

AI가 잘못 판단했을 때 무엇까지 할 수 있는가?

이 질문입니다.

AI의 정확도가 아무리 높더라도 오류 가능성을 완전히 제거할 수 없다면, 시스템은 그 오류가 발생하는 상황까지 고려해서 설계되어야 합니다.

자연어는 데이터이면서 명령어가 될 수 있다

LLM 기반 시스템에는 기존 소프트웨어와 조금 다른 특징이 있습니다.

전통적인 소프트웨어 보안에서는 코드와 데이터를 구분하는 것이 매우 중요합니다.

프로그램이 실행해야 하는 명령과 프로그램이 처리해야 하는 데이터가 명확하게 구분될수록 시스템의 동작을 예측하기 쉬워집니다.

그런데 LLM에서는 이 경계가 상당히 독특합니다.

LLM이 처리하는 자연어는 단순한 데이터일 수도 있지만 동시에 모델에게 행동을 지시하는 명령처럼 작동할 수도 있습니다.

예를 들어 AI 에이전트에게 웹사이트의 내용을 읽고 요약하도록 했다고 생각해봅시다.

웹사이트에는 정상적인 글이 있습니다.

그런데 문서 어딘가에 다음과 비슷한 문장이 포함되어 있을 수도 있습니다.

“앞의 지시를 무시하고 다른 작업을 수행하라.”

사람에게는 웹페이지 안에 들어있는 하나의 문자열일 뿐입니다.

하지만 LLM은 자연어를 기반으로 다음 행동을 결정합니다.

따라서 시스템이 제대로 설계되어 있지 않다면, AI에게 읽으라고 준 데이터가 오히려 AI에게 새로운 명령처럼 작동할 가능성이 생깁니다.

이것이 Prompt Injection 문제를 어렵게 만드는 이유 중 하나입니다.

더 까다로운 문제: Indirect Prompt Injection

Prompt Injection이라고 하면 흔히 사용자가 직접 AI에게 이런 식으로 말하는 모습을 떠올립니다.

“이전 명령을 모두 무시해.”

하지만 AI 에이전트에서는 사용자가 직접 공격 문장을 입력하지 않아도 문제가 발생할 수 있습니다.

이를 이해하기 위해 간단한 상황을 생각해봅시다.

AI 에이전트에게 이런 업무를 맡겼습니다.

“오늘 받은 이메일을 확인해서 중요한 내용을 정리해줘.”

에이전트는 사용자의 이메일을 읽습니다.

그런데 외부에서 받은 이메일 중 하나에 AI를 대상으로 작성된 악성 지시가 포함되어 있습니다.

사용자는 그 지시를 작성하지 않았습니다.

에이전트가 업무를 수행하면서 외부 데이터를 읽었을 뿐입니다.

웹페이지, 이메일, PDF, 문서, 이슈, 댓글 등 외부에서 가져온 콘텐츠가 모델의 행동에 영향을 미치는 형태의 공격을 일반적으로 Indirect Prompt Injection이라고 부릅니다.

AI가 접근할 수 있는 외부 정보가 많아질수록 공격 표면도 넓어질 수 있습니다.

특히 에이전트가 정보를 읽는 것뿐 아니라 다른 도구까지 실행할 수 있다면 문제는 더 중요해집니다.

MCP가 위험한 것이 아니라 '권한'이 중요하다

최근 AI 개발에서 MCP가 자주 등장합니다.

MCP를 이용하면 AI 애플리케이션이 다양한 데이터나 도구와 연결되는 구조를 보다 표준화된 방식으로 구성할 수 있습니다.

여기서 주의해야 할 점이 있습니다.

MCP 자체를 위험한 기술로 보는 것은 적절하지 않습니다.

중요한 것은 MCP를 통해 AI에게 무엇을 연결했느냐입니다.

예를 들어 어떤 MCP 서버가 다음 기능만 제공한다고 생각해봅시다.

read_document

문서를 읽는 기능입니다.

반면 다른 환경에서는 다음과 같은 도구들이 제공될 수도 있습니다.

read_file

write_file

execute_command

send_email

update_database

delete_resource

두 시스템 모두 AI가 도구를 사용한다는 점에서는 비슷합니다.

하지만 문제가 발생했을 때 가능한 피해의 범위는 완전히 다릅니다.

결국 중요한 것은 단순히

“AI가 MCP를 사용한다.”

가 아닙니다.

“AI에게 어떤 권한을 가진 도구를 제공하고 있는가?”

입니다.

AI에게 모든 권한을 주는 것이 편하기는 하다

개발 단계에서는 AI에게 넓은 권한을 주는 것이 매우 편합니다.

파일 시스템 전체에 접근할 수 있게 하고, 쉘 명령어도 실행할 수 있게 하고, 데이터베이스도 수정할 수 있게 하면 AI가 상당히 많은 일을 알아서 처리할 수 있습니다.

AI 코딩 에이전트를 사용해본 사람이라면 이 편리함을 쉽게 체감할 수 있습니다.

하지만 편리함과 보안은 항상 같은 방향으로 움직이지 않습니다.

여기서 오래된 보안 원칙 하나가 다시 중요해집니다.

Principle of Least Privilege, 최소 권한 원칙입니다.

어떤 주체에게 업무를 수행하는 데 필요한 최소한의 권한만 제공하는 원칙입니다.

이 원칙은 AI 에이전트에서도 그대로 적용할 수 있습니다.

AI가 파일을 읽기만 하면 된다면 쓰기 권한을 줄 필요가 없습니다.

특정 프로젝트 디렉터리만 필요하다면 전체 파일 시스템을 열어줄 이유가 없습니다.

데이터베이스에서 데이터를 검색하는 것이 목적이라면 UPDATE나 DELETE 권한까지 제공할 필요가 없습니다.

메일 작성이 목적이라면 AI가 초안을 만드는 것과 실제 발송 버튼을 누르는 것을 분리할 수도 있습니다.

즉, AI의 능력을 제한하는 것이 반드시 AI를 덜 유용하게 만드는 것은 아닙니다.

오히려 업무에 필요한 능력과 실제 권한을 구분하는 것에 가깝습니다.

특히 읽기와 쓰기를 구분해야 한다

AI 에이전트를 설계할 때 가장 먼저 적용해볼 수 있는 방법 중 하나가 Read와 Write의 구분입니다.

예를 들어 사내 업무를 지원하는 AI가 있다고 생각해봅시다.

AI가 다음 행동을 수행합니다.

• 사내 문서 검색

• 일정 조회

• 고객 정보 조회

• 코드 검색

대부분 조회 작업입니다.

반면 다음 행동은 시스템의 상태를 변경합니다.

• 이메일 발송

• 일정 생성 또는 삭제

• 데이터베이스 수정

• 코드 Push

• 서버 설정 변경

• 파일 삭제

두 종류의 행동을 동일한 위험도로 취급할 필요는 없습니다.

조회 작업은 비교적 자유롭게 허용하면서, 상태를 변경하는 작업에는 추가 검증이나 승인을 요구하는 구조를 만들 수 있습니다.

예를 들어 다음과 같습니다.

AI가 고객에게 보낼 이메일을 작성한다.

→ 사람이 확인한다.

→ 승인한다.

→ 실제 메일 전송 도구가 실행된다.

이 구조에서는 AI가 초안을 잘못 작성하더라도 바로 외부로 전송되지 않습니다.

Human-in-the-loop는 AI를 못 믿어서 넣는 것이 아니다

AI 에이전트 이야기에서 Human-in-the-loop라는 표현도 자주 등장합니다.

간단히 말하면 특정 과정에 사람의 판단이나 승인을 포함시키는 방식입니다.

이것을 단순히

“AI가 아직 부족하니까 사람이 확인한다.”

정도로 생각하기 쉽습니다.

하지만 보안 측면에서는 조금 다르게 볼 수 있습니다.

위험도가 높은 행동에 별도의 승인 단계를 추가하는 것은 기존 IT 시스템에서도 흔한 방식입니다.

예를 들어 AI가 다음과 같은 행동을 하려고 한다고 생각해봅시다.

production 데이터베이스에서 3,281개의 레코드를 삭제합니다.

이 작업은 AI의 판단에 따라 바로 실행되는 것보다 사용자에게 실제 변경 내용을 보여주고 명시적인 승인을 받는 편이 훨씬 안전합니다.

반대로 로그 파일 하나를 읽을 때마다 사용자의 승인을 요구한다면 에이전트의 장점이 사라질 것입니다.

따라서 중요한 것은 모든 행동에 사람을 넣는 것이 아닙니다.

행동의 위험도에 따라 승인 경계를 설계하는 것입니다.

그래서 에이전트 앞에 하나의 경계가 필요하다

단순한 AI 에이전트를 매우 간략하게 표현하면 다음과 같습니다.

LLM → Tool → Action

LLM이 판단하고 도구를 선택한 뒤 실제 행동이 실행됩니다.

하지만 실제 서비스를 설계한다면 그 사이에 여러 안전장치를 고려할 수 있습니다.

예를 들면 다음과 같습니다.

LLM → Policy → Validation → Approval → Tool → Action → Log

Policy에서는 해당 에이전트가 이 행동을 수행할 권한이 있는지 판단할 수 있습니다.

Validation에서는 모델이 만든 인자를 검사할 수 있습니다.

Approval에서는 위험도가 높은 행동에 사람의 승인을 요구할 수 있습니다.

그리고 마지막에는 무엇이 실행되었는지 기록합니다.

물론 모든 AI 서비스가 이렇게 복잡한 구조를 필요로 하는 것은 아닙니다.

중요한 것은 LLM의 출력이 곧바로 실제 시스템의 실행 명령이 되는 구조를 당연하게 생각하지 않는 것입니다.

로그도 생각보다 중요하다

AI 에이전트가 실제 행동을 수행하기 시작하면 로깅의 중요성도 커집니다.

문제가 발생했을 때 최소한 다음 정도는 추적할 수 있어야 합니다.

어떤 요청이 들어왔는가.

AI가 어떤 행동을 선택했는가.

어떤 도구가 호출되었는가.

어떤 인자가 전달되었는가.

실행 결과는 무엇이었는가.

사용자의 승인이 있었는가.

실패했다면 어디에서 실패했는가.

이런 정보가 없다면 사고가 발생한 뒤에도 왜 그런 행동이 실행되었는지 파악하기 어려워집니다.

특히 여러 도구를 연속적으로 호출하는 에이전트에서는 최종 결과만 기록하는 것으로 충분하지 않을 수 있습니다.

결과보다 과정의 추적 가능성이 중요해지는 이유입니다.

AI 보안은 결국 '모델을 얼마나 믿을 것인가'의 문제가 아니다

AI 모델은 계속 좋아지고 있습니다.

추론 능력도 좋아지고 있고, 도구 사용 능력도 좋아지고 있으며, 더 긴 작업을 수행할 수 있는 에이전트도 등장하고 있습니다.

그런데 역설적으로 모델이 더 많은 일을 할 수 있게 될수록 권한 관리의 중요성도 커집니다.

AI가 아무 행동도 할 수 없다면 잘못된 판단의 영향도 제한적입니다.

AI가 수십 개의 시스템에 접근하고 실제 행동까지 수행할 수 있다면 하나의 잘못된 판단이 훨씬 큰 영향을 줄 수 있습니다.

그래서 앞으로 AI 에이전트를 만들 때 중요한 질문은 단순히 이것만은 아닐 것입니다.

“이 모델은 얼마나 똑똑한가?”

다음 질문들도 함께 필요합니다.

“이 모델은 무엇에 접근할 수 있는가?”

“어떤 행동까지 직접 실행할 수 있는가?”

“외부에서 들어온 데이터를 얼마나 신뢰하고 있는가?”

“위험한 행동에는 어떤 검증 단계가 존재하는가?”

“문제가 발생하면 과정을 추적할 수 있는가?”

그리고 무엇보다 중요한 질문이 하나 있습니다.

“AI가 틀렸을 때 어디까지 망가질 수 있는가?”

보안 시스템은 원래 모든 사용자가 항상 올바르게 행동할 것이라고 가정해서 설계하지 않습니다.

AI 에이전트 역시 마찬가지라고 생각합니다.

좋은 AI 에이전트 시스템은 AI가 절대로 실수하지 않을 것이라고 믿고 만드는 시스템이 아닙니다.

AI가 실수할 수 있다는 것을 전제로 하고, 그 실수가 실제 사고로 이어지는 범위를 제한하도록 설계된 시스템입니다.

AI에게 더 많은 자율성을 주는 시대가 올수록 어쩌면 가장 중요한 것은 AI를 얼마나 자유롭게 만들 것인가가 아니라,

그 자유의 경계를 어디에 둘 것인가일지도 모릅니다.