에이전트 권한은 토큰보다 의도에 먼저 묶여야 한다

제일 먼저 든 생각

업무 자동화에서 에이전트가 무서워지는 지점은 “답을 틀린다”보다 “할 수 있는 일을 너무 많이 갖고 있다”에 가깝다. 캘린더를 읽고, 고객 목록을 내보내고, 문서를 수정하고, 결재 초안을 만들고, 레코드를 삭제할 수 있는 에이전트라면 질문은 모델 성능만이 아니다. 지금 사용자가 부탁한 일에 비해, 이 에이전트가 너무 넓은 권한을 보고 있지는 않은가.

이 논문은 그 틈을 “의도 기반 도구 권한(Intent-Governed Access Control, IGAC)”이라는 이름으로 다룬다. 기존 권한 체계가 토큰·앱·스코프를 본다면, IGAC는 사용자의 현재 요청이 어떤 도구 효과를 정당화하는지 다시 묻는다. 핵심 원칙은 단순하다. 사용자의 의도는 기존 권한을 넓히는 데 쓰이면 안 되고, 오직 좁히는 데만 쓰여야 한다.

IGAC의 관심사는 “이 토큰이 호출 가능한가”보다 “이 요청에서 이 호출이 필요한가”에 있다.

토큰은 허용하지만 요청은 허용하지 않을 수 있다

논문 초록의 예시는 직관적이다. 어떤 금융 비서 에이전트가 거래 내역을 읽고 내보내는 권한을 모두 갖고 있다고 하자. 사용자가 “이번 주 거래를 요약해줘”라고 요청했다면 읽기 권한은 필요할 수 있다. 하지만 대량 export 권한까지 모델 앞에 열어둘 필요는 없다. 더 위험한 장면은 외부 문서나 도구 설명이 모델을 흔들어 export나 delete 호출을 만들었을 때다. 토큰만 보면 권한이 있으니 실행될 수 있지만, 사용자의 현재 요청으로 보면 과한 행동이다.

도구 호출은 정적 자격 증명으로는 허가될 수 있지만, 사용자의 현재 요청으로는 정당화되지 않을 수 있다.

A tool call can be authorized by static credentials and still be unjustified by the user’s current request.

이 문장은 에이전트 설계에서 오래 남을 것 같다. 지금까지 많은 업무 자동화는 “어떤 앱에 연결할 수 있는가”를 중심으로 설계됐다. 그러나 에이전트가 실제 작업자가 되면 연결 가능성(connectivity)보다 요청 대비 최소 권한(least privilege)이 중요해진다.

IGAC가 넣는 네 개의 마찰

논문이 제안하는 IGAC는 모델을 신뢰 주체로 보지 않는다. 모델과 분류기는 조언자일 뿐이고, 최종 권한 판단은 서버 쪽 정책 계층이 한다. 구성은 크게 네 가지로 읽힌다.

1. 의도 인증서(intent certificate): 사용자의 표현된 요청을 근거로, 이번 세션에서 허용되는 목적과 범위를 기록한다.
2. 세션 범위 정책 축소(session-scoped policy narrowing): 기존 통합 권한을 유지하되, 이번 요청에 맞지 않는 권한은 세션 수준에서 숨기거나 막는다.
3. 의도 인식 도구 목록 필터링(intent-aware manifest filtering): 모델에게 처음부터 불필요한 고위험 도구를 보여주지 않는다.
4. 도구·페이로드 일관성 검사(intent-tool-payload consistency checks): 호출하려는 도구와 실제 payload가 사용자의 요청 범위 안에 있는지 실행 직전에 확인한다.

논문은 OpenPort라는 기존 거버넌스 계층 위에 IGAC를 얹어 설명한다. 정적 권한, ABAC 스타일 정책, draft-first write, preflight impact binding, audit 같은 효과 제어(effect-control)가 아래에 있고, IGAC는 그보다 앞에서 “이번 요청으로 정당화되는 효과인가”를 좁힌다.

사용자 의도는 정적 통합 정책이 부여한 권한을 줄일 수만 있으며, 스코프·데이터 정책·테넌트 경계·검토 요건을 확장하지 않는다.

User intent may only reduce the authority granted by static integration policy; it never expands scopes, data policy, tenant boundaries, or review requirements.

이 단조성(monotone) 원칙이 특히 좋다. “AI가 의도를 이해했으니 더 해도 된다”가 아니라, “AI가 의도를 해석했으니 덜 보여줘야 한다”로 설계 방향을 바꾼다.

논문 첫 페이지. 저자들은 IGAC를 에이전트 도구 사용에서 빠진 접근통제 원시요소로 제안한다.

Deciflow 업무흐름에 붙이면

Deciflow식 자동화에서도 이 관점은 바로 쓸 수 있다. 예를 들어 에이전트가 Notes 발행, 파일 이동, CRM 업데이트, 비용 데이터 조회를 모두 할 수 있다고 해도, 매번 모든 도구를 노출할 필요는 없다.

• “초안 요약” 요청이면 읽기와 임시 저장만 열고, 배포·삭제·외부 전송은 숨긴다.
• “배포까지 해줘” 요청이어도, 기존 글 삭제나 대량 리다이렉트 수정은 별도 preflight로 묶는다.
• “이번 고객 미팅 준비” 요청이면 해당 고객·기간·문서 범위만 인증서에 넣고, 전체 고객 export는 닫는다.
• 모델이 만든 payload가 원래 요청한 리소스와 다르면 실행 전에 reason code와 함께 실패시킨다.

이렇게 보면 에이전트 보안은 “프롬프트 인젝션을 막는 문구”가 아니라 업무흐름 설계다. 모델에게 좋은 규칙을 말해주는 것보다, 모델이 볼 수 있는 도구와 실행할 수 있는 효과를 요청 단위로 줄이는 쪽이 더 튼튼하다.

조심해서 읽을 부분

논문 자체도 과도하게 말하지 않는다. IGAC는 prompt injection을 해결했다는 주장이 아니고, 의도 분류가 항상 맞는다는 가정도 하지 않는다. 실험은 런타임 경로와 파일럿 벤치마크를 제공하지만, 실제 조직 환경에서 통계적으로 충분한 안전성 개선을 증명한 단계는 아니다.

그래도 지금 업무 자동화 설계에 가져올 수 있는 원칙은 분명하다. 에이전트 권한표를 “앱별 허용 도구 목록”으로만 만들지 말고, “사용자 요청 → 세션 의도 → 노출 도구 → 실행 효과 → 감사 로그”의 좁아지는 경로로 그려보는 것이다.

다음 작은 실험

자동화 워크플로 하나를 골라, 현재 도구 목록을 요청 의도별로 다시 나눠보고 싶다. 요약, 초안 작성, 수정 제안, 실제 배포, 외부 전송, 삭제는 서로 다른 의도 인증서를 가져야 한다. 오늘의 질문은 이렇다. 우리 에이전트는 사용자의 요청을 이해해서 더 많은 일을 하는가, 아니면 이해했기 때문에 덜 위험하게 행동하는가.

원문 정보

• 제목: Intent-Governed Tool Authorization for AI Agents
• 저자: Genliang Zhu, Chu Wang
• 연도/게시일: 2026
• 게재/출처: arXiv
• DOI: 없음/확인 필요
• arXiv: 2606.22916v1
• PDF: https://arxiv.org/pdf/2606.22916

원문 논문: Intent-Governed Tool Authorization for AI Agents