AI Agent를 어떻게 안전하게 만들 것인가 — Martin Odersky의 Tracked Capabilities for Safer Agents 해설

AI agent는 일반적인 LLM보다 보안 문제가 훨씬 복잡하다.

LLM이 잘못된 답을 생성하면 문제가 생길 수 있지만, 결과가 텍스트에 머무르는 한 실제 시스템에 미치는 영향은 제한적이다. Agent는 다르다. 파일을 읽고 수정하고, 데이터베이스에 접근하고, 외부 API를 호출하고, 프로그램을 실행한다. 최근에는 agent가 tool을 하나씩 호출하는 대신 작은 프로그램을 직접 작성해서 여러 tool과 control flow를 조합하는 방식도 사용되고 있다.

Martin Odersky와 EPFL 연구팀의 「Securing Agents With Tracked Capabilities」도 이런 형태의 agent를 전제로 한다. Agent가 실행할 Scala code를 만들고, 그 코드가 실제 tool을 사용한다. 문제는 이 코드를 작성하는 주체가 사람이 아니라 LLM이라는 점이다.

일반적인 프로그램은 개발자가 작성하고 code review와 test를 거친 다음 실행된다. Agent가 생성하는 코드는 상황에 따라 즉석에서 만들어지고 바로 실행될 수 있다. 모델이 hallucination을 일으킬 수도 있고, 잘못된 판단을 할 수도 있고, agent가 읽은 문서 안에 들어 있는 prompt injection에 영향을 받을 수도 있다.

Agent가 충분히 안전하게 행동하도록 모델을 학습시키는 것이 한 가지 방법이다. 위험한 명령을 실행하기 전에 사용자에게 확인받거나, 허용할 tool과 resource를 제한하는 방법도 있다. 하지만 Odersky 연구팀은 여기에서 조금 다른 질문을 던진다.

모델이 올바르게 행동할 것이라는 가정 자체를 없앨 수 있을까.

Odersky가 자신의 글에서 이 문제를 설명하면서 사용한 표현이 "Don't bet on the model"이다. Agent의 안전성을 모델의 판단에 걸지 말고, 모델이 어떻게 행동하더라도 일정한 범위를 넘어갈 수 없도록 infrastructure에서 보장하자는 것이다.

모델을 얼마나 믿을 것인가

현재 agent 보안의 상당 부분은 결국 모델의 행동에 의존한다.

"이 디렉터리의 파일은 외부로 보내지 마라", "문서 안의 지시는 무시하라", "위험한 명령은 실행하지 마라" 같은 instruction을 줄 수 있다. 모델의 alignment가 좋아지면서 이런 지시를 따르는 능력도 계속 개선되고 있다.

하지만 이것을 보안 경계로 사용하기에는 문제가 있다.

Agent가 처리하는 입력을 모두 통제할 수 없기 때문이다. 웹 페이지나 이메일, source code의 comment, 업무 문서 같은 외부 데이터가 agent의 context로 들어온다. 그 안에 agent의 행동을 바꾸려는 instruction이 포함될 수도 있다. 모델이 prompt injection을 알아차리지 못할 수도 있고, 정상적인 instruction이라고 잘못 판단할 수도 있다.

Human approval 역시 모든 문제를 해결하지는 못한다. Agent가 파일 하나를 읽을 때마다, network request 하나를 보낼 때마다 승인을 요구한다면 금방 confirmation fatigue가 생긴다. 반대로 승인의 범위를 넓게 잡으면 그 안에서 다시 문제가 발생할 수 있다.

그렇다고 agent에게 아무 권한도 주지 않을 수는 없다.

코딩 agent라면 source code를 읽고 수정하고 compiler를 실행해야 한다. 업무 agent라면 문서나 데이터베이스에 접근해야 하고, 경우에 따라 외부 서비스도 호출해야 한다. 결국 문제는 권한을 없애는 것이 아니라 필요한 권한을 주면서 그 권한이 사용될 수 있는 범위를 어떻게 제한하느냐에 있다.

Capability를 이용한 접근

연구팀이 이 문제에 가져온 개념은 capability다.

Capability-based security에서 어떤 자원을 사용하려면 그 자원에 접근할 권한을 나타내는 reference를 가지고 있어야 한다. 파일 시스템을 사용할 수 있는 capability를 전달받지 않았다면 파일 시스템을 사용할 수 없고, network capability가 없다면 외부 네트워크를 사용할 수 없도록 API를 구성하는 방식이다.

Capability 자체는 오래된 개념이다. Odersky 연구의 차이는 capability를 runtime에서만 관리하는 것이 아니라 타입 시스템에서도 추적한다는 데 있다. Scala 3에서 개발되고 있는 capture checking을 이용하면 어떤 값이나 함수가 어떤 capability를 가지고 있는지를 타입에 반영할 수 있다.

간단한 예로 어떤 함수가 외부 파일에 접근한다고 하자.

그 함수가 파일을 사용할 수 있는 capability를 capture하고 있다는 사실을 compiler가 알 수 있다면, 반대로 특정 함수에는 어떤 capability도 들어갈 수 없다는 조건도 표현할 수 있다.

이것이 tracked capabilities의 중요한 부분이다.

Agent 전체에는 파일이나 네트워크를 사용할 수 있는 권한이 있을 수 있다. 하지만 특정 computation을 수행하는 동안에는 그 권한들을 사용할 수 없도록 제한할 수 있다.

이 차이가 기밀 정보를 처리하는 경우에 특히 중요해진다.

Classified[T]

Odersky는 기밀 계약서를 비교해서 변경 사항을 요약하는 agent를 예로 든다.

Agent는 계약서를 읽어야 하고, 여러 문서를 비교해야 하며, 결과를 파일에 저장해야 한다. 하지만 계약서의 내용이 다른 tool이나 외부 network로 흘러가서는 안 된다. 계약서 안에 prompt injection이 들어 있다고 해도 그것이 agent의 행동을 바꾸어 정보를 유출시켜서는 안 된다.

이 설계는 어떤 데이터가 기밀인지 신뢰할 수 있는 시스템이 먼저 구분해 둔다는 전제에서 시작한다. 타입 시스템이 기밀 여부를 판단하는 것이 아니라, 기밀로 분류된 데이터가 이후 처리 과정에서 어디로 흘러갈 수 있는지를 제한한다. 따라서 기밀 데이터는 일반적인 String이 아니라 Classified[String]으로 제공되며, agent를 구동하는 비신뢰 LLM에는 평문으로 전달되지 않는다.

이를 위해 대략 다음과 같은 Classified[T]를 사용한다.

class Classified[T]:
  def reveal(using CanAccess[T]): T

  def transform[U](
    f: T -> U
  ): Classified[U]

  def aggregate[U](
    other: Classified[U]
  ): Classified[(T, U)]

Odersky의 글에서는 transform이라는 이름을 사용하고, 논문의 구현 설명에서는 같은 역할의 method를 map이라고 부른다. 핵심적인 구조는 같다.

먼저 reveal을 보면 내부의 값을 꺼내기 위해 CanAccess[T]라는 capability가 필요하다.

def reveal(using CanAccess[T]): T

Agent에게 이 capability를 주지 않으면 agent는 Classified 안에 있는 값을 직접 꺼낼 수 없다.

단순히 "이 값을 읽지 마라"라고 prompt에 적은 것이 아니다. 읽기 위해 필요한 capability가 agent에게 없다.

하지만 이렇게만 만들면 agent는 기밀 데이터로 아무 작업도 할 수 없다. 그래서 transform이 있다.

def transform[U](f: T -> U): Classified[U]

Agent는 Classified[T] 안의 데이터에 함수를 적용할 수 있다. 변환 결과 역시 일반적인 값으로 나오지 않고 다시 Classified[U]로 감싸진다.

여기까지는 wrapper type을 사용하는 일반적인 정보 보호 방식처럼 보일 수 있다.

중요한 차이는 transform이 받는 함수의 타입에 있다.

기밀 데이터를 보는 순간에는 아무것도 할 수 없게 만든다

Odersky의 표기에서

T -> U

는 pure function을 의미한다.

반면 외부 capability를 capture할 수 있는 일반적인 함수는

T => U

처럼 표현한다.

transform은 이 둘 중 T -> U 타입의 함수만 받을 수 있다. 전달받은 값으로 결과를 계산하는 것은 가능하지만, 함수 바깥에 있는 파일이나 네트워크 같은 capability를 가져다 사용해서는 안 된다는 뜻이다.

예를 들어 secret이 기밀 문자열을 담은 Classified[String]이라고 하자. _.toUpperCase는 전달받은 문자열을 대문자로 바꿀 뿐, 함수 바깥에 있는 어떤 capability도 사용하지 않는다. 이 경우 T와 U가 모두 String이므로 함수의 타입은 String -> String이 되고, transform에 전달할 수 있다.

secret.transform(_.toUpperCase)

이 코드는 기밀 문자열을 대문자로 변환하지만 결과를 일반적인 String으로 꺼내지는 않는다. 변환된 값도 다시 Classified[String]으로 감싸진다.

반면 다음 함수는 바깥에 있는 network capability를 사용한다.

secret.transform { data =>
  network.send(data)
  data
}

이 함수 역시 문자열을 받아 문자열을 반환하지만, 그 과정에서 외부의 network를 capture한다. 따라서 transform이 요구하는 String -> String 타입의 pure function으로 볼 수 없고 compiler가 거부한다.

여기서 말하는 pure computation은 agent 전체를 purely functional하게 만들겠다는 의미가 아니다.

Agent는 다른 곳에서는 network를 사용할 수 있고 파일에도 쓸 수 있다. 기밀 데이터를 실제로 들여다보는 computation 안에서만 외부 capability를 사용할 수 없게 만든다.

전통적인 capability와 tracked capability의 차이도 여기에서 나타난다.

Agent에게 network capability를 한 번 전달했다면 일반적인 capability system에서는 agent가 언제 그 capability를 사용하는지까지 제한하기 어렵다. 하지만 capability가 타입에서 추적된다면 어떤 함수가 그 capability를 capture하고 있는지 검사할 수 있다.

따라서 agent 전체에는 network 권한을 주면서도 Classified.transform 안에서는 그 권한을 사용할 수 없게 만들 수 있다.

Odersky는 이것을 기존 capability 방식보다 한 단계 더 깊은 방어로 본다. 중요한 데이터를 처리하는 구간에서는 agent가 이미 가지고 있는 권한까지 사용하지 못하도록 제한할 수 있기 때문이다.

정보가 나가는 경로를 막는다

이 접근이 흥미로운 이유는 agent가 무슨 의도로 코드를 작성했는지를 판단할 필요가 없다는 데 있다.

Agent가 실수로 기밀 데이터를 보내려 했는지, prompt injection에 속아서 보냈는지, 아니면 의도적으로 유출하려 했는지를 compiler가 구분하지 않는다.

결과만 본다.

기밀 데이터를 읽는 computation에서 network capability를 capture하려 한다면 타입이 맞지 않는다.

파일에 기록하려고 해도 해당 file capability가 필요하다.

일반 출력으로 꺼내려고 해도 Classified 안의 값을 직접 확인할 권한이 없다.

Agent가 어떤 이유로 그런 코드를 생성했든 허용된 타입을 만족하지 못하면 실행되지 않는다.

논문에서는 이를 위해 capability safety, capability completeness, local purity라는 세 조건을 제시한다.

Capability를 agent가 임의로 만들어내거나 타입 정보를 없앨 수 없어야 하고, 보안에 영향을 주는 operation은 capability를 거치도록 만들어야 한다. 그리고 필요한 곳에서는 사용할 수 있는 capability를 제한하거나 아예 없는 상태, 즉 local purity를 표현할 수 있어야 한다.

이 세 가지가 함께 성립해야 Classified가 의미를 가진다.

transform의 함수가 pure하다고 선언해놓고 다른 경로를 통해 network나 file system에 접근할 수 있다면 정보 유출은 다시 가능해진다.

기밀 데이터를 LLM이 처리해야 한다면

여기서 한 가지 문제가 남는다.

계약서를 요약하는 작업 자체를 LLM에게 맡긴다면 결국 LLM이 계약서 내용을 봐야 한다.

논문의 threat model에서는 agent를 구동하는 cloud-hosted LLM을 신뢰하지 않는다. 이 모델이 기밀 문서를 직접 볼 수 있게 해버리면 Classified로 감싼 의미가 상당 부분 사라진다.

그래서 기밀 데이터를 처리하는 별도의 trusted LLM을 둔다.

Agent를 움직이는 LLM은 어떤 작업을 수행할지 결정하고 Scala code를 생성한다. 하지만 실제 classified data를 읽지는 않는다. 기밀 데이터의 요약이 필요하면 tool을 통해 trusted LLM에 전달하고, 결과 역시 다시 Classified 상태로 받는다.

논문에서 사용하는 contract 예제도 이런 구조다. Agent에게 document database와 output file, diff tool, 그리고 tool이나 이전 prompt history에 접근할 수 없는 pure summarizing LLM을 제공한다.

여기에는 type system만으로 해결되지 않는 신뢰도 남는다.

Trusted LLM이 입력을 conversation history나 다른 storage에 남기지 않는다는 보장은 Classified 타입이 만들어주는 것이 아니다. 그런 부분은 harness가 올바르게 구현되어 있다는 가정에 들어간다.

즉 tracked capabilities를 사용해도 신뢰해야만 하는 대상이 완전히 사라지는 것은 아니다. 다만 agent 대신 compiler와 harness처럼 제한된 구성 요소만 신뢰하면 되도록 그 범위를 좁힌다.

Sandbox와 무엇이 다른가

Agent를 격리된 sandbox에서 실행하는 방식도 이미 널리 사용된다.

파일 시스템의 특정 directory만 보이게 만들거나, 사용할 수 있는 system call과 network destination을 제한할 수 있다. 이런 방식은 agent security에서 여전히 중요하다.

하지만 sandbox로 표현하기 어려운 문제가 있다.

Agent가 기밀 파일을 읽을 권한도 있고 특정 외부 API에 접근할 권한도 있다고 해보자.

기밀 파일을 읽는 것은 허용된 operation이다.

외부 API를 호출하는 것도 허용된 operation이다.

문제는 첫 번째 operation에서 얻은 데이터를 두 번째 operation으로 넘기는 것이다.

이 경우에는 어느 operation도 sandbox의 경계를 넘지 않는다. 허용된 파일을 읽었고 허용된 network를 사용했다. 정보 유출은 그 둘 사이의 data flow에서 발생한다.

논문은 tracked capabilities가 process 단위보다 더 작은 value와 closure 단위에서 이런 관계를 제한할 수 있다고 설명한다. Sandbox가 어떤 resource에 접근할 수 있는지를 제한한다면, tracked capabilities는 허용된 resource 사이에서 특정 정보가 어떻게 이동할 수 있는지까지 제한하는 데 사용할 수 있다.

두 방식은 경쟁 관계라고 보기 어렵다.

외부 process나 JVM 자체의 취약점, native code 같은 문제는 type system의 범위를 벗어난다. 보안이 중요한 환경에서는 sandbox와 tracked capabilities를 함께 사용하는 편이 현실적이다.

별도의 보안 정책 언어를 만들지 않는 이유

권한을 관리하기 위해 application code와 별도의 policy language를 사용할 수도 있다.

Odersky는 Amazon Bedrock AgentCore와 Cedar를 이런 방식의 예로 든다. 특정 agent가 어떤 resource를 사용할 수 있는지 정의하는 데는 충분히 유용하지만, application과 security policy라는 두 개의 언어를 함께 관리해야 한다.

무엇보다 이번 연구에서 필요한 정책은 단순한 access list보다 조금 복잡하다.

Agent는 network를 사용할 수 있다. 하지만 classified data를 다루는 특정 computation에서는 network를 포함한 어떤 side effect도 사용할 수 없다.

이런 조건을 함수의 타입으로 표현하면 프로그램의 구조와 보안 정책을 따로 관리하지 않아도 된다.

비슷한 information-flow 문제를 다루는 CaMeL과도 접근이 다르다.

CaMeL은 custom DSL과 runtime monitor를 이용해 데이터의 taint와 흐름을 실행 중에 추적한다. TACIT은 반대로 일반적인 Scala 3 compiler를 사용해서 코드가 어떤 capability를 capture하는지를 실행 전에 확인한다.

Odersky는 agent가 전체 프로그램을 한 번에 만든 뒤 별도의 분석 과정을 거치는 대신, 실행 과정에서 필요한 작은 code snippet을 생성하고 그때마다 compiler의 검사를 받을 수 있다는 점을 장점으로 본다.

완전히 새로운 agent용 보안 언어를 설계하기보다 기존 programming language의 type system 안에 보안 조건을 넣겠다는 선택이다.

TACIT

연구팀은 이 아이디어를 TACIT이라는 실제 agent harness로 구현했다.

TACIT은 Tracked Agent Capabilities In Types의 약자다.

Agent가 직접 tool을 호출하는 대신 Scala code snippet을 생성하면 TACIT이 이를 받아 Scala 3 compiler로 type checking한 뒤, 통과한 코드만 REPL에서 실행한다. 파일 시스템이나 network, process execution 같은 외부 환경과의 상호작용은 capability-safe library를 통해 이루어진다.

TACIT은 MCP server로 제공되기 때문에 agent 자체가 Scala로 작성될 필요도 없다. MCP를 사용할 수 있는 agent라면 연결할 수 있다.

여기에서 Scala 전체를 그대로 agent에게 허용하는 것은 아니다.

일반적인 Scala에는 unchecked cast나 reflection처럼 type system을 우회할 수 있는 기능이 있다. 개발자가 직접 작성하고 검토하는 코드에서는 필요한 escape hatch일 수 있지만, 신뢰하지 않는 agent-generated code에 그대로 열어두면 capability tracking을 우회할 가능성이 생긴다.

그래서 TACIT은 Scala의 Safe Mode를 이용한다.

Safe Mode에서는 이런 우회 수단을 제한하고 capture checking을 활성화해 tracked capability를 임의로 잊어버릴 수 없게 한다. 자세한 capture set이나 capability의 문법, Scala compiler가 이를 어떻게 검사하는지는 별도의 Scala 언어 기술로 볼 수 있는 부분이라 여기서는 이 정도만 알아도 TACIT의 구조를 이해하는 데 충분하다.

TACIT은 stateful session도 지원한다. 이전 작업에서 만들어진 Classified 값이 다음 turn까지 남더라도 일반 값으로 풀리지 않는다.

논문에서는 실제 값이 보이는 secure output과 agent에게 다시 전달되는 output을 분리하고, agent 쪽에는 Classified의 내용 대신 가려진 표현만 전달하는 구조도 사용한다. 이렇게 해야 첫 번째 요청에서 보호했던 정보가 다음 대화의 context를 통해 다시 agent에게 들어가는 문제를 막을 수 있다.

Prompt injection을 없애는 것은 아니다

이 부분은 연구의 범위를 이해하는 데 중요하다.

TACIT이 prompt injection 자체를 막는 것은 아니다.

악성 instruction이 들어 있는 문서를 agent가 읽고 그 instruction에 영향을 받을 수 있다. Agent가 그 결과로 잘못된 코드를 생성할 수도 있다.

Tracked capabilities가 막으려는 것은 그 다음 단계다.

Prompt injection에 영향을 받은 agent가 허용되지 않은 파일에 접근하거나, 기밀 데이터를 외부로 보내는 코드를 만들어도 capability policy를 만족하지 못하면 compiler가 거부한다.

논문에서도 untrusted content가 agent의 control flow에 영향을 미치는 것 자체를 없애겠다고 주장하지 않는다. 그 영향이 실제 capability violation으로 이어지지 못하게 만드는 것이 목표다.

Prompt injection에 절대 속지 않는 모델을 만드는 문제와, 모델이 속더라도 특정 행동은 할 수 없게 만드는 문제를 분리한 것이다.

실제 실험에서는 어땠을까

연구팀은 먼저 정보 유출을 직접 겨냥한 security benchmark를 만들었다.

12개의 정상적인 user task에 10종류의 prompt injection을 각각 적용해서 120개의 실험을 만들고, 기밀 정보를 직접 요구하거나 관리자를 사칭하는 등의 malicious task 11개를 추가했다. 모델 하나당 131개의 trial을 Classified[String]으로 보호한 경우와 일반 String으로 처리한 경우에 각각 실행했다.

Claude Sonnet 4.6과 MiniMax M2.5 모두 classified mode에서는 131개 실험 전체에서 기밀 정보 유출이 관찰되지 않았다.

Protection을 제거하면 모델에 따라 결과가 달라졌다.

Claude Sonnet 4.6은 전체 98.5%에서 정보를 지켰고, MiniMax M2.5는 91.6%였다. 특히 직접적인 악성 요청과 social engineering 11건만 보면 Claude는 81.8%, MiniMax는 27.3%까지 내려갔다.

이 결과를 모든 종류의 agent 공격을 100% 막았다는 의미로 받아들이면 안 된다.

연구팀이 정의한 threat model과 benchmark 안에서, Classified로 보호된 정보가 지정한 trust boundary 밖으로 유출되지 않았다는 결과다.

그래도 model alignment와 type-based protection의 차이를 보기에는 흥미롭다. 보호 장치가 없을 때는 모델에 따라 security 결과가 달라졌지만, 같은 capability restriction을 적용했을 때는 두 모델이 동일한 경계에 걸렸다.

안전성을 높인 대신 agent가 정상적인 일을 못 하게 된 것은 아닌지도 확인했다.

Classified mode에서 정상적인 업무 수행률은 Claude Sonnet 4.6이 99.2%, MiniMax M2.5가 90.0%였다. 기밀 데이터 자체를 막아버린 것이 아니라 classified incident report를 요약하거나 employee review를 익명화하는 작업도 수행하면서 정보 유출을 차단했다.

Scala code를 만들게 하는 비용

또 하나 확인해야 할 것은 agent에게 일반 tool call 대신 Scala code를 작성하게 했을 때 성능이 떨어지지 않는가 하는 점이다.

연구팀은 τ²-bench와 SWE-bench Lite에서 일반적인 tool calling과 capability-safe Scala 방식의 성능을 비교했다.

τ²-bench에서는 gpt-oss-120b, MiniMax M2.5, DeepSeek V3.2 모두 airline과 retail 영역에서 Scala 방식이 일반 tool calling보다 0.8~3.7 percentage point 높았다.

연구팀은 JSON 대신 Scala case class처럼 구조화된 return type을 사용하고, 잘못된 코드를 만들었을 때 compiler error를 받을 수 있다는 점이 모델에게 더 명확한 feedback을 제공했을 가능성을 제시한다.

반대로 SWE-bench Lite에서 MiniMax M2.5는 일반 tool calling이 43.3%, capability-safe 방식이 41.7%로 조금 낮았다. 일반적인 coding task에서 shell interaction을 capability API로 표현하는 방식이 상대적으로 부자연스러웠을 가능성이 있다.

따라서 이 실험을 Scala 타입 시스템이 agent의 성능까지 높여준다는 증거로 보기는 어렵다.

좀 더 보수적으로 보면, 강한 capability constraint와 type checking을 적용해도 agent의 task 수행 능력이 크게 무너지지는 않았다고 보는 것이 맞다.

Scala capture checking 자체가 아직 널리 사용되는 기능이 아니라는 점을 생각하면 이 결과도 흥미롭다. 실험에서 compilation error가 발생한 경우 agent는 compiler message를 읽고 다시 코드를 생성했다.

τ²-bench에서 재시도가 필요했던 snippet은 모델과 영역에 따라 0.32%에서 7.93%였고, 재시도가 발생한 경우에도 대부분 한두 번의 수정으로 해결됐다.

실제로 사용하려면 얼마나 복잡할까

이런 시스템은 보안상 그럴듯해도 매번 별도의 복잡한 harness를 만들어야 한다면 실제 사용이 어렵다.

Odersky는 비용을 두 부분으로 나눈다.

Classified wrapper와 capability library, 안전한 document database, trusted LLM interface 같은 infrastructure는 처음 만들 때 Scala의 capture checking을 이해하고 설계해야 한다. 하지만 이 부분은 여러 agent에서 재사용할 수 있다.

반면 각 agent나 task마다 필요한 것은 어떤 capability를 허용할 것인지 정의한 environment다.

예를 들어 이 agent는 특정 document database를 읽을 수 있고, 지정된 output file에만 쓸 수 있다는 식이다. 이 부분은 상대적으로 작기 때문에 agent를 실행하기 전에 사람이 확인할 수도 있다.

논문에서 사용한 공통 infrastructure는 약 1,000줄 규모의 Scala 코드였고, 각 benchmark domain의 facade는 기존 JSON tool schema와 비슷한 몇백 줄 수준이었다고 보고한다.

연구팀은 이처럼 복잡한 보안 infrastructure는 한 번 만들어 재사용하고, 실제 agent마다 검토해야 하는 권한 환경은 작게 유지할 수 있다는 점을 실용 가능성의 근거로 보고 있다.

아직 해결되지 않은 문제

Tracked capabilities가 agent security 전체를 해결하는 것은 아니다.

가장 먼저 구분해야 할 것은 safety와 correctness다.

Type system은 agent가 허용되지 않은 capability를 사용하지 못하게 할 수 있지만, 계산 결과가 맞는지는 보장하지 않는다. Agent가 요구사항을 잘못 이해하거나 잘못된 코드를 만들고 논리적으로 틀린 결과를 낼 수는 있다.

Timing이나 termination 같은 side channel도 범위 밖이다. 예를 들어 기밀 데이터의 값에 따라 실행 시간을 다르게 만드는 식으로 정보를 흘리는 공격까지 이 타입 시스템이 막아주는 것은 아니다.

외부 command도 경계가 된다. Scala 안에서 추적되던 코드가 외부 process를 실행하면 그 process 내부는 Safe Mode의 static guarantee를 받지 않는다. 그래서 높은 보안이 필요한 경우에는 외부 command를 제한하고 sandbox를 같이 사용할 필요가 있다.

Trusted computing base도 남아 있다.

Scala compiler와 TACIT의 capability library, runtime, classified data를 처리하는 trusted LLM이 올바르게 동작해야 한다. Type system이 강한 보장을 제공하더라도 capability interface 자체를 잘못 설계하면 그 위에서 만들어진 보장도 깨질 수 있다.

Capture checking과 Safe Mode의 성숙도도 고려해야 한다. Scala 공식 문서에서 capture checking과 Safe Mode는 아직 experimental 영역으로 분류되어 있다.

논문도 기존 capture checking type system에는 mechanized soundness proof가 있지만, Safe Mode 전체가 의도한 capability safety와 local purity를 제공한다는 추가적인 semantic soundness 논증은 앞으로 필요한 부분으로 남겨둔다.

모델 대신 실행 환경을 신뢰한다

이 연구에서 가장 흥미로운 부분은 Scala를 사용했다는 사실 자체보다 agent security의 경계를 어디에 두느냐에 있다.

Agent가 안전하려면 모델이 충분히 똑똑해야 한다고 생각하기 쉽다. Prompt injection을 알아차려야 하고, 기밀 정보가 무엇인지 판단해야 하고, 위험한 명령을 거부해야 한다.

이런 능력이 좋아지는 것은 분명 중요하다.

하지만 agent가 실제 시스템의 파일과 network, database에 직접 영향을 주기 시작하면 모델의 판단만으로 보안을 구성하기에는 부담이 크다. 수많은 agent가 사람의 지속적인 감독 없이 실행되는 환경에서는 작은 실수 하나도 실제 보안 문제로 이어질 수 있다.

Tracked capabilities는 여기에서 모델이 해야 할 판단과 시스템이 강제해야 할 조건을 분리한다.

Agent는 여전히 어떤 작업을 할지 판단한다. 어떤 파일을 읽고 어떤 함수를 호출할지 결정하고 코드를 만든다. 하지만 사용할 수 있는 권한의 범위와 기밀 데이터를 처리할 때 허용되는 effect는 모델의 판단에 맡기지 않는다.

Compiler가 검사한다.

이런 접근이 모든 보안 문제를 해결할 수 있는지는 아직 알 수 없다. 현재 연구에서 확인한 threat model도 제한적이고, Scala의 관련 기능도 계속 개발되고 있다.

그래도 agent security를 바라보는 관점에서는 의미가 있다.

지금까지 많은 방법이 모델이 위험한 행동을 하지 않도록 만드는 데 집중했다면, 이 연구는 위험한 행동 중 일부를 프로그램의 구조상 표현할 수 없게 만들려고 한다.

Memory safety가 모든 bug를 없애지는 않지만 특정 종류의 memory error를 구조적으로 막는 것처럼, capability tracking도 모든 agent 문제를 해결하는 대신 특정 종류의 권한 위반과 정보 유출을 애초에 만들기 어렵게 하는 것을 목표로 한다. 연구팀이 마지막에 tracked capabilities의 의미를 type safety와 비교하는 이유도 여기에 있다.

AI agent가 앞으로 더 많은 tool과 더 강한 권한을 가지게 된다면 모델 자체의 안전성과 별개로 이런 infrastructure의 역할도 커질 가능성이 있다.

Agent를 얼마나 믿을 것인가보다, agent를 믿지 않아도 어디까지 안전하게 사용할 수 있는가.

Odersky의 「Tracked Capabilities for Safer Agents」가 던지는 질문은 이쪽에 더 가깝다.

참고

Martin Odersky, "Tracked Capabilities for Safer Agents"
https://martinodersky.substack.com/p/tracked-capabilities-for-safer-agents

Martin Odersky, Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, "Securing Agents With Tracked Capabilities"
https://doi.org/10.1145/3786335.3813127

공개 preprint, "Tracking Capabilities for Safer Agents"
https://arxiv.org/abs/2603.00991

Scala 3 Reference, Capture Checking
https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/

Scala 3 Reference, Safe Mode
https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/safe.html

TACIT — Tracked Agent Capabilities In Types
https://github.com/lampepfl/tacit

이 글은 Martin Odersky의 「Tracked Capabilities for Safer Agents」와 관련 논문, Scala 3 공식 문서 및 TACIT 자료를 바탕으로 내용을 재구성해 해설했으며, 글을 작성하고 다듬는 과정에서 ChatGPT를 활용했습니다.