본문으로 건너뛰기

기계 번역입니다. 정식 기준은 영어판이며, 원어민 검수는 아직 완료되지 않았습니다.

Product · Identity & NHI

모든 에이전트에 고유한 ID를 부여하십시오 — 그리고 그렇지 못할 때를 파악하십시오

공유 서비스 계정에서는 "어떤 에이전트가 이 일을 했는가?"라는 질문에 답할 수 없습니다. Olivares는 에이전트를 비인간 ID에 바인딩하고, 에이전트별 전용 NHI를 발급하며, 하나를 공유하는 에이전트를 드러냅니다 — 이것이 액세스를 대략이 아니라 확실하게 귀속하는 차이입니다. 해석할 수 없는 ID를 실제 ID인 것처럼 조용히 취급하는 일은 결코 없습니다. ID 인벤토리와 에이전트 바인딩은 Community이며, 디렉터리 및 명단 커넥터, 에이전트 ID 페더레이션, PIV/CAC는 Business(Identity & Scale)입니다. 에이전트 등록은 Business(Identity & Scale)입니다.

제품 내

ID 및 액세스

예시 데이터. 로그인에 쓰는 사용자 소스, 그룹·역할·로그인 방식이 표시된 모든 사용자, 역할에 매핑된 그룹. 여러 사용자 소스와 그룹-역할 매핑은 Business(Identity & Scale)입니다.

ID 및 액세스
Olivares AI ID 및 액세스: 사용자 소스 5개, 소스·그룹·역할·로그인 방식이 표시된 사용자, 역할에 매핑된 그룹.

거버넌스 대상

공유 계정에서 에이전트별 ID로

ID는 액세스 맵이 귀속을 수행하는 축입니다. 에이전트별 전용 NHI는 "대략"을 "확실하게"로 바꿉니다. 아래의 모든 내용은 어디까지 도달할 수 있는지에 대해 정직합니다.

NHI 바인딩 또는 발급

에이전트를 기존 비인간 ID에 바인딩하거나, 에이전트별 전용 NHI를 발급하십시오. 전용 NHI가 있어야 액세스 맵이 풀에 대해 대략이 아니라 하나의 에이전트에 액세스를 확실하게 귀속할 수 있습니다.

공유 ID 발견 항목

둘 이상의 에이전트가 같은 계정을 사용하면 에이전트별 귀속은 실제로 모호해집니다. Olivares는 이를 발견 항목으로 드러내고 그렇다고 명시합니다 — 차이를 절충하여 어떤 에이전트가 행동했는지 아는 척하지 않습니다.

정직한 미상

Olivares가 해석할 수 없는 ID는 미상으로 표시되고 플래그가 지정됩니다 — 결코 명명된 NHI로 조용히 승격되지 않습니다. ID 신호가 없으면 귀속도 없으며, 이를 분명하게 명시합니다.

동작 방식

ID 레코드와 선언된 관계

NHI를 만들면 Olivares에 에이전트별 ID 레코드가 추가됩니다. 그 레코드만으로 SPIFFE 자격 증명을 발급하지 않습니다. 또한 레코드 생성만으로 페더레이션이 성립하지 않습니다. 이 다이어그램은 선언된 관계를 보여 주며, 확인할 수 없는 ID는 알 수 없음으로 남습니다.

에이전트와 Entra ID, AWS IAM, Google Cloud 사이에 선언된 ID 연결을 보여 주는 개념도. 확인할 수 없는 에이전트는 ID 없음으로 표시됩니다.
선언된 페더레이션 규칙을 설명하는 개념도이며 발급된 자격 증명의 증거가 아닙니다. 확인할 수 없는 ID는 알 수 없음으로 남습니다.

실제로 작동하는 것

ID 레코드, 설정 가능한 추가 인증, 페더레이션 가시성

읽기 전용 WIF 그래프는 구성된 페더레이션 규칙에서 시작합니다. Anthropic WIF 연결과 org:admin OAuth 토큰을 구성하면 Olivares가 규칙을 현재 페더레이션 구성과 비교하고 출처와 차이를 표시합니다. 해당 토큰이 없으면 선언만 표시하며, 실시간 조회가 실패하면 사용 불가로 표시합니다. 모든 ID 공급자와의 페더레이션을 증명하는 것은 아닙니다. 에이전트 ID 페더레이션은 Business(Identity & Scale)입니다.

  • 읽기 전용 수집으로 제공: 명단 커넥터가 하이퍼스케일러의 에이전트 ID 레지스트리 — Microsoft Entra Agent ID, AWS Bedrock AgentCore, Google의 에이전트 레지스트리 — 를 읽습니다. 이들 레지스트리에 대한 회선상 실시간 검증 페더레이션은 로드맵에 있으며, 출시 전에는 주장하지 않습니다.
  • Community에는 활성 OIDC 또는 SAML ID 공급자 하나가 포함됩니다. Business: Identity & Scale은 사용자 및 그룹용 인바운드 SCIM 2.0 서버, 여러 ID 공급자, SSO 정책 강제 적용을 추가합니다.

Business: 디렉터리와 여러 ID 공급자

Community는 하나의 OIDC 또는 SAML 공급자로 로그인합니다. Business는 인바운드 SCIM 2.0 서버, 최대 5개의 활성 ID 공급자, Okta, Entra ID, Keycloak 등에서 디렉터리 가져오기, 부서, 아웃바운드 SCIM 프로비저닝, PIV/CAC 단계 상향 인증을 더합니다.

Business가 더하는 것

Identity & NHI — 질문

Olivares는 오늘 Entra Agent ID, AWS AgentCore 또는 Google Agent Identity와 실시간으로 페더레이션합니까?
두 에이전트가 하나의 서비스 계정을 공유합니다. Olivares는 어느 쪽이 행동했다고 말합니까?

어느 쪽도 확실하게 말하지 않습니다. 공유 ID는 에이전트별 귀속을 실제로 모호하게 만들기에, Olivares는 공유 ID 발견 항목을 제기하고 액세스를 대략으로만 귀속합니다 — 어떤 에이전트가 행동했는지에 대한 확신을 조작하지 않습니다. 에이전트별 전용 NHI를 발급하면 액세스 맵이 해당 에이전트를 확실하게 귀속할 수 있습니다.

권한 로그인에 대해 WebAuthn AAL3 또는 PIV-CAC 단계 상향을 지원합니까?

Olivares는 WebAuthn/FIDO2와 PIV/CAC를 지원합니다. 관리자가 추가 인증 정책을 선택합니다. none(기본값, 추가 인증 절차 없음), totp(인증 앱 코드 또는 지원되는 ID 공급자 MFA), passkey(최근 패스키 또는 PIV 검증)입니다. 긴급 접근과 중요한 승인은 이 정책을 따릅니다. 인증, 권한, 테넌트 격리는 계속 적용됩니다. AAL3는 보증 수준 목표이며 NIST 또는 FIPS 인증이 아닙니다. PIV/CAC와 비상 접근은 Business입니다.

Community와 Business에 SSO와 SCIM 프로비저닝이 포함됩니까?

Community에는 활성 OIDC 또는 SAML ID 공급자 하나가 포함됩니다. Business: Identity & Scale은 사용자 및 그룹용 인바운드 SCIM 2.0 서버, 여러 ID 공급자, SSO 정책 강제 적용을 추가합니다.

귀속할 수 있는 ID를 에이전트에 부여하십시오

Olivares를 자체 인프라에 배포하고, 에이전트별 전용 NHI를 발급하여, 액세스 맵에서 "대략"을 "확실하게"로 바꾸십시오.