검증 서명과 21개 캡슐로 고정된 오픈 에이전트 OS
AOS Community Edition은 검사 가능하고 구성 가능한 에이전트 실행 환경을 제공하며 고정된 21개 캡슐과 서명된 릴리스 검증을 통해 배포 무결성을 유지한다.
TL;DR
AOS Community Edition은 에이전트 네이티브 소프트웨어를 검사 가능하고 구성 가능한 홈 디렉토리 기반 운영 환경에 배치하여 재현 가능한 배포를 실현한다. 설치 과정은 제품 소유의 고정된 21개 캡슐과 핀된 런타임을 배치하고 릴리스마다 Sigstore 번들과 빌드 증거를 포함한 기계 판독 가능한 메타데이터로 출처와 무결성을 검증한다. 명령 경계와 MCP 엣지의 제한적 승인 모델은 실행 루트 변조와 임의 입력 수집을 줄이며 Forge와 meta-harness는 에이전트가 시스템을 검사하고 최소 권한 캡슐을 생성하는 연구 루프를 지원한다.
주요 기능
- 제품 명령과 런타임을 설치하고 관리하는 기능을 제공하며 인스톨러는 제품 명령과 고정된 런타임을 사용자의 홈 디렉토리 아래에 배치한다. 인스톨러는 서명된 메타데이터를 사용하여 설치 아티팩트를 검증하며 재실행 시 조정된 업그레이드를 수행한다. 이 방식은 재현 가능한 설치 상태와 업그레이드 경로를 보장한다.
- 로컬과 제품 소유의 실행 루트에 대해 일관된 명령 경계를 유지하여 init, status, migrate, update, mcp, daemon 등 제품 수준의 작업을 직접 소유한다. 명령 경계는 제품이 특정 루트를 소유할 때 하위 레벨 명령을 대체하는 방식으로 동작하며 릴리스 검증은 런타임의 공개 명령 인벤토리를 비교하는 방식으로 수행된다. 이를 통해 새로운 런타임 동사가 제품 릴리스에 무단으로 포함되는 것을 방지한다.
- MCP 엣지를 통해 클라이언트 폼 기반 승인과 로컬 대체 상호작용을 처리하며 상호작용 모드는 auto, client, native, deny 등을 제공한다. 클라이언트가 제한된 폼을 제공하지 않을 때 로컬 결정 표면이 대체로 동작하며 입력으로는 단일 불리언 또는 고정된 승인 열거형만 허용된다. 이러한 제약은 민감한 문자열이나 임의 필드의 수집을 방지하여 승인 경계를 단순화한다.
- Forge와 meta-harness 같은 도구를 통해 에이전트가 실행 중인 시스템을 검사하고 캡슐 모델을 학습하여 최소 권한 캡슐을 생성하도록 지원한다. Forge는 대체로 에이전트가 실무 중에 유용한 확장을 발견하면 새로운 코드를 생성하도록 유도하며 meta-harness는 에이전트가 자체 작업을 개선하는 연구 루프를 제공한다. 이 도구 체계는 에이전트가 운영 환경을 개선하는 과정에서 검증 가능한 증거와 빌드 과정을 포함한다.
어떻게 동작하는가
AOS는 제품 소유의 홈 디렉토리 하에 고정된 런타임과 캡슐 아티팩트를 배치하고 인스톨러는 해당 아티팩트를 서명과 체크섬으로 검증하여 설치한다. 릴리스 파이프라인은 Sigstore 번들, GitHub 빌드 증거, runtime-compatibility.toml 같은 기계 판독 가능한 메타데이터를 사용하여 게이트 조건을 평가하고 두 가지 게이트가 충족되어야만 태그가 게시된다. MCP 엣지는 클라이언트 제출 폼을 우선 수용하고 그렇지 않을 때 로컬 결정 표면으로 대체하며 입력 형식과 승인값을 엄격히 제한한다.
해결 문제
AOS는 에이전트와 에이전트 네이티브 소프트웨어가 검사 가능하고 구성 가능한 환경에서 실행되도록 하여 신뢰 가능한 운영과 재현 가능한 배포를 제공한다. 제품 수준의 명령 경계를 명확히 하여 런타임과 명령 인벤토리 사이의 무결성 검증을 자동화하며 이를 통해 무단 명령 추가나 실행 루트 변조를 방지한다. 또한 서명된 릴리스 메타데이터와 고정된 캡슐 집합을 통해 공급망 무결성 문제를 완화한다.
지금 주목받는 이유
AOS는 에이전트 네이티브 소프트웨어를 위한 검사 가능하고 구성 가능한 운영 환경이라는 목표를 갖고 있으며 릴리스마다 Sigstore 번들과 빌드 증거를 공개하는 엄격한 공급망 검증 절차를 적용한다. 또한 설치가 제품 소유의 고정된 캡슐 집합과 핀된 런타임을 자동으로 구성하도록 설계되어 재현 가능한 배포를 제공한다. 이러한 공급망 보강과 제품 수준의 소유 모델이 보안과 운영 예측 가능성 측면에서 주목을 받는다.
차별점
- 릴리스마다 Sigstore 번들과 GitHub 빌드 증거를 포함하는 공급망 증빙을 게시하고 runtime-compatibility.toml로 런타임 호환성을 기계적으로 검증한다. 이 체계적 증빙은 단순 서명과 달리 릴리스가 게시되기 전 자동 게이트를 통과해야만 제품 채널에서 유효하게 되는 구조를 만든다. 결과적으로 배포의 출처와 무결성을 재현 가능하고 자동화된 방식으로 확보한다.
- 제품은 정확히 21개의 Community Edition 캡슐을 제품 소유 위치에 고정하여 동일한 아티팩트 집합을 모든 설치에서 제공한다. 고정된 캡슐 집합은 재현 가능한 동작과 검증 가능한 테스트 경로를 만들며 임의의 외부 캡슐 혼입을 방지한다. 이로 인해 운영자가 시스템 상태를 예측 가능하게 유지하면서도 캡슐 단위의 최소 권한 모델을 적용할 수 있다.
- 명령 경계 모델은 제품 소유 루트가 동일한 위치에서 하위 명령을 대체하는 정책을 적용하며 릴리스 검증은 런타임이 제공하는 공개 명령 인벤토리와 제품 분류 루트를 비교한다. 이 접근 방식은 새로운 런타임 동사가 제품 릴리스에 포함되기 전 명시적 상속 또는 소유 결정이 필요하다는 점에서 권한과 변경 관리를 엄격하게 만든다. 따라서 런타임 수준에서의 위협과 무결성 위반을 줄이는 설계적 이점을 제공한다.
사용 사례
- 검증 가능한 에이전트 실행 환경을 필요로 하는 조직에서 AOS를 사용하여 에이전트와 캡슐을 표준화된 방식으로 배포할 수 있다. 고정된 캡슐과 서명된 릴리스 메타데이터가 배포 무결성을 보장하므로 감사 가능성이 중요한 환경에서 유용하다. 또한 런타임 호환성 검증을 통해 환경 간 이식성을 관리할 수 있다.
- 에이전트가 자체적으로 시스템을 검사하고 필요 시 코드를 생성하는 워크플로를 운영하기 위해 Forge와 meta-harness를 활용할 수 있다. 이 패턴은 에이전트가 현장 작업 중에 발견한 기능 갭을 최소 권한 캡슐로 보완하고 검증 루프를 통해 점진적으로 개선하는 데 적합하다. 에이전트 주도 개발과 운영을 통합한 실무 사례에 어울린다.
- 운영자와 대상 환경을 분리하여 인증된 주체가 다른 주체의 상태를 프로비저닝하거나 마이그레이션해야 하는 시나리오에서 AOS의 principal 기반 명령을 활용할 수 있다. 이 방식은 권한 경계를 유지하면서 원격 환경의 상태를 안전하게 가져오거나 초기화하는 절차를 단순화한다. 특히 다중 사용자 또는 멀티테넌시 환경에서 유용한 관리 패턴을 제공한다.
시작하기
공식 인스톨러를 실행하면 제품 명령과 고정된 런타임, 그리고 21개 Community Edition 캡슐이 사용자 홈의 .aos 루트에 설치된다. 설치 후 기본 초기화는 aos init 명령으로 수행하며 오프라인 환경용으로 aos init --offline 플래그를 사용할 수 있다. 인스톨러를 재실행하면 조정된 업그레이드가 수행되며 릴리스 메타데이터와 서명 증빙을 기반으로 실패 봉쇄 방식으로 업데이트가 적용된다.
요구사항
- 설치된 결과로 제품 전용 런타임이 홈 디렉토리 아래에 배치되며 README 기반으로 설치 과정은 Unix 스타일 데몬 신호와 종료 상태를 보존하는 동작을 기대한다.
- 다른 배포를 적용하려면 별도의 standalone astrid 설치와 런타임 홈을 사용해야 하며 Homebrew를 통한 설치는 homebrew 업데이트 경로를 통해 동작한다.
- 릴리스 검증과 업그레이드는 체크섬, Sigstore 번들, GitHub 빌드 증거, runtime-compatibility.toml 같은 메타데이터가 필요하므로 네트워크 접근과 서명 검증 도구를 활용할 수 있는 환경이 요구된다.
8.1k
Stars
14
Forks
+208
Trending
0
조회수
관련 토론
아직 관련 토론이 없습니다.
댓글
댓글을 작성하려면 로그인이 필요합니다.