에이전트 중심의 거버넌스 및 보안 구축

AI 에이전트가 조직 내에서 인간과 협업하는 비중이 늘어나면서, 기존 IAM(Identity and Access Management) 체계로는 감당하기 어려운 새로운 공격 표면이 등장하고 있다. 기술적으로 AI 에이전트는 LLM 기반의 의사결정 엔진이 도구 호출(tool calling)이나 MCP(Model Context Protocol)를 통해 내부 시스템, DB, SaaS API에 접근하는 구조다. 이때 에이전트는 OAuth 토큰, API 키, 서비스 계정 같은 비인간 식별자(Non-Human Identity, NHI)를 사용하는데, 이미 다수의 엔터프라이즈에서 NHI 수가 인간 계정보다 10~50배 많은 상황이며 에이전틱 AI 도입으로 그 격차가 폭발적으로 커지고 있다. 더 큰 문제는 에이전트가 자연어 입력을 신뢰하기 때문에 프롬프트 인젝션, 도구 오용(tool poisoning), 권한 승격(confused deputy) 같은 새로운 공격 벡터에 취약하다는 점이다.

개발자 입장에서 가장 큰 변화는 "코드가 아니라 행동을 통제해야 한다"는 점이다. 기존 RBAC는 사람이 명시적으로 버튼을 누르는 행위를 전제로 설계됐지만, 에이전트는 동일 권한으로 분당 수백 건의 행동을 자율적으로 수행할 수 있다. 예컨대 고객지원 에이전트에 read-only DB 권한만 부여했다고 해도, 프롬프트 인젝션으로 SELECT 한 번에 전체 고객 PII를 외부 webhook으로 유출시키는 시나리오가 충분히 가능하다. 따라서 단순 권한 부여를 넘어 도구 호출 단위의 정책 엔진(OPA, Cedar 등), 행동 감사 로그, anomaly detection, 그리고 에이전트별로 분리된 단명(short-lived) 자격증명 발급이 필수가 된다. 특히 MCP 서버를 직접 구축하는 개발자라면 도구 응답 자체가 다음 LLM 입력이 되는 점을 고려해 출력 sanitization과 권한 스코프 최소화를 처음부터 설계해야 한다.

실무적으로 지금 당장 점검해야 할 항목은 명확하다. 첫째, 자신이 운영 중인 에이전트에 부여된 토큰/키의 스코프가 "에이전트가 정말 필요한 최소 권한"으로 제한돼 있는지 확인하고, 가능하면 STS 같은 단명 토큰으로 전환해야 한다. 둘째, 모든 도구 호출에 대해 누가(어떤 에이전트), 누구의 위임으로(on behalf of which user), 어떤 도구를, 어떤 인자로 호출했는지를 구조화된 로그로 남겨야 한다. 셋째, human-in-the-loop 게이트를 비용 발생, 외부 통신, 데이터 삭제 같은 비가역적 액션에 의무화해야 한다. 넷째, Anthropic·OpenAI·Google이 제시하는 에이전트 보안 가이드라인과 OWASP의 LLM Top 10, 그리고 NIST AI RMF 같은 프레임워크를 사내 보안 정책에 반영해 두는 것이 좋다.

마지막으로 이는 보안팀만의 문제가 아니라 백엔드·플랫폼 엔지니어의 책임 영역으로 빠르게 이동하고 있다. 향후 1~2년 내 대부분의 기업에서 "에이전트 거버넌스 플랫폼" 도입이 표준이 될 가능성이 높고, 채용 시장에서도 NHI 관리, 에이전트 보안, AI 가드레일 설계 경험이 차별화 요소가 될 것이다. 지금 사이드 프로젝트로 에이전트를 만들고 있다면 기능 구현뿐 아니라 권한 모델·감사 로그·정책 enforcement를 함께 설계해 보는 것이, 가까운 미래에 매우 가치 있는 실무 역량으로 이어질 것이다.