엔터프라이즈 AI 에이전트 거버넌스, 정책에서 런타임 제어로 이동
엔터프라이즈 AI 에이전트 거버넌스는 첫 번째 운영상의 경계를 넘어섰다. 정책 문서만으로는 현실 세계에서 독립적으로 행동하는 소프트웨어를 통제할 수 없다. 새롭게 부상하는 모델은 에이전트가 데이터를 전송하고, 레코드를 변경하고, 도구를 호출하거나, 비용을 지출하기 직전에 집행을 수행한다.
이러한 전환은 최근 행동 시점(point-of-action) 논지의 핵심 주장을 규정한다. 거버넌스는 더 이상 모델을 승인하고, 위험을 문서화하거나, 배포 후 결과물을 검토하는 일에만 국한되지 않는다. 이는 런타임 보안 문제로 바뀌고 있다.
압력은 보안 팀, 아이덴티티 제공업체, 애플리케이션 소유자, 그리고 에이전트 플랫폼을 구축하는 모든 공급업체에 가해지고 있다. 이들의 충돌 지점은 분명하다. 기업은 더 적은 감독으로 에이전트가 더 긴 워크플로를 완료하기를 원하지만, 보안 팀은 모든 중대한 작업이 추적 가능하고 되돌릴 수 있어야 한다.
이는 인공지능에 규칙이 필요한지에 관한 또 다른 논쟁이 아니다. 더 시급한 질문은 그 규칙이 어디에서 작동해야 하는가다. 자율 시스템의 경우, 답은 점점 더 작업 자체에 가까워지고 있다.
엔터프라이즈 AI 에이전트 거버넌스에서 달라진 점
이제 거버넌스 대상은 단순한 모델이나 애플리케이션이 아니다. 도구, 메모리, 권한, 그리고 변화하는 맥락을 지닌 행동 주체로서의 아이덴티티다.
전통적인 AI 감독은 비교적 안정적인 순서에 초점을 맞춘다. 사람이 입력을 제출하면 모델이 결과를 생성하고, 누군가 그 결과를 검토하거나 활용한다. 거버넌스는 모델, 학습 데이터, 의도된 사용 사례, 평가 결과, 생성된 콘텐츠를 검토할 수 있다.
AI 에이전트는 이 순서를 바꾼다. 목표를 여러 단계로 나누고, 도구를 선택하며, 정보를 검색하고, 외부 서비스를 호출하고, 시스템을 수정할 수 있다. 또한 목표가 완료되었다고 판단할 때까지 이 과정을 반복할 수 있다.
각 단계는 다음 단계의 위험을 바꿀 수 있다. 고객 피드백을 요약해 달라는 무해한 요청도 에이전트가 고객 데이터베이스를 열면 더 민감해진다. 레코드를 내보내거나, 메시지를 작성하거나, 검토 없이 해당 메시지를 전송할 경우 위험은 다시 달라진다.
이로 인해 설계 단계의 승인과 런타임 동작 사이에 간극이 생긴다. 거버넌스 위원회는 영업 지원용 에이전트를 승인할 수 있지만, 그 라벨만으로는 특정 데이터베이스 쿼리에 대해 거의 알 수 없다. 또한 임원 계정에서 오전 2시에 특정 이메일을 보내도 되는지 판단할 수도 없다.
NIST AI 프레임워크는 조직이 AI 위험을 거버넌스화하고, 매핑하고, 측정하고, 관리할 수 있는 폭넓은 구조를 제공한다. 이 구조는 여전히 유용하지만, 에이전트는 팀이 그 원칙을 훨씬 더 세밀한 수준에서 구현하도록 요구한다.
애플리케이션 전체에 적용된 위험 분류만으로는 모든 런타임 질문에 답할 수 없다. 시스템은 누가 작업을 요청했는지, 어떤 에이전트가 행동하는지, 어떤 데이터에 접근했는지, 어떤 도구를 선택했는지를 알아야 한다. 또한 요청된 작업이 사용자의 권한을 초과하는지도 파악해야 한다.
이것이 행동 시점 거버넌스의 실질적 의미다. 제어 장치는 현재의 아이덴티티, 권한, 데이터, 환경 신호를 사용해 시도된 작업을 평가한다. 이후 해당 작업을 허용, 차단, 제한하거나 상위 검토로 이관한다.
예를 들어 자금이 이동하기 전 사람의 승인을 요구할 수 있다. 정보가 모델에 전달되기 전에 민감한 필드를 마스킹할 수도 있다. 동일한 에이전트가 내부 초안을 만들 수 있더라도 외부 주소로 이메일을 보내지 못하게 할 수 있다.
이러한 결정은 실행 중에 이루어져야 한다. 분기별 정책 검토로는 위험한 API 호출을 중단할 수 없다. 배포 후 수행되는 감사는 사고를 설명할 수는 있어도, 최초의 행동을 막을 수는 없다.
이 전환은 무엇이 증거로 간주되는지도 바꾼다. 조직에는 에이전트가 승인되었다는 기록만으로는 충분하지 않다. 최초 요청과 모델의 결정, 도구 호출, 검색된 데이터, 승인, 최종 결과를 연결하는 로그가 필요하다.
에이전트가 여러 서비스에 걸쳐 작동할 때 이 연결 고리는 중요하다. 하나의 워크플로는 채팅 인터페이스에서 시작해 계약서를 검색하고, 고객 레코드를 업데이트한 뒤, 결제 요청을 생성할 수 있다. 각 전환은 권한이 확대되거나 맥락이 사라질 수 있는 또 하나의 지점을 만든다.
행동 시점 거버넌스는 이러한 전환을 보안 경계로 다룬다. 이 접근 방식은 승인된 에이전트가 워크플로 전반에서 안전하다고 가정하지 않는다. 각 의미 있는 작업이 여전히 본래 목적과 위임된 권한에 부합하는지 검증한다.
정적 AI 정책이 런타임에서 통제력을 잃는 이유
문서화된 정책은 허용 가능한 행동을 설명하지만, 자율 워크플로에는 모든 중대한 단계 전에 집행 가능한 결정이 필요하다.
정적 거버넌스는 시스템이 예측 가능하게 작동할 때 가장 효과적이다. 팀은 승인된 사용 사례를 정의하고, 민감한 입력을 금지하며, 고정된 워크플로를 테스트하고, 직원들을 교육할 수 있다. 그러나 에이전트가 연결된 도구들을 통과하는 경로를 스스로 선택하면 이러한 조치의 신뢰도는 떨어진다.
에이전트는 허용된 목표에서 시작하더라도 허용되지 않는 행동을 만들어낼 수 있다. 지시를 오해하거나, 문서에서 검색한 악성 콘텐츠를 따르거나, 개별적으로는 무해한 권한을 결합할 수 있다. 그 결과 생기는 역량은 어느 단일 권한이 시사하는 범위를 넘어설 수 있다.
프롬프트 인젝션은 이 문제를 잘 보여준다. 적대적인 지시는 에이전트가 검색하는 웹페이지, 이메일, 문서 또는 지원 티켓 안에 나타날 수 있다. 이 콘텐츠는 에이전트에게 원래 목표를 무시하고, 정보를 공개하거나, 다른 도구를 활성화하라고 지시한다.
기존 필터는 사용자의 첫 프롬프트를 검사해 위험 요소가 없다고 판단할 수 있다. 하지만 유해한 지시는 워크플로가 이미 시작된 뒤에 유입된다. 따라서 거버넌스는 에이전트의 맥락 변화 전반을 따라가야 한다.
OWASP 에이전틱 가이드라인은 과도한 자율성, 도구 오용, 메모리 조작, 연쇄적 실패, 손상된 에이전트 상호작용과 관련된 위험을 설명한다. 이는 단순히 바람직하지 않은 텍스트 출력의 문제가 아니라 실행 과정의 위험이다.
과도한 자율성은 에이전트가 작업에 필요한 범위보다 더 많은 권한을 부여받을 때 발생한다. 일정 관리 도우미에는 캘린더를 읽고 회의 시간을 제안할 권한이 필요할 수 있다. 하지만 이벤트를 무제한 삭제하거나, 외부 참가자를 초대하거나, 모든 비공개 첨부 파일을 읽을 필요는 거의 없다.
워크플로가 동적으로 변화하면 이러한 구분은 단순해 보이지만 복잡해진다. 에이전트는 한 작업에서는 확장된 접근 권한이 정당하게 필요할 수 있지만, 다른 작업에서는 그렇지 않을 수 있다. 영구적이고 광범위한 권한은 운영 문제를 해결하는 대신 지속적인 보안 노출을 만든다.
런타임 제어는 다른 접근 방식을 제공한다. 시스템은 작업과 그 맥락을 평가한 뒤 좁고 일시적인 인가를 발급할 수 있다. 이 인가는 한 번의 작업 후 만료되거나, 요청 범위가 바뀔 때 승인을 요구하도록 설계될 수 있다.
동일한 원칙은 데이터에도 적용된다. 분기 요약을 준비하는 에이전트에는 집계된 매출 정보가 필요할 수 있지만, 모든 고객의 개인 레코드가 필요한 것은 아니다. 데이터 소스 가까이에 있는 제어 장치는 모델이 데이터를 보기 전부터 에이전트의 검색 범위를 제한할 수 있다.
이는 모델 수준의 안전장치가 하나의 계층에 불과하기 때문에 중요하다. 모델에는 민감한 정보를 공개하지 않도록 지시할 수 있지만, 지시는 충돌하거나 실패할 수 있다. 데이터 최소화와 도구 인가는 모델 동작이 신뢰할 수 없게 될 때의 영향을 줄인다.
런타임 접근 방식은 저위험 추론과 고위험 실행도 분리한다. 에이전트는 작업을 수행할 권한 없이도 선택지를 분석하고, 권고안을 작성하며, 행동을 시뮬레이션할 수 있다. 권한은 워크플로가 통제된 경계에 도달할 때에만 부여된다.
사람의 승인은 여전히 중요하지만, 보편적인 해답이 될 수는 없다. 모든 도구 호출에 승인을 요구하면 에이전트가 약속하는 효율성의 상당 부분이 사라진다. 또한 사람들은 맥락을 검토하지 않고 요청을 수락하게 되는 승인 피로를 겪을 수 있다.
효과적인 거버넌스는 의미 있는 임계값에 개입을 집중한다. 공개 제품 페이지를 읽는 일은 자동으로 진행될 수 있다. 고객 레코드 내보내기, 프로덕션 코드 변경, 자금 송금에는 더 강력한 검사가 필요하다.
정확한 경계는 조직과 작업에 따라 달라진다. 그러나 메커니즘은 일관된다. 작업, 대상, 요청 주체, 잠재적 영향을 평가한 뒤 합법적인 업무를 계속할 수 있는 최소한의 권한만 적용한다.
NIST의 생성형 AI 프로필은 AI 수명주기 전반의 위험 관리를 강조한다. 에이전틱 시스템은 이 수명주기를 즉각적인 영향을 만들 수 있는 의사결정의 연쇄로 확장한다.
따라서 거버넌스는 규칙집을 발행하는 일이라기보다 인가 시스템을 운영하는 일에 가까워진다. 정책은 여전히 무엇이 일어나야 하는지를 정의한다. 런타임 제어는 결과가 현실이 되기 전에 이러한 정책을 기술적 결정으로 전환한다.
아이덴티티가 AI 에이전트 제어 플레인이 된다
에이전트에는 뚜렷하고 추적 가능한 아이덴티티가 필요하다. 직원의 자격 증명을 빌려 쓰면 책임성이 사라지고 모든 후속 제어가 약화되기 때문이다.
초기 에이전트 상당수는 사람 사용자의 기존 계정을 통해 작동한다. 에이전트는 세션, API 토큰 또는 서비스 자격 증명을 상속받는다. 이 설계는 프로토타입을 더 쉽게 만들지만, 조사와 접근 권한 검토 과정에서 모호성을 초래한다.
시스템 로그에는 직원이 파일을 다운로드했다고 표시될 수 있다. 하지만 실제로 그 사람이 다운로드를 클릭했는지, 승인된 에이전트가 파일을 검색했는지, 손상된 워크플로가 해당 계정을 통해 행동했는지는 드러나지 않을 수 있다. 인가 기록에 실제 행위자가 빠져 있는 것이다.
별도의 에이전트 아이덴티티는 이 문제의 일부를 해결한다. 관리자는 에이전트에 권한을 할당하고, 그 행동을 모니터링하며, 사람 후원자를 비활성화하지 않고도 접근 권한을 철회할 수 있다. 또한 정책은 사람의 행동과 기계의 행동을 구분할 수 있다.
그 아이덴티티는 여전히 책임 있는 사람 또는 비즈니스 프로세스와 연결되어야 한다. 그렇지 않으면 조직은 명확한 소유자가 없는 기계 계정의 증가를 초래한다. 비활성 에이전트는 원래 프로젝트가 끝난 뒤에도 접근 권한을 유지할 수 있다.
Microsoft는 에이전트를 발견하고, 거버넌스화하고, 보호하기 위한 아이덴티티 계층으로 Agent ID 제어를 제시했다. 이러한 방향은 더 넓은 업계의 결론을 반영한다. 에이전트에는 다른 비인간 아이덴티티와 비슷한 수명주기 관리가 필요하다.
발견이 먼저인 이유는 보안 팀이 보이지 않는 에이전트를 거버넌스화할 수 없기 때문이다. 사업 부서는 소프트웨어 플랫폼, 로우코드 시스템, 개발 프레임워크, 클라우드 서비스 안에서 에이전트를 만들 수 있다. 각 경로는 또 하나의 아이덴티티, 토큰 또는 통합을 만들어낼 수 있다.
등록 과정에서는 에이전트의 소유자, 목적, 환경, 승인된 도구, 예상 데이터 접근 범위를 기록해야 한다. 에이전트가 자동으로 행동할 수 있는지, 아니면 확인이 필요한지도 기록해야 한다. 이러한 속성은 런타임 시스템에 인가의 근거를 제공한다.
인증은 호출자가 등록된 에이전트인지에 답한다. 인가는 그 에이전트가 이러한 조건에서 이 작업을 수행할 수 있는지에 답한다. 팀이 첫 번째 질문만 해결하고 두 번째 질문에는 광범위하고 지속적인 접근 권한을 부여할 때 거버넌스는 실패한다.
컨텍스트는 권한 부여를 더 정밀하게 만든다. 정책은 요청 사용자, 기기 상태, 데이터 분류, 대상, 거래 금액, 최근 에이전트 행동을 검토할 수 있다. 이를 통해 에이전트 전체를 다시 정의하지 않고도 서로 다른 통제를 적용할 수 있다.
어시스턴트는 정상 업무 중 직원 자신의 회의 메모를 읽을 수 있다. 그러나 다른 부서의 제한된 파일을 대상으로 하는 동일한 요청은 더 면밀한 검토를 받아야 한다. 갑작스러운 대량 다운로드는 문서 한 건을 조회하는 것과 다르게 취급되어야 한다.
메모리는 또 다른 정체성 문제를 더한다. 에이전트는 작업 이력, 선호도, 검색된 사실, 중간 의사결정을 저장할 수 있다. 이 메모리는 원래 사용자 세션이 끝난 뒤에도 남아, 다른 요청에 대한 향후 행동에 영향을 줄 수 있다.
팀은 어떤 정체성이 메모리를 소유하며 누가 이를 변경할 수 있는지 알아야 한다. 또한 저장된 정보의 출처와 변경 과정을 보여 주는 기록인 프로비넌스도 필요하다. 프로비넌스가 없으면 오염된 메모리가 이후 워크플로를 조용히 다른 방향으로 이끌 수 있다.
지식 시스템은 출처 경계와 접근 통제를 유지할 때 더 안전한 검색을 지원할 수 있다. 엔지니어링 지식 기반은 에이전트가 현재 요청자가 접근할 수 있는 문서만 제공받을 때 가장 유용하다.
멀티 에이전트 워크플로에서는 정체성이 더욱 중요해진다. 한 에이전트가 다른 에이전트에 조사를 위임한 뒤, 세 번째 에이전트에게 시스템 업데이트를 요청할 수 있다. 요청을 받는 서비스는 위임된 권한이 그 연결 과정 전체에서 여전히 유효한지 알아야 한다.
위임이 우연히 새로운 권한을 만들어서는 안 된다. 첫 번째 에이전트가 결제를 승인할 수 없다면, 위임받은 에이전트도 그 기능을 얻어서는 안 된다. 모든 권한 이전은 원래의 제한, 목적, 만료 시간을 보존해야 한다.
이 요구 사항은 정체성 보안의 기존 개념과 닮아 있지만, 에이전트는 이례적인 속도와 규모를 더한다. 사람은 한 세션 동안 몇 건의 민감한 작업을 수행할 수 있다. 자동화된 에이전트는 검토자가 알아차리기 전에 여러 시스템에서 많은 작업을 시작할 수 있다.
따라서 제어 평면은 정체성과 속도 제한, 행동 모니터링, 거래 정책을 결합해야 한다. 정체성은 조직에 누가 행동했는지를 알려 준다. 런타임 거버넌스는 그 주체가 계속 행동하도록 허용해야 하는지를 판단한다.
실행 시점 통제에는 고유한 트레이드오프가 있다
런타임 강제 적용은 통제되지 않은 권한을 줄이지만, 지연 시간, 정책 복잡성, 통합 위험, 그리고 공격자가 노릴 수 있는 새로운 제어 지점을 초래하기도 한다.
거버넌스 논거의 가장 강력한 형태는 그럴듯하게 완전해 보일 수 있다. 모든 에이전트에 정체성을 부여하고, 각 행동을 평가하며, 모든 결정을 기록하고, 위험한 작업에는 승인을 요구하면 된다는 주장이다. 실제로는 각 구성 요소가 실패할 수 있다.
첫 번째 한계는 정책 품질이다. 런타임 엔진은 팀이 정밀한 규칙으로 옮기지 못한 의도를 강제할 수 없다. 민감한, 적절한, 중대한, 신뢰할 수 있는 같은 용어는 부서마다 달라지는 비즈니스 판단을 요구하는 경우가 많다.
지나치게 광범위한 규칙은 위험한 행동을 가능하게 둔다. 지나치게 엄격한 규칙은 정당한 업무를 방해하고 직원들이 시스템을 우회하도록 부추긴다. 조직은 추상적인 위험 범주만이 아니라 실제 워크플로를 바탕으로 정책을 조정해야 한다.
컨텍스트 역시 불완전할 수 있다. 보안 서비스는 그 요청을 낳은 대화를 이해하지 못한 채 API 요청만 볼 수 있다. 모델 게이트웨이는 프롬프트를 이해할 수 있지만 대상 시스템 데이터의 분류 정보는 부족할 수 있다.
공격자는 이러한 틈을 악용할 수 있다. 금지된 목표를 여러 개의 허용된 행동으로 분할할 수 있다. 각 단계는 개별적으로 살펴보면 무해해 보이지만, 전체 순서는 권한 없는 결과를 만들어 낸다.
순서를 인식하는 통제는 일부 패턴을 탐지할 수 있지만, 더 풍부한 상태 정보와 더 긴 보존 기간이 필요하다. 이는 개인정보 보호와 운영상의 우려를 낳는다. 상세 추적 기록에는 직원 요청, 고객 데이터, 모델 출력, 기밀 비즈니스 의사결정이 포함될 수 있다.
조직은 거버넌스 텔레메트리를 모니터링 대상 시스템만큼 신중하게 보호해야 한다. 손상된 로그는 공격을 숨기거나 사용자를 거짓으로 연루시킬 수 있다. 노출된 추적 기록은 통제가 보호하도록 설계된 바로 그 정보를 드러낼 수 있다.
성능도 또 다른 트레이드오프를 제시한다. 에이전트는 하나의 작업을 완료하는 동안 많은 소규모 도구 호출을 수행할 수 있다. 모든 호출을 여러 정책 엔진에 통과시키면 지연, 비용, 추가 장애 지점이 늘어날 수 있다.
위험 기반 강제 적용은 이 부담을 줄일 수 있다. 영향이 작고 되돌릴 수 있는 작업에는 가벼운 검사를 적용한다. 영향이 크거나 되돌릴 수 없는 작업에는 더 강력한 권한 부여, 더 풍부한 로깅 또는 사람의 검토를 적용한다.
이 구분에는 신중한 분류가 필요하다. 초안을 내부 검토 대기열로 보내는 일은 되돌릴 수 있다. 같은 텍스트를 고객에게 게시하는 일은 그렇지 않다. 고객 기록 하나를 읽는 일은 전체 데이터베이스를 내보내는 일과 다르다.
모델 업데이트 이후 에이전트의 행동도 달라질 수 있다. 새 모델은 다른 순서로 도구를 선택하거나, 다른 인수를 생성하거나, 더 많은 단계를 시도할 수 있다. 기존 정책은 새 행동을 차단하거나 새로 도입된 경로를 놓칠 수 있다.
이 때문에 지속적인 테스트는 거버넌스의 일부가 된다. 팀은 업데이트된 모델, 도구, 정책을 대상으로 대표적인 워크플로를 재현해야 한다. 테스트에는 적대적인 문서, 모호한 지시, 취소된 권한, 사용할 수 없는 서비스가 포함되어야 한다.
상호운용성은 또 다른 불확실성을 더한다. 업계는 에이전트가 기능을 발견하고 시스템 간에 소통하도록 돕는 프로토콜을 개발하고 있다. Google은 서로 다른 프레임워크로 구축된 에이전트 간 협업을 지원하기 위해 Agent2Agent 프로토콜을 도입했다.
상호운용성은 통합 작업을 줄일 수 있지만, 신뢰 관계도 확장한다. 로컬 에이전트는 원격 에이전트가 설명하는 기능, 정체성 또는 완료된 작업에 의존할 수 있다. 그러한 주장은 기술적 검증이 필요하다.
공유 프로토콜이 자동으로 공유 거버넌스를 만드는 것은 아니다. 조직은 여전히 위임된 작업을 수락하고, 민감한 컨텍스트를 전송하며, 반환된 결과를 검증하기 위한 규칙이 필요하다. 어떤 원격 에이전트가 각 신뢰 경계 내부에 속하는지도 결정해야 한다.
벤더 집중은 관련된 위험을 제시한다. 하나의 정체성 또는 정책 플랫폼이 모든 에이전트 행동을 중개한다면, 장애 하나로 핵심 워크플로가 멈출 수 있다. 구성 실수 하나로 조직 전체가 차단되거나 과도한 접근 권한이 대규모로 부여될 수 있다.
팀은 배포 전에 대체 동작을 마련해야 한다. 일부 작업은 통제를 사용할 수 없을 때 시스템이 이를 차단하는 페일 클로즈 방식으로 처리해야 한다. 다른 저위험 작업은 더 엄격한 제한과 강화된 로깅 아래 계속될 수 있다.
따라서 실행 시점 거버넌스는 보장이 아니라 계층화된 방어로 다뤄야 한다. 제한된 도구, 최소한의 데이터 접근, 격리된 실행, 출력 검증, 모니터링, 사고 대응과 함께할 때 가장 효과적이다.
회의적인 결론은 간단하다. 통제를 실행에 더 가깝게 옮기면 조직의 피해 예방 역량은 향상된다. 그러나 이는 자율적 행동을 예측 가능하게 만들지 않으며, 설계 단계 검토의 필요성도 없애지 않는다.
압력은 보안 팀을 넘어 확장된다
AI 에이전트 거버넌스는 애플리케이션 벤더와 비즈니스 책임자에게 보안 팀이 워크플로 외부에서 추가할 수 없는 통제를 노출하도록 요구한다.
보안 팀은 정체성과 네트워크 접근을 관리할 수 있지만, 애플리케이션의 비즈니스적 의미를 항상 이해할 수는 없다. 필드를 변경하는 API 호출은 환불을 승인하거나, 문서를 게시하거나, 고객 계정을 해지할 수 있다.
애플리케이션 벤더는 중요한 결과를 초래하는 행동에 레이블을 지정하고 그 주변에 권한 부여 지점을 노출해야 한다. 또한 정책 시스템이 미리보기와 확정을 구분할 수 있도록 충분한 컨텍스트를 반환해야 한다. 이러한 세부 정보가 없으면 강제 적용은 거칠게 남는다.
에이전트 플랫폼 제공업체도 비슷한 의무를 진다. 계획 단계, 도구 선택, 인수, 응답, 승인에 대한 지속 가능한 기록이 필요하다. 보안 팀은 제한 없는 사고 과정 데이터를 노출하지 않고도 이러한 기록을 검색할 수 있어야 한다.
모델 제공업체는 여전히 안전장치, 평가, 예측 가능한 도구 사용 행동에 대한 책임이 있다. 그러나 모든 고객의 권한 부여 정책을 결정할 수는 없다. 동일한 모델 행동도 한 환경에서는 무해하지만 다른 환경에서는 금지될 수 있다.
비즈니스 책임자는 이러한 구분을 정의해야 한다. 재무 리더는 어떤 거래에 직무 분리가 필요한지 안다. 인사 팀은 어떤 직원 기록에 더 엄격한 접근이 필요한지 안다. 법무 팀은 생성된 초안이 언제 공식 커뮤니케이션이 되는지 안다.
그다음 개발자가 이러한 요구 사항을 기술적 경계로 옮긴다. 에이전트가 호출할 수 있는 도구, 제공할 수 있는 매개변수, 받을 수 있는 응답을 결정한다. 또한 통제가 단계를 거부할 때 어떤 일이 일어나는지도 정한다.
이러한 책임 분담은 어느 참여자도 혼자 문제를 해결할 수 없기 때문에 압박을 만든다. 정체성 플랫폼에는 작업의 완전한 의미가 없다. 애플리케이션 벤더에는 조직의 완전한 컨텍스트가 없다. 모델 제공업체에는 고객 정책에 대한 권한이 없다.
가장 취약한 통합 지점이 전체 연결 고리를 약화시킬 수 있다. 에이전트는 강력한 정체성을 가질 수 있지만 공유 서비스 계정을 통해 도구를 호출할 수 있다. 도구는 권한을 강제할 수 있지만 외부 문서의 검증되지 않은 지시를 받아들일 수 있다.
조달 팀은 에이전트 벤더에게서 더 구체적인 답변을 기대해야 한다. 책임 있는 AI에 대한 일반적인 설명만으로는 충분하지 않다. 구매자는 제품이 정체성, 위임, 승인, 로그, 메모리, 권한 철회를 어떻게 처리하는지 알아야 한다.
또한 커넥터 전반에서 통제가 계속 효과적인지 물어야 한다. 에이전트는 기본 플랫폼 내부에서는 제한을 준수하지만 타사 서비스를 호출할 때 이를 잃을 수 있다. 권한 상속은 그 전환을 견뎌야 한다.
구매 후에도 운영 책임은 중요하다. 누군가는 접근 권한을 검토하고, 이상 징후를 조사하며, 사용하지 않는 에이전트를 제거하고, 워크플로가 바뀔 때 정책을 업데이트해야 한다. 운영 프로세스 없는 에이전트 인벤토리는 또 하나의 오래된 자산 목록이 된다.
개발자와 지식 근로자도 더 엄격한 거버넌스가 제품 경험을 형성하게 될 것이므로 관심을 가져야 한다. 일부 에이전트는 민감한 작업 전에 멈춘다. 다른 에이전트는 미리보기, 제한 모드 또는 명시적 권한 요청을 제공한다.
그러한 중단이 항상 결함은 아니다. 눈에 보이는 승인 단계는 에이전트가 무엇을 하려는지, 어떤 데이터를 사용할지를 명확히 할 수 있다. 사용자가 실행 전에 잘못 이해한 목표를 발견할 기회를 준다.
잘 설계되지 않은 통제는 반대의 결과를 낳는다. 반복되는 모호한 프롬프트는 사용자가 요청을 자동으로 승인하도록 훈련시킨다. 인터페이스는 구체적인 행동, 대상, 범위, 결과를 평이한 언어로 설명해야 한다.
따라서 시장의 압력은 유용한 자율성과 이해할 수 있는 경계를 결합하는 제품에 유리하게 작용한다. 원시적인 작업 완료 역량은 여전히 중요할 것이다. 에이전트가 가치 있는 시스템에 접근할수록 신뢰할 수 있는 위임도 똑같이 중요해질 것이다.
런타임 거버넌스의 효과를 보여 줄 세 가지 신호
다음 시험대는 또 다른 정책 발표가 아니다. 실제 다단계 워크플로 전반에서 정체성, 권한 부여, 증거가 온전히 유지되는지 여부다.
첫 번째 신호는 주요 엔터프라이즈 플랫폼 전반에서 별도 에이전트 정체성이 채택되는 것이다. 중요한 증거에는 수명 주기 통제, 지정된 책임자, 제한된 권한, 만료, 권한 철회가 포함될 것이다.
제품 라벨만으로는 충분하지 않다. 보안 팀은 에이전트를 이를 후원하는 직원 및 도구 뒤에 있는 서비스 계정과 구분할 수 있어야 한다. 더 폭넓은 지원은 런타임 거버넌스 논지를 강화할 것이다.
두 번째 신호는 애플리케이션 경계에서의 강제 적용이다. 엔터프라이즈 소프트웨어 제공업체는 외부 메시지, 기록 변경, 코드 배포, 금융 운영을 포함한 중요한 결과를 초래하는 행동에 대한 정책을 노출해야 한다.
이러한 제어 장치가 비즈니스 맥락을 이해하는지, 아니면 단지 텍스트를 필터링하는지 지켜봐야 한다. 맥락 인식형 권한 부여는 거버넌스가 실행 단계로 들어섰음을 보여줄 것이다. 일반적인 경고와 선택적 로그만 제공된다면, 이러한 전환은 아직 불완전하다는 의미다.
세 번째 신호는 실패 사례와 독립적인 테스트에서 나오는 증거다. 연구자들은 프롬프트 인젝션, 위임된 권한, 오염된 메모리, 과도한 권한, 원격 에이전트 간 상호작용을 테스트해야 한다.
투명한 사고 보고서는 성공적인 시연만큼 중요하다. 이를 통해 제어 장치가 유해한 행동을 차단했는지, 그 범위를 제한했는지, 아니면 사후에 피해만 기록했는지를 확인할 수 있다. 반복적인 우회 사례는 실행 시점의 강제가 성숙했다는 주장을 약화시킬 것이다.
향후 몇 달 동안 구매자는 공급업체에 하나의 완전한 체인을 시연해 달라고 요청해야 한다. 특정 사용자를 시작점으로 삼아, 범위가 제한된 작업을 위임하고, 보호된 데이터를 조회하며, 도구를 호출하고, 승인을 요구한 뒤, 접근 권한을 철회하는 과정이다.
그다음 증거를 검토해야 한다. 공급업체는 누가 작업을 시작했는지, 어떤 에이전트가 행동했는지, 무엇에 접근했는지, 어떤 정책이 적용됐는지, 그리고 위임이 권한을 변경했는지를 보여줄 수 있는가?
엔터프라이즈 AI 에이전트 거버넌스는 이러한 답변이 실제 배포 환경에서도 유지될 때에만 성공할 수 있다. 조직에서 에이전트를 시범 운영하고 있다면, 각 워크플로에서 되돌릴 수 없는 첫 번째 행동을 식별해야 한다. 그 지점에 가장 강력한 제어를 적용하고, 거부 경로를 테스트하며, 모든 결정이 계속해서 추적 가능하도록 확인해야 한다.
