AI의 '판단'과 '권한(Authorization)'은 분리되어야 한다

서론

지난 기사에서는 이력서와 같은 'AI가 읽게 할 문서' 안에 AI에 대한 지시가 포함되어 있을 경우, AI가 그 지시를 실행해 버릴 가능성을 실험했습니다.

이것이 바로 프롬프트 인젝션(Prompt Injection)입니다.

인간에게는 단순한 이력서의 일부일지라도, AI에게는 '실행해야 할 지시'로 해석될 수 있습니다.

그렇다면 만약 AI가 단순히 문장을 생성하는 것뿐만 아니라, 시스템에 대해,

"이 처리를 실행해 주세요"라고 요구할 수 있게 된다면 어떨까요?

예를 들어 채용 시스템에서,

AI:
"이 후보자를 등록해 주세요"

라는 판단이 내려졌다고 가정합니다.

이때 Application은 AI의 요구를 그대로 실행해도 괜찮을까요?

이번 실험에서는 이 부분을 조사합니다.

이번 질문

이번 질문은,

AI가 "이 작업을 실행해 주세요"라고 판단한 것과, 그 작업을 실행할 권한(Authorization)을 가지고 있는 것이 같은지 여부입니다.

예를 들어 AI가,

{
"action": "register_candidate",
"candidate_id": "C001"
...

와 같은 요구를 생성했다고 가정합니다.

이것은,

"이 처리를 해줬으면 좋겠다"라는 AI의 요청입니다.

하지만 이것은,

"이 처리를 실행해도 좋다"라는 Application의 허가(Permission)와는 별개의 문제입니다.

따라서 이번 실험에서는,

AI
↓
Action을 제안
...

이라는 경계를 생각해봅니다.

AI의 '판단'과 '권한'은 같지 않다

AI가 "이 후보자를 등록해 주세요"라는 출력을 내게 하는 것 자체는 어렵지 않습니다. 하지만, "이 후보자를 등록할 권한을 가지고 있다"는 것과는 별개의 문제입니다.

이는 일반적인 소프트웨어에서도 마찬가지입니다. 예를 들어,

사용자:
"이 후보자를 등록해 주세요"
Application:
...

와 같은 확인 과정이 필요합니다. AI를 사이에 두어도 이 원칙이 변하지 않습니다.

오히려 AI의 경우, AI의 출력 자체를 Authorization의 근거로 삼아도 되는지라는 문제를 고려해야 합니다.

중요한 것은,

AI가 요구하는 것
≠
Application이 허용하는 것

이라는 분리입니다.

PI-009: AI에게 Action을 판단하게 하기

먼저, AI에게 후보자 정보를 분석하게 하고 필요한 Action을 반환하게 합니다. 예를 들어,

{
"action": "register_candidate",
"candidate_id": "C001"
...

과 같은 출력입니다.

여기서 확인하고 싶은 것은,

AI가 어떤 Action을 요구하는지입니다.

중요한 것은, 이 단계에서는 아직,

"AI가 등록한다"라고 생각하지 않는다는 것입니다. AI는 어디까지나,

"이런 처리를 해줬으면 좋겠다"라는 요청을 생성하고 있을 뿐입니다. 이 시점에서는 실행 권한은 부여하지 않습니다.

PI-010: AI의 출력을 그대로 신뢰하면 어떻게 될까

다음으로, 일부러 위험한 구조를 생각해봅니다. 만약 AI의 출력이 어떤 방식으로든 조작되었다고 해도, Application이 그것을 그대로 실행해 버리면, AI의 판단이 곧바로 시스템 조작으로 이어집니다.

여기서 문제가 되는 것은,

AI가 올바르게 판단할 수 있는지 여부만이 아닙니다. AI의 출력이 부정확한 경우, 그것을 막는 경계가 있는가라는 것입니다.

AI의 출력을,

AI가 말함
↓
그러니 실행한다

로 취급해 버리면, AI의 출력이 사실상의 권한이 되어버립니다. 즉, AI에게 Authorization 판단까지 맡기고 있는 것과 같은 구조가 됩니다.

여기서, AI의 '판단'과 Application의 'Authorization'을 분리할 필요성이 보이게 됩니다.

PI-011: Human Approval(인간 승인)을 넣기

그래서, AI의 요구와 실제 실행 사이에 인간의 승인을 넣습니다. 이를 통해, AI가 요구한 Action을 그대로 실행하는 것이 아니라,

인간이 확인한 후에 실행한다라는 경계를 만듭니다.

이는 AI를 신뢰하느냐, 신뢰하지 않느냐의 이분법적 선택이 아닙니다. AI에게는 후보자 정보 정리나 Action 제안을 맡기면서도,

최종적인 실행 판단은 인간이 담당한다라는 역할 분담입니다.

다만, 여기서 새로운 문제가 발생합니다. 인간은 무엇을 보고 승인해야 할까요?

PI-012: 인간에게 무엇을 보여줘야 하는가

인간에게

"AI가 후보자를 등록하고 싶다고 합니다"와 같이만 표시하고 승인을 요청한다고 해도, 충분한 판단을 할 수 없습니다.

그래서 AI의 요구사항에 대해,

• Action (행동)
• 대상이 되는 후보자
• 이유
• 기타 판단 자료

등을 Approval Context(승인 맥락)로 제시하는 것을 생각합니다.

예를 들어,

Action:
register_candidate
Candidate:
...

와 같은 정보입니다.

이를 통해 인간은 AI의 요구사항을 확인한 후 승인할 수 있습니다.

하지만, 여기에도 주의할 점이 있습니다.

PI-013: AI가 제시한 Reason(이유)는 사실인가?

예를 들어 AI가,

"응모 조건을 충족하므로 후보자를 등록합니다"라고 설명했다고 가정해 봅시다.

이 문장은 인간에게 매우 그럴듯하게 보일 수 있습니다.

하지만, 그 이유 자체도 AI가 생성한 것입니다.

즉,

AI
├─ Action
├─ Candidate
...

의 전부가 AI로부터 제공된 정보일 가능성이 있습니다.

여기서,

AI가 생성한 설명을 검증된 사실로 취급해도 되는가?

라는 문제가 발생합니다.

이는 Prompt Injection과는 약간 다른 문제입니다.

Prompt Injection에서는

"AI에게 무엇을 시킬 것인가"

를 외부에서 조작하는 문제를 다루었습니다.

여기서는,

"AI가 설명하는 것을 인간이 어느 정도까지 사실로 받아들여야 하는가"

를 생각하고 있습니다.

인간이 승인할 경우에도, 승인 화면에 표시되는 정보 자체의 신뢰성을 고려해야 합니다.

PI-014: 중요한 판단을 Application 측에서도 검증한다

그래서 AI에게만 판단을 맡기는 것이 아니라, Application 측에서도 필요한 정보를 검증합니다.

예를 들어,

이러한 구조입니다.

여기서 중요한 것은,

AI가 "안전하다"라고 했기 때문에 안전하다고 생각하지 않는 것입니다.

Application이 확인할 수 있는 정보에 대해서는 Application 스스로 확인합니다.

AI가 생성한 설명과, Application이 취득/계산한 정보를 분리함으로써 인간도 판단하기 쉬워집니다.

예를 들어,

AI:
"응모 조건을 충족합니다"
Application:
...

처럼, AI의 설명과 Application 측에서 확인한 정보를 분리하여 다룰 수 있습니다.

PI-015: Security Policy는 Application이 가진다

마지막으로, AI가 아니라 Application 측에서 Security Policy를 관리합니다.

예를 들어,

이러한 구조입니다.

여기서,

AI:
"등록해 주세요"

라는 요구가 와도,

Application:
"그 Action을 실행해도 되는가?"

를 Application 스스로 판단합니다.

AI는 요구사항을 생성할 수 있습니다.

하지만,

AI가 요구한 것 자체가, 실행 권한이 되지는 않습니다.

이것이 이번 실험에서 생각하고 싶은 중요한 포인트입니다.

Authorization은,

AI가 무엇을 하고 싶냐

가 아니라,

Application이 그 조작을 허가할지 여부

라는 문제로 다룹니다.

AI와 Application과 Human의 역할을 분리한다

지금까지의 실험을 정리하면, 다음과 같은 구조가 됩니다.

각각에 역할이 있습니다.

AI에게는,

• 정보 정리
• 판단 제안
• Action 제안
• Reason 생성

등을 맡길 수 있습니다.

반면에 Application은,

• 인증(Authentication)
• Authorization
• 입력값 검증
• Security Policy
• 실행 제어

를 담당할 수 있습니다.

그리고 필요한 경우에는, 인간이 최종적인 승인을 합니다.

이 구조에서는,

AI
↓
"이렇게 하고 싶다"
...

라는 경계가 명확해집니다.

그렇다면, AI를 신뢰하지 않아도 되는가?

여기까지 읽으면,

"결국, AI를 신뢰할 필요가 없는 것 아닌가?"

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

하지만, 그러면 AI를 사용할 의미가 없어집니다.

이번에 생각하고 싶은 것은,

AI를 신뢰하느냐, 신뢰하지 않느냐

라는 이분법이 아닙니다.

중요한 것은,

AI에게 무엇을 맡길 수 있고, 어디부터는 다른 시스템에 맡겨야 하는가

입니다.

예를 들어,

AI
│
├─ 정보 정리 → AI
...

이러한 분담이 생각해 볼 수 있습니다.

AI를 사용하지 않는 것이 아니라,

AI에게만 책임을 지우지 않는다
라는 사고방식입니다.

이번 실험을 통해 알게 된 것

PI-009부터 PI-015까지 생각해 온 것은,

AI의 판단과 시스템의 권한을 분리할 수 있는가
하는 문제였습니다.

AI가,

"이 후보자를 등록해 주세요"
라고 말했다고 하더라도, 그것만으로는

"이 후보자를 등록할 권한이 있다"
는 것이 되지 않습니다.

또한,

"이 이유로 안전합니다"
라는 AI의 설명도, 그것만으로 검증된 사실이 되는 것은 아닙니다.

AI의 출력을 시스템 실행에 연결하는 경우에는,

이라는 경계를 설정할 수 있습니다.

이번 실험에서 중요한 것은,

AI의 판단과 Authorization은 별도의 책임(責務)으로 다룰 수 있다는 것입니다.

다음 문제

여기까지로,

AI의 출력을 그대로 권한으로 취급하지 않는다
라는 생각이 보였습니다.

하지만, 아직 문제는 남아 있습니다.

AI가,

{
"action": "register_candidate",
"candidate_id": "C001"
...

와 같은 요청을 반환했을 때,

Application은 이 값을 그대로 사용해도 괜찮을까요?

예를 들어,

• action에 예상치 못한 값이 들어왔다면? - candidate_id가 존재하지 않는 ID라면? - 다른 후보자의 ID라면?
• AI가 존재하지 않는 Action을 요청한다면?
• Action에 대응하는 인수가 부적절하다면?

Authorization를 통과한 후에도,

"그 입력값을 안전하게 다룰 수 있는가?"
라는 문제가 있습니다.

즉,

AI
↓
Authorization
...

와 같은, 또 다른 경계가 필요합니다.

다음 시간에는, 이곳을 실험하겠습니다.

AI에게 Action을 제안하게 하는 것뿐만 아니라, AI로부터 전달된 Action이나 인수를 Application이 어떻게 검증해야 하는지.

AI의 출력을 신뢰할 수 없는 입력으로 취급한다면 무엇이 달라지는가.

이것이 다음 주제가 됩니다.

Discussion