대상: open-multi-agent/open-multi-agent
이슈: open-multi-agent/open-multi-agent#96
풀 리퀘스트 (Pull request): open-multi-agent/open-multi-agent#377
필드 테스트 상태: 업스트림 (upstream)에 병합됨.

요청된 기능

Open Multi Agent는 이미 프리셋 (presets), 허용 목록 (allowlists), 차단 목록 (denylists)을 통해 도구 액세스 제어 (tool access controls)를 지원했습니다.

이러한 제어 기능은 에이전트가 bash나 파일 시스템 도구와 같은 도구를 사용할 수 있는지 여부를 결정할 수 있었습니다.

부족했던 계층은 더 정밀한 것이었습니다.

도구가 허용되더라도, 검증된 인자 (arguments), 현재 에이전트, 또는 주변 애플리케이션 컨텍스트 (application context)에 따라 특정 호출 (invocation)은 여전히 승인되거나 거부될 필요가 있을 수 있습니다.

따라서 문제는 단순히 다음과 같은 것이 아니었습니다:

“이 에이전트가 이 도구를 사용할 수 있는가?”

그것은 다음과 같았습니다:

“이 특정 호출이 실행되도록 허용되어야 하는가?”

경계 (The boundary)

올바른 결정 지점은 기존의 도구 실행 경로 (tool execution path) 내부에 있었습니다:

입력 검증 (input validation) 이후, 그리고 도구 구현 (tool implementation)이 실행되기 전

이 위치가 중요합니다.

검증 전에는 프레임워크가 아직 평가할 수 있는 신뢰할 수 있는 호출을 가지고 있지 않습니다.

실행이 시작된 후에는 결정이 이미 너무 늦습니다.

이번 기여는 도구 액세스가 구체적인 부수 효과 (side effect)가 되는 시점에 좁은 의미의 거버넌스 훅 (governance hook)을 추가했습니다.

변경 사항

이 PR은 다음과 같은 공개적인 호출별 도구 게이트 (per-call tool gate) API를 추가했습니다:

ToolCallContext
ToolCallDecision
ToolCallGate
...

이제 애플리케이션은 에이전트 및 오케스트레이터 (orchestrator) 설정을 통해 선택적인 onToolCall 핸들러 (handler)를 제공할 수 있습니다.

게이트는 Zod 입력 검증 이후, 그리고 tool.execute() 호출 전의 ToolExecutor 내부에서 실행됩니다.

만약 호출이 거부되면, 도구 구현은 호출되지 않습니다. 대신 프레임워크는 일반적인 에러 ToolResult를 반환합니다.

또한 이 PR은 게이트가 평가되었는지, 어떤 조치가 취해졌는지, 그리고 이유가 제공된 경우 그 이유가 무엇인지를 보여주는 트레이스 메타데이터 (trace metadata)를 추가했습니다.

이것이 광범위한 보안 재작성이 아닌 이유

이번 기여는 완전한 정책 엔진 (policy engine)을 추가한 것이 아닙니다.

이슈에서 논의된 선택적인 셸 위험 분류기 (shell-risk classifier)를 추가하지도 않았습니다.

샌드박싱 (sandboxing)이나 프로세스 격리 (process isolation)를 재설계한 것도 아닙니다.

또한 기존의 허용 목록 (allowlist) 및 차단 목록 (denylist) 모델을 대체하지도 않았습니다.

허용되지 않은 도구들은 새로운 게이트 (gate)에 도달하기 전에 여전히 차단됩니다.

이 패치는 누락되었던 하나의 경계, 즉 검증된 도구 호출 (tool invocation)에 대해 애플리케이션이 최종적으로 정의하는 결정 지점을 추가했습니다.

이것이 중요한 이유

도구 수준의 권한 (tool-level permissions)은 필요하지만, 그것만으로는 항상 충분하지 않습니다.

동일한 셸 (shell) 도구라도 무해한 명령을 실행할 수도 있고, 파괴적인 명령을 실행할 수도 있습니다.

동일한 파일 시스템 (filesystem) 도구라도 프로젝트 파일을 읽을 수도 있고, 디렉토리 전체를 삭제할 수도 있습니다.

위험은 도구의 이름뿐만 아니라, 실제 인자 (arguments)와 컨텍스트 (context)에 따라 결정되는 경우가 많습니다.

호출당 게이트 (per-call gate)는 애플리케이션 개발자가 프레임워크로 하여금 모든 사용 사례에 대해 하나의 보편적인 정책을 정의하도록 강제하지 않고도, 런타임 (runtime)에 해당 결정을 내릴 수 있는 방법을 제공합니다.

이로 인해 이 기능은 승인 흐름 (approval flows), 컨텍스트 기반 제한 (contextual restrictions), 워크스페이스 규칙 (workspace rules), 사용자 정의 위험 검사 (custom risk checks) 및 기타 형태의 애플리케이션 수준 거버넌스 (application-level governance)에 유용하게 사용될 수 있습니다.

Scarab의 해석

이것은 거버넌스 경계 (governance-boundary) 기능이었습니다.

기존의 액세스 제어 (access controls)는 도구의 사용 가능 여부를 관리했습니다.

입력 검증 (input validation)은 호출이 구조적으로 유효한지를 관리했습니다.

새로운 게이트는 검증된 호출이 실행 단계로 넘어갈지 여부를 관리합니다.

이러한 분리는 프레임워크의 책임을 명확하게 유지합니다.

Scarab의 경계는 다음과 같습니다:

도구가 사용 가능하고 그 인자가 유효하다는 이유만으로 도구 호출이 실행되는 부수 효과 (side effect)로 이어져서는 안 됩니다. 애플리케이션은 실행 전에 최종 결정 지점을 가져야 합니다.

검증

해당 기여분은 저장소의 필수 린트 (lint) 및 테스트 체크를 통과했습니다.

추가적인 빌드 (build), 커버리지 (coverage), 스캐폴드 (scaffold) 및 패키지 (package) 체크도 통과했습니다.

이후 풀 리퀘스트 (pull request)는 수락되어 업스트림 (upstream)에 병합되었습니다.

현장 결과

결과:

업스트림에 병합된 에이전트 거버넌스 (agent-governance) 기능.

기여분에서 추가된 사항은 다음과 같습니다:

• 타입이 지정된 호출별 도구 게이트 (typed per-call tool gate)
• 에이전트 (agent) 및 오케스트레이터 (orchestrator) 설정을 통한 통합
• 검증 (validation) 이후 및 실행 (execution) 이전의 평가
• 거부된 호출에 대한 일반적인 결과 처리
• 게이트 결정에 대한 트레이스 메타데이터 (trace metadata)
• 기존의 도구 액세스 모델 유지

이것이 에이전트 보안 전체를 해결한다고 주장하는 것은 아닙니다.

이는 애플리케이션에서 정의한 거버넌스 (governance)가 특정 검증된 도구 호출을 실행할지 여부를 결정할 수 있는, 누락되었던 프레임워크 경계 (framework boundary)를 추가합니다.

공개 주장 (Public claim)

Scarab/SDS는 open-multi-agent/open-multi-agent#96을 위한 경계가 설정된 기능 기여 (feature contribution)의 틀을 잡는 데 도움을 주었습니다.

병합된 PR은 입력 검증 (input validation) 이후 및 도구 실행 (tool execution) 이전에 작동하는 공개적인 호출별 도구 게이트 (per-call tool gate)를 추가합니다. 이를 통해 애플리케이션은 프레임워크의 기존 프리셋 (presets), 허용 목록 (allowlists), 차단 목록 (denylists)을 유지하면서 개별 호출을 승인하거나 거부할 수 있습니다.

그 결과, 검증된 에이전트 의도 (agent intent)와 실제 도구 부작용 (tool side effects) 사이의 좁지만 중요한 거버넌스 경계가 형성되었습니다.

공개 (Disclosure): 이 필드 보고서는 공개된 이슈 (issue) 및 풀 리퀘스트 (pull-request) 기록, 검증 노트, 그리고 병합된 기여 기록을 바탕으로 AI 보조 편집을 통해 작성되었습니다. 기술적 주장과 최종 문구는 사람이 검토하였습니다.