글 안에 다른 사이트에 올리라는 문장이 있다고 작업 대상까지 바뀌면 안 된다. 방문한 페이지가 권한을 더 달라고 해도 사용자의 새 지시가 되는 것은 아니다. 북극성에서는 읽는 자료와 작업 요청의 출처를 구별하고, 그 구분을 실제 도구 호출 검사까지 이어가려 했다.
같은 문장도 어느 경로로 왔는지가 다르다
페이지 본문, 참고 자료, 예시 원고에는 명령형 문장이 있을 수 있다. 문장의 모양만으로 사용자의 새 요청이라고 판단하면 읽기 작업이 다른 행동으로 바뀐다. request-sites의 설계는 현재 human message만 routing 입력으로 보고 page·history·skill이 새 목적지를 만들지 않도록 범위를 정한다.
하지만 함수가 문자열 하나를 받는다는 사실도 한계다. 호출자가 페이지 본문을 현재 요청인 것처럼 잘못 넘기면 모든 의미를 자동 인증해 주는 함수는 아니다. 신뢰할 수 있는 입력 경로를 지키는 책임과 문장을 해석하는 규칙은 함께 필요하다. 나는 작은 파서를 완전한 프롬프트 공격 방지기로 소개하지 않는다.
원고의 제목과 본문은 이동 지시에서 분리한다
현재 구현은 한국어 제목·본문 필드가 짝으로 나타나면 그 앞부분까지만 routing 지시로 본다. 원고 안의 플랫폼 이름이나 계정 예시가 작성 위치를 덮지 않도록 한 좁은 휴리스틱이다. 모든 언어와 임의의 문서 형식을 자동 이해한다는 약속은 아니다.
시험은 현재 작성 탭을 지정한 뒤 원고 안에 다른 계정과 서비스 예시, 주소가 들어가도 원래 destination이 유지되는지 본다. 반대로 원고 필드 앞에서 명시한 계정 선택은 보존하고 모르는 계정은 ambiguous로 남긴다. 모호함을 편리한 기본 계정으로 덮지 않는 것이 중요하다. 본문을 무시하는 것과 사용자가 실제로 고른 대상을 무시하는 것은 다르다.
참고 사이트와 올릴 사이트도 같은 언급이 아니다
requestSites는 특정 서비스의 이름만 봐서 모두 새 목적지로 삼지 않는다. 관련 주제 설명이나 어떤 매체에 쓸 자료라는 말, 부정 표현을 구별하고 참고와 destination의 역할을 나눈다. source 내용을 읽어 가져오는 일과 그곳에 작성하는 일은 다른 권한을 요구하기 때문이다.
이 역할 분류는 작은 문자열 규칙이므로 오해 가능성이 남는다. 코드가 특정 문장을 분류했다는 사실을 실제 로그인 계정과 게시 권한이 맞다는 증거로 바꾸지 않는다. 뒤의 탭·프로필·작업 범위 검사가 필요하다. 더 똑똑한 해석을 추가하더라도 그 분류 하나로 나머지 검사를 건너뛸 수는 없다.
본문이 오류 이름을 말해도 실행 상태는 호스트가 정한다
ActionBroker는 실제 요청을 ToolCall 스키마로 검사하고 작업의 epoch·상태, 선택한 탭의 소유와 프로필·프로젝트를 확인한다. prepared·dispatched 기록과 기다리는 결과도 호스트의 경계다. 페이지에 오류 코드나 확인 문장이 적혀 있다고 그 값이 실제 전달 상태가 되지는 않는다.
복구의 ToolExecutionError도 호스트가 분류한 실패를 표현한다. 모델이나 페이지가 말한 실패 이유가 자동으로 새 재시도 권한을 만들면 안 된다. 다만 형식과 범위 검사가 사용자의 의도에 맞는 모든 의미를 입증하는 것은 아니다. 나는 기계적으로 확인한 경계와 계속 판단해야 할 내용을 서로 다른 층으로 남겼다.
검사한 사례와 모든 공격 차단을 구별한다
이번에는 현재 파서·broker·구조화 시험을 읽었고 실제 악성 사이트나 새로운 모델 공격 시험을 실행하지 않았다. 원고가 목적지를 바꾸지 않는 fixture는 구체적 회귀 근거지만 모든 형태의 지시 주입을 막았다는 인증은 아니다. 과거 위협 모델의 알파 문구도 현재 전체 제품의 보장으로 가져오지 않는다.
관련 합성 작업 문맥 모듈은 요청에 묶인 범위를 비교하는 실험이다. 원문이 어디에서 왔는지 실제로 인증하는 도구는 아니다. 독자가 적용할 것은 문장의 설득력보다 입력의 출처를 먼저 나누고, 실제 행동 경계에서 현재 요청과 대상·결과를 다시 확인하는 순서다. 읽기 편의가 새 권한으로 커지지 않게 한 판단을 공유한다.