FROST 내 AI 에이전트 간 규칙 및 메모리 상속 테스트 — Agent Lab Journal

  Agent Lab Journal

    Guides
...

실습형 랩 · 멀티 에이전트 시스템 (Multi-agent systems)

FROST 내 AI 에이전트 간 규칙 및 메모리 상속 테스트

작업을 위임하는 것이 부모에 대한 제어권까지 위임해서는 안 됩니다. 이 랩에서는 FROST 에이전트 계층 구조와 그 저장소 및 도구(tools) 사이에 결정론적 거버넌스 경계(deterministic governance boundary)를 설정합니다. 후손(Descendants)은 명시적으로 상속된 메모리를 읽을 수는 있지만, 조상(ancestor)이 소유한 데이터를 수정하거나, 스스로 추가적인 권한(capabilities)을 부여하거나, 유효하지 않은 운영 절차(operating procedure)를 시작할 수는 없습니다.

      Advanced
      60 minutes
      Result: working prototype and reproducible tests

구축하게 될 내용

이 프로토타입에서 AI 에이전트는 식별자(identifier), 선택적 부모(optional parent), 개인 메모리 범위(private memory scope), 그리고 선언된 권한 세트(declared capability set)를 가진 주체(principal)입니다. FROST는 에이전트를 생성하고 조정하는 책임을 유지합니다. 별도의 거버넌스 구성 요소(governance component)가 저장소 또는 도구 실행 전에 최종 승인(authorization) 결정을 내립니다.

완성된 프로토타입은 네 가지 속성을 입증합니다:

• 자식(child)은 로컬 값이 없을 때 조상으로부터 가시적인 값을 해결(resolve)할 수 있습니다.

• 자식은 자신의 메모리를 생성하고 업데이트할 수 있지만, 조상이 소유한 기록을 변경하거나 삭제할 수 없습니다.

• 후손은 조상이 전달하지 않은 권한을 획득할 수 없습니다.

• 유효하지 않은 표준 운영 절차(SOP, Standard Operating Procedure)는 첫 번째 단계가 실행되기 전에 완전히 거부됩니다.

테스트는 저장된 상태, 승인 결정, 그리고 실행된 부수 효과(side effects)를 검사합니다. 테스트는 에이전트의 최종 메시지를 제어가 작동했다는 증거로 취급하지 않습니다.

어댑터 경계(Adapter boundary): FROST 설치 환경에 따라 서로 다른 에이전트 생성자(constructors), 훅(hooks), 프로세스 형식이 노출될 수 있습니다. 따라서 이 랩은 프레임워크 특정적인 배선(wiring)을 정책 코어(policy core) 외부에 유지합니다. 에이전트 등록 및 도구 디스패치(tool dispatch)를 귀하의 설치 환경에 맞게 조정하되, 승인 계약(authorization contracts)과 테스트는 그대로 유지하십시오.

구체적인 사례: 보고서 생성 계층 구조

report_manager라는 이름의 루트 에이전트(root agent)가 프로젝트 정책(project policy)을 소유하며, researcher에게 조사를 위임합니다. researcher는 formatter라는 더 좁은 범위의 자식(child)을 생성합니다.

manager는 다음 기록들을 소유합니다:

• project.client_region = "EU", 모든 후손에게 공개됨;
• policy.external_upload = false, 모든 후손에게 공개됨;
• report.retention_days = 30, 모든 후손에게 공개되지만 소유자만 수정 가능;
• credentials.storage_token, manager 전용(private).

researcher는 지역(region)과 보존 기간(retention period)을 읽을 수 있고, 자체 노트를 작성하며, 문서를 요약하고, 내부 아티팩트(artifact)를 저장할 수 있습니다. 적대적 시나리오(hostile scenario)는 researcher에게 manager의 보존 설정을 변경하고, 소스 문서를 외부 서비스로 업로드하는 표준 운영 절차(SOP)를 실행하도록 요구합니다.

시스템 프롬프트(system prompt)에만 작성된 규칙은 모델의 준수 여부를 테스트하는 것이지, 액세스 제어(access control)를 테스트하는 것이 아닙니다. 더 강력한 불변량(invariant)은 모델의 설명이나 의도와 관계없이, 금지된 작업이 저장소나 도구(tool)에 절대 도달하지 않는다는 것입니다.

코드를 작성하기 전에 불변량 정의하기

프레임워크 동작, 모델 동작, 보안 동작이 서로 뒤섞이지 않도록 명시적인 불변량(invariants)을 사용하십시오:

• 출처(Provenance)가 보존됩니다. 결정된 값(resolved value)은 항상 원래의 소유자를 유지합니다.
• 가시성(Visibility)이 가변성(mutability)을 의미하지는 않습니다. 조상 기록을 읽는다고 해서 이를 업데이트할 수 있는 권한이 생성되지는 않습니다.
• 권한(Capabilities)은 계층 구조를 좁혀 나갑니다. 자식의 유효 권한 집합(effective set)은 부모의 유효 권한 집합보다 결코 넓을 수 없습니다.
• 승인(Authorization)이 실행에 앞섭니다. 모든 SOP 단계는 핸들러(handler)가 실행되기 전에 검증됩니다.
• 알 수 없는 작업은 실패(fail closed)합니다. 익숙하지 않은 단계 유형을 추가한다고 해서 암시적인 권한이 생성되지 않습니다.
• 거부된 작업은 증거를 남깁니다. 결정 로그(decision log)는 주체(subject), 작업(operation), 리소스(resource), 정책 버전(policy version), 그리고 이유(reason)를 기록합니다.

이러한 불변량은 언어 모델(language-model)의 품질과 무관합니다. 더 강력한 모델은 더 나은 계획을 제안할 수 있지만, 정책 경계(policy boundary)를 우회하는 특별한 경로를 부여받지는 않습니다.

병합된 딕셔너리가 아닌 레코드로서의 모델 메모리 (Model memory as records, not a merged dictionary)

에이전트 메모리는 하나의 재귀적으로 병합된 딕셔너리 (merged dictionary)로 안전하게 표현될 수 없습니다. 병합은 출처 (provenance)를 제거하며, 출처가 없으면 시스템은 누가 값을 소유하고 있는지 또는 누가 이를 수정할 수 있는지 증명할 수 없습니다.

저장된 각 레코드는 최소한 다음을 포함해야 합니다:

{
  "namespace": "report",
  "key": "retention_days",
...

읽기와 쓰기는 의도적으로 서로 다른 주소 지정 규칙 (addressing rules)을 사용합니다:

• 읽기 (Read)는 현재 에이전트에서 루트 (root)를 향해 탐색하며 가장 가까운 가시적 레코드를 반환합니다.

• 쓰기 (Write)는 정확한 소유자 범위 (owner scope)를 지정하며, 행위자 (actor)가 해당 소유자일 때만 허용됩니다.

이러한 구분은 흔히 발생하는 버그를 방지합니다: 자식 에이전트가 부모의 값을 확인(resolve)한 후, 업데이트된 값을 실수로 동일한 부모 레코드에 다시 쓰는 경우입니다.

유효한 권한 (Effective capabilities)은 교집합으로 계산됩니다:

effective(child) =
    environment_capabilities
    ∩ declared(root)
...

이는 최소 권한 원칙 (principle of least privilege)을 적용합니다. 보고서 (report)를 위임한다고 해서 매니저가 사용할 수 있는 모든 도구 (tool)가 자동으로 위임되는 것은 아닙니다.

위협 모델 (Threat model)

          위험 (Risk)
          예시 (Example)
          통제 (Control)
...

프로토타입은 프로세스, 정책 코드 또는 메모리 데이터베이스를 직접 편집할 수 있는 호스트 관리자 (host administrator)로부터는 방어하지 못합니다. 이를 위해서는 프로세스 격리 (process isolation), 보호된 정책 배포 (protected policy deployment), 그리고 별도로 신뢰할 수 있는 영속성 계층 (persistence layer)이 필요합니다.

1단계: 프로젝트 생성 (Step 1: create the project)

Python 3.11 이상 버전과 pytest가 필요합니다. 정책 코어 (policy core)는 모델 API 키나 외부 서비스가 필요하지 않습니다.

mkdir frost-governance-lab
cd frost-governance-lab

...

Windows PowerShell에서는 다음 명령으로 환경을 활성화합니다:

.\.venv\Scripts\Activate.ps1

결과적인 레이아웃은 다음과 같습니다:

frost-governance-lab/
├── frost_governance/
│   ├── __init__.py
...

2단계: 신뢰할 수 있는 거버넌스 계층 구현 (Step 2: implement the trusted governance layer)

다음 내용을 frost_governance/core.py로 저장하세요. 이 코드는 에이전트의 추론 (reasoning)을 모방하지 않습니다. 이는 FROST와 실제 메모리(memory) 또는 도구 핸들러 (tool handlers) 사이에 위치하는 실행 가능한 권한 경계 (authorization boundary)입니다.

from __future__ import annotations

from dataclasses import dataclass, field
...

validate_sop는 명령을 전달 (dispatch)하기 전에 모든 단계를 검증합니다. 만약 최종 단계가 금지되어 있다면, 시스템은 그 이전의 허용된 단계들도 실행하지 않습니다. KNOWN_ACTIONS는 허용 목록 (allowlist)입니다. 익숙하지 않은 동작은 그 이름이 무해해 보이더라도 거부됩니다.

핸들러 가용성 (Handler availability)은 권한 부여 (authorization) 이후, 그러나 실행 (execution) 전 단계에서 확인됩니다. 이를 통해 특정 로컬 어댑터 (local adapter)가 누락되어 완료할 수 없는 프로세스를 시작하는 것을 방지합니다.

3단계: 재현 가능한 테스트 추가 (Step 3: add reproducible tests)

다음 내용을 tests/test_governance.py로 저장하세요. 플레이스홀더 (placeholder) 토큰은 합성 테스트 데이터 (synthetic test data)입니다. 실제 비밀 값 (secret)을 삽입하지 마세요.

import pytest

from frost_governance.core import (
    AccessDenied,
    Agent,
    Governance,
    MemoryRecord,
    RevisionConflict,
    SOP,
    SOPStep,
)

ALL = frozenset({
    "memory.read",
    "memory.write",
    "document.summarize",
    "artifact.save",
    "external.upload",
})

@pytest.fixture
de