AI 에이전트가 새로운 보안 주체가 된다고 해서 지금까지 구축한 보안 체계를 모두 바꿔야 하는 것은 아닙니다. IAM, Zero Trust, 최소 권한, DLP, SIEM, 감사 로그와 같은 기존 원칙은 여전히 유효합니다. 달라지는 것은 이 원칙을 적용해야 하는 대상과 범위입니다.

먼저 조직은 어떤 AI와 에이전트가 실제 환경에서 운영되고 있는지 파악해야 합니다. 어떤 에이전트가 어떤 목적으로 만들어졌는지, 누구의 책임 아래 운영되는지, 어떤 모델과 데이터를 사용하고 어떤 시스템과 도구에 접근할 수 있는지까지 관리 대상에 포함해야 합니다.

권한 관리 역시 사람과 서비스 계정에서 에이전트로 확장되어야 합니다. 하나의 에이전트에 광범위한 서비스 계정을 제공하기보다 작업 단위로 필요한 권한을 제한하고, 데이터 조회와 변경처럼 위험 수준이 다른 작업은 가능하면 분리해야 합니다.

하지만 IAM만으로 AI의 행동을 모두 통제할 수는 없습니다. 에이전트가 정상적인 권한으로 비정상적인 행동을 수행할 수 있기 때문에, 런타임에서 실제 행동을 관찰하고 통제하는 계층이 필요합니다.

예를 들어 CRM 조회 권한을 가진 에이전트가 고객 한 명의 정보를 확인하는 것은 정상적인 업무일 수 있습니다. 하지만 짧은 시간에 고객 데이터를 대량으로 내려받은 뒤 외부 API로 전송한다면 동일한 권한 안에서도 전혀 다른 보안 이벤트로 봐야 합니다.

따라서 AI 시대의 로그에는 어떤 작업을 수행하고 있었는지, 어떤 데이터와 컨텍스트를 전달받았는지, 어떤 도구를 어떤 순서로 사용했는지, 최종 행동이 처음 부여된 목적과 일치하는지까지 연결해서 볼 수 있어야 합니다.

모든 행동을 사람에게 승인받게 하는 것도 현실적인 해답은 아닙니다. 대신 데이터 삭제, 권한 변경, 운영 환경 수정, 금융 거래, 민감 정보의 외부 전송처럼 실패했을 때 영향이 큰 작업에 명확한 정책 게이트와 Human-in-the-loop를 두는 방식이 더 현실적입니다.

결국 기존 보안 체계는 다음과 같이 확장됩니다. IAM은 Agent Identity와 권한까지, DLP는 AI가 처리하는 데이터와 컨텍스트까지, SIEM과 SOC는 에이전트의 행동과 작업 흐름까지 관찰해야 합니다. Zero Trust 역시 사람과 기기를 넘어 자율적으로 행동하는 소프트웨어까지 포함하는 방향으로 넓어져야 합니다.

AI를 위한 완전히 새로운 보안 체계를 만드는 것이 아니라, 기존 보안 원칙을 AI가 실제로 행동하는 환경에 맞게 확장하는 것입니다.