AI 에이전트에게 필요한 것은 마스터 키가 아니라 경계입니다
MCP를 통해 AI 에이전트에게 앱 접근 권한을 부여하는 것은 위험합니다. 이는 열쇠 꾸러미를 넘겨주면서 에이전트가 특정 문만 열기를 바라는 것과 같습니다. 그러한 신뢰는 보안 리스크가 됩니다.
멀티 테넌트(multi-tenant) Laravel 앱을 위한 MCP 도구를 구축할 때, 반드시 해결해야 할 문제가 하나 있습니다. 바로 에이전트가 다른 사용자의 데이터에 접근하지 않고도 앱을 제어할 수 있도록 하는 방법입니다.
각 MCP 도구는 엔드포인트 역할을 합니다. 에이전트가 도구를 호출하면 서버에서 코드가 실행됩니다. 멀티 테넌트 환경에서는 모든 도구가 다음 두 가지 질문에 답할 수 있어야 합니다:
- 이 작업을 수행할 권한이 있는가?
- 여기서 이 작업을 수행할 권한이 있는가?
이 과정을 생략하면 보안 취약점이 발생합니다.
웹 요청은 멀티 테넌시를 처리하기 위해 세션을 사용하지만, MCP 도구는 토큰을 사용합니다. 현재 테넌트 컨텍스트를 설정할 세션이나 미들웨어가 없습니다. 만약 세션에서 "현재 조직(current org)"을 찾는 글로벌 스코프(global scope)에 의존한다면, 아무것도 찾지 못할 것입니다. 제한되어야 할 쿼리가 데이터베이스의 모든 행을 반환할 수도 있습니다.
저는 안전을 유지하기 위해 다음 네 가지 규칙을 사용합니다:
- 명시적 필터링: 토큰 인증 환경에서 암시적 스코프(ambient scope)에 의존하지 마세요. 매번 조직별로 필터링할 수 있도록 단일 트레이트(trait)를 사용하세요.
- UUID 사용: 자동 증가(auto-increment) ID를 절대 사용하지 마세요. 에이전트가 다른 레코드를 추측할 수 없도록 예측 불가능한 식별자를 사용하세요.
- 권한 재사용: 에이전트를 위한 새로운 권한 세트를 만들지 마세요. 웹 앱에서 사용하는 것과 동일한 권한 문자열(ability strings)을 사용하세요.
- 부수 효과(side effects) 표시: 어노테이션을 사용하여 도구를 읽기 전용 또는 쓰기 가능으로 표시하세요.
조직 조회를 위해 단일 트레이트를 사용하면 감사(audit)할 수 있는 지점이 하나로 통합됩니다. 조회 결과가 null을 반환하면, 도구는 에이전트에게 레코드를 찾을 수 없다고 알립니다. 에이전트는 다른 테넌트에 대한 어떠한 정보도 얻을 수 없습니다.
이것은 AI의 문제가 아닙니다. 멀티 테넌시와 권한 부여(authorization)의 문제입니다. MCP는 앱을 노출하기 쉽게 만들어 주므로, 경계 설정에 있어 엄격해야 합니다.
에이전트는 자신의 테넌트 내에서 인간이 할 수 있는 것과 정확히 동일한 작업만 수행해야 하며, 그 이상은 안 됩니다.
Optional learning community: https://t.me/GyaanSetuAi