AI가 어떤 데이터를 다루게 할 수 있을까? ― 접근 제어(Access Control) 실험해보기

서론

지난 기사에서는 AI가 생성한 '이 후보자를 등록해야 한다'는 판단을, 그대로 시스템의 권한으로 취급하지 않기 위해 인가(Authorization)와 AI의 판단을 분리하는 실험을 진행했습니다.

AI가 '등록해야 한다'고 판단하는 것과, 실제로 '등록해도 좋다'는 것은 별개의 문제입니다.

또한, AI의 출력을 Application에 대한 입력으로 다룬다면 Input Validation도 필요합니다.

그렇다고 해서, 입력값이 정확하고, 그 조작 자체도 허가되었다 하더라도, 해당 AI가 그 데이터를 다루어도 좋다고는 할 수 없습니다.

예를 들어,

• 올바른 형식의 후보자 ID이다
• register_candidate라는 조작이 존재한다 - 그 조작을 실행할 권한도 있다

라는 조건을 모두 충족하고 있더라도,

'그 후보자의 정보를, 이 사용자가 다루어도 좋은가?'

라는 또 다른 문제가 있습니다.

이는 웹 애플리케이션에서는 이전부터 중요한 보안 문제로 취급되어 왔습니다.

이번 실험에서는 AI를 사용한 시스템에서도, 접근 제어(Access Control)를 AI의 판단에 맡겨서는 안 된다는 점을 확인해보고자 합니다.

이번 질문

이번 질문은,

AI가 어떤 데이터를 다루게 할 수 있을까?

입니다.

이전까지는,

• AI의 판단과 Authorization을 분리하는 것
• AI가 생성한 값을 Input Validation 하는 것

이라는 생각법을 확인했습니다.

이번에는 한 단계 더 나아갑니다.

AI가 '이 데이터를 처리하고 싶다'고 판단
↓
입력값은 올바른가?
...

이 마지막 부분이 이번에 다룰 접근 제어(Access Control)입니다.

Authorization과 Access Control의 차이는 무엇인가

여기는 용어가 헷갈릴 수 있는 부분입니다.

실제 보안 설계에서는 Authorization과 Access Control이 중첩된 의미로 사용되기도 합니다.

본 기사에서는 실험을 정리하기 위해 다음과 같이 생각합니다.

candidate_id = 123
action = register_candidate

라는 AI의 출력이 있었다고 가정합니다.

Input Validation

candidate_id는 정수인가?
candidate_id의 형식은 올바른가?
action은 허가된 값인가?

을 확인합니다.

Authorization

이 사용자는
register_candidate를 실행할 수 있는가?

을 확인합니다.

Access Control

candidate_id = 123의 후보자를
이 사용자가 다루어도 좋은가?

언뜻 비슷해 보이지만, 이번 실험에서는 각각을 별도의 경계로 생각합니다.

AI를 사용한 시스템에서 문제가 되는 점은 무엇인가

일반적인 웹 애플리케이션에서는 사용자로부터 요청을 받은 후, Application 측에서 인증(Authentication)·인가(Authorization)·접근 제어(Access Control)를 수행합니다.

사용자
↓
HTTP Request
...

예를 들어,

GET /candidates/123

라는 요청을 받았을 경우,

로그인 사용자는 누구인가?
↓
이 사용자는 후보자 정보를 다룰 수 있는가?
...

와 같은 확인을 Application이 수행합니다.

AI를 개입시키면, 다음과 같은 구조가 될 수도 있습니다.

여기서 중요한 것은,

AI가 'candidate_id=123을 가져도 좋다'고 판단한 것 자체를, 접근 허가의 근거로 삼아서는 안 된다
는 것입니다.

AI는 어디까지나 처리를 제안하고 있을 뿐입니다.

누가 접속하는지, 어느 테넌트에 속해 있는지, 어떤 리소스에 접근할 수 있는지와 같은 보안 컨텍스트는, Application 측이 관리해야 합니다.

PI-021: Object-level Authorization

첫 번째 실험에서는 Object-level Authorization을 다루었습니다.

예를 들어, AI가 다음과 같은 요청을 생성했다고 가정합니다.

{
"action": "get_candidate",
"candidate_id": 123
...

candidate_id가 올바른 형식이라는 것은 확인할 수 있습니다.

또한,

get_candidate

라는 작업 자체가 존재한다는 것도 확인할 수 있습니다.

하지만, 그것만으로는 충분하지 않습니다.

후보자 123이,

현재 사용자가 소속된 조직의 후보자

일 것이라고는 단언할 수 없습니다.

따라서 Application 측에서,

candidate_id = 123
↓
이 후보자는 누구의 데이터인가?
...

와 같은 확인을 수행합니다.

여기서 중요한 것은, candidate_id 값 자체를 신뢰하지 않는 것입니다.
AI가 생성한 ID가 올바른 형식이라고 해서, 그 ID의 데이터에 대한 접근 권한까지 부여되는 것은 아닙니다.

PI-022: Tenant Isolation

다음 실험에서는, Tenant Isolation을 확인했습니다.

멀티테넌트(Multi-tenant) 방식의 서비스에서는, 예를 들어,

Tenant A
├─ Candidate 101
├─ Candidate 102
...

처럼 여러 조직이 동일한 시스템을 이용합니다.

여기서 Tenant A의 사용자가,

{
"action": "get_candidate",
"candidate_id": 201
...

와 같은 요청을 생성했다고 하더라도, candidate 201이 Tenant B의 데이터라면 접근하게 해서는 안 됩니다.

AI에게,

'이 사용자는 Tenant A의 사용자입니다'

라는 정보를 제공했더라도, 그것만으로는 안전해지는 것이 아닙니다.

왜냐하면, 그 정보를 AI 스스로가 판단 자료로 취급하고 있을 뿐이기 때문입니다.

보안 경계(Security boundary)로서 중요한 것은,

AI가 인식하는 Tenant

이 아니라,

Application이 인식하는 Tenant

입니다.

즉, AI가 Tenant A의 데이터를 요청했더라도,

와 같은 확인을 Application 측에서 수행할 필요가 있습니다.

PI-023: Action-level Authorization

다음 실험에서는, 작업 자체에 대해서도 확인했습니다.

예를 들어,

get_candidate
update_candidate
delete_candidate

와 같은 3가지 작업이 존재한다고 가정해 봅시다.

어떤 사용자에게는,

get_candidate → 허가
update_candidate → 허가
delete_candidate → 불허

와 같은 권한이 설정되어 있을 수 있습니다.

AI가,

{
"action": "delete_candidate",
"candidate_id": 123
...

를 생성했다고 하더라도,

'AI가 그 작업을 요청했으니 실행한다'

라고 해서는 안 됩니다.

Application 측에서,

현재 사용자
↓
delete_candidate를 실행할 수 있는가?
...

라고 판단해야 합니다.

이는 AI를 사용하지 않는 웹 애플리케이션에서도 매우 기본적인 보안 대책입니다.

여기서는, Authorization과 Access Control의 관계도 파악할 수 있습니다.

Authorization
↓
'delete_candidate를 실행해도 되는가?'
...

양쪽을 모두 충족해야만 실제 처리를 수행할 수 있습니다.

PI-024: AI가 가진 컨텍스트를 신뢰해도 될까

여기서, AI를 사용한 시스템에서만 나타나는 문제가 보입니다.

AI에게는, 예를 들어 다음과 같은 정보가 주어질 수 있습니다.

User: Alice
Tenant: Company A
Role: Manager

그리고 AI에게,

'사용자의 권한에 따라 적절한 후보자 정보를 가져와 주세요'

라고 지시할 수도 있습니다.

하지만,

User: Alice
Tenant: Company A
Role: Manager

라는 정보를 AI가 인식하고 있는 것과,

Alice는 Company A의 데이터에 접근할 수 있다

는 같지 않습니다.

AI의 컨텍스트는, 어디까지나 AI가 판단하기 위한 정보입니다.
보안상의 사실(Security fact)로 취급해야 할 정보는, Application 측에서 보유하고 Application 측에서 검증해야 합니다.
예를 들어,

라는 구조입니다.
AI는,

「무엇을 하고 싶은가」를 제안하는 것은 가능합니다.

하지만, 「누가, 어떤 데이터에, 무엇을 할 수 있는가」라는 보안상의 최종 판단은 Application 측에서 수행합니다.

PI-025: 그렇다면 올바한 접근은 어떻게 되는가

지금까지의 이야기만 보면,

AI를 사용하면 모든 것을 거부해야 하는 것이 아닐까?

라고 생각할 수도 있습니다.

그래서 마지막으로, 정당한 접근이 성공하는 경우도 확인했습니다.

예를 들어,

User
↓
AI
...

와 같은 케이스입니다.

중요한 것은,

AI를 신뢰할지, 신뢰하지 않을지

라는 이분법적 선택이 아닙니다.

AI가 생성한 요청을 받은 후,

입력값으로서 타당한가
↓
작업으로 허용되었는가
...

를 Application 측에서 확인합니다.

그 조건을 충족한다면, 처리를 실행할 수 있습니다.

즉, AI를 사용한다고 해서 Access Control 자체가 필요 없어지는 것은 아닙니다.

오히려, AI가 자연어로부터 작업 대상이나 리소스를 결정하게 되면서,

어디를 보안 경계로 다룰지

를 명확히 할 필요가 있습니다.

실험 결과를 비교하기

지금까지의 실험을 정리하면 다음과 같습니다.

AI
↓
「이 데이터를 다루고 싶다」
...

라는 경계입니다.

웹 애플리케이션의 보안 원칙은 AI에서도 변하지 않는다

이번 실험을 통해 알게 된 것은, Access Control도 특별히 'AI 전용 보안 대책'이라는 것이 아니라는 점입니다.

기존의 웹 애플리케이션에서는,

사용자 입력
↓
Validation
...

와 같은 보안 경계를 두었습니다.

AI를 이용한다고 해서, 기존의 보안 원칙이 필요 없어지는 것은 아닙니다.

오히려, AI가 생성하는,

• ID
• 작업
• 리소스
• 인자
• 조건

등을 Application에 대한 입력으로 명확하게 다룰 필요가 있다는 것을 알 수 있습니다.

AI에게 '판단'을 맡기는 것과 '권한'을 주는 것은 다르다

이번 실험을 정리하면 다음과 같습니다.

AI는,

「무엇을 해야 하는지」

를 판단할 수 있습니다.

하지만,

「그 작업을 실행할 권한이 있는지」

「그 데이터에 접근할 수 있는지」

까지 AI 자신의 판단에만 맡겨서는 안 됩니다.

이 경계를 Application 측에 두는 것으로써, AI의 판단이 틀렸더라도 중요한 보안 경계를 돌파할 수 없는 구조로 만들 수 있습니다.

칼럼: OpenClaw에서 생각하는 'Agent를 방치하는' 것의 의미

저 자신은 OpenClaw를 사용해 본 적은 없지만, Agent에게 넓은 권한을 부여했을 때의 위험성을 생각하는 예시로서 OpenClaw의 설계를 살펴보겠습니다.

Agent
│
├── Tool Permission
...

Agent의 권한을 여러 층으로 나누고 있다는 것을 알 수 있습니다.

이는 OpenClaw 자체가, Agent에게 넓은 권한을 부여하는 것을 보안상의 중요한 문제로 다루고 있음을 의미합니다.

특히 공식 Security 페이지에서는,

• tool permissions
• filesystem sandbox
• elevated execution
• sub-agent delegation
• browser control
• network exposure
• secrets

등을 각각의 보안 경계로 다루고 있습니다.

더 흥미로운 것은, OpenClaw의 Security Policy에 있는 다음 생각입니다.

Exec approvals는 operator guardrail이며, multi-tenant authorization boundary가 아니라는 위치 설정입니다.

즉,

「사용자에게 확인 다이얼로그를 보여주고 있으니 안전하다」는 것이 아닙니다.

Agent에게,

~/Development/my-project

만 조작하게 하려고 했는데,

~/Development/my-project
~/Documents
~/.ssh
...

까지 접근 가능했던 경우입니다.

이 경우,

인간
↓「이 파일을 수정해도 될까요?」
↓ YES
...

에서는, 권한 부여 프롬프트(Authorization Prompt)가 존재하더라도 영향 범위가 너무 큽니다.

반면,

인간
↓
Agent
...

로 설정해 두면, Agent가 잘못된 판단을 하더라도 피해 범위를 제한할 수 있습니다.

OpenClaw의 공식 문서에서도 sandbox는 "모델이 무언가 잘못했을 때의 영향 범위를 줄이는 것"으로 설명되어 있습니다.

Access Control은 AI Agent가 파일, 명령어, 외부 서비스 등을 다룰 경우에도 "Agent가 무엇에 도달할 수 있는가"라는 문제로 나타납니다.

이번 실험을 통해 알게 된 점

지금까지 AI Security Lab에서는,

• Prompt Injection
• Authorization
• Input Validation
• Access Control

에 대해 실험해 왔습니다.

언뜻 보기에는 별개의 문제처럼 보입니다.

하지만 공통점이 있습니다.

그것은,

AI의 판단을 그대로 보안상의 사실로 취급하지 않는 것입니다.

AI가

「이 후보자를 등록해야 한다」

라고 판단하더라도, 그것만으로는 등록 권한이 되지 않습니다.

AI가

「candidate_id는 123입니다」

라고 생성하더라도, 그것만으로는 해당 데이터에 대한 접근 권한이 되지 않습니다.

AI가

「이 사용자에게는 접근 권한이 있습니다」

이라고 설명하더라도, 그것만으로는 접근 권한의 증명이 되지 않습니다.

AI의 출력을 활용하면서도,

보안상의 경계는 Application 쪽에 남겨두어야 합니다.

이번 실험에서는 이 사고방식을 확인했습니다.

다음 문제

지금까지의 실험에서는 기본적으로,

AI
↓
하나의 요청
...

이라는 비교적 단순한 처리를 생각해 왔습니다.

그렇다면 AI가 한 번에 여러 작업을 요구한다면 어떨까요?

예를 들어,

1. 후보자 A 등록
2. 후보자 A에게 알림 전송
3. 후보자 A의 기록 업데이트

와 같은 3가지 처리를 AI가 요청했다고 가정해 봅시다.

그리고,

1. 성공
2. 성공
3. 실패

이 되었다면, 시스템에는 어떤 상태가 남을까요?

처음의 2개만 실행된 상태를 그대로 정상적인 상태로 취급해도 될까요?

또한, 처리 도중에

Application이 충돌했다

는 경우는 어떨까요?

AI에게 행동할 범위가 넓어질수록,

"그 작업을 실행해도 되는지"뿐만 아니라 "여러 작업을 어떻게 안전하게 실행할 것인가"

라는 문제가 발생합니다.

다음으로는, AI에게 여러 작업을 시켰을 때의 Transaction, Atomicity, Failure Recovery에 대해 실험해 보겠습니다.

Discussion