Trust in Depth: Giving agents more autonomy without losing control

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 에이전트의 자율성을 안전하게 확대하기 위해 Scope·Know·Bound·Observe의 네 계층과 자동 추론을 결합하는 Trust in Depth를 제시한다.

📌 핵심 요약

• 에이전트는 같은 작업에서도 서로 다른 경로를 선택할 수 있어 기존 테스트만으로 다음 실행을 보장하기 어렵고, 모든 행동에 대한 사람의 승인은 규모가 커질수록 검토 피로와 병목을 만든다. AWS는 검증 가능한 행동은 자율적으로 수행하게 하고 판단이 필요한 결정은 사람에게 남기자고 제안한다.
• Trust in Depth는 실행 전 Scope, 배포 시 Know, 실행 중 Bound, 실행 후 Observe로 구성된다. 자동 추론은 정확하게 기술된 시스템과 가정이 포괄하는 모든 경로에서 규칙의 성립 여부를 검증하지만, 친절한 말투처럼 맥락에 따른 판단까지 증명하지는 못한다.
• AWS는 자동 추론을 10년 넘게 운영 환경에 적용했으며, 초당 21억 건이 넘는 요청을 처리하는 IAM과 AWS Nitro Hypervisor, Amazon S3 Block Public Access, VPC Reachability Analyzer를 사례로 든다. 에이전트 구축에서는 Kiro가 요구사항의 모순·모호성·누락을 드러내고, Amazon Bedrock AgentCore의 정책은 과도한 접근이나 충족 불가능한 규칙을 사전에 검사한다.
• AWS Agent Registry는 조직의 에이전트·MCP 서버·도구·스킬을 승인된 목록으로 관리하고, AgentCore는 각 에이전트의 신원을 요청마다 확인한다. Policy in AgentCore는 AgentCore Gateway를 거치는 모든 도구 호출에 정책을 적용하며, temporal policies는 세션에서 앞서 발생한 일을 반영해 권한을 조정한다.
• Amazon Bedrock Guardrails와 Strands Box는 각각 콘텐츠와 실행 환경의 경계를 통제하고, Amazon CloudWatch Omni는 실행 추적과 정확성·충실성·도구 선택 평가를 제공한다. 원문은 Sam의 퇴사 처리에서 로그인 차단이 사서함 전환·공유보다 먼저 이뤄져야 하고 이메일 라이선스 변경 전에 법적 보존 조치를 확인해야 한다는 사례를 제시하지만, 해당 설명 도중에 끊긴다.

🧩 주요 포인트

1. 요구사항과 가정의 정밀성 → 자동 추론으로 입증할 수 있는 범위와 안전하게 부여할 수 있는 자율성의 범위를 결정하므로, Scope 단계의 업무·접근 권한·사람의 판단 경계 설정이 기반이 된다.
2. 신원 확인과 에이전트 외부의 정책 집행 → 행동의 책임 주체를 추적하면서 에이전트의 오류나 프롬프트 인젝션에도 경계를 유지하도록 설계하며, 개별 도구 호출뿐 아니라 행동 순서와 세션 이력도 통제 대상으로 삼는다.
3. 운영 상태와 작업 성공의 구분 → 오류 없는 실행만으로 올바른 결과를 판단할 수 없으므로, Observe에서 맥락·도구 호출·정책 결정·결과를 재구성하고 실패 추적을 수정 검증에 활용해야 한다.

🧠 상세 정리

1. 자율성 확대와 전면 승인 방식의 한계

글은 기업 리더들이 에이전트에 더 많은 일을 맡기고 싶어 하면서도, 언제나 올바르게 수행하리라고 신뢰하지는 못한다는 문제에서 출발한다. 에이전트의 유용성을 만드는 창의성과 자율성은 개발자가 미리 작성하지 않은 도구 선택과 단계 조합을 가능하게 하므로, 같은 작업을 반복해도 다른 경로를 택할 수 있다. 모든 행동을 사람이 승인하는 방식은 작은 규모에서는 작동하지만, 업무가 늘어나면 승인이 쌓이고 검토 피로 때문에 중요한 문제를 놓칠 수 있다. AWS가 제안하는 방향은 행동을 검증할 수 있는 경우에는 자율적으로 실행하도록 하고, 사람의 판단이 필요한 결정에 검토를 집중하는 것이다. 특히 금융 거래처럼 잘못된 행동의 피해가 큰 업무에서는, 사람이 지켜보지 않아도 설정한 한계를 지킨다는 신뢰를 별도로 구축해야 한다고 주장한다.

2. 네 계층과 자동 추론이 제공하는 조건부 증명

Trust in Depth는 실행 전에 업무와 금지 사항을 정하는 Scope, 배포 시 승인 주체와 신원을 확인하는 Know, 실행 중 행동의 한계를 지키는 Bound, 실행 후 행동과 이유를 재구성하는 Observe로 신뢰를 쌓는다. AWS는 이를 20년간 활용된 Defense in Depth의 계층적 원리를 새로운 목적에 적용한 것으로 설명하며, 여러 독립 계층이 서로를 보강해 안전하게 허용할 수 있는 행동을 넓힌다고 본다. 자동 추론은 예상한 사례를 확인하는 테스트를 넘어, 정확한 시스템 기술과 가정이 포괄하는 모든 경로에서 규칙이 성립함을 입증하거나 실패하는 구체적 사례를 찾는 기술로 제시된다. 다만 증명의 타당성은 규칙과 가정의 품질에 달려 있고, 관리자만 접근을 승인한다는 조건과 달리 친절한 말투 같은 기대는 같은 방식으로 증명할 수 없다. AWS는 자동 추론을 10년 넘게 운영 환경에 적용했으며, 초당 21억 건이 넘는 요청을 처리하는 IAM과 AWS Nitro Hypervisor, Amazon S3 Block Public Access, VPC Reachability Analyzer를 근거로 든다.

3. Scope: 의도를 구체적인 업무와 권한으로 전환

Scope 단계에서는 에이전트가 책임질 업무, 접근할 도구·데이터·서비스, 준수할 규칙, 사람이 결정할 사안을 실행 전에 정의하며, AWS는 이 단계에 가장 많은 노력을 투자해야 한다고 강조한다. 고객 문제를 해결하라는 목표만으로는 볼 수 있는 정보와 허용 행동, 멈추고 질문할 시점이 정해지지 않으며, 한 작업을 위해 부여한 관리자 역할이 환경 전반의 권한까지 함께 넘길 수 있다. Kiro는 상위 의도를 구조화된 명세 중심 요구사항으로 바꾸고, 코드 작성 전에 자동 추론으로 모순·모호성·누락을 드러내며, 다양한 입력에서 구현을 확인하는 속성 기반 테스트도 도출한다. Strands는 모델·지시·도구를 정의하는 오픈소스 도구 모음과 운영을 위한 관리형 런타임을 제공하지만, 어떤 프레임워크를 쓰든 업무와 경계를 정하는 책임은 같다고 설명한다. Amazon Bedrock AgentCore의 정책 기능은 자연어로 표현한 도구·API·데이터 접근 규칙에 과도한 권한이나 충족 불가능한 모순이 있는지 적용 전에 검사하며, 정책의 정밀성이 이후 자율성 확대의 기반이 된다.

4. Know: 조직의 에이전트와 권한 주체 식별

Know 단계는 조직을 대신해 어떤 에이전트가 활동하고 있으며 누구의 권한으로 행동하는지를 파악하는 데 초점을 둔다. 글은 팀들이 추적 속도보다 빠르게 에이전트를 만들고 있고, 존재를 모르는 에이전트는 통제할 수도 없으므로 각 에이전트에 고유한 신원을 부여하고 행동할 때마다 확인해야 한다고 주장한다. AWS Agent Registry는 에이전트, Model Context Protocol(MCP) 서버, 도구, 스킬을 관리되는 승인 목록으로 제공하며, 관리자는 승인 절차로 검색 가능 여부를 통제하고 보안·규정 준수·품질 기준에 미달하는 항목을 제거할 수 있다. 사람과 에이전트는 이 목록에서 기존 자원을 찾아 재사용할 수 있지만, 목록만으로 실행 중 행동의 책임까지 확인할 수 있는 것은 아니다. 이를 이어받아 AgentCore가 에이전트마다 신원을 발급하고 요청마다 확인함으로써, 문제가 발생했을 때 특정 행동을 수행한 에이전트와 그 권한의 근거를 추적하도록 한다.

5. Bound: 에이전트 외부에서 행동과 순서 통제

Bound 단계의 출발점은 승인한 행동 10개를 수행했더라도 그 조합이 의도하지 않은 결과를 만들 수 있다는 점이며, 개별 행동의 허용 여부만으로 전체 업무의 적절성을 보장할 수 없다는 것이다. 경계가 느슨하면 민감한 정보 노출이나 금지된 행동 조합을 막지 못하고, 지나치게 엄격하면 업무 자체가 불가능해지므로 에이전트의 작업 경로 선택과 한계 집행을 분리해야 한다. Policy in AgentCore는 에이전트·도구·모델의 보안 진입점인 AgentCore Gateway를 거치는 모든 도구 호출에 Scope에서 정의한 정책을 적용한다. AWS는 통제가 에이전트의 추론 외부에 있기 때문에 에이전트에 버그가 있거나 조작 또는 프롬프트 인젝션을 당해도 자신이 운영하지 않는 통제를 끌 수 없다고 설명한다. 또한 temporal policies는 세션에서 이미 발생한 일을 평가해 작업 진행에 따라 권한을 조정하므로, 행동 전체의 순서와 변화하는 위험을 통제에 반영한다.

6. 콘텐츠와 실행 환경을 보완하는 경계

행동에 대한 정책 집행과 함께, 글은 에이전트가 말하고 전달받는 내용 및 실제로 접근할 수 있는 실행 자원에도 별도의 경계를 둔다. Amazon Bedrock Guardrails는 유해하거나 주제에서 벗어난 콘텐츠를 걸러내고 민감한 데이터를 가리며, Automated Reasoning checks는 응답이 모델의 해석이 아니라 설정된 정책과 일치하는지 증명하는 기능으로 소개된다. 실행 환경에서는 접근 가능한 파일, 호출할 수 있는 서비스, 사용할 수 있는 자격 증명이 통제 대상이며, 오픈소스 샌드박스인 Strands Box가 에이전트 지시문 외부에서 그 경계를 집행한다. AWS는 개발자의 첫 로컬 세션부터 운영 환경까지 같은 경계를 유지해, 에이전트가 실제 도구와 데이터를 사용하면서도 허용된 자원에만 접근하도록 한다고 설명한다. 다만 정밀한 증명이 적용되지 않는 기대에는 접근과 행동 제한, 동작 평가, 실제 모호성에 대한 사람의 판단을 결합하고, 규칙 집행과 작업 신뢰성 및 실패 대응이 확인되는 만큼 자율성을 확대해야 한다.

7. Observe: 정상 실행과 올바른 결과 구분

Scope·Know·Bound를 갖추더라도 에이전트는 밀리초 단위로 오류 없이 응답하면서 잘못된 일을 할 수 있고, 잘못된 정보 검색이나 도구 선택 또는 예상 밖 경로는 일반적인 시스템 상태 지표만으로 드러나지 않을 수 있다. 따라서 Observe에서는 에이전트가 받은 맥락, 호출한 도구, 적용된 정책 결정, 최종 결과를 재구성해 시스템의 정상 작동과 작업의 성공을 구분해야 한다. 배포 전 테스트는 여전히 필수이며, 운영 환경은 실제 조건에서의 행동을 보여 주는 추가 근거와 조사·개입·개선에 필요한 정보를 제공한다. Amazon CloudWatch Omni는 모든 실행 추적을 수집하고 모델 호출부터 도구 실행까지의 단계를 시간 순서로 보여 주어 팀이 조사할 수 있게 한다. 내장 평가기는 정확성·충실성·적절한 도구 선택처럼 일반 모니터링이 놓치는 품질을 평가하고, 실패한 실행 추적은 수정 사항을 검증하는 데이터로 활용되므로 운영과 개선이 같은 근거를 공유한다.

8. Sam의 퇴사 처리 사례와 제공된 원문의 한계

마지막 사례에서 관리자는 헬프데스크 에이전트에게 퇴사하는 계정 관리 담당자 Sam의 접근 권한을 제거하고, 사서함을 후임자에게 넘기며, 더 이상 필요하지 않은 라이선스를 회수하도록 요청한다. 그러나 Sam의 이메일에 고객 분쟁에 필요한 증거가 포함될 수 있어, 순서를 잘못 정하면 퇴사 후에도 접근 권한이 남거나 증거가 위험해질 수 있다. 이 업무에는 보안·메시징·법무·재무의 요구가 함께 적용되며, 전체 작업 흐름이 미리 작성되어 있지 않더라도 에이전트는 그 조건들을 따라야 한다. 제시된 첫 번째 규칙은 Sam의 로그인을 차단한 뒤에 사서함을 전환하고 후임자와 공유해야 한다는 것이며, 두 번째 규칙은 이메일 라이선스를 변경하기 전에 법적 보존 조치의 존재를 확인해야 한다는 것이다. 제공된 원문은 법적 보존 조치를 설명하는 문장 중간에서 끝나므로, 이후의 실행 과정이나 통제 결과, 사례의 최종 결론은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Trust in Depth에서 자율성의 확대는 통제의 완화보다 통제의 검증 가능성에 연결된다. 특히 Scope에서 요구사항과 가정을 정밀하게 표현할수록 자동 추론으로 확인할 수 있는 범위가 넓어진다는 논리다.
• 에이전트의 신원, 개별 도구 호출, 세션의 행동 순서는 서로 다른 통제 대상이다. AgentCore의 신원 확인과 정책 집행, temporal policies를 함께 설명하는 이유는 허용된 행동의 조합도 금지된 결과를 만들 수 있기 때문이다.
• Observe는 실행 기록을 보관하는 데서 끝나지 않고 작업 품질을 평가하고 수정의 효과를 확인하는 근거를 제공한다. 이 접근은 오류가 없다는 운영 신호와 실제 업무가 올바르게 끝났다는 판단을 구분한다.

✅ 액션 아이템

• Scope에서 업무·접근 권한·사람의 판단 경계를 구체화하고, 자동 추론의 검증 대상이 되는 규칙과 가정 명확화.
• AgentCore의 요청별 신원 확인과 AgentCore Gateway의 도구 호출 정책 집행, temporal policies의 행동 순서 반영 여부 검토.
• Observe에서 맥락·도구 호출·정책 결정·결과를 재구성하고, 실패 추적을 수정 검증에 활용.

❓ 열린 질문

• Scope의 요구사항과 가정은 어느 범위까지 정밀하게 표현되어 자동 추론으로 검증할 수 있는가?
• AgentCore Gateway의 도구 호출 정책과 temporal policies는 허용된 행동의 조합이 금지된 결과를 만드는 경우를 어떻게 통제하는가?
• Amazon CloudWatch Omni의 실행 추적과 정확성·충실성·도구 선택 평가는 오류 없는 실행과 실제 작업 성공을 구분하기에 충분한가?