4. 등록부터 폐기까지

결론부터

self-service는 심사를 없애는 것이 아니라 위험에 맞는 검사를 자동 경로로 만드는 것이다

이 장에서 처음 나오는 말4개

promotionPromotion: 같은 immutable artifact를 dev에서 staging, production으로 승격하는 과정이다.
attestationAttestation: 어떤 build와 검사가 artifact에 수행됐는지 서명된 증거로 남긴 것이다.
reconciliationReconciliation: 원하는 상태와 provider 실제 상태를 반복 비교해 차이를 줄이는 동작이다.
publication pointerPublication Pointer: 사용자가 호출할 때 선택할 준비된 Deployment를 가리키는 control-plane 참조다.

세 lifecycle 전체

세 상태를 한 그림에 섞으면 APPROVED, READY, AVAILABLE을 같은 종류의 상태로 오해하기 쉽다. 다음처럼 각 lifecycle을 독립된 상태도로 읽고, 앞 lifecycle의 성공 상태는 다음 lifecycle을 시작할 수 있는 gate로만 사용한다.

AgentVersion — 승인

AgentVersion이 draft에서 자동 검사와 승인을 거쳐 approved 또는 rejected가 되고, approved version이 최종적으로 retired되는 상태 전이

Deployment — 실행

Deployment가 provisioning을 거쳐 ready가 되고, 실패와 성능 저하를 복구하거나 drain 뒤 stopped되는 상태 전이

Publication — 공개

Publication이 closed에서 ACL과 route 공개를 거쳐 available이 되고, 일시 중지 또는 영구 폐기되는 상태 전이

한 AgentVersion은 온프렘·AWS 또는 blue·green처럼 여러 Deployment를 가질 수 있다. 하나가 READY이고 다른 하나가 FAILED여도 version은 여전히 APPROVED다. Publication은 준비된 Deployment 하나와 route weight를 가리키므로, provider health가 초록이어도 ACL·audit sink·synthetic invoke가 함께 검증되지 않으면 AVAILABLE로 전이하지 않는다.

lifecycle	상태의 단일 원본	답하는 질문
AgentVersion	portal approval DB	이 불변 구성을 배포해도 되는가
Deployment	portal desired state + provider observed state	이 target의 복사본이 실제로 준비됐는가
Publication	portal catalog·route DB	지금 누가 어느 Deployment를 호출하는가

Creator가 제출하는 것

구성형 Agent는 portal form이나 Git의 선언 파일을 제출한다. 코드형 Agent는 source repository와 build recipe를 제출하고 platform CI가 target capability에 맞는 immutable artifact를 만든다. portable production 기본은 OCI digest이고 AgentCore CodeZip은 명시적 extension이다. production에서 사용자가 임의 registry URL이나 mutable tag를 직접 입력하게 하지 않는다.

사용자가 만든 MCP도 같은 제출·검사·승인 뼈대를 쓰되 AgentVersion에 종속시키지 않는다. MCP source·image 또는 remote endpoint를 독립된 ToolVersion으로 받고, discovery schema와 tool publication을 추가로 검증한다. 구체적인 분기는 사용자 MCP를 플랫폼에 올리기에서 다룬다.

공통 제출물은 다음이다.

metadata와 owner
framework와 protocol contract
model·knowledge·tool·data classification 선언
KnowledgeVersion·ToolVersion binding과 effective configuration hash
CPU·memory·architecture hint
test case와 expected behavior
target 제약: restricted only, AWS allowed 등

자동 검사는 위험별로 나눈다

검사	구성형	코드형
schema와 필수 metadata	✓	✓
prompt·knowledge source revision·data 등급	✓	✓
knowledge ACL·index digest·삭제 lineage	✓	✓
tool scope와 human approval	✓	✓
dependency·container 취약점		✓
SBOM·image signature·digest	runtime image 기준	✓
non-root·read-only FS·seccomp	공통 runtime preset	✓
egress destination	tool allowlist	image 실행 검증 포함
malicious behavior·resource exhaustion	제한적	sandbox dynamic test

검사를 통과했다는 사실은 안전의 보증이 아니라 배포 조건이다. runtime에서도 resource limit, network policy, tool policy를 다시 강제해야 한다.

승인과 소유권

승인은 한 줄의 관리자 클릭이 아니라 책임 분리다.

업무 owner: 이 Agent가 해결할 문제와 사용자 범위를 승인
data owner: knowledge와 tool이 접근하는 data 등급 승인
platform/security: code·egress·credential 방식 승인
creator: 기능과 test case 책임

모든 Agent가 네 번의 수동 승인을 받을 필요는 없다. read-only 구성형 Agent는 policy가 자동 승인하고, write tool이나 code형 Agent만 필요한 owner에게 보낸다.

배포와 공개

adapter는 승인된 digest와 target만 받아 배포한다. 배포 후 다음 synthetic path를 확인한다.

endpoint health
인증 없는 호출 거부
허용 principal의 기본 invoke
금지 principal의 invoke 거부
허용·금지 tool action 각각 한 번
trace·audit·cost record 도착

새 version은 바로 전체 전환하지 않는다. backend가 traffic split을 지원하면 canary를 사용하고, 아니면 portal route에서 소수 test principal만 새 deployment로 보낸다.

여기에는 서로 다른 복구 동작 두 개가 있다.

publication rollback — platform core가 active pointer를 직전 READY Deployment로 되돌린다. image를 다시 build하지 않으며 provider adapter operation도 아니다.
deployment rollback·repair — provider resource 자체가 잘못됐을 때 adapter가 이전 spec을 별도 Deployment로 다시 reconcile하거나 provider-native traffic weight를 조정한다. 결과가 READY가 된 뒤에만 publication 후보가 된다.

변경과 drift

runtime console이나 kubectl로 긴급 수정할 수는 있지만 control plane은 drift를 발견해야 한다. 처리 정책은 다음 셋 중 하나를 resource별로 정한다.

되돌리기: Git/portal desired state로 자동 복원
흡수하기: 승인 workflow를 통해 새 version으로 가져오기
격리하기: 보안 관련 drift면 publication을 중지

provider의 일시적 조회 실패를 DELETED로 오판하지 않도록 UNKNOWN 상태와 grace period를 둔다.

중지와 폐기

Publication의 SUSPENDED는 route와 invoke를 즉시 막되 Deployment를 조사할 수 있게 남긴다. Publication RETIRED는 새 conversation을 받지 않는 종결 상태다. AgentVersion RETIRED는 신규 Deployment 후보에서 제외한다. Deployment는 drain 뒤 STOPPED로 전이하고 retention 기간 뒤 adapter가 runtime resource를 제거한다. 세 상태를 한 필드로 덮어쓰지 않으며 DB record와 audit log는 보존 정책에 따라 남긴다.

owner 퇴사, 취약한 dependency, 오래 사용되지 않은 Agent, 만료된 data approval은 자동 review trigger다.

4장 요약

immutable artifact 하나를 검사하고 environment 사이에서 승격한다.
구성형과 코드형은 자동 검사와 승인 강도가 다르다.
AgentVersion 승인, Deployment 준비, Publication 공개는 서로 다른 상태 머신이다.
publication rollback과 provider deployment repair를 별도 연산으로 둔다.

5. 권한은 세 번 검사한다배포 관리, Agent 호출, tool action의 서로 다른 authorization 경계를 설계한다.