무슨 문제를 푸는 도구냐면요
요즘 LLM 에이전트를 만들다 보면 한 번쯤 이런 코드를 짜본 적 있을 거예요. 시스템 프롬프트에 "너는 관리자가 아니면 이 데이터에 접근하면 안 돼", "민감한 정보는 보여주지 마" 같은 문장을 잔뜩 적어넣는 거요. 그런데 이게 진짜 위험하거든요. 프롬프트로 적은 규칙은 '진짜 보안'이 아니라 '부탁'일 뿐이에요. 사용자가 살짝 말을 바꾸거나(프롬프트 인젝션), 모델이 깜빡하면 그냥 뚫려버려요.
cast는 바로 이 문제를 정조준한 오픈소스예요. 글 제목 그대로 "에이전트 프롬프트에 접근 제어를 덕테이프로 붙이는 데 지쳤다, 여기 해결책이 있다"는 거죠. 핵심 아이디어는 권한 관리를 프롬프트(말)가 아니라 코드(실행 계층)에서 강제하자는 거예요.
핵심 내용: 말이 아니라 코드로 막는다
전통적인 웹 서비스에서는 권한 관리가 당연히 코드 레벨에서 이뤄지잖아요. 로그인한 유저가 누구인지 확인하고, 그 유저가 이 API를 호출할 권한이 있는지 서버가 검사하죠. 사용자가 아무리 "나 관리자야"라고 우겨도 서버 코드가 안 된다고 하면 끝이에요.
그런데 AI 에이전트는 이상하게도 이 당연한 원칙을 자꾸 잊어버려요. 에이전트가 도구(tool)를 호출해서 DB를 읽거나 외부 API를 부를 때, '지금 이 사용자가 이 도구를 쓸 자격이 있나'를 검사하는 단단한 관문이 없는 경우가 많거든요. cast가 하려는 건 바로 그 관문(gatekeeper)을 도구 호출 단계에 박아넣는 거예요.
쉽게 비유하면 이래요. 기존 방식이 "손님한테 '냉장고 함부로 열지 마세요' 쪽지를 붙여놓는" 거라면, cast 방식은 냉장고에 진짜 잠금장치를 달고 권한 있는 사람한테만 열쇠를 주는 거예요. 모델이 뭐라고 생각하든 상관없이, 실제 실행 경로에서 차단되는 거죠.
구조적으로는 보통 이런 흐름이에요. 어떤 사용자/세션에 어떤 역할(role)과 권한(permission)이 있는지 정의해두고, 에이전트가 도구를 실행하려 할 때 그 컨텍스트를 검사해서 통과한 호출만 실제로 실행시키는 거예요. 권한이 없으면 도구 자체가 호출되지 않으니, 프롬프트 인젝션으로 모델을 꼬드겨도 실행 계층에서 막혀요.
업계 맥락
이런 고민은 지금 AI 에이전트 생태계 전반의 뜨거운 주제예요. MCP(Model Context Protocol)가 퍼지면서 에이전트가 외부 도구·데이터에 붙는 일이 폭증했는데, 그만큼 '에이전트가 권한을 넘어선 행동을 하면 어쩌지'라는 불안도 커졌거든요. OWASP도 LLM 보안 위협 목록에서 과도한 권한 부여(Excessive Agency)와 프롬프트 인젝션을 핵심 위험으로 꼽고 있어요.
비슷한 결의 접근으로는 권한 정책 엔진인 OPA(Open Policy Agent)나 구글이 밀던 Zanzibar 스타일 권한 모델이 있어요. cast는 이런 묵직한 정책 엔진을 에이전트 도구 호출이라는 구체적 맥락에 맞춰 가볍게 가져온 느낌이라고 보면 돼요.
한국 개발자에게 주는 시사점
사내에 LLM 챗봇이나 에이전트를 붙여 사내 DB·문서를 다루게 하는 회사가 정말 많아졌죠. 이때 "프롬프트로 막아놨으니 괜찮겠지"는 가장 위험한 착각이에요. 보안 감사나 컴플라이언스(특히 금융·의료) 관점에서, '실행 계층에서 강제되는 권한 검사'는 선택이 아니라 필수가 되어가고 있어요.
당장 cast를 도입하지 않더라도, 여러분의 에이전트 아키텍처에서 '권한 검사가 프롬프트에만 있는지, 코드에도 있는지'를 점검해보세요. 답이 '프롬프트뿐'이라면 지금이 리팩터링할 때예요.
마무리
AI 보안의 제1원칙은 단순해요. 신뢰 경계(trust boundary)는 말랑한 프롬프트가 아니라 단단한 코드에 그어야 한다. 여러분 프로젝트의 에이전트는 지금 '쪽지'로 막고 있나요, '잠금장치'로 막고 있나요?
🔗 출처: Hacker News