Tool을 허용했다고 데이터까지 허용한 것은 아니다

앞선 글과 두 번째 글에서는 Agent 실행에 위임된 권한 범위와 그 수명을 정리했습니다. 이번 글에서는 두 조건을 모두 통과했다고 가정합니다.

인사평가 조회 Tool을 사용할 수 있다고 해서 모든 구성원의 평가를 볼 수 있다는 뜻일까요?

현재는 Tool operation의 권한까지 확인하고 있습니다. 이번 글에서는 여기서 한 단계 더 내려가, 그 Tool을 어떤 대상과 조건에서 실행할 수 있는지를 다룹니다.

같은 Operation, 다른 대상#

앞선 두 글의 경계를 통과했다면 사용자는 evaluation.read operation을 실행할 기본 자격을 갖습니다. 하지만 어떤 대상에 대해 실행할 수 있는지는 아직 결정되지 않았습니다.

evaluation.read(employeeId=100)
→ 본인 또는 관리 대상 구성원이라면 ALLOW 가능
 
evaluation.read(employeeId=999)
→ 관계없는 구성원이라면 DENY 가능

operation 권한은 호출 가능한 함수의 범위를 제한합니다. 같은 함수에 전달된 인자가 어떤 데이터를 가리키는지는 별도로 판단합니다.

권한 판정에 포함되는 Tool 인자#

Agent는 앞선 조회 결과를 바탕으로 employeeId, period 같은 값을 Tool 인자로 전달합니다. Tool schema의 입력 검증은 값의 타입과 형식, 필수 여부를 확인하지만 사용자가 해당 employeeId의 데이터에 접근할 수 있는지까지 판단하지는 않습니다.

operation 권한과 실제 데이터 조회 사이에 대상별 권한을 확인하는 경계가 없다면, Tool에 전달된 employeeId를 기준으로 특정 구성원의 정보를 그대로 조회할 수 있습니다. 만약 evaluation.read에 대해서 사용 권한만 확인한다면, employeeId=100과 employeeId=999는 권한 판정상 같은 요청으로 처리될 수 있습니다.

이 문제는 Agent에만 국한되는 것은 아닙니다. UI나 다른 API가 같은 값을 보내더라도 대상 범위는 서버에서 판정해야 합니다. Agent가 앞선 결과를 조합해 다음 Tool의 인자를 만들면서 operation 권한만으로는 부족한 점이 더 분명하게 드러났습니다.

따라서 operation authorization과 실제 데이터 조회 사이에 Resource Authorization 경계를 두고, Tool 인자에서 서버가 대상의 종류와 ID를 추출하도록 설계했습니다. 별도로 전달된 대상 정보나 Agent가 판단한 관계는 권한 판정의 근거로 사용하지 않습니다.

Tool 인자 전달
    ↓
입력 검증
    ↓
대상 추출과 권한 판정
    ↓
데이터 조회

Operation별 대상 규칙#

각 operation은 대상 필요 여부, 대상을 가져올 인자, 대상의 종류와 확인할 관계를 정책으로 정의합니다.

인사평가 조회는 employeeId에서 대상을 찾고, 사용자가 해당 구성원의 평가를 볼 수 있는 관계인지 확인합니다. 실제 정책에서는 본인, 조직장, 하위 조직과 같은 업무 관계를 조합해 평가 조회 범위를 표현합니다.

대상 관계 판정에 기존 operation 권한과 요청 시점의 추가 조건까지 합치면 전체 실행 조건은 다음과 같습니다.

CanExecute(request)
  = CanUseOperation(request)     // 앞선 두 글에서 다룬 조건
  ∧ CanAccessTarget(request)     // 대상
  ∧ RequestConditionsAllow(request) // 요청 시점

대상이 필요한 operation에서는 대상 추출과 관계 검사를 모두 통과해야 하고, 대상을 요구하지 않는 operation은 CanAccessTarget을 추가 검사 없이 통과합니다.

대상이 필수인데 인자가 없거나 ID를 대상으로 변환하지 못하면 대상별 권한을 확인할 수 없으므로 거절합니다.

요청 시점의 추가 조건#

사용자와 대상의 관계만으로 권한을 결정하기 어려운 경우도 있습니다. 예를 들어 특정 기간의 평가만 조회할 수 있다면, 사용자가 평가 대상자를 볼 수 있는지뿐 아니라 요청한 기간이 허용 범위에 있는지도 함께 확인해야 합니다.

이처럼 요청할 때마다 달라질 수 있는 값은 그 시점에 추가로 확인합니다. 전환 설계에서는 대상의 종류처럼 미리 정할 수 있는 정보를 요청마다 다시 계산하지 않고 정책이나 관계 정보로 관리하도록 했습니다.

새 Tool을 추가할 때 함께 정의하는 권한 정보#

새로운 Agent Tool을 추가할 때는 operation 이름과 기존 permission만 연결하지 않습니다. 해당 Tool이 특정 대상을 다룬다면 어떤 인자에서 대상을 찾을지, 대상의 종류는 무엇인지, 어떤 관계를 확인할지까지 함께 등록합니다. 요청 시점에 추가로 확인할 조건이 있다면 이것도 operation 정책에 포함합니다.

evaluation.read
  permission       = evaluation : READ
  targetFrom       = employeeId
  targetType       = employee
  relation         = evaluation_viewer
  requestCondition = allowed_evaluation_period

evaluation_viewer와 allowed_evaluation_period는 설명을 위한 이름입니다. 실제 정책에서는 본인, 조직장, 하위 조직과 같은 업무 관계와 허용된 평가 기간을 사용합니다.

이 정보가 없으면 서버는 해당 Tool의 대상별 권한을 확인할 수 없습니다. 대상이 필요한 operation인데 관련 mapping이 없거나 Tool 인자에서 대상을 식별하지 못하면, 이름이나 URL로 권한을 추론하지 않고 요청을 거절합니다.

Tool schema에 기능을 노출하는 것과 실행 권한을 부여하는 것도 별개의 문제입니다. Tool schema는 모델에게 선택 가능한 기능을 알려주는 인터페이스일 뿐이며, 실제 호출 가능 여부와 대상 접근 권한은 서버의 authorization policy에서 판단합니다.

판정 결과에는 Tool 이름만 남기지 않습니다. 어떤 operation이 호출됐는지뿐 아니라 어떤 대상을 식별했고, 어떤 관계와 요청 조건을 확인했으며, 그 결과가 무엇이었는지도 함께 남기도록 설계했습니다. 같은 Tool이라도 대상에 따라 결과가 달라지므로 나중에 허용하거나 거절한 이유를 확인하려면 이 판정 근거가 필요합니다.

적용 범위#

이번 글에서 다루는 경계는 이미 허용된 operation을 어떤 대상과 요청 조건에서 실행할 수 있는지 판정하는 부분입니다. 이번 요청에 필요한 최소한의 Tool만 허용하거나, 허용 범위 안에서 불필요한 Tool 실행을 막는 정책까지 다루지는 않습니다.

현재 운영 경로는 CanUseOperation까지이며 대상 관계 검사, 요청 시점 조건과 통합 판정 근거 기록은 전환 범위에 있습니다. 관계 기반 판정과 누락 시 거절하는 mapping이 구현되고 검증되기 전까지 대상별 접근 제어를 현재 보장으로 서술할 수는 없습니다.

요약하자면, Agent가 어떤 Tool을 사용할 수 있는지 판단하는 것만으로는 데이터 권한이 완성되지 않습니다. 같은 Tool이라도 전달된 인자에 따라 접근 대상이 달라지기 때문입니다. 그래서 operation 권한 이후에도 Tool을 사용할 수 있는지와 그 Tool로 어떤 데이터까지 접근할 수 있는지에 대한 레이어의 구현이 필요합니다.