프롬프트 인젝션이 에이전트형 AI에서 SQL 인젝션이 웹 앱에 가졌던 위치와 같다는 비유는 이상함. 프롬프트 인젝션은 SQL 인젝션보다 LLM에 훨씬 치명적인 것 아닌가 싶음
SQL 인젝션은 사용자 입력이 SQL 엔진에 전달되는 명령 문자열 일부가 되면서 생겼고, 악성 입력이 SQL 문법 토큰으로 현재 명령을 끝낸 뒤 자기 SQL 명령을 붙이면 엔진이 둘 다 실행했음. 해결책은 준비된 문장처럼 고정·정적·사전 컴파일된 명령 문자열을 쓰고, 임의 사용자 입력은 데이터로만 적용하는 것이었음
에이전트에서 비슷한 완화책은 “repo 1 읽기”, “repo 2 읽기” 같은 고정 동작을 두고 사용자 입력은 어떤 동작을 실행할지 고르는 데이터로만 쓰는 방식인데, 이건 이미 메뉴라고 부르는 기술임. LLM의 가치는 본질적으로 메뉴 이상이라는 데 있고, SQL의 가치는 “임의 데이터에 적용되는 사전 정의 로직” 이상일 필요가 없다는 점이 다름

맞음. SQL 인젝션은 사용자 입력을 순수 데이터가 아니라 명령의 일부로 취급해서 생겼고, 둘을 분리하니 해결됐음. 프롬프트 인젝션은 사용자 입력 자체가 명령으로 의도되기 때문에 피하기 어려움

“해결책은 준비된 문장”이라기보다 핵심은 매개변수 바인딩임. 매개변수를 SQL 문장과 따로 제출해 코드와 사용자 데이터를 분리하는 것임
에이전트에 제한된 동작만 허용하는 건 일부 특수 문제만 다루며, 코드와 사용자 데이터를 분리하지도 않으니 같은 문제가 아님. 제한된 동작만 두는 건 더 엄격한 데이터베이스 권한을 쓰는 것에 가까움. 사용자가 어차피 실행할 수 있는 SQL만 허용된다면 SQL 인젝션도 별 의미가 없어짐

SQL 인젝션과 같은 유형의 문제이긴 하지만, 해결 난이도는 같지 않음. 더 미묘한 문제가 많이 생길 수 있지만 설명용 비유로는 괜찮은 편임
메뉴에서 고르게 하는 것도 한 방법이지만 가능한 행동 범위는 더 넓게 설계할 수 있음. 이메일 도구를 주면 고객에게 스팸을 보낼 수 있고, 답장만 가능하도록 잠그면 사고 범위를 줄일 수 있음. 이미지 렌더링으로 데이터가 새는 식의 취약점처럼, 데이터 유출도 제한해야 함

프롬프트 인젝션은 치명적이지도 않고, 사실상 진짜 문제라기보다 밑바탕의 보안 아키텍처 문제를 드러내는 것에 가까움. 인간 대상 사회공학 공격과 비슷함
해결책도 같음. 최소 권한의 역할 기반 접근 제어를 적용하고, 중요한 행동에는 관리자 승인을 요구하면 됨. 그러면 LLM이 혼자 할 수 있는 최악은 부적절한 단어를 출력하는 정도임

이게 모두가 생각하는 만큼 깊은 문제인지 확신이 안 듦. SQL 인젝션도 똑같이 위험함. 쿼리 사용자가 수행할 수 있는 모든 데이터베이스 작업에 무제한 접근을 열어주기 때문임
완화책 중 하나는 준비된 문장이지만, 다른 하나는 어떤 사용자에게도 데이터베이스 전체 접근을 허용하지 않는 것임. 읽기 전용 사용자는 SQL 인젝션 여부와 무관하게 DROP TABLE을 할 수 없어야 함
이 에이전트는 무제한 읽기 접근을 갖고 있고, 답변의 “수신자” 개념이 없음. 수신자의 권한을 포함시키면 자동으로 읽기 접근이 거부되게 만드는 건 꽤 단순함. 유일한 해결책은 아니지만 그런 방향의 해법을 떠올리기 어렵지 않음
“메뉴” 예시는 달라진 게 없다는 뜻이기도 함. LLM이든 인간 직원이든 허용되는 건 통제된 고정 행동 집합뿐임. 자유도는 주로 표현에 있고, 권한 부여는 고정 집합임. 왜 메뉴 이상이어야 하는지 모르겠음

이게 왜 GitHub 취약점인지 모르겠음. 연구자들이 에이전트에 비공개 저장소 접근 권한을 주고, 공개 저장소에서 질문에 답하게 했으니 당연히 비공개 정보 추출이 가능함
비밀값에 접근 가능한 일반 CI 작업을 만들어 공개 PR에서 실행하는 것과 같음. 공개 코드나 LLM 지시가 민감한 것에 접근 가능한 문맥에서 실행되도록 GitHub를 설정하면 유출됨. 그건 GitHub 잘못이 아니라 설정한 사람 잘못임

현재 질문하는 저장소에만 권한이 제한되고, 비공개 저장소까지는 포함되지 않는다고 가정한 것 같음. 양쪽 논리 모두 이해는 감

GitHub가 에이전트 접근을 안전하게 설정하기 쉽게 만들어주지는 않음. 일반 접근 토큰과 앱 자격 증명은 비공개 저장소에 직접 접근시키기엔 세분화된 제어가 충분하지 않음
토큰 범위를 빡빡하게 잡아도 공개 저장소 접근은 항상 허용되고, 예를 들어 공개 저장소 이슈를 통한 유출 경로가 남음. 안전하게 하려면 GitHub가 제공하는 것보다 더 엄격한 제어를 구현하는 MITM 프록시로 보완해야 함
GitHub Agentic workflows가 이런 문제를 위한 공식 1차 해결책일 텐데, 보안 모델이든 안전한 사용성 측면이든 아직 할 일이 있어 보임
자세한 내용: https://haulos.com/blog/do-not-give-your-agent-github-access...

이런 프롬프트 인젝션 공격의 핵심에는 에이전트 권한 범위를 제대로 제한하지 못한 문제가 있음. 이 경우 실제로 에이전트가 해야 하는 일에 따라 저장소별로 별도 워크플로 에이전트를 두거나, 더 넓은 저장소 접근권을 가진 에이전트를 두되 허용 목록의 사용자에게만 트리거되도록 설정할 수 있음
공개 개발과도 양립 가능하고, 외부인이 공개 이슈를 여는 것도 허용하면서 각 사용자에게 둘 신뢰 수준을 반영할 수 있음. 제대로 생각해보면 선택지는 더 많을 것임
그러려면 세밀한 범위 지정과 권한을 기술적으로 지원해야 하고, 에이전트로 무엇을 달성할지와 그에 필요한 최소 권한·기능을 시간을 들여 따져야 함
첫 번째는 올 것 같음. 아직 에이전트 사용은 서부 개척 시대임. 사람이 에이전트를 설계할 때 범위와 권한을 찾고 정의하는 마찰을 줄이는 추상화, 에이전트 기능을 제한할 때 세밀함과 사용성 사이의 균형을 잡는 인터페이스가 무엇이 될지 흥미로움
두 번째는 늘 고품질 소프트웨어 구축을 막아온 핵심 장애물임. 제대로 생각하고 제대로 구현할 시간을 들이는 일은 “빠르게 움직이고 부수기” 식으로 에이전트를 아무 데나 던지는 방식과 정면으로 어긋남

에이전트형 워크플로별로 접근을 나눠서, 하나는 민감한 데이터에 접근하고 다른 하나는 공개 데이터에만 접근하게 할 수 있는 방법이 있는가? 기본값은 현재 저장소로만 범위를 제한하는가? GitHub가 비공개 저장소 데이터 접근과 에이전트형 워크플로 결합의 위험을 적절히 알려주는가?
이 질문 중 하나라도 답이 “아니오”라면 문제임. 고전적인 GitHub Workflows도 PR 트리거 워크플로를 통한 권한 상승이 잔뜩 있지만 그건 별도 주제임

권한 관점에서 LLM은 그냥 멍청한 터미널임. 원하는 건 프롬프트를 바탕으로 즉석에서 합성 권한을 만드는 것처럼 보이는데, 이건 “준비된 문장” 해법이 아니라 “정규식으로 사용자 SQL 문을 깨끗이 만들겠다”에 가까움. 그 결말은 이미 잘 앎
진짜 해법은 프롬프트별 권한 제어 UI를 더 좋게 만드는 것임. “웹 검색 여부”를 고르듯 “내 비공개 저장소 포함” 옵션을 쉽게 켜고 끌 수 있어야 함

연구자들이 “Additionally” 같은 단어 하나로 GitHub가 자랑하던 가드레일을 우회하는 모습이 웃김. LLM 문맥 창 안에 강한 보안 경계를 세우려는 시도는 실패할 수밖에 없다는 걸 보여줌
모델은 본질적으로 지시를 따르도록 만들어졌기 때문에, 시스템 규칙과 사용자 입력을 섞으면 더 최신이거나 더 집요한 지시가 이기게 됨

“책임 있는 공개” 섹션에 언제 수정됐는지, GitHub가 인정했는지 거부했는지가 왜 없을까? GitLost가 GitHub에 책임 있게 공개됐고 세부 정보는 GitHub가 아는 상태에서 공유한다고 되어 있는데, 아직 고치지 않은 건가?

이건 일반적인 소프트웨어 버그가 아니고, 일반 지원 직원이 속는 일을 “수정”할 수 없는 것처럼 같은 방식으로 고칠 수 없음. 답은 LLM에 신뢰할 수 없는 입력과 민감한 데이터를 동시에 접근시키지 않는 것임

뭘 고친다는 건가? LLM에 비공개 데이터 접근권과 공개 댓글 읽기 능력을 함께 준 것뿐임. 그냥 잘못된 설정임

Microsoft 같은 대기업은 투자자 압박 때문에 이제 AI 회사라고 주장하려고 모든 제품에 AI를 얹고 있음. Adobe가 했던 것과 비슷함
소비자는 이런 반쯤 만든 AI 통합에 지쳐가고 있고, 곧 한계점이 올 것 같음

난 끝났음. Forgejo로 옮김. 훌륭하고 모든 게 더 잘 동작함
진지하게, 여기저기 클릭할 때 모든 게 즉각적이고 러너를 붙인 CI도 아름답게 돌아감. 러너 설정 문서는 조금 더 명확할 수 있지만, 그 외에는 전부 너무 매끄러웠음

Microsoft는 상장사임. 어떤 투자자가 원치 않는 AI 기능으로 GitHub를 망치게 압박하고 있는 건가? 어느 자리에서 그런 일이 벌어짐?

동의하지만 기업용 AI 제품은 꽤 인상적이라고 봄. 투자자와 소비자는 잘 모르고, 직원은 거래할 수 없음
매출은 실제로 존재하고 인상적이며, 소비자·좌석 기반 매출을 대체하고 있음. 시장은 아직 SaaS 배수를 낮추는 중인데 그 판단은 맞다고 봄. 분기 보고서에서 매출을 분리해 보면 실제 효율성에서 나온 큰 성장 스토리가 있음

공개 저장소 문맥에서 실행되는 액션이 왜 비공개 저장소 접근권을 갖고 있었는지 모르겠음. 워크플로를 보면 보통 비공개 저장소 권한을 주지 않는 github token을 쓰는 것처럼 보임
아니면 에이전트 자체가 somehow 더 높은 권한을 갖고 있었던 건가? 그렇다면 에이전트를 잘못 설정한 것임. 에이전트가 무엇인가를 강제한다고 믿으면 안 된다는 건 이미 알고 있음

이 글은 Noma 마케팅처럼 읽힘. 귀여운 이름, 로고, 낚시성 제목, 비기술 독자를 겨냥한 듯한 극적인 톤까지 있음
실제 취약점이 뭔가 하면, LLM에 비공개 데이터를 주고 아무나 상호작용하게 하면 데이터가 샐 수 있다는 것임. 너무 당연함

이런 사람들은 LLM에 디스크 전체 쓰기 권한을 주고 파괴적인 작업을 했다고 불평할 것임
AI 에이전트가 비공개 저장소를 읽지 않게 하려면 비공개 저장소 접근권을 주지 않으면 됨. 이건 권한 우회 문제가 아니라 프롬프트 인젝션 문제이고, 에이전트 계층에서 신뢰성 있게 해결할 수 없음

이미 해결된 문제이거나, 아직 GitHub가 해결하지 못했고 그 사이 악의적 행위자가 저장소들에 취약점을 시도할 것임
저장소 수가 많으니 0이 아닌 확률로 유출이 생길 수 있음. 다만 사기 피해처럼 거의 아무도 유출을 인정하지 않을 것임