브라우저가 AI 업무 공간이 된 지금, 보안 가시성은 어디까지 설계해야 할까요?
업무는 브라우저 안에서 끝나지 않습니다
직원이 브라우저에서 문서를 읽고 생성형 AI에 요약을 요청하며 연결된 도구로 업무를 처리하는 흐름은 자연스러워지고 있습니다. 어떤 데이터가 프롬프트에 포함됐는지, 어떤 계정이 도구를 호출했는지 확인할 수 있어야 합니다.
Google Cloud는 10월 1일 브라우저를 AI 업무 공간이자 자율 에이전트와 상호작용하는 환경으로 설명하며 텔레메트리 기반의 방어 관점을 제시했습니다. 네트워크·엔드포인트 로그만으로 업무 맥락을 충분히 설명하기 어려울 수 있다는 신호입니다.
‘접속함’보다 ‘업무 맥락’을 확인하세요
먼저 승인된 AI 서비스와 업무 도구의 목록을 정하고, 각 도구에 허용되는 데이터 유형과 인증 방식을 합의해야 합니다. 이어 브라우저에서 시작한 요청이 SaaS, API, 내부 시스템 어디로 이어지는지 확인할 식별자를 설계합니다. 개인정보와 민감 정보의 수집·보관 범위는 법무·보안·현업과 함께 정해야 합니다.
AI 에이전트의 권한을 사람의 권한과 분리하세요
브라우저에서 시작된 자동화가 내부 API나 SaaS를 호출한다면, 에이전트를 사용자의 연장으로만 취급해서는 안 됩니다. 사람의 세션, 에이전트 주체, 도구 호출 권한을 구분하고 각각의 만료·회수 기준을 둡니다. 여러 단계의 업무에는 작업별 최소 권한과 중요한 변경의 추가 승인을 검토할 수 있습니다.
조사 기록에는 사용자 또는 서비스 주체, 호출 도구, 대상 시스템, 결과, 정책 결정 근거가 연결되어야 합니다.
차단 정책은 작은 범위에서 검증하세요
새 정책을 전사에 즉시 적용하면 정상 업무를 막을 위험이 있습니다. 민감 데이터 업로드, 비승인 확장 기능, 위험한 도구 호출처럼 기준이 분명한 사례부터 제한된 조직의 알림 모드에서 확인하세요. 오탐과 업무 영향을 기록한 뒤 정책을 조정하는 편이 안전합니다.
Litis는 API Security, Gateway 정책, AI·API 운영 가시성을 연결하는 관점에서 기업 환경에 맞는 접근 통제와 모니터링 구조를 검토할 수 있습니다. 내부 업무 시스템을 안전한 API 인터페이스로 정리해야 한다면 litis API Creator의 적용 범위도 함께 살필 수 있습니다. 브라우저 보안 제품의 구체적 기능이나 연동 가능 여부는 별도 기술 검증이 필요합니다.
지금 한 가지 업무 시나리오를 골라 보세요. 브라우저에서 시작한 AI 요청이 어떤 데이터와 도구를 거쳐 어디까지 도달하는지 설명할 수 있나요? 답이 흐리다면, 그 지점이 다음 보안 설계의 시작입니다.
브라우저 기반 AI 업무의 API 접근 통제, 보안 이벤트, 운영 가시성을 함께 점검하려면 [Litis에 보안·아키텍처 상담을 문의하세요]
