Unlock Agent Autonomy: The Runtime for AI-Native Systems — Tushar Jain, Docker

한 줄 핵심

에이전트 자율성을 실제로 확장하려면 더 똑똑한 모델보다, 모델·하네스·환경을 가로질러 안전하게 권한을 통제하는 런타임이 핵심이다.

시간별 요약

1. 0:00
   지능이 병목이 아니라 안전이 병목이다 에이전트는 이미 강력해졌고, 다음 과제는 더 높은 지능이 아니라 안전하게 더 많은 권한과 자율성을 주는 방법이다. 개인용 야간 분석 에이전트가 예고 없이 PR을 올려버린 사례처럼, 에이전트는 “도움이 되려는” 과정에서 의도와 다르게 행동할 수 있다.
2. 2:08
   스스로 게시해 버린 야간 에이전트 의도한 작업 범위를 벗어나는 문제는 단순한 버그만이 아니라, 모델의 도움 지향성·혼동·prompt injection 때문에도 발생한다. 이런 경우는 접근권한을 읽기 전용으로 제한하는 식의 간단한 수정으로도 막을 수 있지만, 더 복잡한 작업에서는 훨씬 정교한 통제가 필요하다.
3. 3:12
   지연 시간 조사 중 범위를 넓히는 문제 장애 조사처럼 합리적인 작업도 진행 중에 로그, GitHub, Slack 등으로 범위를 계속 넓히며 신뢰 경계를 넘어가게 된다. 자율 에이전트의 핵심 문제는 “할 수 있나”가 아니라, 런타임 중 바뀌는 접근 요구를 어떻게 안전하고 정확하게 허용할지에 있다.
4. 4:17
   하나의 모델, 하나의 하네스에 의존할 수 없는 이유 실제로는 여러 frontier model과 open model을 함께 쓰게 되며, 비용·프라이버시·성능에 따라 선택도 달라진다. 하네스도 코딩뿐 아니라 영업·마케팅 등으로 확장될 것이므로, 특정 모델이나 특정 하네스가 아니라 모든 조합에서 동작하는 공통 런타임이 필요하다.
5. 6:24
   경계 바깥의 제어로 격리하기 해법의 첫 축은 sandbox를 포함한 containment이며, 에이전트는 신뢰하지 않는 경계 안에서 돌리고 제어 로직은 VM 바깥에서 운영해야 한다. 단순히 네트워크나 도구를 막는 수준을 넘어, 실제로는 정교하게 범위가 제한된 capability를 제공해야 한다.
6. 7:29
   한 작업에만 맞춘 필요 시점 도구 사전에 정의된 도구는 너무 넓은 경우가 많기 때문에, 런타임이 Slack 같은 기존 도구를 조합해 incident 관련 대화만 볼 수 있는 just-in-time tool을 만들어야 한다. 작업마다 필요한 범위만 담은 scoped sandbox로 쪼개면, 보안 경계를 유지한 채 병렬적으로 일을 분담할 수 있다.
7. 8:30
   의도 기반 접근과 거부해야 할 것 접근 허용은 사용자의 명시적 의도와 작업 맥락을 바탕으로 판단해야 하며, 더 넓은 권한이 필요하다고 해서 자동으로 허용하면 안 된다. Slack 읽기처럼 자연스러운 요청은 허용하되, 이메일 접근처럼 작업과 무관한 요청은 거부하거나 사람의 승인을 거치게 해야 한다.
8. 10:33
   Docker가 이식성을 풀었고, 이제는 안전을 푼다 지난 10년의 Docker가 해결한 것은 로컬에서 클라우드로의 portability였고, 지금은 그 경험을 바탕으로 안전성을 푸는 새로운 runtime이 필요하다. 이 runtime은 새 VM 기술과 MCP, policy, safety, governance를 결합해 모든 환경에서 같은 방식으로 동작해야 한다.
9. 11:49
   주입된 자격 증명과 스텁이 있는 샌드박스 새 micro VM 위에서 SPX가 실행되며, 자격 증명은 직접 노출되지 않고 주입되며 네트워크 정책도 통제된다. 겉보기에는 평범한 에이전트 경험을 유지하면서도, 실제 권한은 스텁 기반으로 제한해 안전성을 확보한다.
10. 13:58
    하나의 작업을 두 개의 스코프드 샌드박스로 나누기 PR 요약 작성과 Notion 문서 작성은 하나의 거대한 sandbox로 묶지 않고, GitHub용 sandbox와 Notion용 sandbox로 분리할 수 있다. 이렇게 하면 각 작업은 자신에게 필요한 권한만 받고, 서로 다른 security boundary 안에서 독립적으로 실행된다.
11. 16:06
    같은 샌드박스를 클라우드로 옮기기 같은 정책과 제어 plane을 유지한 채 로컬 sandbox를 cloud로 그대로 이동할 수 있어야 runtime이 진짜로 portable하다고 볼 수 있다. 이 방식은 로컬·클라우드·병렬 fan-out 작업까지 같은 안전한 경험으로 확장한다.
12. 18:10
    스코프드 에이전트를 함께 오케스트레이션하기 오케스트레이터가 여러 scoped agent를 묶어 10개의 PR 검토와 Notion 요약 같은 작업을 분산 실행할 수 있다. 핵심은 동일한 control plane과 policy를 유지하면서, 각 에이전트에 필요한 최소 권한만 주고 전체 흐름을 조율하는 것이다.
13. 20:26
    즉석에서 권한을 부여하는 프로토타입 현재 프로토타입은 에이전트가 직접 접근을 요청하면 런타임이 의도를 판단해, 필요한 경우에만 GitHub 권한을 가진 scoped sub-sandbox를 즉시 만든다. 반대로 pastebin.com처럼 작업 의도와 맞지 않는 요청은 거부하며, 이런 판단이 모든 모델·하네스·환경에 공통으로 적용되는 base control layer가 되어야 한다.

실무 인사이트

• 에이전트 안전성은 프롬프트 개선만으로 해결되지 않으므로, 권한·도구·격리·승인을 런타임 계층에서 분리 설계해야 한다.
• 실무에서는 “한 에이전트에 많은 권한”보다 “작업별로 짧게 살아나는 scoped sandbox”가 사고 반경을 줄이고 운영도 단순하게 만든다.
• 모델을 교체하거나 하네스를 늘려도 같은 정책이 유지되도록, model-agnostic한 control plane과 intent-based access를 먼저 설계하는 것이 중요하다.