얼마 전부터 AI Agent가 실제로 무엇을 할 수 있는지 면밀히 살펴보기 시작했습니다. 데모가 아니라, 실제 데이터 위에서 돌아가고 실수에 대가가 따르는 실제 환경에서 운영되는 것들 말입니다. 능력 자체는 진짜였습니다. Agent를 이메일, 캘린더, 코드, 파일에 연결하면 의미 있는 작업을 수행할 수 있었습니다. 그 부분은 인상적이었습니다.

인상적이지 않았던 것은 보안 모델이었습니다. 정확히 말하면 보안 모델의 부재였습니다. 제가 살펴본 모든 플랫폼이 같은 방식으로 규칙을 집행하고 있었습니다. 모델에게 하지 말아야 할 것을 알려주는 방식이었습니다. 좋은 system prompt를 작성하고, 경계를 설명하고, 모델이 그 안에 머무를 것이라 신뢰하는 것입니다. 이 방식은 누군가가 "지금 이 특정 상황에서는 규칙이 적용되지 않는다"고 모델을 설득할 수 있는 표현을 찾아낼 때까지만 작동합니다. 그리고 사람들은 실제로 그런 방법을 찾아냅니다. 그다지 어렵지도 않습니다.

저는 누군가 제가 정말로 사용하고 싶은 버전을 만들어 주기를 계속 기다렸습니다. 모든 것에 연결할 수 있고, 이미 사용 중인 모든 채널에서 작동하며, 모델이 오늘 컨디션이 좋기를 바라지 않아도 진정으로 민감한 데이터를 다룰 수 있는 버전 말입니다. 하지만 나타나지 않았습니다.

그래서 직접 만들었습니다.

Triggerfish는 제가 원했던 바로 그 Agent입니다. 이메일, 캘린더, 파일, 코드, 메시징 앱에 연결됩니다. 프롬프트를 보낼 때만이 아니라 능동적으로 작동합니다. 이미 업무를 수행하고 계신 곳에서 함께 작동합니다. 그러나 제가 가장 진지하게 다루는 부분은 보안 아키텍처입니다. Agent가 무엇에 접근할 수 있고 데이터가 어디로 흐를 수 있는지에 관한 규칙은 prompt 안에 있지 않습니다. 모델 외부에 완전히 분리된 enforcement 계층에 존재합니다. 모델은 시스템에 하고 싶은 것을 전달하고, 별도의 계층이 그것의 실행 여부를 결정합니다. 모델은 이 계층과 협상할 수 없습니다. 우회할 수도 없습니다. 볼 수도 없습니다.

이 차이는 들리는 것보다 훨씬 중요합니다. 모델이 더 강력해져도 시스템의 보안 특성이 약화되지 않는다는 뜻입니다. 침해된 서드파티 도구가 Agent를 설득하여 해서는 안 되는 일을 하게 만들 수 없다는 뜻입니다. 규칙을 실제로 읽고, 이해하고, 신뢰할 수 있다는 뜻입니다. 왜냐하면 그것은 자연어가 아닌 코드이기 때문입니다.

바로 이 이유로 enforcement 핵심부를 오픈소스로 공개했습니다. 읽을 수 없다면 신뢰할 수도 없습니다. 이것은 모든 보안 주장에 해당되며, 보호 대상이 가장 민감한 데이터에 접근 권한을 가진 자율 Agent일 때는 더욱 그렇습니다.

이 플랫폼은 개인 사용자에게 무료이며, 직접 운영하실 수 있습니다. 인프라를 신경 쓰고 싶지 않으시다면 모델과 검색을 저희가 관리하는 구독 옵션도 있습니다. 어느 쪽이든 보안 모델은 동일합니다.

이것이 2년 전 제가 간절히 원했던 Agent입니다. 많은 분들이 같은 것을 기다려 오셨으리라 생각합니다.