AI가 취약점을 찾아냈다는 소식을 접하면 발견한 모델과 공격의 심각도에 먼저 눈길이 갑니다. 하지만 서비스를 운영하는 입장에서는 그다음이 궁금합니다. 누가 수정 방식을 결정하고, 언제 정보를 공개하며, 내 서버에 수정된 코드가 실행 중이라는 사실은 어떻게 확인할 수 있을까요. 2026년 10월 21일 OpenAI는 Patch the Planet의 PHP 대응 사례와 취약점 공개를 조율하는 방안을 발표했습니다. OpenAI의 설명에 따르면 Calif가 GPT-5.6 Sol을 활용해 중대한 결함을 찾았고, Wiz도 두 취약점을 독립적으로 발견해 보고했습니다. 수정과 릴리스는 PHP 유지관리자들이 주도했습니다. ...
2026-09-11 정정: A2A와 MCP의 필수 보안 요구사항을 반영하고, 기존 검증 연구와 이력 기반 통제의 적용 범위를 명확히 했습니다. 사내 문서를 검색하고 요약해서 메일로 보내는 에이전트를 하나 상상해 보겠습니다. 이 에이전트에는 세 가지 도구가 붙어 있습니다. 문서 검색, 문서 본문 읽기, 메일 발송입니다. 세 도구는 각각 정당한 권한을 받았고, 호출 한 건씩 떼어 놓고 보면 어느 것도 규칙을 어기지 않습니다. 검색은 읽기 전용이고, 본문 읽기도 사용자가 접근 권한을 가진 문서만 반환하며, 메일 발송은 사용자가 명시적으로 요청한 기능입니다. ...
지난 몇 년간 LLM 애플리케이션의 보안 논의는 대체로 prompt injection에 집중되어 있었습니다. 신뢰되지 않은 텍스트가 모델의 지시 사항인 척 끼어드는 문제입니다. 그런데 이 논의의 전제 하나가 조용히 바뀌었습니다. 초기의 LLM 호출은 요청 하나가 끝나면 그 세션의 상태도 함께 사라지는 stateless 구조였지만, 지금의 에이전트는 대화·경험·선호를 세션 경계 너머로 저장하는 지속 메모리를 기본으로 갖추고 있습니다. 그런데 지속 메모리는 편의만 가져온 게 아닙니다. 새로운 attack surface도 함께 열렸습니다. Prompt injection의 payload는 응답이 끝나면 컨텍스트와 함께 사라집니다. 하지만 그 payload가 메모리 쓰기 한 번을 성공시키면, 원본 텍스트가 사라진 뒤에도 저장된 항목은 남습니다. 이 글에서는 이것을 “payload는 휘발되지만 쓰기 결과는 잔존한다"는 성질로 부르겠습니다. memory poisoning을 prompt injection과 따로 다뤄야 하는 것도 이 때문입니다. ...