소개: 시스템의 다음 사용자는 사람이 아닐 수도 있습니다
귀하의 시스템에 액세스하는 다음 계정은 직원의 것이 아닐 수도 있습니다. AI 에이전트에 속할 수도 있고 속해야 합니다.
운영 관리자가 상담원에게 주간 보고서를 준비하도록 요청합니다. 대시보드를 열고, CSV를 다운로드하고, Excel 통합 문서를 읽고, 지난주 결과를 비교하고, 보고서를 생성하고, 초안을 반환합니다.
워크플로는 성공하지만 모든 로그에는 alex@company.com이 기록됩니다. 조직에서는 Alex가 수행한 작업, 상담원이 해당 작업을 초과했는지 또는 액세스가 계속되었는지 알 수 없습니다.
AI 에이전트가 사용자와 같은 시스템과 상호 작용할 수 있다면 사용자의 신원을 계속 빌려야 할까요?
이곳은 인간이 아닌 정체성 AI 거버넌스의 중심이 됩니다. 조직은 작업을 수행하는 엔터티를 해당 엔터티가 사용하는 자격 증명 및 받는 권한과 분리해야 합니다.
Non-Human Identity이란 무엇입니까?
에이 인간이 아닌 정체성 소프트웨어, 서비스, 자동화된 프로세스, 장치, 워크로드 또는 AI 에이전트가 인간 사용자 역할을 하지 않고 시스템을 인증하고 액세스하는 데 사용되는 디지털 ID입니다.
예로는 서비스 계정, 서비스 주체, 관리 ID, 워크로드, 장치, 봇, 스크립트, CI/CD 파이프라인, API 통합 및 AI 에이전트가 있습니다.
Non-Human Identity은 자동으로 API 키, 비밀번호, 토큰, 인증서, 기계, 봇 또는 모델이 아닙니다. 이는 자격 증명, 인증 메커니즘, 실행 엔터티 또는 연결된 리소스일 수 있습니다.
모델에는 세 가지 질문이 있습니다.
- 신원: 누가 또는 무엇을 연기하고 있나요?
- 신임장: 그 신원을 어떻게 증명합니까?
- 허가: 무엇에 접근하거나 변경할 수 있나요?
신원, 자격 증명 및 권한
| 개념 | 질문에 답변됨 | 예 |
|---|---|---|
| 신원 | 누가 또는 무엇을 연기하고 있나요? | 주간 신고 상담원 |
| 신임장 | 그 정체성을 어떻게 증명합니까? | 단기 액세스 토큰 |
| 허가 | 무엇에 접근하거나 변경할 수 있나요? | 대시보드 데이터 읽기 및 보고서 파일 쓰기 |
| 인간 스폰서 | 신원에 대한 책임은 누구에게 있습니까? | 운영 관리자 |
| 수명주기 | 액세스는 언제 시작되고 종료되어야 합니까? | 워크플로용 Active 및 분기별 검토 |
자격 증명은 신원 자체가 아닙니다. 신원을 인증하기 위해 사용되는 증거입니다.
Non-Human Identity의 주요 유형
서비스 계정
이러한 계정은 애플리케이션, 스크립트, 일정 및 통합을 지원합니다. 위험에는 공유 소유권, 정적 비밀번호, 과도한 액세스, 만료 날짜 없음 등이 포함됩니다.
애플리케이션 및 서비스 주체 ID
이는 SaaS 및 내부 자동화를 포함하여 API, 클라우드 서비스 또는 리소스에 액세스하는 애플리케이션을 나타냅니다.
관리형 및 워크로드 아이덴티티
이는 가상 머신, 컨테이너, 서버리스 기능, CI/CD 작업, 클라우드 애플리케이션과 같은 소프트웨어 워크로드를 나타냅니다. 지원되는 플랫폼에서는 영구 비밀을 코드에 직접 저장하지 않고도 이를 사용할 수 있습니다.
기계 및 장치 ID
이는 인증서, 키 또는 장치 기록을 통해 서버, 노트북, 네트워크 장비, 산업 시스템 및 IoT 장치를 확인합니다.
AI 에이전트 ID
이는 목표를 해석하고, 도구를 선택하고, 리소스에 액세스하고, 조치를 취하는 에이전트를 나타냅니다. AI 에이전트는 Non-Human Identity에 적합하지만 적응형 동작으로 인해 고정 서비스 계정보다 관리하기가 더 어렵습니다.
Non-Human Identity 및 머신 Identity 및 워크로드 Identity
인간이 아닌 정체성 넓은 우산이에요. Machine identity, 워크로드 아이덴티티, 서비스 계정, 에이전트 아이덴티티는 더 좁은 범주 또는 구현 패턴입니다.
Non-Human Identity 관련 Identity 유형과 비교
| Identity 유형 | 그것이 나타내는 것 | 전형적인 예 |
|---|---|---|
| 인간의 정체성 | 실제 사람 | 직원, 계약자, 파트너, 고객 |
| 인간이 아닌 정체성 | 리소스에 액세스하는 소프트웨어 기반 또는 머신 기반 엔터티 | Service account, 애플리케이션, 봇, 워크로드, AI 에이전트 |
| 기계 정체성 | 기계, 장치, 서버 또는 기술 구성요소 | 장치 인증서, 서버 키, IoT ID |
| 워크로드 아이덴티티 | 클라우드 또는 인프라에서 소프트웨어 실행 | 컨테이너, 가상 머신, 서버리스 기능 |
| 서비스 계정 | 애플리케이션이나 자동화된 작업에 사용되는 계정 | 예약된 보고서 계정, 데이터베이스 통합 |
| 상담원 신원 | AI 에이전트를 나타내는 ID | 연구 대리인, 보고 대리인, 데스크탑 대리인 |
용어는 플랫폼마다 다릅니다. 거버넌스는 ID가 나타내는 내용, 실행 위치, 액세스할 수 있는 항목 및 소유자가 누구인지에 초점을 맞춰야 합니다. 모든 Non-Human Identity이 물리적 시스템을 나타내는 것은 아닙니다.
AI 에이전트가 Non-Human Identity 문제를 변경하는 이유
상담원은 고정된 지침뿐만 아니라 목표를 따릅니다.
기존 자동화에서는 자정에 백업을 복사할 수 있습니다. 비정상적인 성과를 조사하고 보고서를 준비하도록 요청받은 에이전트는 발견한 내용에 따라 다른 조치를 선택할 수 있습니다.
상담원은 여러 도구를 사용합니다.
하나의 에이전트는 API, 파일, 브라우저, 스프레드시트, 데이터베이스, 통신 도구 및 하위 에이전트 간에 이동할 수 있습니다. 각 연결은 권한 체인을 확장합니다.
권한은 작업에 따라 다릅니다.
연구, 보고 및 고객 지원 워크플로우는 단순히 동일한 플랫폼을 사용한다는 이유만으로 동일한 액세스 권한을 받아서는 안 됩니다.
대리인이 위임할 수 있음
기본 상담원은 전문 도구나 다른 상담원에게 전화를 걸 수 있습니다. 액세스는 추적 가능해야 하며 명확한 규칙에 따라 상속되거나 별도로 승인되어야 합니다.
에이전트는 사람을 대신하여 행동합니다.
시스템은 인간 작업, 인간이 요청한 에이전트 작업, 승인된 작업 내에서 에이전트가 선택한 단계 및 위임된 작업을 구별해야 합니다. Agent identity은 요청자, 실행자, 자격 증명 및 결과 간의 링크를 보존해야 합니다.
AI 에이전트가 인간 계정 뒤에 숨어서는 안 되는 이유
상담원은 직원의 브라우저 세션, API 토큰, 이메일 계정 또는 애플리케이션 로그인을 사용할 수 있습니다. 워크플로는 작동할 수 있지만 속성이 약해집니다.
로그에는 직원 계정만 표시되지만 상담원은 직원이 접근할 수 있는 모든 것을 상속합니다. 보안 팀은 인간의 행동과 자동화를 확실하게 분리할 수 없으며 액세스가 의도한 작업 이상으로 지속될 수 있습니다.
더 나은 기여 모델은 다음과 같습니다.
- 시작한 사람: 알렉스
- 실행자: 주간 신고 상담원
- 환경: 승인된 기업 데스크탑
- 승인자: 재무 관리자
스폰서는 목적에 대한 책임을 갖고, 에이전트 신원은 해당 작업을 수행한 내용을 보여줍니다. 에이전트는 인간과 구별되지 않으면서 인간을 대신하여 행동해야 합니다.
관리되지 않는 비인간 신원의 주요 위험
고아 정체성
직원이 퇴사하거나, 프로젝트가 종료되거나, 통합이 교체되거나, 에이전트가 중단된 후에도 액세스는 활성 상태로 유지됩니다.
과도한 권한
제한된 정책으로 인해 실패가 발생하고 일시적인 편의가 영구적인 권한이 되기 때문에 광범위한 액세스가 부여됩니다.
장기 자격 증명
정적 비밀번호, API 키, 인증서 및 토큰은 원래 필요성이 사라진 후에도 오랫동안 사용 가능한 상태로 남아 있을 수 있습니다.
공유 ID
여러 애플리케이션, 에이전트 또는 직원이 하나의 계정을 사용하므로 귀속 및 소유권이 약화됩니다.
신원의 확산
Service accounts, 봇, OAuth 앱, 토큰, 스크립트 및 하위 에이전트는 안정적인 인벤토리 없이 축적됩니다.
약한 책임감
사고가 발생한 후 요청자, 워크플로 소유자, 응용 프로그램 소유자, 승인자 및 기술 제공자 간에 책임에 대해 논쟁이 벌어질 수 있습니다.
가장 큰 위험은 종종 정체성이 존재한다는 것이 아니라 그것이 왜 존재하는지, 무엇을 할 수 있는지, 언제 사라져야 하는지 아무도 모른다는 것입니다.
8단계 Non-Human Identity Lifecycle
Step 1: 발견
인벤토리 서비스 계정, 애플리케이션 ID, OAuth 앱, 클라우드 및 로컬 에이전트, 봇, 스크립트, 인증서, 일정, API 통합 및 연결된 도구.
Step 2: 등록
고유한 이름, 유형, 목적, 작성자, 후원자, 부서, 런타임, 연결된 도구, 액세스 가능한 데이터, 자격 증명 유형 및 만료를 기록합니다.
Step 3: 인간 스폰서 지정
지명된 사람은 목적을 승인하고, 액세스를 검토하고, 사고에 대응하고, 소유권을 이전하고, 폐기를 승인해야 합니다.
Step 4: ID 경계 정의
문서 허용 시스템, 폴더, 기록, 도구, 작업 및 명시적인 금지 사항.
Step 5: 최소 권한 적용
현재 워크플로우에 필요한 것만 부여하십시오. 단지 실패를 줄이기 위해 추가된 관리 액세스 권한을 유지하지 마십시오.
Step 6: 단기 자격 증명을 선호합니다.
지원되는 경우 임시 토큰, 관리 ID, 워크로드 페더레이션, 작업 범위 자격 증명, 만료 및 해지를 사용합니다.
Step 7: 모니터 동작
인증 이벤트, 액세스한 리소스, 호출된 도구, 열린 파일, 변경 사항, 전송, 실패, 재시도 및 위임을 캡처합니다.
Step 8: 순환, 양도 및 폐기
워크플로가 변경되거나 종료되면 자격 증명을 교체하고, 소유권을 이전하고, 일정을 제거하고, 권한을 취소하고, 도구 연결을 끊고, 하위 ID를 폐기하고, 감사 기록을 유지하세요.
인간이 아닌 신원 수명주기 체크리스트
| Lifecycle 질문 | 필수 답변 |
|---|---|
| 정체성은 무엇입니까? | 고유한 이름 및 ID 유형 |
| 왜 존재합니까? | 문서화된 사업 목적 |
| 누가 그것을 소유합니까? | 지명된 인간 후원자 |
| 어디에서 실행되나요? | 알려진 애플리케이션, 장치 또는 워크로드 |
| 무엇에 접근할 수 있나요? | 정의된 시스템, 파일, 데이터 및 도구 |
| 어떻게 인증하나요? | 승인 및 관리되는 자격 증명 |
| 액세스 권한은 언제 검토되나요? | 예정된 검토 날짜 |
| 언제 만료되나요? | 정의된 만료 또는 만료 조건 |
| 활동은 어떻게 모니터링되나요? | 로그, 경고 및 감사 프로세스 |
AI 에이전트에 최소 권한 액세스 권한을 부여하는 방법
상담사의 최대 능력이 아닌 최소 권한이 워크플로를 따라야 합니다.
주간 보고 상담원에게는 보고 폴더 1개, 대시보드 2개, CSV 다운로드, 출력 디렉터리 1개, 초안 준비 권한이 필요할 수 있습니다. 전체 하드 드라이브, 모든 브라우저 프로필, 개인 이메일, 청구 제어, 권한 관리, 소스 파일 삭제 또는 보고서를 외부로 보내는 권한이 필요하지 않을 수도 있습니다.
4개의 레이어를 정의합니다.
- 리소스 범위: 어떤 시스템, 폴더, 애플리케이션, 기록이 있나요?
- 작업 범위: 읽기, 쓰기, 수정, 삭제, 게시 또는 보내기?
- 시간 범위: 영구, 예약, 임시 또는 작업 기반?
- 승인 범위: 명시적인 확인이 필요한 작업은 무엇입니까?
최소 권한은 에이전트가 볼 수 있는 내용, 수행할 수 있는 작업, 수행할 수 있는 기간 및 승인 대상을 제한합니다.
데스크톱 AI 에이전트에 명확한 Identity Boundaries이 필요한 이유
Desktop Agent는 로컬 파일, 설치된 애플리케이션, 브라우저 세션, 저장된 자격 증명, 다운로드, 스크린샷, 클립보드 콘텐츠, 운영 체제 컨트롤 및 통신 앱과 상호 작용할 수 있습니다. 따라서 ID 경계는 하나 이상의 API에 걸쳐 있을 수 있습니다.
데스크톱 워크플로에는 다음이 포함될 수 있습니다.
인간 요청자 -> 통신 채널 -> 데스크톱 에이전트 -> 기업 장치 -> 브라우저 ID -> 비즈니스 애플리케이션 -> 출력 폴더
조직은 작업을 제출한 사람, 작업을 받은 에이전트, 사용된 장치 및 계정, 발생한 작업, 생성된 출력, 검토한 사람을 알아야 합니다.
로컬 실행은 구성에 따라 일부 데이터 전송을 줄일 수 있습니다. 신원 위험을 제거하거나 에이전트가 누구를 대표하는지, 어떤 권한을 사용하는지에 대해 답변하지 않습니다.
EasyClaw은 데스크톱 에이전트가 파일, 브라우저, 애플리케이션 및 출력에 걸쳐 명시적인 경계가 필요한 이유를 보여줍니다.
EasyClaw이 관리 에이전트에 적합한 방법 Identity 전략
EasyClaw은 로컬 파일, 애플리케이션, 브라우저 인터페이스, 보고서, 리뷰 및 프로젝트 폴더와 관련된 작업을 위한 데스크탑 기반 AI 워크플로우 에이전트입니다. 이는 ID 관리 플랫폼이 아니며 IAM, 권한 있는 액세스, 자격 증명 순환 또는 위협 제어를 대체하지 않습니다.
실질적인 역할은 데스크톱 에이전트가 이름이 지정되고 제한되며 가시적이며 검토 가능한 ID 경계 내에서 작동해야 하는 이유를 설명하는 것입니다.
인간 요청자를 식별합니다
EasyClaw 작업을 발행할 수 있는 사람, 승인되는 채널, 요청자 인증 방법, 민감한 워크플로를 시작할 수 있는 사람을 정의합니다. 모든 요청은 특정 사람에게 연결되어야 합니다.
실행 중인 EasyClaw 환경 식별
EasyClaw 배포, 회사 장치, 운영 체제 계정, 브라우저 프로필, 승인된 애플리케이션 및 워크플로 소유자를 기록합니다. 요청자와 실행 환경은 연결되어 있지만 동일한 행위자는 아닙니다.
파일 및 애플리케이션 범위 제한
보고 워크플로에는 폴더 1개, Excel 통합 문서 1개, 선택한 대시보드, PDF 템플릿 및 출력 디렉터리 1개가 필요할 수 있습니다. 모든 로컬 파일, 브라우저 계정, 클라우드 드라이브, 관리 설정 또는 관련 없는 시스템에 자동으로 액세스해서는 안 됩니다. 범위를 명확하게 지정하면 잘못된 파일 선택과 실수로 덮어쓰는 일도 줄어듭니다.
승인 뒤에 결과적 조치 유지
외부 메시지, 공개 게시, 파일 삭제 또는 덮어쓰기, 금융 정보 제출, 고객 기록 변경, 권한 수정, 결제 완료, 계약 변경에 대해서는 사람의 승인이 필요합니다.
EasyClaw은 중간 작업을 구성하고, 검토 패키지를 준비하고, 사용 가능한 결과물을 반환할 수 있습니다. 되돌릴 수 없고, 외부적으로 가시적이며, 재정적으로 중요하거나 법적으로 중대한 결정은 책임자의 몫입니다.
워크플로 수명주기 문서화
각 워크플로에는 이름, 목적, 후원자, 승인된 입력, 작업, 출력 대상, 검토 날짜, 중지 조건 및 폐기 절차가 있어야 합니다. 새 계정, 채널 또는 대상은 검토를 시작해야 합니다.
EasyClaw은 인간 계정에서 무제한 액세스를 빌려오는 보이지 않는 소프트웨어가 아니라 승인된 작업 흐름 내에서 가시적이고 범위가 지정된 데스크톱 에이전트로 작동해야 합니다.
Example: EasyClaw 보고 에이전트에게 명확한 Identity 경계 제공
운영 관리자가 다음과 같이 요청합니다. “이번 주 성과 보고서를 준비하고 지난주와 비교한 후 검토를 위해 초안을 제출하세요.
승인된 EasyClaw 워크플로는 선택한 대시보드를 열고, 현재 내보내기를 다운로드하고, 주간 Excel 추적기를 읽고, 이전 보고서를 비교하고, 초안을 준비하고, 패키지를 저장하고, 반환합니다. EasyClaw은 문서가 많은 실행을 처리하는 반면 신원 및 보안 제어는 사용할 수 있는 항목을 정의합니다.
EasyClaw 보고 워크플로에 대한 Identity Boundaries
| Identity 또는 구성요소 | 역할 | 필수 경계 |
|---|---|---|
| 운영 관리자 | 작업을 시작합니다 | 승인된 보고 워크플로를 시작할 수 있습니다. |
| EasyClaw 보고 워크플로 | 작업을 실행합니다. | 보고 조치로 제한됨 |
| 기업 컴퓨터 | 실행 환경 | 승인 및 관리되는 기기 |
| 브라우저 ID | 성능 시스템을 읽습니다. | 선택한 대시보드에 대한 읽기 전용 액세스 |
| 파일 액세스 범위 | 보고서 자료를 읽고 작성합니다. | 주간 보고 폴더만 |
| 출력 디렉터리 | 생성된 재료를 저장합니다. | Dedicated 검토 폴더 |
| 인간 검토자 | 보고서를 확인합니다 | 최종 결론을 승인해야 함 |
| 커뮤니케이션 채널 | 결과를 반환합니다. | 승인된 요청자 및 전달 경로만 |
어트리뷰션 체인은 계속 표시되어야 합니다.
- 시작한 사람: 운영 관리자
- 실행자: EasyClaw 보고 워크플로
- 액세스된 데이터: 승인된 대시보드 및 보고 폴더
- 검토자: 운영 관리자
- 배포자: 승인 후 인간 소유자
이는 요청, 실행, 액세스, 승인 및 배포를 분리합니다. 숫자가 잘못된 것으로 보이면 팀에서는 승인된 소스, 사용된 파일, 생성된 출력 및 검토자의 결정을 검사할 수 있습니다. EasyClaw은 워크플로 실행 계층입니다. 기존 ID 시스템은 인증, 자격 증명, 권한 및 정책을 계속 담당합니다.
결론: 모든 에이전트에는 Identity, 소유자 및 만료일이 필요합니다.
Non-Human Identity에는 애플리케이션, 서비스, 기계, 워크로드, 스크립트, 봇, 자동화된 프로세스 및 AI 에이전트가 포함됩니다.
AI 에이전트의 행동은 적응적이고 위임되며 여러 도구에 걸쳐 확산될 수 있기 때문에 위험이 높아집니다. 조직은 어떤 에이전트가 활동하는지, 누가 후원하는지, 어떤 자격 증명과 권한을 사용하는지, 작업이 기록되는 방식, 승인이 필요한 시기, 액세스가 만료되는 시기를 알아야 합니다.
EasyClaw은 신원 관리 플랫폼이 아닙니다. 데스크톱 실행 모델은 에이전트 워크플로에 소유자 지정, 파일 및 애플리케이션 액세스 제한, 가시적 실행, 검토 가능한 출력, 후속 작업에 대한 사람 승인이 필요한 이유를 보여줍니다.
모든 AI 에이전트에는 신원, 인간 후원자, 권한 경계 및 만료 날짜가 필요합니다.
FAQ
Q: API 키는 Non-Human Identity입니까?
A: 그 자체는 아닙니다. API 키는 일반적으로 자격 증명입니다. ID는 이를 사용하는 애플리케이션, 서비스, 워크로드, 스크립트 또는 에이전트입니다.
Q: 서비스 계정은 Non-Human Identity과 동일합니까?
A: 서비스 계정은 비인간 신원의 일반적인 형태 중 하나입니다. 더 넓은 범주에는 서비스 주체, 관리 ID, 워크로드, 머신, 장치, 봇, 애플리케이션 및 에이전트도 포함됩니다.
Q: AI 에이전트가 직원 계정을 사용하면 안되는 이유는 무엇입니까?
A: 공유된 신원은 개인이나 대리인의 행동 여부를 숨기고 과도한 액세스 권한을 부여할 수 있습니다. 관리형 모델은 요청자, 실행자, 환경, 액세스 및 검토자를 기록합니다.
Q: 모든 AI 에이전트에는 별도의 ID가 필요합니까?
A: 프로덕션 에이전트는 귀속, 정책, 검토 및 취소를 지원할 만큼 충분히 구별 가능해야 합니다. 구현은 플랫폼 기능, 위험, 데이터 민감도 및 허용되는 작업에 따라 달라집니다.
Q: EasyClaw은 Non-Human Identity 관리와 어떤 관련이 있나요?
A: EasyClaw은 IAM 대체 또는 자격 증명 관리 서비스가 아닙니다. 데스크톱 워크플로는 팀이 요청자, 장치, 브라우저 계정, 파일 범위, 작업, 승인, 소유권, 검토 및 폐기를 정의해야 하는 이유를 보여줍니다.
Q: EasyClaw 워크플로는 무엇을 기록해야 합니까?
A: 이름, 목적, 스폰서, 장치, 브라우저 프로필, 허용된 파일 및 앱, 작업, 승인, 대상, 검토 날짜 및 만료 조건을 기록합니다.
Q: 사람의 승인이 필요한 에이전트 작업에는 어떤 것이 있나요?
A: 예로는 외부 커뮤니케이션, 공개 게시, 파일 삭제, 재무 제출, 결제, 고객 기록 변경, 권한 변경, 계약 조치 등이 있습니다.