AI에게 건넨 비밀번호와 접속 키, 대화 기록에 그대로 남을까

#다운로드 링크 한 줄에 살아 있는 토큰이 들어 있다

회사 DB와 클라우드 드라이브를 AI에 연결하면 DB 비밀번호와 드라이브 접근 권한을 AI 쪽에 맡기게 됩니다. 드라이브의 파일을 받아 정리해 달라고 하면 AI는 다운로드 링크를 받아 파일을 엽니다. 그 링크는 2천 자가 넘는 주소이고, 안에는 살아 있는 접근 토큰이 통째로 박혀 있습니다. 이 주소가 대화 기록과 서버 로그, 외부 AI 회사로 가는 요청에 그대로 실린다면 비밀번호를 메모장에 적어 돌리는 것과 다를 바 없습니다.

OwlAI에서는 그 토큰이 AI의 대화 맥락에도 서버 로그에도 남지 않습니다. 원래 주소는 서버에 암호화해 한 시간만 맡겨 두고, AI에게는 열아홉 자짜리 참조만 건넵니다. 비밀번호와 키는 처음부터 이중으로 잠긴 금고에 들어 있습니다.

#비밀번호와 키는 이중으로 잠긴 금고에 있다

DB 비밀번호, 외부 서비스의 토큰과 API 키, AI 모델 키, DB 연결에 쓰는 SSH 키, 2단계 인증 비밀은 모두 자격증명 금고에 들어갑니다. 금고는 봉투 암호화 방식입니다. 비밀 하나하나를 데이터 키로 잠그고, 그 데이터 키를 다시 마스터 키로 잠급니다. 그래서 DB가 통째로 빠져나가도 마스터 키가 없으면 아무것도 풀리지 않습니다.

잠근 비밀은 저장된 자리와 조직, 용도에 묶여 있어 다른 조직의 행에 복사해 넣으면 풀리지 않습니다. 금고 키가 준비되지 않은 서버는 비밀을 저장하지 않고, 키 설정이 틀리면 서비스가 아예 뜨지 않습니다. 마스터 키는 설치형이면 서버 설정이나 비밀 관리 도구로 넣고, SaaS라면 클라우드의 키 관리 서비스가 맡습니다.

관리 화면에서도 비밀 값은 보이지 않습니다. 외부 서비스에 붙이는 추가 인증 정보는 이름만 보이고 값은 가려집니다. 서버 주소에 비밀번호나 토큰을 섞어 등록하면 거절하고 별도의 인증 칸에 넣도록 안내합니다. 주소는 화면과 기록에 그대로 보이는 칸이기 때문입니다.

#AI는 열아홉 자짜리 참조만 본다

다운로드 링크는 금고에 넣어 두기만 할 수 없습니다. 다음 단계에서 AI가 그 주소로 파일을 받아야 하기 때문입니다. 그래서 토큰이 박힌 주소는 서버 보관소에 암호화해 두고, AI에게는 원래 주소 대신 짧은 참조를 보여 줍니다. AI가 그 참조로 파일을 받아 달라고 하면 도구가 보관소에서 원래 주소를 되찾아 씁니다.

참조는 한 시간이 지나면 사라지고, 발급받은 사용자만 되찾을 수 있습니다. 다른 사람이 참조 문자열을 짐작해 넣어도 열리지 않습니다. 덤으로 AI가 2천 자짜리 주소를 한 글자씩 옮겨 적다가 틀려서 작업이 끊기는 일도 사라집니다.

#큰 결과를 파일로 남길 때도 토큰부터 가린다

AI가 받은 결과가 너무 크면 원본을 파일로 보관해 두고 AI가 나눠 읽게 합니다. 이 파일을 쓰기 전에 토큰이 박힌 주소부터 가리므로, 디스크에 토큰이 평문으로 남지 않습니다. 그 파일이 엑셀이나 메일로 바깥에 나갈 때는 다른 출구와 같은 출력 경계를 한 번 더 지납니다.

#마스터 키를 잃으면 비밀은 다시 등록한다

마스터 키 없이는 누구도 금고를 열 수 없게 한 것은 의도한 선택입니다. 키를 잃으면 관리자가 비밀을 전부 다시 등록해야 합니다. 그 수고를 감수하더라도, DB를 통째로 가져간 사람이 비밀을 풀 수 없게 하는 편이 낫다고 보았습니다.

그래서 마스터 키는 서버 설정 파일과도, DB 백업과도 다른 곳에 보관합니다. 백업과 키가 함께 새어 나가면 이중으로 잠근 의미가 사라집니다. 도입을 앞두고 IT 부서와 먼저 정할 것도 이것입니다. 마스터 키를 어디에 두고 누가 보관하며, DB 백업과 어떻게 떼어 놓을지입니다.