거버넌스 및 승인

Olivares AI가 위험 계층, 고위험 작업에 대한 이중 통제, 감사된 비상 유리, 모든 결정의 추가 전용 원장으로 에이전트 접근을 거버넌스하는 방법

소스가 연결되고 접근 맵이 각 에이전트가 읽고 쓸 수 있는 것을 보여주면, 다음 작업은 거버넌스입니다: 누구와 무엇이 행동할 수 있는지 결정하고, 모든 결정을 기록된 사실로 만드는 것입니다. 이 페이지는 승인 워크플로우를 다룹니다 — 위험 계층, 이중 통제, 비상 유리, 이 모든 것이 앵커하는 원장.

거버넌스는 기본적으로 기본 거부입니다. 테넌트에 역할이 없는 주체는 거부됩니다; 암묵적 권한 부여가 없습니다. 제품은 광범위하게 관찰하지만 광범위하게 작동하지 않습니다 — 작업을 거버넌스하는 곳에서는 기본 거부로 수행하며, 무차별 실행기가 아닙니다.

인가 모델

모든 거버넌스 호출은 나머지 API와 동일한 인가 코어를 통해 실행됩니다: RBAC 우선, 단일 테넌트로 범위 지정, 선택적 외부 정책 레이어가 위에.

역할은 계단식입니다 — viewer (읽기), editor (쓰기), admin (테넌트 IAM), owner (테넌트 내 모든 것). 접근 맵 읽기는 의도적으로 최하위 계층이 아닙니다: 모든 에이전트가 접근할 수 있는 것의 맵은 정찰 로드맵이므로, editor 이상에서 부여되고 테넌트 범위이며, 모든 읽기는 원장에 기록됩니다.

선택적 정책 결정 지점(임베디드 Cedar 또는 HTTP를 통한 OPA)이 속성 기반 규칙을 위에 레이어할 수 있습니다. 교집합으로 합성됩니다 — RBAC ∩ 네이티브 ABAC ∩ 외부 PDP — 하나의 불변 조건이 있습니다:

정책 레이어는 접근을 제거만 할 수 있으며, 추가할 수 없습니다. 정책은 RBAC가 허용한 것을 거부할 수 있습니다; RBAC가 거부한 것을 부여할 수 없습니다. 잘못 구성되거나 도달할 수 없는 PDP는 기본 거부(fail closed)하며, 외부 PDP를 비활성화해도 요청이 거버넌스되지 않은 상태로 남지 않습니다 — 네이티브 RBAC와 ABAC가 계속 거버넌스합니다.

위험 계층

거버넌스된 작업은 네 가지 계층 중 하나로 분류됩니다 — low, medium, high, critical — OWASP AI 에이전트 위험 분류법에서 도출. 계층은 작업이 진행되기 전에 필요한 인간 통제 수준을 결정합니다.

계층은 승인 행에 저장되지 않습니다. 모든 결정 시 현재 정책 세트와 내장 기본값에서 재도출되므로, 정책 변경은 즉시 적용되고 오래된 스냅샷이 라이브 분류 아래로 기준을 유지할 수 없습니다(기본 거부).

계층	기본 통제
`low` / `medium`	명시적 정책에 의해서만 할당
`high`	승인 큐에 도달하는 모든 것의 기본 — 한 명의 인간 승인
`critical`	필수 2인 최저 기준 (아래 참조)

내장된 critical 세트는 진정으로 되돌릴 수 없는 것을 다룹니다: 프로덕션 배포 및 폐기, 데이터 삭제 및 소거, 보안 시행 및 킬 스위치 변경, 키 관리 및 교체, NHI 오프보딩. 명시적 risk_tier가 있는 승인 정책은 작업별로 기본값을 올리거나 낮출 수 있습니다 — 운영자의 감사된 발언 — 그러나 critical 작업을 이중 통제 최저 기준 아래로 절대 낮출 수 없습니다.

승인 요청과 이중 통제

승인 요청은 기본 거부이고 시간 제한으로 열립니다: pending으로 시작하고, 만료를 가지며, 충분한 인간이 결정할 때까지 아무것도 인가하지 않습니다. 일치하는 승인 정책이 임계값과 타임아웃에 대해 권위적이므로, 요청자가 자체 기준을 낮출 수 없습니다.

세 가지 불변 조건이 관례가 아닌 서버 측에서 시행됩니다:

직무 분리. 요청자가 자신의 요청을 결정할 수 없습니다. 한 사람이 변경할 수 있는 자격증명 문자열이 아닌 안정적인 사용자 신원에 기반합니다.
인간당 하나의 결정. 고유 인덱스가 중복 결정자 경쟁을 방지합니다; 같은 사람이 임계값에 두 번 계산될 수 없습니다.
만료 바인딩. 만료된 요청은 바인딩 결정을 받을 수 없습니다 — 유효 상태는 모든 결정 시, 정리 작업 유무에 관계없이 재도출됩니다.

critical 작업의 경우 임계값은 두 명의 서로 다른 인간 승인자로 최저 기준이 설정됩니다(NIST SP 800-53 AC-3(2) 이중 인가). 최저 기준은 요청 생성 시(저장된 임계값이 2 미만으로 시작할 수 없음)와 결정 시점(작업이 critical이 되기 전에 생성된 요청도 한 명의 인간으로 통과할 수 없음) 모두에서 시행됩니다. 단일 승인자는 critical 작업을 충족할 수 없습니다.

critical 결정은 추가로 하드웨어 인증 세션을 요구합니다: 결정하는 인간은 새로운 WebAuthn 또는 PIV 단계적 강화(AAL3)가 있어야 합니다. 시스템 토큰은 인간 보증이 없으므로 거부됩니다 — 시스템 토큰은 승인할 수 없습니다.

모든 결정은 요청의 결정 추적에 변경 불가능한 행을 추가하고, 결정, 결과 상태, 결정이 이루어진 위험 계층을 기록하는 원장 이벤트를 기록합니다.

비상 유리

2인 통제에는 두 번째 승인자에게 연락할 수 없는 새벽 3시 사고를 위한 탈출 밸브가 있습니다. admin — 항상 실제 인간, 시스템 토큰 아님 — 이 게이트된 작업이 정족수 없이 진행할 수 있게 하는 시간 제한 비상 부여를 활성화합니다. 경로는 절대 조용하지 않습니다:

활성화는 사유를 요구하고, 동일한 트랜잭션에서 원장에 자체 감사하며, 알림 레일에 critical 발견을 출력합니다.
모든 사용은 부여, 작업, 주체를 명시하는 변경 불가능한 행과 원장 이벤트를 추가합니다. 비상 유리 하에서 진행된 작업은 적절히 승인된 작업과 영구적으로 구별됩니다.
부여는 시간 제한 — 기본 1시간, 하드 캡 24시간. 더 오래 필요한 “비상”은 비상이 아닌 운영 모드이며, 일반 이중 통제를 거쳐야 합니다.
강제 사후 검토. 이전 부여가 검토되지 않은 상태에서 새 부여를 활성화할 수 없으며, 검토는 활성화자와 다른 인간이 수행해야 합니다. 감시를 회피하기 위해 비상을 쌓을 수 없습니다.

비상 유리는 누락된 정족수를 완화합니다; 명시적 인간 거부를 재정의하지 않습니다. 누군가 의도적으로 거부한 요청은 거부 상태를 유지합니다.

기록된 결정 보장

위의 워크플로우 깊이에 관계없이, 거버넌스 결정은 기록된 사실입니다. 변경 작업은 변경과 동일한 트랜잭션에서 실제 행위자와 함께 감사 원장에 추가되며, 민감한 읽기(접근 맵, 원장 자체)는 커밋된 쓰기에서 자체 감사됩니다. 원장이 조용히 잊어버리는 거버넌스되지 않은 변경을 만들 수 없습니다.

원장은 추가 전용, 해시 체인, Ed25519 서명입니다. 각 레코드는 seq, prev_hash, hash, sig를 포함하므로 이력 재작성은 암호학적으로 감지 가능하며, 원장은 PII를 포함하지 않습니다. 감사관이 요구하는 외부, 변경 불가능 사본을 위해 원장은 /v1/audit/export에서 인증된 풀 내보내기로 노출되며, format 값은 cef, leef, syslog, otlp, ocsf입니다. 각 내보낸 레코드는 체인 무결성 필드를 포함하므로, SIEM이나 WORM 스토어가 체인을 오프라인으로 재검증할 수 있습니다 — 분리된 서명은 데이터베이스 전용 침해에 대해 방어하고, 오프박스 사본은 완전히 침해된 호스트에 대해 방어합니다.

정직한 범위

인가 코어, 승인 엔진, 원장은 오늘 실행됩니다. 아직 성숙 중인 것은 더 풍부한 운영자 검토 표면 — 전체 승인 큐 콘솔; 엔드포인트와 서버 측 불변 조건은 출시되었고, 정제된 UI가 앞으로의 경로입니다. 나머지 플랫폼과 마찬가지로 1.0 이전 오픈 코어입니다: 라이브인 것과 설계 방향인 것은 정직함 & 한계를 읽으세요. Olivares AI는 SOC 2, ISO 27001, EU AI Act 제어 방향으로 설계되었으며, 인증된 것이 아닙니다.