AI 에이전트에 ID가 없으면 실무에서 곤란해지는 이유 — 아이덴티티, 위임, 권한 설계 입문 - Insights | Molayo

AI 에이전트를 데모에서 실무 운영으로 전환할 때, "이 액션, 누가 수행했는가?" 라는 질문에 답하지 못하는 케이스가 빈번하게 발생합니다.

원인은 단순합니다. 에이전트에 명확한 아이덴티티(Identity, ID) 가 없으며, 위임한 사용자나 워크플로우(Workflow) 와 연결되어 있지 않기 때문입니다.

본 기사에서는 다음과 같은 관점에서 실무적인 설계 패턴을 정리합니다.

기존의 엔터프라이즈 아키텍처(Enterprise Architecture)에서 액터(Actor)는 "인간", "애플리케이션", "서비스 계정", "스케줄 작업" 중 하나였습니다.

Agentic AI는 여기에 **"추론하고, 도구를 선택하며, 여러 단계를 자율적으로 실행하는 디지털 액터"**라는 새로운 카테고리를 추가합니다.

이 에이전트를 단순한 백그라운드의 익명 스크립트로 취급하면, 실무에서 다음 세 가지가 불분명해집니다.

누가 액션을 실행했는가 -
**누구의 위임(Mandate)**으로 움직였는가 -
어떤 워크플로우의 맥락에서 발생했는가

예를 들어, 구매 에이전트가 ERP에 발주 요청 초안을 작성했을 때, 그 로그가 범용 서비스 계정의 것으로만 남는다면 어떨까요?

"그 사용자가 요청한 것인가", "스케줄 작업이 실행된 것인가", "누군가 권한을 악용한 것인가" —— 구분이 불가능합니다.

에이전트가 비즈니스 상태를 변경하기 시작하는 순간, 그 ID는 인간이나 애플리케이션과 동일하게 추적 가능해야 합니다.

"에이전트에 역할을 할당하면 끝이다" —— 이는 오래된 실수의 새로운 형태입니다.

에이전트의 권한에는 컨텍스트(Context) 가 필요합니다.

동일한 에이전트라도, "송장 데이터를 읽기", "차이점에 대한 설명을 초안 작성하기", "해결책을 권장하기" 는 허용하되, "지불 차단 해제하기" 는 허용하지 않는 —— 식의 입도가 필요합니다.

구현의 기본은 권한을 레이어(Layer)로 나누는 것입니다.

레이어	의미	예
Read	읽기	분개장 읽기
...	...	...

이 레이어를 정책 엔진(Policy Engine)으로 평가함으로써, "읽기는 OK, 실행은 NG"와 같은 제어가 가능해집니다.

에이전트 액션의 대부분은 에이전트 자신에게 귀속되는 것이 아닙니다.

"사용자의 지시", "승인된 워크플로우", "자율 이벤트 트리거" 라는 위임원(Source of Mandate) 이 있습니다.

이 위임원은 구별 가능해야 합니다.

감사 추적(Audit Trail)에는 위임원의 정보, 에이전트 ID, 유효 기간, 사용 도구, 정책 준수 여부를 기록합니다.

위임에는 경계를 설정합니다.

취소 가능: 인시던트 발생 시 즉시 권한을 박탈할 수 있음 -
시간 제한: 특정 시간대에만 유효함 -
스코프 제한: 특정 데이터 소스나 도구로만 한정 -
금액 제한: 표준 발주는 임계치까지, 그 이상은 인간의 승인이 필요

심플하게 요약하면, 다음 네 가지를 정비하면 대부분의 케이스를 커버할 수 있습니다.

범용 서비스 계정을 공유하지 않는다.

에이전트마다 다음 속성을 관리합니다.

런타임의 액세스 평가는 세션 시작 시뿐만 아니라, 도구 호출 시마다 수행합니다.

# 의사 코드(Pseudo-code): 정책 평가의 이미지
def call_tool(agent_id, tool_name, input_data, mandate_source):
policy_result = policy_engine.evaluate(
...

앞서 언급한 Read / Recommend / Draft / Execute / Approve를 API나 도구별로 매핑합니다.

최종적인 API 호출뿐만 아니라, 다음 정보를 연결하여 기록합니다.

이것을 재구성할 수 없다면, 해당 에이전트는 프로덕션 스케일(Production Scale)을 견딜 수 없습니다.

다음과 같은 위험 신호가 여러 개 있다면, 에이전트를 스케일링할 때 리스크가 가치를 상회하게 됩니다.

또한, 다음과 같은 영역에서는 에이전트에게 실행 권한 (Execute) 을 부여하는 것이 아직 시기상조입니다.

이런 경우에는 Read / Recommend / Draft로 한정하고, ID 관리와 정책 기반을 먼저 공고히 하는 것이 더 안전합니다.

내일 감사 부서나 리스크 위원회로부터 다음과 같은 질문이 왔을 때, 당신의 팀은 증거를 가지고 답할 수 있습니까?

**이 액션을 실행한 것은 누구인가?****그 액션은 누구의 위임에 근거하는가?**왜 시스템은 그것을 허가했는가?

답변이 아직 명확하지 않다면, 다음에 우선순위를 두어야 할 것은 "더 똑똑한 모델"이 아닙니다.

아이덴티티, 권한 위임, 정책 평가, 감사——AI 에이전트를 신뢰할 수 있는 디지털 액터(Digital Actor)로 만들기 위한 기반입니다.

AI 에이전트에 ID가 없으면 실무에서 곤란해지는 이유 — 아이덴티티, 위임, 권한 설계 입문