Capability Permission, Planning, Policy Reasoning

Capability와 Permission

Capability는 agent가 할 수 있는 능력입니다. 파일을 읽을 수 있고, 웹을 검색할 수 있고, 코드를 실행할 수 있고, 배포할 수 있습니다. Permission은 해도 되는 권한입니다. 이 둘은 다릅니다. capability가 있어도 permission이 없으면 실행하면 안 됩니다.

예를 들어 agent가 서버에 접속할 수 있어도 사용자가 요청하지 않은 서비스를 재시작하면 안 됩니다. API key가 있어도 외부 전송이 약관상 금지될 수 있습니다. Capability Permission 분리는 agent 안전의 기본입니다.

Planning과 Policy Reasoning

Planning은 목표를 실행 순서로 나누는 작업입니다. Policy reasoning은 그 순서가 허용되는지 확인하는 작업입니다. 둘이 분리되어야 합니다. 계획이 먼저 나오고, policy가 나중에 통과 도장을 찍는 구조가 아니라, 계획을 만들 때부터 policy가 제약으로 들어가야 합니다.

정책 판단은 금지, 조건부 허용, 인간 승인 필요, 로그 필요, 전문가 검토 필요로 나눌 수 있습니다. 이 분기가 있어야 agent가 무작정 질문하거나 무작정 실행하지 않습니다.

Planning은 agent가 행동을 잘 하려면 무엇을 알아야 하는지 찝는 작업입니다. Belief State에서 plan을 뽑아낼 때 허용, 제한, 의무, 절대금지를 구분해 정보를 줘야 합니다. 그리고 Planning Failure 자체를 관리하는 taxonomy가 필요합니다. 계획 실패는 실행 실패보다 먼저 고쳐야 하는 데이터입니다.

Policy reasoning에서 중요한 것은 정책과 집행의 분리입니다. 조지 워싱턴이 스스로 권력을 내려놓았기 때문에 미국이 강대국이 되었고, 오늘날 프론티어 AI 기업도 만들 수 있었다고 말하면 조금 과장일 수 있지만 방향은 맞습니다. 집행자가 자기 정책을 마음대로 완화하면 시스템은 오래 못 갑니다. 정책이 agent를 사사건건 제한해야 하고, 그때 생기는 충돌이 agent 개선 데이터가 됩니다.

Human In The Loop는 계획 실패와 정책 충돌이 사람에게 올라오는 통로입니다. 사람에게는 그냥 '승인할까요?'가 아니라, 어떤 정보가 부족하고, 어떤 대안이 있으며, 승인하면 어떤 operation이 실행되는지 보여줘야 합니다.

실행 계획의 최소 뼈대

좋은 계획은 goal, subgoal, dependency, risk, rollback, evidence, postcondition을 가집니다. 예를 들어 새 문서를 배포한다면 글 생성, 링크 확인, 빌드, served content 확인, 캐시 purge 필요 여부, rollback 방법이 계획에 들어갑니다.

Policy reasoning은 각 subgoal에 붙습니다. 글 생성에는 저작권과 인용 제한이 붙고, 광고에는 플랫폼 정책이 붙고, 배포에는 개인정보 노출 확인이 붙습니다. agent는 계획을 만드는 순간부터 policy object를 같이 들고 다녀야 합니다.

정리

이 문서에서는 capability, permission, policy decision, planning dependency, delegation을 나눠야 합니다. agent가 직접 할 일, 도구에 맡길 일, 인간에게 물을 일, 금지할 일을 구분하는 것이 핵심입니다.

법적 규제 준수는 permission의 가장 강한 층입니다. 사용자 허락이 있어도 법적 제한을 넘을 수 없고, API 권한이 있어도 약관상 금지된 사용은 안 됩니다. Planning은 이 우선순위를 반영해야 합니다.