AI 에이전트가 맡은 일의 범위 안에서 움직이려면

AI 에이전트는 사람의 요청이나 정해진 업무에 따라 도구를 사용해 자료를 찾고, 파일을 만들거나 다른 시스템에서 작업하는 프로그램입니다. 기능이 많아질수록 누구의 요청으로 어떤 자료를 이용하고, 어디까지 작업하며, 결과를 누구에게 전달할 수 있는지 분명해야 합니다.

이 제안은 업무에 필요한 접근 범위를 정하고, 외부 자료에 섞인 지시나 결과물 전달 과정에서 그 범위를 넘지 않는지 확인할 설명·절차·지원을 다룹니다. AI가 읽을 수 있는 정보와 대화 중인 사용자에게 보여줄 수 있는 정보의 차이도 함께 살펴봅니다.

누구를 대신해 어떤 자료를 이용하는지 정해야 합니다

사용자를 대신하는 에이전트에는 해당 사용자의 권한과 맡긴 일의 범위가 함께 적용되어야 합니다. 로그인하지 않은 방문자에게 공개 정보만 제공하는지, 다른 사용자의 대화나 파일이 섞이지 않는지 확인할 필요가 있습니다. 이전 업무에서 기억해 둔 자료도 새로운 사용자나 업무에 그대로 사용할 수 있는지 구분해야 합니다.

내부 운영 자료를 넓게 읽는 에이전트를 고객 응대에도 그대로 사용하면, 문의와 무관한 자료가 답변에 섞일 수 있습니다. 모든 자료를 읽게 한 뒤 답변에서 가리도록 맡기기보다, 처음부터 업무에 필요한 자료와 항목만 제공할 수 있도록 범위를 정하는 방안을 제안합니다.

운영용 에이전트에도 업무를 맡긴 주체, 접근할 자료와 결과를 받을 사람이 분명해야 합니다. 개인별 정보가 필요하지 않은 업무라면 일부를 가린 값이나 건수·합계로 처리할 수 있는지도 검토할 수 있습니다.

필요한 도구를 제공하고 실행 단계에서도 제한해야 합니다

도구는 파일 조회, 주문 취소, 메시지 발송처럼 에이전트가 실행할 수 있는 기능을 말합니다. 처음부터 모든 도구와 권한을 제공하기보다 맡긴 업무에 필요한 기능을 구분할 수 있어야 합니다. 가상의 주문 서비스에서 상태 확인을 맡겼다면 조회 기능만 제공하고, 이후 취소 요청이 생겼을 때 그 작업의 권한과 대상을 별도로 확인하도록 구성할 수 있습니다.

도구 목록에서 기능을 숨기거나 지시문에 사용하지 말라고 적는 것만으로 실행 권한까지 제한되는 것은 아닙니다. 도구와 연결된 시스템에서도 요청한 자료와 작업이 허용된 범위인지 확인해야 합니다. 읽기와 생성·수정·삭제를 구분하고, 검색 조건을 바꾸어도 허용되지 않은 자료가 반환되지 않는지 살펴야 합니다.

사용자가 누구인지와 승인 범위는 서비스가 확인한 정보를 기준으로 판단해야 합니다. 에이전트가 필요하다고 주장하거나 외부 자료에 허락받았다고 적혀 있다는 이유만으로 권한을 늘려서는 안 됩니다. 별도 승인이 필요한 작업은 대상, 변경 내용과 전달받을 사람이 드러나게 준비하고, 권한이 있는 사람이 검토할 수 있어야 합니다. 거부된 작업을 다른 계정이나 도구로 우회하지 않는지도 확인할 필요가 있습니다.

외부 자료의 설명과 작업 지시를 구분해야 합니다

웹페이지, 이메일과 문서는 업무에 참고할 자료입니다. 그 안에는 틀리거나 오래된 설명뿐 아니라, AI가 맡은 일이나 제한을 벗어나도록 유도하는 지시가 섞일 수도 있습니다. 이런 지시 주입을 프롬프트 인젝션이라고 합니다. 자료를 읽는 행위가 새 작업을 승인하는 행위로 바뀌지 않도록 설명과 제한이 필요합니다.

가상의 예로, 보고서 요약을 맡겼는데 보고서 안에 다른 내부 파일을 찾아 외부로 보내라는 문구가 들어 있을 수 있습니다. 이 문구는 보고서 내용의 일부이며, 다른 파일을 읽거나 전송할 권한을 주지는 않습니다. 익숙한 관리자 이름이나 신뢰하는 출처가 표시되어 있어도, 정보의 출처 확인과 작업 승인은 구분해야 합니다.

중요한 판단에 쓰는 정보는 출처와 작성 시점, 확인 근거를 살펴보고 미확인 내용은 따로 표시할 필요가 있습니다. 숨은 글자나 지시처럼 보이는 문구를 검사하는 일은 확인을 도울 수 있지만, 눈에 보이는 자연스러운 문장에도 유도가 담길 수 있으므로 검사 통과를 안전의 보증으로 삼아서는 안 됩니다.

공유 파일과 메모리가 권한 부여나 검증을 대신하지 않아야 합니다

여러 에이전트가 함께 읽고 쓰는 파일이나 공유 메모리에는 추측이나 요약 오류가 사실처럼 남을 수 있습니다. 여기서 공유 메모리는 에이전트들이 이후 작업에서도 꺼내 쓰도록 저장한 정보를 뜻합니다. 외부 자료의 잘못된 지시가 이런 공유 공간에 옮겨진 뒤, 다른 에이전트가 승인된 절차로 받아들이는 문제도 살펴야 합니다. 내부에 저장되었거나 여러 에이전트가 같은 내용을 반복한다는 이유만으로 검증이 끝난 것은 아닙니다.

공유 자료에는 원래 출처, 작성·수정한 주체와 시점, 검토 상태를 남기는 방안을 제안합니다. 작업 중 쌓인 기록과 승인된 운영 기준을 구분하고, 파일을 수정하거나 메모리를 갱신할 수 있는 권한이 다른 에이전트의 권한을 바꾸는 데까지 이어지지 않도록 해야 합니다.

잘못된 내용이 발견되면 사용과 전달을 멈추고, 복사본과 요약본, 각 에이전트가 별도로 저장한 정보에도 같은 내용이 남았는지 확인할 필요가 있습니다. 원문 정정만으로 이미 진행한 작업이나 파생 자료까지 바로잡히지는 않습니다. 영향을 검토하고 정정 내용을 전달할 담당자와 절차가 필요합니다.

입력과 출력의 확인이 실제 권한 제한과 이어져야 합니다

민감한 자료를 읽거나 중요한 작업을 실행하는 에이전트에는 위험한 지시와 정보 노출을 줄이는 보호 장치가 필요할 수 있습니다. 이를 가드레일이라고 부릅니다. 읽을 자료와 실행 가능한 작업에 맞춰 사용자 요청, 외부 자료와 다른 에이전트가 공유한 파일·메모리의 내용을 확인하고, 내보낼 답변·파일·메시지도 살펴보는 방안을 제안합니다.

의심스러운 입력이나 공개 범위를 벗어나는 출력이 발견되면 해당 작업과 전달을 멈추고 검토할 수 있어야 합니다. 이 장치도 문제를 놓칠 수 있으므로 통과했다는 이유로 도구와 서버의 권한 확인을 생략해서는 안 됩니다. 사람이 검토할 경우에도 무엇을 확인해야 하는지와 실제로 중단할 권한이 있는지까지 준비되어야 합니다.

보호 장치가 자주 업무를 막거나 필요한 작업을 구분하지 못한다면 운영자가 제한을 임의로 해제하도록 두기보다, 오판을 검토하고 허용 범위를 조정할 경로가 필요합니다. 업무를 이어 갈 방법과 범위를 지킬 방법을 함께 마련해야 합니다.

중요한 조건은 코드로 정한 규칙에 따라 검증해야 합니다

AI가 여러 차례 비슷하게 응답하거나 제한을 지켰더라도, 이후의 모든 작업에서 같은 결과가 나온다고 볼 수는 없습니다. 대화 맥락과 참고 자료, 도구가 돌려준 결과에 따라 판단과 선택할 작업이 달라질 수 있습니다. 잘못된 판단을 반복하는 경우도 있으므로, 결과가 일정하다는 사실과 올바르게 동작한다는 사실은 구분해야 합니다.

온도(temperature)는 생성할 내용의 후보를 얼마나 다양하게 선택할지 조절하는 설정입니다. 이 설정을 제공하는 모델에서는 온도를 낮추면 결과가 비슷해지는 경향이 있지만, 낮은 값이나 0으로 설정했다는 사실만으로 동일한 동작이나 정확성·안전성이 보장되지는 않습니다. 결과의 변동을 줄이는 설정과 허용 범위를 지키게 하는 제한은 별도로 마련할 필요가 있습니다.

사용자의 권한과 승인 여부, 접근할 자료와 실행할 작업의 범위처럼 명확한 조건으로 정할 수 있는 항목은 프로그램 코드에 규칙을 두고, 실제 작업을 처리하는 서버나 도구에서 검증하도록 제안합니다. 다음은 가상의 서비스에서 확인할 조건의 예시입니다.

AI가 “허용된 작업”이라고 답하거나 요청에 승인되었다고 적었다는 이유로 검증을 통과해서는 안 됩니다. 시스템이 확인한 사용자 정보와 권한, 승인 기록을 기준으로 판단하고, 조건을 충족하지 않거나 확인할 수 없다면 실행을 멈춰야 합니다. AI가 사용하는 다른 도구나 계정으로 이 검증을 우회하거나 검증 규칙 자체를 임의로 바꾸지 못하도록 권한도 구분할 필요가 있습니다.

문장의 맥락이나 자료 공개의 적절성처럼 규칙만으로 판단하기 어려운 부분은 AI의 분석과 사람의 검토로 보완할 수 있습니다. 코드로 만든 검증에도 오류나 누락이 있을 수 있으므로, 허용되는 요청과 거부되어야 할 요청을 함께 시험하고 적용한 규칙을 관리할 담당자를 정해야 합니다. AI의 응답이 달라져도 필요한 제한이 유지되는지 확인할 수 있도록, 반복 점검과 실행 기록을 검토할 지원을 함께 마련하는 것이 중요합니다.

읽을 수 있는 파일과 전달할 수 있는 결과물을 구분해야 합니다

에이전트의 작업 공간에는 사용자가 맡긴 자료뿐 아니라 내부 운영 파일이나 다른 사용자의 자료가 있을 수 있습니다. 그 공간에 접근할 수 있다는 사실이 모든 파일을 사용자에게 제공할 권한을 뜻하지는 않습니다. 파일을 하나씩 전달하거나 압축하고, 내용을 답변에 붙여 넣는 경우에도 받는 사람의 권한을 확인해야 합니다.

내부 자료를 결과물 폴더로 복사하거나 다운로드 링크를 만들었다고 공개 가능한 자료로 바뀌는 것은 아닙니다. 사용자가 받을 수 있는 파일의 범위를 정하고, 실제 파일을 읽어 주거나 전달하는 기능도 그 범위를 확인할 수 있어야 합니다.

출력 확인에는 내용뿐 아니라 받는 사람과 전달 경로도 포함할 필요가 있습니다. 같은 결과라도 내부 검토자에게 보내는 것과 외부 사용자에게 제공하는 것은 허용 범위가 다를 수 있습니다. 전달 전에 판단할 자료를 제공하고, 전달 결과를 확인할 수 있도록 지원해야 합니다.

사용 현황과 종료할 권한을 관리해야 합니다

에이전트를 업무마다 추가하다 보면 무엇이 실행 중이고 누가 관리하는지 파악하기 어려워질 수 있습니다. 이름과 용도, 담당자, 연결된 계정과 자료, 허용한 도구와 권한을 확인할 수 있는 목록을 제안합니다. 담당자가 바뀌면 목록과 미확인 사항을 함께 넘겨 관리가 끊기지 않도록 해야 합니다.

맡긴 일이 끝나거나 사용할 이유가 없어졌다면 실행을 중지하고 필요 없어진 계정 연결과 권한을 정리할 수 있어야 합니다. 권한을 바꾼 뒤의 요청에도 변경이 반영되는지, 남은 작업이나 임시 파일을 누가 처리할지도 확인해야 합니다. 사용을 중단하는 절차가 있어야 제한을 벗어난 동작을 발견했을 때도 대응할 수 있습니다.

답변과 실제 작업을 함께 점검해야 합니다

점검용 사용자와 자료로 허용되는 요청과 거부되어야 할 요청을 함께 확인할 필요가 있습니다. 다른 사용자의 자료 요구, 맡기지 않은 수정이나 발송, 외부 문서에 섞인 지시, 공유 파일·메모리를 통한 권한 변경, 여러 파일을 묶어 전달하는 요청 등이 점검 상황에 포함될 수 있습니다. 실제 개인정보나 비공개 자료를 불필요하게 점검에 사용하지 않도록 준비해야 합니다.

AI가 거절했다고 답했더라도 그 전에 자료를 읽거나 작업을 실행했을 수 있습니다. 답변과 함께 누구의 요청으로 어떤 자료를 이용했고 무슨 작업을 했으며 어디로 전달했는지 실제 기록을 확인해야 합니다. 기록에는 필요한 작업 사실을 남기되, 비공개 원문이나 대화 전체를 불필요하게 복사하지 않아야 합니다.

확인한 범위와 미확인 부분을 나누어 남기고, 모델·도구·권한 구성이 바뀌면 관련 항목을 다시 살펴볼 필요가 있습니다. 몇 가지 점검을 통과한 결과를 모든 공격에 대한 보장으로 표현하기보다, 다음 검토에서 이어 볼 수 있는 근거로 남기는 지원이 필요합니다.