CLAIIM: AI 에이전트가 행동하기 전의 신원 확인 및 거버넌스

CLAIIM: AI 에이전트가 행동하기 전의 신원 확인 및 거버넌스

AI 에이전트(AI agents)가 실험 단계를 넘어 실제 조직의 워크플로(workflows)로 이동하고 있습니다.

이들은 코드 리뷰(code review), 인프라 운영(infrastructure operations), 고객 지원(customer support), 재무 보고(finance reporting), 내부 지식 작업(internal knowledge work), 워크플로 자동화(workflow automation), 그리고 의사 결정 지원(decision support)을 돕고 있습니다.

이러한 변화는 단순하지만 불편한 질문을 던집니다:

AI 에이전트가 행동할 때, 누가 책임을 지는가?

대부분의 조직은 이미 인간을 위한 통제 수단(controls)을 갖추고 있습니다:

• SSO (Single Sign-On)
• MFA (Multi-Factor Authentication)
• IAM 역할 (IAM roles)
• 특권 액세스 관리 (privileged access management)
• 승인 워크플로 (approval workflows)
• 감사 로그 (audit logs)

또한 서비스(services)를 위한 통제 수단도 갖추고 있습니다:

• 서비스 계정 (service accounts)
• API 키 (API keys)
• 워크로드 신원 (workload identity)
• 인프라 로그 (infrastructure logs)
• SIEM 파이프라인 (SIEM pipelines)

하지만 AI 에이전트는 이 두 세계 사이에 어색하게 위치합니다.

그들은 정확히 인간도 아닙니다.

그들은 정확히 서비스도 아닙니다.

그들은 추론하고, 도구를 선택하며, API를 호출하고, 사람을 대신하여 행동할 수 있습니다.

그리고 오늘날의 많은 시스템에서, 그들은 여전히 "단순한 토큰(just a token)"으로서 작동합니다.

그것이 바로 CLAIIM이 메우고자 하는 격차입니다.

CLAIIM이 하는 일

CLAIIM은 AI 에이전트를 위한 신원 통제 평면(identity control plane)입니다.

CLAIIM은 각 에이전트에게 거버넌스가 적용된 신원(governed identity)을 부여하고, 에이전트가 행동하기 **전(before)**에 해당 에이전트가 무엇을 할 수 있도록 허용되었는지 확인합니다.

핵심 아이디어는 간단합니다:

• 행동 전 신원 확인 (Identity before action).
• 실행 전 정책 적용 (Policy before execution).
• 모든 결정 후 증거 확보 (Proof after every decision).

CLAIIM을 통해 조직은 다음과 같은 질문에 답할 수 있습니다:

• 어떤 에이전트가 이 행동을 수행했는가?
• 어떤 인간이 해당 에이전트에 대해 책임을 지는가?
• 행동이 일어나기 전에 해당 행동이 허용되었는가?
• 어떤 정책 버전(policy version)이 해당 결정을 거버넌스했는가?
• 당시 어떤 기술(skill)이나 역량(capability)이 활성화되어 있었는가?
• 행동 후에 어떤 증거(proof)가 존재하는가?

이것이 중요한 이유는 AI 거버넌스(AI governance)가 모델 평가(model evaluation)나 프롬프트 안전성(prompt safety)에 관한 것뿐만이 아니기 때문입니다.

그것은 운영상의 책임(operational accountability)에 관한 것이기도 합니다.

기존 통제 수단이 충분하지 않은 이유

전통적인 IAM은 다음과 같이 답합니다:

"이 사용자 또는 서비스가 이 시스템에 접근할 수 있는가?"

하지만 에이전트 거버넌스(agent governance)는 더 구체적인 질문에 답해야 합니다:

“이 특정 목적을 위해, 이 책임 있는 인간의 감독 하에 행동하는 이 특정 에이전트가, 지금 바로 이 동작을 수행할 수 있는가?”

그것은 다른 종류의 제어 문제 (control problem) 입니다.

예를 들어, DevOps 에이전트는 스테이징 (staging) 환경에 배포하는 것은 허용될 수 있지만, 프로덕션 (production) 환경은 허용되지 않을 수 있습니다.

지원 (support) 에이전트는 환불 응답 초안을 작성하는 것은 허용될 수 있지만, 환불을 실행하는 것은 허용되지 않을 수 있습니다.

금융 (finance) 에이전트는 보고 데이터를 읽는 것은 허용될 수 있지만, 자금을 이동하는 것은 허용되지 않을 수 있습니다.

코드 리뷰 (code review) 에이전트는 풀 리퀘스트 (pull request)에 댓글을 다는 것은 허용될 수 있지만, 이를 머지 (merge) 하는 것은 허용되지 않을 수 있습니다.

이 차이는 기술적인 것뿐만이 아닙니다. 조직적인 (organizational) 차이입니다.

AI 에이전트에는 현실 세계의 책임 관계를 반영하는 경계 (boundaries) 가 필요합니다.

CLAIIM 모델

CLAIIM은 네 가지 아이디어를 중심으로 구축되었습니다.

1. 관리되는 에이전트 신원 (Governed Agent Identity)

각 에이전트는 고유한 신원을 가집니다.

그 신원은 단순히 일반적인 API 토큰 (API token) 이 아닙니다. 그것은 조직, 에이전트에게 허용된 기능 (capabilities), 그리고 에이전트의 운영에 책임을 지는 인간과 연결됩니다.

2. 인간의 책임 (Human Accountability)

모든 관리되는 에이전트는 이름이 명시된 인간에게 고정됩니다.

이것이 인간이 모든 동작을 수동으로 승인해야 한다는 의미는 아닙니다. 에이전트가 행동할 때 명확한 책임 체인 (accountability chain) 이 존재함을 의미합니다.

규제 대상이거나 민감한 환경에서는 이것이 필수적이 됩니다.

3. 동작 전 정책 확인 (Policy Before Action)

에이전트가 동작을 수행하기 전에, CLAIIM에 해당 동작이 허용되는지 묻습니다.

CLAIIM은 정책 (policy) 에 따라 요청을 평가하고 허용 (allow) 또는 거부 (deny) 결정을 반환합니다.

에이전트는 동작이 허용된 경우에만 진행할 수 있습니다.

4. Chron 증명 (Chron Proof)

모든 허용 및 거부 결정은 CLAIIM의 감사 추적 (audit trail) 인 Chron에 기록됩니다.

Chron은 다음 사항에 대한 증거를 보존하도록 설계되었습니다:

• 에이전트
• 동작
• 결정
• 책임 있는 인간
• 정책 버전 (policy version)
• 스킬 버전 (skill version)
• 차단된 경우, 거부 사유

이를 통해 팀은 도구들에 흩어져 있는 로그가 아니라, 사후에 확인할 수 있는 증거를 확보할 수 있습니다.

간단한 예시

배포 (deployment) 에이전트를 상상해 보십시오.

이 에이전트는 팀이 소프트웨어를 배포하는 것을 도울 수 있지만, 조직은 명확한 경계를 원합니다.

정책은 다음과 같을 수 있습니다:

• 스테이징 (staging) 환경으로의 배포 허용
• 프로덕션 (production) 환경으로의 배포 차단
• 모든 결정 사항 기록
• 결정을 책임 있는 인간 및 활성 정책 (active policy)에 연결

에이전트가 스테이징 환경에 배포를 시도할 때, CLAIIM은 이를 허용합니다.

동일한 에이전트가 프로덕션 환경에 배포를 시도할 때, CLAIIM은 이를 차단합니다.

두 결정 모두 기록됩니다.

이것이 핵심입니다: 에이전트는 유용하지만, 무제한적이지는 않습니다.

DevOps를 넘어 이것이 중요한 이유

동일한 패턴이 조직 전체에 적용됩니다.

고객 지원 (support) 분야:

• 고객 응답 초안 작성 허용
• 검토 없이 응답을 전송하는 것은 차단
• 어떤 사용자가 에이전트를 소유했는지 기록

재무 (finance) 분야:

• 보고서 읽기 허용
• 결제 실행 차단
• 감사를 위한 증거 보존

인사 (HR) 분야:

• 정책 문서 요약 허용
• 민감한 직원 관련 작업 차단
• 결정 경로 로그 기록

법무 (legal) 분야:

• 문서 분석 허용
• 외부 공개 차단
• 관리 연속성 (chain of custody) 보존

문제는 엔지니어링 분야에만 국한되지 않습니다.

AI 에이전트가 행동할 수 있는 모든 곳에는 신원 (identity), 정책 (policy), 책임 (accountability), 그리고 증거 (proof)가 필요합니다.

설계 단계부터 고려된 주권 (Sovereign by Design)

CLAIIM은 고객의 자체 환경에서 실행되도록 설계되었습니다.

이는 다음을 의미합니다:

• 귀하의 데이터베이스
• 귀하의 정책
• 귀하의 에이전트 기록
• 귀하의 감사 추적 (audit trail)
• 귀하의 인프라 경계

Nivaya는 CLAIIM이 작동하기 위해 귀하의 에이전트 활동 데이터를 수신할 필요가 없습니다.

이는 데이터 거주성 (data residency), 규제 경계, 내부 기밀 유지 또는 고객 신뢰를 중요하게 생각하는 조직에게 매우 중요한 요소입니다.

퍼블릭 프리뷰 (Public Preview)

CLAIIM은 현재 퍼블릭 프리뷰 단계에 있습니다.

이 프리뷰는 AI 에이전트가 비즈니스 워크플로에 깊숙이 통합되기 전에, 어떻게 AI 에이전트를 거버넌스 (govern) 할 것인지 탐색하는 팀들을 위한 것입니다.

특히 다음과 같은 분야에서 작업 중이라면 매우 유용합니다:

• AI 에이전트 플랫폼
• 내부 코파일럿 (internal copilots)
• DevOps 자동화
• 지원 (support) 자동화
• 재무 워크플로
• 규제 대상 AI 시스템
• 보안 및 컴플라이언스 (compliance) 프로그램

프리뷰의 목표는 간단합니다:

에이전트 확산 (agent sprawl)이 또 다른 관리되지 않는 신원 문제(identity problem)가 되기 전에, 팀들이 제어 모델 (control model)을 조기에 테스트할 수 있도록 돕습니다.

사용해 보기

웹사이트: https://claiim.io

문의: support@claiim.io

만약 여러분이 이미 다음과 같은 질문을 던지고 있다면:

• "우리 조직 내에서 어떤 에이전트들이 실행되고 있는가?"
• "그 에이전트들의 소유자는 누구인가?"
• "그들은 무엇을 할 수 있도록 허용되어 있는가?"
• "무슨 일이 일어났는지 증명할 수 있는가?"
• "위험한 행동이 실행되기 전에 차단할 수 있는가?"

그렇다면 CLAIIM을 살펴볼 가치가 있을 것입니다.

AI 에이전트는 조직 내부의 행위자 (actors)가 되어가고 있습니다.

그들에게는 신원 (identity)이 필요합니다.

그들에게는 경계 (boundaries)가 필요합니다.

그들에게는 책임성 (accountability)이 필요합니다.

그들에게는 증거 (proof)가 필요합니다.

그것이 바로 CLAIIM이 존재하는 이유입니다.