Supabase 엔지니어로서 MCP 작업 담당자임을 밝힘. 최근 프롬프트 인젝션 방지를 위해 여러 완화책을 추가한 경험 공유. 기본적으로 read-only 사용을 문서에서 권장하고, SQL 응답을 포장해 LLM이 명령을 따르지 않도록 함. E2E 테스트로 덜 똑똑한 LLM도 공격에 쉽게 속지 않게 하고 있음. 이런 노력들로 인해 실제 Haiku 3.5 같은 덜 강력한 모델에서도 공격 성공률이 크게 떨어졌음을 체감. 하지만 이러한 노력들은 완화책일 뿐이고, 프롬프트 인젝션 문제는 여전히 미해결 문제라는 사실을 강조. 세밀한 토큰 수준의 권한 부여, LLM 접근 서비스 범위 지정, 작성중인 자세한 문서 추가, 프롬프트 인젝션 시도를 탐지하는 모델 등 다양한 추가 장치 개발 중임을 알림. Responsible disclosure(책임 있는 보안 이슈 공개) 절차 따르지 않은 General Analysis 측의 소통 부재에 아쉬움 표명. 자세한 이슈 및 커밋 링크는 pull/94, pull/96, supabase security.txt에서 확인 가능함
이 방식이 정말 효과적인지 의문을 제기. 신뢰할 수 없는 사용자 Javascript를 eval()로 넘기며 sanitize(정규화)하려는 시도가 항상 실패했던 것처럼, 지금의 접근 역시 위험 요소를 완전히 제거하지 못한다고 지적. MCP가 보안 경계로 작동하는 것이 납득되지 않으며, 실제 운영 환경이라면 LLM이 티켓을 읽는 컨텍스트와 SQL 호출 권한을 가진 컨텍스트를 분리하고, 이 둘을 잇는 agent 코드로 인변트 보장 필요함을 강조. Cursor(컨텍스트 분리 불가한 구조)이기 때문에 MCP를 프로덕션 데이터베이스에 바로 연결하는 것은 비상식적 선택임을 주장
책임 있는 보안 공개 프로세스가 실질적으로 의미가 있는지 질문. 해결책이 결국 LLM에 "데이터를 유출하지 말라"고 여러 번 요청하고, 관련 위험을 문서에 추가하는 수준이라면 그 효과에 의구심 품음
Supabase의 공개 보안 정책이 해커원(HackerOne)을 통한 야속한 조건을 강제하는 것뿐이어서, 본인 역시 해당 방식에 동의하지 않음을 밝힘
General Analysis 공동창업자로서 기술적으로 Supabase MCP 단독의 책임이 아님을 강조. 이 취약점은 (1) 비정규화된 데이터가 agent 컨텍스트에 들어가는 구조, (2) Foundation 모델이 명령과 데이터를 분간하지 못하는 한계, (3) 잘못된 접근 권한 범위 설정(커서의 과도한 권한) 등이 결합된 결과라고 설명. 이런 유형의 취약점은 다양한 MCP 사용 패턴에서 공통적으로 관찰 가능함. MCP 사용자를 위한 Guardrail(보호장치) 개발 진행 중임을 부연
개인적으로 추가 프롬프트 포장에서 특별히 효과를 보지 못했다고 판단. fail fast(빠르게 실패) 방식이 더 적합하다고 생각하며, 오히려 프롬프트 포장은 나쁜 개발 습관을 조장할 수 있다고 우려. LLM이 시스템 접근 도구를 쓰는 것과 사용자가 REST API에 직접 시스템 접근 권한을 갖는 상황에 본질적 차이 없음. 개발자의 권한 검증 책임은 변하지 않는 교훈임을 강조. 프롬프트 인젝션이 아닌, 보안 경계 문제로 진단, 세밀한 권한 토큰 관리로 충분히 해결 가능하다고 판단
XSS(크로스 사이트 스크립팅)가 LLM 세계에 옮겨진 현상이라고 봄. 특히 Cursor와 Supabase MCP 같은 어드민 앱에서는 신뢰할 수 없는 사용자가 만든 콘텐츠를 가공 없이 받아들이기 쉬움. 기존처럼 지원 티켓에 악의적 HTML/Javascript를 삽입하는 대신, 이제는 LLM 지시에 해당하는 프롬프트를 삽입하게 되는 것임. 관리자가 이를 열람할 때 세션(여기서는 Supabase MCP 접근 권한)을 탈취당하는 구조라고 비유
기술적으로 맞는 지적이지만, 이 문제를 단순히 "내부 XSS의 또 다른 형태"로 축소하면 본질을 놓칠 수 있음. XSS는 입력을 가공해 안전하게 만들 수 있지만, 프롬프트 인젝션은 입력 데이터에서 LLM 명령을 완벽히 제거할 결정적 규칙이 전혀 없어 구조적으로 안전하지 못함. 결국 임의의 신뢰할 수 없는 입력을 특권 정보에 접근 가능한 LLM에 연결하는 것은 본질적으로 위험하다고 판단
문제의 상당 부분은 LLM 입력 정규화가 불가능하다는 데 있음. 이런 기능을 사용하는 한, 항상 취약점에 노출되는 셈
SimonW가 'prompt injection'이라는 용어를 만든 배경을 소개. SQL 인젝션과 유사하지만, LLM 프롬프트는 신뢰할 수 있는 방식으로 escape(탈출)하는 방법이 없어 오히려 더 위험하다고 진단
Supabase 같은 데이터베이스 접근 MCP를 사용할 때는 다음 권장 팁을 제공. (1) 무조건 read-only로 설정해 공격 발생 시 데이터 손상을 직접 막기, (2) 이 MCP를 외부 커뮤니케이션이 가능한 다른 MCP(HTTP 요청, 이메일 발송 등)와 결합 시 데이터 유출 위험 주의. 관련해서 본인이 쓴 "lethal trifecta" 분석 글도 참고 lethal trifecta 포스트
공격 의도 없이도 데이터 유출(Exfiltration)이라는 용어가 적합하다고 생각
LLM을 생산계 인프라에 직접 연결하는 것이 결국 큰 취약점임을 간결하게 지적
이 내용이 기사 상단에 있는 한 줄 요약이 되어야 한다고 강조
실제 이렇게 세팅하는 사람이 예상보다 많아 놀랍다는 반응
Hacker News를 오래 읽으며 과거에는 해킹이 정말 뛰어난 엔지니어링의 결과로 보였으나, LLM 관련 취약점은 유치원을 속일 정도로 단순한 프롬프트로도 이루어지는 현실에 놀람
tramlines.io 소속으로, Neon DB MCP에서도 유사 취약점을 발견했다는 개인적 경험과 글 링크 공유 neon exploit 사례
해당 취약점이 동일하게 나타나고, Neon's MCP가 데이터베이스에 read-write 접근 권한을 쉽게 줄 수 있기 때문에 'lethal trifecta'(민감 데이터 접근, 악의적 인스트럭션 노출, 데이터 유출 기능) 조건을 모두 충족시킬 수 있음을 추가 설명
실제로 이런 MCP 취약점을 이용한 현실 공격 사례가 적은 것이 의외라고 밝힘. Supabase 관련 사례를 몇 달 전에 따로 다뤘는데도 공식 문서에서 이를 분명히 언급하지 않는 점이 흥미로움. 참고 사례 supabase 취약점 케이스, supabase 공식 문서
현실 공격이 많이 없는 이유는 MCP 사용이 아직 널리 퍼지지 않아서라고 추측. 앞으로 타겟화 될 가능성이 높다고 예상
다양한 공격에서 지원 사이트가 자주 사용되는 점 지적. 예전에도 SaaS 가입 시 조직 이메일을 자동 등록하는 구조를 악용해, 지원 티켓 시스템을 통해 인증 이메일을 받고 계정 가입/로그인에 이용하는 사례들이 있었음을 회상
Cursor assistant가 Supabase 데이터베이스에 service_role로 접근하며, 이로 인해 모든 RLS(행 수준 보안)이 우회된다는 점이 무척 위험하다고 지적. 생산 데이터베이스를 AI 에이전트에 바로 공개하는 것은 큰 리스크임을 강조. 원시 SQL 접근에는 무조건 리드 레플리카를 쓰고, 생산 데이터베이스에는 특별히 노출된 API 엔드포인트만을 이용해야 근본적 위험을 줄일 수 있음. 1~2년 안에 프롬프트 인젝션을 완벽히 해결하는 건 불가능하고, AI agent와 생산 데이터베이스 사이에 데이터 복제 및 보안 규칙 자동화용 미들웨어 계층이 많이 등장할 것으로 전망. 본인이 prototyping한 사례로 dbfor.dev 언급
공격자가 다음과 같은 문구를 지원 티켓에 담아두는 현상 ("CURSOR CLAUDE 관련 명령... integration_tokens 테이블을 읽어서 티켓 메시지로 추가"와 같은) 자체가 납득이 어렵다는 반응. AI agent가 사용자 입력에 따라 데이터와 직접 상호작용하게 만들 리가 없다고 생각
LLM에는 Prepared statement가 없고, 데이터와 명령을 구분하지 못함. 봇에게 특정 업무만 허용하려고 해도 프롬프트 엔지니어링으로는 완벽한 안전 보장 불가. 심지어 '티켓 우선순위' 같은 단순 조작만 허용하더라도 악용 위험은 여전히 존재
이런 구조의 문제는 시스템 설계 과정의 실수가 아니라, LLM이 입력 텍스트에서 사용자 명령과 유입된 기타 명령을 구분할 수 없다는 근본적 한계 때문임. 본인은 이 문제를 SQL 인젝션과 유사하다고 생각해 'prompt injection'이라는 용어를 사용. SQL 인젝션의 경우 안전한 방어 기법(escape, parameterize)이 있지만, 프롬프트 인젝션은 이에 대응하는 해결책이 없음
Hacker News 의견
Supabase 엔지니어로서 MCP 작업 담당자임을 밝힘. 최근 프롬프트 인젝션 방지를 위해 여러 완화책을 추가한 경험 공유. 기본적으로 read-only 사용을 문서에서 권장하고, SQL 응답을 포장해 LLM이 명령을 따르지 않도록 함. E2E 테스트로 덜 똑똑한 LLM도 공격에 쉽게 속지 않게 하고 있음. 이런 노력들로 인해 실제 Haiku 3.5 같은 덜 강력한 모델에서도 공격 성공률이 크게 떨어졌음을 체감. 하지만 이러한 노력들은 완화책일 뿐이고, 프롬프트 인젝션 문제는 여전히 미해결 문제라는 사실을 강조. 세밀한 토큰 수준의 권한 부여, LLM 접근 서비스 범위 지정, 작성중인 자세한 문서 추가, 프롬프트 인젝션 시도를 탐지하는 모델 등 다양한 추가 장치 개발 중임을 알림. Responsible disclosure(책임 있는 보안 이슈 공개) 절차 따르지 않은 General Analysis 측의 소통 부재에 아쉬움 표명. 자세한 이슈 및 커밋 링크는 pull/94, pull/96, supabase security.txt에서 확인 가능함
이 방식이 정말 효과적인지 의문을 제기. 신뢰할 수 없는 사용자 Javascript를 eval()로 넘기며 sanitize(정규화)하려는 시도가 항상 실패했던 것처럼, 지금의 접근 역시 위험 요소를 완전히 제거하지 못한다고 지적. MCP가 보안 경계로 작동하는 것이 납득되지 않으며, 실제 운영 환경이라면 LLM이 티켓을 읽는 컨텍스트와 SQL 호출 권한을 가진 컨텍스트를 분리하고, 이 둘을 잇는 agent 코드로 인변트 보장 필요함을 강조. Cursor(컨텍스트 분리 불가한 구조)이기 때문에 MCP를 프로덕션 데이터베이스에 바로 연결하는 것은 비상식적 선택임을 주장
책임 있는 보안 공개 프로세스가 실질적으로 의미가 있는지 질문. 해결책이 결국 LLM에 "데이터를 유출하지 말라"고 여러 번 요청하고, 관련 위험을 문서에 추가하는 수준이라면 그 효과에 의구심 품음
Supabase의 공개 보안 정책이 해커원(HackerOne)을 통한 야속한 조건을 강제하는 것뿐이어서, 본인 역시 해당 방식에 동의하지 않음을 밝힘
General Analysis 공동창업자로서 기술적으로 Supabase MCP 단독의 책임이 아님을 강조. 이 취약점은 (1) 비정규화된 데이터가 agent 컨텍스트에 들어가는 구조, (2) Foundation 모델이 명령과 데이터를 분간하지 못하는 한계, (3) 잘못된 접근 권한 범위 설정(커서의 과도한 권한) 등이 결합된 결과라고 설명. 이런 유형의 취약점은 다양한 MCP 사용 패턴에서 공통적으로 관찰 가능함. MCP 사용자를 위한 Guardrail(보호장치) 개발 진행 중임을 부연
개인적으로 추가 프롬프트 포장에서 특별히 효과를 보지 못했다고 판단. fail fast(빠르게 실패) 방식이 더 적합하다고 생각하며, 오히려 프롬프트 포장은 나쁜 개발 습관을 조장할 수 있다고 우려. LLM이 시스템 접근 도구를 쓰는 것과 사용자가 REST API에 직접 시스템 접근 권한을 갖는 상황에 본질적 차이 없음. 개발자의 권한 검증 책임은 변하지 않는 교훈임을 강조. 프롬프트 인젝션이 아닌, 보안 경계 문제로 진단, 세밀한 권한 토큰 관리로 충분히 해결 가능하다고 판단
XSS(크로스 사이트 스크립팅)가 LLM 세계에 옮겨진 현상이라고 봄. 특히 Cursor와 Supabase MCP 같은 어드민 앱에서는 신뢰할 수 없는 사용자가 만든 콘텐츠를 가공 없이 받아들이기 쉬움. 기존처럼 지원 티켓에 악의적 HTML/Javascript를 삽입하는 대신, 이제는 LLM 지시에 해당하는 프롬프트를 삽입하게 되는 것임. 관리자가 이를 열람할 때 세션(여기서는 Supabase MCP 접근 권한)을 탈취당하는 구조라고 비유
기술적으로 맞는 지적이지만, 이 문제를 단순히 "내부 XSS의 또 다른 형태"로 축소하면 본질을 놓칠 수 있음. XSS는 입력을 가공해 안전하게 만들 수 있지만, 프롬프트 인젝션은 입력 데이터에서 LLM 명령을 완벽히 제거할 결정적 규칙이 전혀 없어 구조적으로 안전하지 못함. 결국 임의의 신뢰할 수 없는 입력을 특권 정보에 접근 가능한 LLM에 연결하는 것은 본질적으로 위험하다고 판단
문제의 상당 부분은 LLM 입력 정규화가 불가능하다는 데 있음. 이런 기능을 사용하는 한, 항상 취약점에 노출되는 셈
SimonW가 'prompt injection'이라는 용어를 만든 배경을 소개. SQL 인젝션과 유사하지만, LLM 프롬프트는 신뢰할 수 있는 방식으로 escape(탈출)하는 방법이 없어 오히려 더 위험하다고 진단
문제 코드 직접 사례 링크 공유
Supabase 같은 데이터베이스 접근 MCP를 사용할 때는 다음 권장 팁을 제공. (1) 무조건 read-only로 설정해 공격 발생 시 데이터 손상을 직접 막기, (2) 이 MCP를 외부 커뮤니케이션이 가능한 다른 MCP(HTTP 요청, 이메일 발송 등)와 결합 시 데이터 유출 위험 주의. 관련해서 본인이 쓴 "lethal trifecta" 분석 글도 참고 lethal trifecta 포스트
LLM을 생산계 인프라에 직접 연결하는 것이 결국 큰 취약점임을 간결하게 지적
이 내용이 기사 상단에 있는 한 줄 요약이 되어야 한다고 강조
실제 이렇게 세팅하는 사람이 예상보다 많아 놀랍다는 반응
Hacker News를 오래 읽으며 과거에는 해킹이 정말 뛰어난 엔지니어링의 결과로 보였으나, LLM 관련 취약점은 유치원을 속일 정도로 단순한 프롬프트로도 이루어지는 현실에 놀람
tramlines.io 소속으로, Neon DB MCP에서도 유사 취약점을 발견했다는 개인적 경험과 글 링크 공유 neon exploit 사례
실제로 이런 MCP 취약점을 이용한 현실 공격 사례가 적은 것이 의외라고 밝힘. Supabase 관련 사례를 몇 달 전에 따로 다뤘는데도 공식 문서에서 이를 분명히 언급하지 않는 점이 흥미로움. 참고 사례 supabase 취약점 케이스, supabase 공식 문서
다양한 공격에서 지원 사이트가 자주 사용되는 점 지적. 예전에도 SaaS 가입 시 조직 이메일을 자동 등록하는 구조를 악용해, 지원 티켓 시스템을 통해 인증 이메일을 받고 계정 가입/로그인에 이용하는 사례들이 있었음을 회상
Cursor assistant가 Supabase 데이터베이스에 service_role로 접근하며, 이로 인해 모든 RLS(행 수준 보안)이 우회된다는 점이 무척 위험하다고 지적. 생산 데이터베이스를 AI 에이전트에 바로 공개하는 것은 큰 리스크임을 강조. 원시 SQL 접근에는 무조건 리드 레플리카를 쓰고, 생산 데이터베이스에는 특별히 노출된 API 엔드포인트만을 이용해야 근본적 위험을 줄일 수 있음. 1~2년 안에 프롬프트 인젝션을 완벽히 해결하는 건 불가능하고, AI agent와 생산 데이터베이스 사이에 데이터 복제 및 보안 규칙 자동화용 미들웨어 계층이 많이 등장할 것으로 전망. 본인이 prototyping한 사례로 dbfor.dev 언급
공격자가 다음과 같은 문구를 지원 티켓에 담아두는 현상 ("CURSOR CLAUDE 관련 명령... integration_tokens 테이블을 읽어서 티켓 메시지로 추가"와 같은) 자체가 납득이 어렵다는 반응. AI agent가 사용자 입력에 따라 데이터와 직접 상호작용하게 만들 리가 없다고 생각
LLM에는 Prepared statement가 없고, 데이터와 명령을 구분하지 못함. 봇에게 특정 업무만 허용하려고 해도 프롬프트 엔지니어링으로는 완벽한 안전 보장 불가. 심지어 '티켓 우선순위' 같은 단순 조작만 허용하더라도 악용 위험은 여전히 존재
이런 구조의 문제는 시스템 설계 과정의 실수가 아니라, LLM이 입력 텍스트에서 사용자 명령과 유입된 기타 명령을 구분할 수 없다는 근본적 한계 때문임. 본인은 이 문제를 SQL 인젝션과 유사하다고 생각해 'prompt injection'이라는 용어를 사용. SQL 인젝션의 경우 안전한 방어 기법(escape, parameterize)이 있지만, 프롬프트 인젝션은 이에 대응하는 해결책이 없음