비밀번호를 대화에 적지 않고 AI에게 일을 맡기는 방법

사내 공지 한 건을 요약하는 일에도 로그인이 필요할 수 있습니다. 개인 에이전트에게 자료를 읽어 달라고 하다가 “그럼 비밀번호도 대화에 적어야 할까?”라는 질문을 만나게 됩니다. 이때 필요한 것은 비밀번호를 잘 숨겨 쓴 요청문보다, 이번 업무에 어떤 계정 사용을 허용할지 정하는 방법입니다.

앞선 글에서 요청부터 결과 검토까지를 살펴봤던 가상 기업의 운영 담당자 서윤을 다시 만나 보겠습니다. 이번에는 조직에서 에이전트를 통한 조회를 허용한 사내 포털 공지 한 건을 읽고, 바뀌는 운영 시간과 적용일만 정리하려 합니다. 게시, 수정, 발송은 맡기지 않습니다.

아래 이야기는 독자가 자신의 허용된 환경에서 따라 해 볼 수 있는 사용 시나리오입니다. 실제 포털 로그인이나 자격증명 사용 승인을 실행한 사례는 아닙니다. 화면도 가상 계정의 설정을 조회한 것이며, 성공한 로그인이나 승인 결과를 보여 주지는 않습니다.

1. 로그인보다 먼저, 읽을 범위를 정합니다

“포털에 들어가서 필요한 정보를 찾아 줘”라고 하면 읽을 페이지와 끝낼 지점이 모호합니다. 서윤은 먼저 공지의 제목과 위치를 확인하고, 자신의 계정으로 볼 수 있는 자료 중 이번 업무에 필요한 범위를 좁힙니다. 포털 전체를 탐색하거나 직원 정보를 모을 이유는 없습니다.

요청에는 비밀번호 대신 목적과 결과 기준을 적습니다.

사내 포털의 ‘다음 달 고객 안내 운영 시간 변경’ 공지 한 건을 읽고, 변경 전후 운영 시간과 적용일을 정리해 줘. 공지 제목과 확인한 기준일도 적어 줘. 해당 공지에 없는 내용은 확인 필요로 남겨 줘. 다른 직원의 자료를 열거나 게시·수정·발송하지 마. 로그인이 필요하면 사용 승인을 요청해 줘.

이 문장은 에이전트가 수행할 업무의 범위를 설명합니다. 사이트 권한이나 보안 설정을 대신하지는 않습니다. 실제로 허용된 계정과 자료인지 확인하고, 에이전트가 사용할 수 있는 브라우저 기능과 해당 사이트의 접근 조건도 함께 살펴봐야 합니다.

2. 대화에는 업무를, 키발트에는 보관할 값을 적습니다

CAP의 개인 키발트에는 사이트 로그인 정보, 비밀 메모, API 토큰을 보관할 수 있습니다. 이번 예시에는 사이트 로그인 항목을 사용합니다. 어떤 포털의 어떤 계정인지 알아볼 수 있게 항목을 정리하고, 사이트 주소와 로그인 위치가 맞는지 확인합니다. 비밀 메모나 토큰을 업무 설명에 붙여 넣어 같은 목적을 해결하려고 하지 않습니다.

보관과 사용 허용은 따로 확인해야 합니다. 현재 새 항목은 에이전트 접근이 허용된 상태로 만들어집니다. 보관만 하려는 항목이라면 저장 후 해당 항목을 다시 열어 에이전트 접근을 끕니다. 접근을 켜 두었다고 이번 로그인 요청의 승인이 생략되는 것은 아닙니다.

API 토큰도 저장했다고 모든 외부 서비스와 자동으로 연결되지는 않습니다. 사용할 Tool과 연결 방식에서 그 토큰을 지원하는지, 어떤 권한으로 어떤 일을 할 수 있는지 따로 확인해야 합니다. Tool 연결 가이드를 보면 연결 준비, 에이전트의 사용 허용, 실제 요청 결과를 나누어 살펴볼 수 있습니다.

3. 패스키는 로그인과 키발트에서 각각 확인합니다

패스키를 등록했으면 모든 준비가 끝났다고 생각하기 쉽습니다. 하지만 CAP 로그인에 사용할 수 있는 패스키와 기존 키발트를 열 수 있는 패스키는 확인할 내용이 다릅니다. 사용하는 기기와 인증 방식이 키발트를 지원하는지, 화면의 확인 절차로 살펴봐야 합니다.

패스키는 개인 설정 → 보안 → 2단계 인증에서 관리하고, 키발트는 개인 설정의 별도 메뉴에서 엽니다. 처음에는 키발트 화면의 패스키 확인과 생성 안내를 따릅니다. 이미 키발트가 있다면 그것을 열 수 있는 패스키를 사용해야 합니다. 단순히 새 로그인 패스키를 등록하는 것으로 기존 보관함에 연결되는 것은 아닙니다.

2026년 9월 26일 촬영. 가상 계정의 키발트 생성 전 실제 설정 화면입니다. 패스키 확인·키발트 생성·포털 로그인을 실행한 결과는 아닙니다.

키발트를 잠금 해제하면 저장한 값을 관리할 수 있습니다. 이것만으로 에이전트의 사이트 로그인을 승인한 것은 아닙니다. 준비 과정과 실제 사용 승인의 화면별 설명은 패스키와 개인 키발트 가이드에 정리되어 있습니다.

4. 세 종류의 허용은 서로 다른 질문에 답합니다

서윤이 브라우저 Tool을 사용할 수 있게 설정하고, 민감 작업 승인을 켜고, 키발트 로그인 요청을 승인하는 것은 각각 의미가 있습니다. 같은 일을 여러 번 확인하는 것처럼 보여도 확인 대상이 다릅니다.

• Tool 사용 허용: 에이전트가 이 기능을 사용할 수 있어야 하는가? 공지를 읽는 데 필요한 브라우저 기능을 사용할 수 있게 합니다.
• 민감 작업 승인: 현재 요청에서 확인을 요구하는 민감 작업을 진행할 것인가? 해당 요청에 대한 본인 확인을 진행하기 전에 작업 내용을 읽습니다.
• 키발트 자격증명 사용 승인: 이 사이트와 목적에 저장된 로그인 정보를 사용해도 되는가? 공지 조회에 필요한 포털 로그인 요청인지 확인하고 패스키로 승인합니다.

민감 작업 승인은 개인 설정 → 보안 → 민감 작업 승인에서 설정합니다. 켜면 현재 CAP 대화 요청에서 민감 작업으로 식별된 작업에 본인 확인을 요구합니다. 같은 요청 안의 후속 단계에서는 다시 확인하지 않을 수 있습니다. 모든 개인정보를 찾아 차단하거나, 모든 자동 실행과 모든 행동에 항상 승인창을 띄우는 기능으로 이해하면 범위를 넘어섭니다.

2026년 9월 26일 촬영. 가상 계정에서 조회한 실제 화면으로 스위치는 꺼져 있습니다. 촬영 중 설정을 변경하거나 민감 작업 승인 요청을 실행하지 않았습니다.

키발트 자격증명 사용은 별도의 패스키 승인을 거칩니다. 따라서 민감 작업 본인 확인이 끝났더라도, 이어지는 키발트 요청의 사이트와 목적을 다시 읽어야 합니다. 개인 설정에서 각각 어떤 범위를 관리하는지는 개인 설정 가이드에서 확인할 수 있습니다.

5. 승인창에서는 사이트와 목적이 내 요청과 맞는지 읽습니다

포털 로그인 승인이 요청되면, 먼저 표시된 사이트와 사용 목적이 자신이 부탁한 공지 조회와 맞는지 봅니다. 함께 표시되는 Tool과 남은 시간도 확인합니다. 저장 항목의 이름은 진행 중 뒤늦게 표시될 수 있고, 그 이름 자체가 실제 로그인 계정의 확인을 대신하지는 않습니다. 작업 전에 어느 계정의 항목을 준비했는지 알아두는 이유입니다.

다른 사이트이거나, 공지를 읽는 데 필요하지 않은 목적으로 보인다면 거부하고 요청 범위부터 바로잡습니다. 기기나 운영체제의 패스키 창을 취소하면 승인이 완료되지 않습니다. 다만 CAP의 요청 카드가 계속 대기할 수 있으므로, 진행하지 않을 요청은 카드에서도 거부 상태를 확인하는 편이 명확합니다. 시간이 만료된 요청도 그대로 승인된 것으로 취급하지 않습니다.

여기서 막혔다고 비밀번호를 대화에 보내거나 비밀값이 들어 있는 화면을 첨부해 우회할 필요는 없습니다. 지원되는 패스키인지, 준비한 항목과 대상 사이트가 맞는지, 요청이 아직 유효한지 확인합니다.

6. 로그인 성공과 공지를 잘 읽은 결과는 따로 확인합니다

사용 승인을 마쳤다는 사실만으로 포털 로그인이 성공했다고 판단할 수는 없습니다. 사이트에서 추가 인증을 요구하거나 접근 정책 때문에 진행되지 않을 수 있습니다. 실제로 의도한 계정으로 필요한 공지가 열렸는지, 결과에 표시된 제목과 적용일이 원문과 같은지까지 확인합니다.

여기에는 중요한 경계가 하나 더 있습니다. 저장된 로그인 정보를 보호하는 일과, 로그인 뒤 읽은 자료를 처리하는 일은 별개입니다. 에이전트가 읽은 페이지 내용은 요약과 답변을 위한 일반 업무 자료로 처리될 수 있습니다. 키발트를 쓴다는 이유만으로 그 페이지의 개인정보나 내부 문서가 모델 처리에서 자동으로 제외되는 것은 아닙니다.

그래서 첫 요청을 공지 한 건으로 좁혔습니다. 그 안에 에이전트가 처리하면 안 되는 인사 정보나 개인 연락처가 있다면, 승인된 범위의 자료를 별도로 준비하거나 담당자와 처리 범위를 먼저 확인합니다. 읽을 수 있는 계정 권한과 에이전트에 맡길 수 있는 자료 범위는 함께 검토해야 합니다. 자료 공개 범위와 연결 키 관리 가이드가 이 판단에 도움이 됩니다.

7. 일을 마치면 잠금, 접근 허용, 이력을 나누어 봅니다

공지 요약을 확인한 뒤에는 남겨 둘 사용 허용이 필요한지 살펴봅니다. 키발트 잠금은 보관된 값을 관리하기 위해 열었던 상태를 닫는 동작입니다. 이미 발급된 모든 사용 승인을 회수하거나 외부 포털에서 로그아웃시키는 동작과 같지 않습니다.

해당 항목을 앞으로 에이전트가 쓰지 않게 하려면 항목의 에이전트 접근을 끕니다. 이 변경은 해당 항목의 관련 사용 승인을 회수합니다. 세션 기억을 켜 두었다면 그 설정의 범위도 확인합니다. 세션 기억을 끄는 동작은 세션 방식의 승인을 회수하는 것이며, 모든 종류의 승인을 일괄 취소한다는 의미는 아닙니다. 같은 사이트의 다음 요청도 다시 승인을 요구할 수 있으므로 화면의 현재 요청을 기준으로 판단합니다.

접근 이력에서 승인이 발급된 것과 실제 사용된 것은 구분해서 읽습니다. 사용 기록이 있어도 포털 로그인이나 공지 요약까지 성공했다는 뜻은 아닙니다. 요청 화면, 접근 이력, 실제 결과를 함께 보면 어느 단계까지 진행됐는지 이해하기 쉽습니다. 거부나 만료가 모두 접근 이력에 남는다고 가정하지도 않습니다.

외부 포털의 로그인 세션을 종료하거나 외부 서비스의 토큰을 폐기해야 한다면 해당 서비스에서도 처리해야 합니다. 거부·회수는 이미 외부에서 완료된 행동을 되돌리는 기능이 아니므로, 결과가 바뀌었다면 그 서비스의 상태를 직접 확인합니다.

8. 예비 패스키는 기기를 잃기 전에 준비합니다

서윤이 이 방식을 계속 쓰려면 평소의 로그인 편의뿐 아니라 기기를 바꿀 때도 생각해야 합니다. 기존 패스키가 정상적으로 동작할 때 키발트에 예비 패스키를 연결하고, 새 패스키로 기존 보관함을 실제로 열 수 있는지 확인한 다음 오래된 기기를 정리하는 순서가 좋습니다. 계정에 로그인용 패스키를 하나 더 등록했다는 것만으로 이 확인을 대신할 수는 없습니다.

키발트를 열 수 있는 패스키를 모두 잃으면 계정 비밀번호 재설정이나 새 패스키 등록으로 기존 비밀값을 복구할 수 없습니다. 키발트 폐기는 기존 내용을 영구적으로 없애고 새로 시작하는 절차이며, 복구 수단이 아닙니다. 따라서 접근할 수 있을 때 예비 수단을 확인해 두는 것이 실제 업무를 이어가는 데 중요합니다.

첫 연습은 조직에서 허용한 계정과 공지 한 건이면 충분합니다. 비밀값을 대화에 적지 않은 상태로 요청을 시작하고, 승인 대상과 읽은 자료의 범위를 확인한 뒤, 공지 제목·적용일·요약을 원문과 비교해 보세요. 어떤 단계에서 본인 확인이 필요했고 어떤 결과를 직접 검토했는지 이해하면, 다음 업무에 맡길 범위도 더 분명하게 정할 수 있습니다.