에이전트가 녹색의 "준비 완료(ready)" 상태를 표시합니다. 검토자(reviewer)는 다듬어진 요약본은 볼 수 있지만, 원래의 요구사항(requirement), 대상 환경(target environment), 해결되지 않은 경고(unresolved warnings), 또는 권장 사항 뒤에 숨겨진 증거(evidence)는 볼 수 없습니다.

승인은 가능하지만, 실질적으로 정보가 없는 상태입니다.

AI 앱 내부의 보안 리뷰(Security review)는 현재 설계의 핫스팟(hotspot)입니다. 다음은 MonkeyCode SaaS에서 평가하기 위한 휴먼 리뷰 프레임워크(human-review framework)입니다. 이는 MonkeyCode의 현재 리뷰 UI에 대한 주장이 아닙니다.

버튼이 아닌 의사결정을 설계하라

요구사항 (requirement) -> 실행 (execution) -> 증거 패키지 (evidence package) -> 휴먼 리뷰 (human review)
                                                                    /       |       \
                                                                승인 (approve)  수정 (revise)  중단 (stop)

"중단(Stop)"은 오류가 아니라 유효한 결과입니다.

다음 리뷰 카드(review card)를 사용하세요:

decision:
  requested_action: "<정확한 다음 작업>"
  owner: "<책임 있는 역할>"
...

이 스키마(schema)는 제안된 산출물(artifact)이며, MonkeyCode의 구현을 나타내는 것이 아닙니다. 에이전트의 해석(interpretation)과 증거(evidence)를 분리하십시오. "세 가지 체크가 통과됨"은 주장(claim)이며, 명명된 체크 항목, 범위(scope), 타임스탬프(timestamps), 그리고 출력값(outputs)이 증거입니다.

중단 조건 (Stop conditions)

실행 후 요구사항이 변경되었을 때, 환경을 알 수 없을 때, 작업 정체성(task identity)이 증거와 일치하지 않을 때, 필수 체크가 실행되지 않았을 때, 경고가 범위(scope)에 영향을 미칠 때, 작업이 권한을 초과할 때, 기록 없이 모델/설정(model/config)이 변경되었을 때, 가역성(reversibility)이 불분명할 때, 또는 승인이 보호된 데이터(protected data)를 노출할 수 있을 때 중단하십시오.

모든 중단 상황은 리뷰를 재개(unblock)하기 위해 무엇이 필요한지를 명시해야 합니다.

연구에 기반한 거절 (Research informed refusal)

세 가지 합성 패키지(synthetic packages)를 테스트합니다:

1. 완전한 증거와 가역적인 작업(reversible action)
2. 하나의 필수 결과가 누락된 설득력 있는 요약
3. 증거는 존재하지만 하나의 경고가 권장 사항과 모순되는 경우

참가자들에게 승인(approve), 수정(revise), 보류(defer), 또는 중단(stop)할 것을 요청한 다음, 결정적인 증거(decisive evidence)를 식별하게 합니다. 성공은 높은 승인율이 아닙니다. 완전한 케이스는 승인하고, 불완전한 케이스는 거절하며, 충돌(conflict)을 설명하는 것이 성공입니다.

원래의 요구사항(requirement), 생성된 권장사항(generated recommendation), 검토자 이의 제기(reviewer objection), 수정된 증거(revised evidence), 그리고 최종 결정(final decision)을 보존하십시오. 상태(Status)는 색상에만 의존해서는 안 됩니다. 키보드 및 스크린 리더 사용자는 구조화된 헤딩(headings), 연결된 경고(linked warnings), 그리고 수정 또는 중단 후의 예측 가능한 포커스(focus)가 필요합니다.

MonkeyCode의 README는 요구사항(requirement), 작업(task), 모델 관리(model management)와 더불어 관리되는 환경(managed environments)을 문서화하고 있으며, 이는 증거의 연속성(evidence continuity)을 평가할 가치가 있게 만듭니다. 합성 작업(synthetic task)으로 SaaS를 시도해 보고, 결정 시점(decision point)에 귀하가 요구하는 증거가 존재하는지 확인해 보십시오.

출처: MonkeyCode repository 및 SaaS.

한계: 이것은 완료된 연구, 보안 평가, 또는 현재 제품 제어 기능에 대한 검증이 아닙니다.

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와 관련이 없습니다. 이 글은 동일한 운영자가 관리하는 계정에서 발행한 여러 독립적이고 유용한 기술 문서 중 하나이며, 독립적인 보증이 아닙니다.

어떤 누락된 증거가 승인을 불가능하게 만들어야 하며, 어떤 추가 필드가 노이즈(noise)만 더할 뿐입니까?