대부분의 코딩 에이전트(coding-agent) 설정은 여전히 에이전트를 프라이빗 터미널 세션 내부의 게스트로 만듭니다. 에이전트는 파일을 수정하고 명령어를 실행할 수 있지만, 팀은 채팅 메시지, Git 히스토리, CI, 그리고 몇 가지 인간의 기억 파편으로부터 무슨 일이 일어났는지 재구성해야 합니다.

Block의 오픈 소스 Buzz는 다른 접근 방식을 취합니다. 인간과 에이전트가 동일한 워크스페이스를 공유하며, 모든 참여자는 워크스페이스 이벤트 로그(event log) 내에서 신원(identity)을 가집니다. 이는 단순히 "채팅에 AI 봇을 추가하는 것"보다 더 흥미로운 엔지니어링적 베팅입니다.

유용한 질문은 Buzz가 당신의 포지(forge)나 채팅 시스템을 대체할 것인가가 아닙니다. 질문은 이것입니다: 에이전트의 신원(identity), 권한(authority), 작업(work), 그리고 리뷰 증거(review evidence)가 일급 객체(first-class objects)가 될 때 무엇이 변하는가?

Buzz가 이동시키려 하는 경계

Buzz는 Nostr을 기반으로 구축된 셀프 호스팅 가능한 워크스페이스입니다. 이 릴레이(relay)는 메시지, 워크플로 단계, 리뷰 승인, Git 활동 및 기타 워크스페이스 작업에 대한 서명된 이벤트(signed events)를 저장합니다. 에이전트는 채널에 참여하고, 에이전트 우선 CLI를 사용하며, ACP 하네스(harnesses)를 통해 연결하고, 리포지토리(repositories) 및 워크플로와 상호작용할 수 있습니다.

Block의 엔지니어링 포스트는 의도된 모델을 명확하게 설명합니다: 인간 소유자가 범위가 지정된 위임(scoped delegation)을 통해 에이전트에게 권한을 부여하는 동안, 에이전트는 자신의 작업에 직접 서명합니다. 권한 부여(Authorization)는 저작권(authorship)과 동일하지 않습니다.

이러한 구분은 중요합니다. 왜냐하면 서비스 계정(service account)은 여러 질문을 하나로 뭉뚱그려 버리기 때문입니다:

• 누가 작업을 실행했는가?
• 어떤 인간이 이를 승인했는가?
• 어떤 도구 또는 런타임(runtime)이 이를 생성했는가?
• 당시 어떤 권한이 부여되었는가?
• 그 이후에 정확히 무엇이 변경되었는가?

신원과 연결된 이벤트 로그(identity-linked event log) 자체가 에이전트를 안전하게 만드는 것은 아닙니다. 하지만 그 질문들에 답하고 테스트하는 것을 더 쉽게 만들어 줍니다.

서명된 신원(signed identity)이 유용한 이유와 해결하지 못하는 것

에이전트가 버그 조사를 요청받은 후 풀 리퀘스트(pull request)를 연다고 가정해 봅시다. 유용한 기록이라면 리뷰어가 다음과 같은 사항을 구분할 수 있어야 합니다:

1. 작업을 위임한 인간 또는 시스템;
2. 작업을 수행한 에이전트 신원 (identity);
3. 범위 내의 저장소 (repository), 브랜치 (branch) 및 파일;
4. 패치 (patch)를 생성한 도구 호출 (tool calls) 및 워크플로 (workflow) 단계;
5. 결과에 첨부된 테스트 및 리뷰 결정.

서명 (signature)은 기록에 대한 귀속 (attribution) 및 변조 탐지 (tamper detection)를 지원할 수 있습니다. 하지만 서명이 패치가 올바르다는 점, 위임된 범위가 적절했다는 점, 또는 해킹된 에이전트가 유효한 권한을 오용하지 않았다는 점을 증명할 수는 없습니다.

그러한 문제들은 여전히 정책 (policy) 및 런타임 (runtime)의 문제입니다. 실질적인 통제 방법은 신원 (identity), 권한 (authority), 그리고 **증거 (evidence)**를 분리하여 유지하는 것입니다:

유효한 서명이 곧 유효한 보안 리뷰를 의미한다고 간주해서는 안 됩니다.

에이전트 참여자를 위한 작은 사전 점검 (preflight) 정책

에이전트를 실제 엔지니어링 채널에 추가하기 전에, 검증하기를 기대하는 계약 (contract)을 작성하십시오. 이는 의도적으로 지루하게 작성되어야 합니다.