생성형 AI가 답변만 만들던 단계에서 이메일을 보내고 코드를 배포하며 결제를 실행하는 에이전트 단계로 넘어가면 클라우드 보안의 기준도 달라진다. 핵심은 모델 정확도만이 아니다. 에이전트가 누구를 대신해 어떤 권한으로 어떤 도구를 사용했는지 증명할 수 있어야 한다. 미국 국립표준기술연구소(NIST)는 2026년 AI 에이전트의 신원·인가를 별도 과제로 다루기 시작했다. 사람 계정을 공유하거나 장기 API 키를 넘기는 방식으로는 자율 행동의 책임과 피해 범위를 통제하기 어렵기 때문이다.
에이전트는 기능이 아니라 새로운 비인간 신원이다
기존 클라우드 환경에도 서비스 계정과 워크로드 신원이 있다. 그러나 AI 에이전트는 고정된 명령만 실행하지 않고 상황을 해석해 도구와 순서를 선택한다. 같은 에이전트가 문서를 읽고, 고객정보를 조회하고, 메시지를 보내고, 인프라 설정까지 바꿀 수 있다. 따라서 ‘애플리케이션에 권한을 줬다’는 설명만으로는 실제 행위자를 구분하기 어렵다.
NIST의 개념 문서는 에이전트 식별, 인가, 감사, 부인방지와 프롬프트 인젝션 대응을 함께 검토한다. 중요한 방향은 에이전트를 사용자 계정의 부속물이 아니라 독립적으로 식별되는 주체로 취급하는 것이다. 에이전트 ID, 실행 버전, 요청한 사용자, 사용한 모델과 도구를 연결해야 사고 후 원인을 재구성할 수 있다.
최소 권한은 작업마다 다시 계산돼야 한다
사람 직원에게 부여한 광범위한 권한을 에이전트가 그대로 상속하면 작은 판단 오류가 큰 피해로 이어질 수 있다. 예를 들어 회의 일정을 잡는 작업에는 캘린더 읽기·쓰기 권한이 필요하지만 메일함 전체 삭제나 결제 승인 권한은 필요하지 않다. 권한은 에이전트의 이름이 아니라 현재 작업, 데이터 민감도, 금액, 대상 시스템을 기준으로 짧게 발급돼야 한다.
실무적으로는 장기 비밀키 대신 단기 토큰을 사용하고, 한 번의 작업이 끝나면 권한을 회수해야 한다. 읽기와 쓰기를 분리하고, 외부 전송·코드 배포·금전 거래처럼 영향이 큰 행위에는 사람 승인이나 별도 정책 엔진을 두는 것이 합리적이다. 에이전트가 다른 에이전트를 호출할 때에도 원래 사용자의 권한 범위를 넘어서는 위임을 금지해야 한다.
프롬프트 인젝션은 권한 문제로 바뀐다
악성 문서나 웹페이지가 에이전트에게 숨은 명령을 전달하는 간접 프롬프트 인젝션은 단순한 잘못된 답변보다 위험하다. 에이전트가 도구 사용 권한을 갖고 있다면 공격자가 데이터 유출이나 설정 변경을 유도할 수 있다. NIST의 2026년 의견수렴 결과도 기존 보안 원칙이 여전히 유효하지만 에이전트 환경에 맞게 조정돼야 한다는 폭넓은 합의를 확인했다.
해결책은 모든 공격 문장을 완벽히 탐지하는 것만이 아니다. 신뢰하지 않는 입력과 권한 있는 실행을 분리하고, 도구 호출 전 정책 검사를 수행하며, 민감한 결과는 외부로 보내기 전에 재검증해야 한다. 모델이 잘못 판단하더라도 권한 경계가 피해를 제한하도록 설계하는 방어심층이 필요하다.
감사 로그는 대화가 아니라 행동의 계보여야 한다
일반 챗봇 로그는 질문과 답변을 저장한다. 에이전트 감사에는 계획 변경, 도구 호출, 입력 매개변수, 승인 결과, 데이터 출처, 최종 변경사항이 포함돼야 한다. 단순히 ‘AI가 실행했다’는 기록으로는 누가 지시했고 어떤 정책이 허용했는지 알 수 없다. 로그는 변조 방지 저장소에 남기고 개인·기밀정보는 최소화해야 한다.
Microsoft가 2026년 공개한 에이전트 거버넌스 도구도 런타임 정책 집행과 관찰 가능성을 강조한다. 특정 공급업체 도구의 채택 여부보다 중요한 것은 통제 지점이 모델 프롬프트 밖에 존재한다는 점이다. 정책은 결정론적으로 검사되고, 모델이 정책을 스스로 해석해 우회할 수 없어야 한다.
클라우드 비용도 권한의 일부다
에이전트는 반복 작업과 다른 에이전트 호출을 통해 예상보다 많은 토큰, 서버리스 실행, 데이터베이스 질의와 네트워크 전송을 발생시킬 수 있다. 보안 권한이 적절해도 비용 한도가 없으면 운영 장애가 된다. 작업별 예산, 호출 횟수, 실행시간, 동시성, 데이터 전송량을 정책에 포함하고 임계치를 넘으면 중단하거나 승인을 요청해야 한다.
비용 통제는 생산성 억제가 아니다. 실패한 루프를 조기에 끊고, 고가 모델이 필요한 단계와 작은 모델로 충분한 단계를 분리하면 서비스 안정성과 경제성이 함께 개선된다. 에이전트의 성능평가에는 성공률뿐 아니라 작업당 비용, 재시도율, 사람 개입률도 포함해야 한다.
도입 순서와 전망
기업은 먼저 에이전트 목록과 소유부서를 등록하고, 각 에이전트에 독립 신원을 부여해야 한다. 다음으로 도구별 최소 권한과 고위험 승인 규칙을 정의하고, 샌드박스에서 프롬프트 인젝션·권한 상승·무한루프를 시험해야 한다. 마지막으로 행동 로그와 비용 데이터를 보안운영센터와 재무운영 체계에 연결해야 한다.
앞으로 에이전트 상호운용 표준이 확대되면 한 클라우드의 에이전트가 다른 기업의 도구를 호출하는 일이 늘어난다. 편의성은 높아지지만 신뢰 경계도 복잡해진다. 경쟁력은 가장 자율적인 에이전트가 아니라 권한을 가장 정확히 설명하고 회수하며 감사할 수 있는 시스템에서 나온다.
자료 및 확인 기록
- NIST, Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents, 2026-05-18, 원문, 확인 2026-08-14 18:48 KST.
- NIST, New Concept Paper on Identity and Authority of Software Agents, 2026-02-05, 원문, 확인 2026-08-14 18:48 KST.
- NIST, Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation, 2026-02-17, 원문, 확인 2026-08-14 18:48 KST.
- Microsoft Open Source Blog, Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents, 2026-04-02, 원문, 확인 2026-08-14 18:48 KST.
대표 이미지 출처: OpenAI 이미지 생성 도구로 제작한 고유 편집 일러스트. 에이전트 신원, 최소권한, 승인 관문과 감사 계보를 표현했다.
의견을 남겨주세요