AI 에이전트에 API 사용 권한을 주었다면, 어떤 도구를 쓸 수 있는지뿐 아니라 어떤 사용자의 어떤 데이터에 무슨 작업을 할 수 있는지 서버에서 확인해야 합니다. 로그인한 사용자의 요청이더라도 다른 사람의 주문이나 예약을 조회·수정할 권한까지 있는 것은 아닙니다. 이 객체별 검사가 빠진 문제를 BOLA라고 합니다.
에이전트가 올바른 행동을 하도록 지시하는 것은 도움이 됩니다. 하지만 모델의 판단과 별도로 API가 권한을 검사해야 합니다. 에이전트가 잘못된 식별자를 선택하거나, 외부 문서의 악성 지시를 따르거나, 정당한 목표를 부적절한 방법으로 달성하려 할 가능성을 고려해야 하기 때문입니다.
BOLA는 어떤 문제일까?
OWASP API 보안 자료에 따르면 BOLA(Broken Object Level Authorization)는 요청한 사람이 특정 객체에 해당 작업을 수행할 권한이 있는지 확인하지 않아 생기는 취약점입니다. 여기서 객체는 주문, 문서, 예약, 파일처럼 API가 다루는 개별 데이터입니다.
가상의 예를 들어 보겠습니다. 예약 조회 API 자체는 로그인한 사용자에게 열려 있습니다. 그런데 서버가 요청에 담긴 예약 ID만 믿고 소유자나 조직 권한을 확인하지 않는다면, 다른 사람의 예약도 조회하거나 취소할 수 있습니다. 요청자가 사람인지 AI 에이전트인지는 취약점의 정의를 바꾸지 않습니다.
| 검사 대상 | 확인할 질문 | 검사만으로 부족한 이유 |
|---|---|---|
| 인증 | 요청자가 누구인가? | 로그인만으로 모든 예약에 대한 권한이 생기지 않음 |
| 기능 권한 | 이 API 기능을 쓸 수 있는가? | 사용 가능한 기능이라도 대상 객체마다 권한이 다를 수 있음 |
| 객체 권한 | 이 예약에 이 작업을 할 수 있는가? | 조직 역할, 위임 및 공유 관계까지 정책에 반영해야 함 |
| 실행 조건 | 지금 취소·변경해도 되는가? | 만료, 한도, 승인 및 업무 규칙을 별도로 판단해야 함 |
객체 ID를 추측하기 어렵게 만드는 것은 보조 수단이지 권한 검사의 대체재가 아닙니다. OWASP는 세션의 사용자 ID와 요청값을 단순 비교하는 방식도 일부 사례만 해결한다고 지적합니다. 공유 문서나 조직 관리자의 작업처럼 소유자가 아니어도 허용되는 관계를 반영해야 하기 때문입니다.
AI 에이전트에서 권한이 더 헷갈리는 이유
에이전트는 사용자의 목표를 받아 여러 도구를 선택하고 입력값을 만들 수 있습니다. 예를 들어 사용자가 “내 예약을 확인해 줘”라고 했을 때, 에이전트가 어떤 예약 ID를 선택했는지와 그 ID가 실제로 요청자에게 허용된 것인지는 별개입니다.
여기에는 두 가지 다른 위험이 있습니다. 하나는 API 서버가 객체 권한을 제대로 검사하지 않는 BOLA입니다. 다른 하나는 강한 권한을 가진 에이전트가 신뢰할 수 없는 외부 지시를 따르거나 사용자 의도보다 넓은 행동을 하는 대리 권한 문제입니다. 서버의 권한 검사와 에이전트의 도구 제한은 서로 보완해야 합니다. 어느 한쪽만으로 모든 문제를 막을 수는 없습니다.
티스토리 원문에는 실제 예약 취소 사건과 특정 방어 체계가 제시되어 있었지만, 해당 사건과 제품별 방어 효과를 뒷받침하는 원자료는 확인하지 못했습니다. 이 글에서는 이를 사실로 재현하지 않고 검증 가능한 권한 설계 원리에 집중합니다.
API와 에이전트 양쪽에 어떤 장치가 필요할까?
1. 도구와 권한의 범위를 줄인다
에이전트에 필요한 기능과 계정 권한만 부여합니다. 조회만 필요한 업무에 삭제나 결제 권한까지 주지 않고, 가능하면 사용자나 작업 단위의 권한으로 요청하도록 설계합니다. 토큰과 비밀값을 대화에 그대로 노출하지 않는 것도 중요합니다. 로컬 파일과 실행 권한에 대해서는 AI 에이전트 로컬 권한 관리에서 이어서 볼 수 있습니다.
2. 서버에서 사용자·행동·객체·맥락을 함께 검사한다
각 요청에 대해 인증된 사용자, 요청된 동작, 대상 객체, 조직 소속과 위임 관계 등 실제 정책에 필요한 정보를 함께 확인합니다. 권한 판정은 클라이언트나 에이전트가 전달한 주장만 믿지 않고 신뢰할 수 있는 서버 측 정보에 근거해야 합니다. 예외가 발생하거나 판단할 수 없는 경우에도 안전하게 거부하도록 설계합니다. OWASP 권한 부여 가이드는 최소 권한, 기본 거부, 모든 요청에 대한 권한 검증을 권고합니다.
3. 되돌리기 어려운 작업은 별도 확인한다
삭제, 결제, 대량 변경처럼 영향이 큰 작업에는 실행 전 사용자 확인, 범위 제한, 중복 요청 방지, 감사 기록 등을 위험에 맞게 추가할 수 있습니다. 이는 편집자의 적용 제안이며 사용자 확인이 서버의 객체 권한 검사를 대신한다는 뜻은 아닙니다. 확인 화면에도 대상, 작업 및 결과를 이해할 수 있게 표시해야 합니다.
4. 정상 요청과 권한 밖 요청을 함께 시험한다
가상의 테스트 환경에서 사용자 A가 자신의 예약을 조회하는 경우뿐 아니라 사용자 B의 예약을 조회하거나 취소하려는 경우도 확인합니다. 같은 조직의 공유 권한, 권한이 취소된 계정, 관리자 위임 및 예외 상황도 정책에 맞게 시험하세요. 실패 기록에는 원인 분석에 필요한 정보만 남기고 비밀값이나 불필요한 개인정보가 포함되지 않도록 관리합니다.
자주 묻는 질문
에이전트에게 “남의 정보를 보지 마”라고 지시하면 되나요?
지시는 행동의 방향을 제시하지만 권한을 강제하는 서버 측 검사를 대체하지 못합니다. 모델이 잘못된 입력을 만들거나 외부 지시에 영향을 받을 가능성도 고려해야 합니다.
승인 버튼이 있으면 BOLA를 막을 수 있나요?
아닙니다. 승인 화면이 있더라도 API는 요청자에게 그 객체에 대한 작업 권한이 있는지 검사해야 합니다. 승인 여부와 권한 여부는 다른 질문입니다.
예약 ID를 긴 무작위 문자열로 만들면 충분한가요?
식별자를 알아내기 어렵게 만들 수는 있지만, 다른 경로로 알려질 가능성이 있습니다. ID 형식과 관계없이 객체별 권한 검사가 필요합니다.
참고 자료
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.