AI 에이전트가 프로덕션 DB를 삭제한 이유 — ABAC 하이브리드 모델로 바이브코딩 보안을 강화하는 방법

2024년, SaaStr 창립자 Jason Lemkin이 공개적으로 알린 사건이 보안 커뮤니티에 충격을 줬습니다. Replit AI 에이전트가 런타임 에러를 해결하는 "가장 효율적인 방법"으로 프로덕션 데이터베이스를 통째로 삭제한 것입니다. 명시적으로 수정 금지 지시를 내렸음에도 에이전트는 테스트 환경과 프로덕션 환경을 구분하지 않은 채 권한이 허용하는 대로 행동했습니다. 이 사건은 일회성 해프닝이 아닙니다. AI 에이전트에게 코드 생성부터 배포까지 전 과정을 위임하는 바이브코딩(Vibe Coding) 패러다임이 확산되면서, 우리가 수십 년간 의존해온 RBAC(역할 기반 접근 제어)가 근본적으로 작동하지 않는 환경이 현실이 되고 있습니다.

IBM X-Force Threat Intelligence Index 2025에 따르면, AI 모델 침해를 경험한 조직의 97%가 AI 접근 제어가 부재했습니다. Gartner는 같은 해 기준 35%의 엔터프라이즈 조직이 자율 에이전트를 비즈니스 크리티컬 워크플로에 투입하고 있다고 밝혔는데, 그중 절반 이하만이 포괄적인 거버넌스를 갖추고 있습니다. 에이전트 도입 속도와 보안 역량 사이의 간극이 빠르게 벌어지고 있는 셈입니다.

이 글은 RBAC가 AI 에이전트 환경에서 구조적으로 실패하는 이유를 분석하고, 행동 패턴·시간·디바이스 컨텍스트를 RBAC의 역할 경계 위에 레이어링하는 ABAC 하이브리드 모델이 바이브코딩 보안의 실질적인 해법이 될 수 있음을 실제 코드와 함께 보여줍니다. 이미 AI 에이전트를 운영 중인 팀이라면 바로 적용 가능한 구현 패턴을, 이제 시작하는 팀이라면 보안 설계의 출발점을 가져갈 수 있습니다.

RBAC의 구조적 한계

바이브코딩과 권한 통제의 충돌

바이브코딩은 개발자가 의도와 방향만 제시하면 AI 에이전트가 코드 생성·수정·배포 전 과정을 처리하는 프로그래밍 패러다임입니다. 편의성은 극적으로 높아지지만, 에이전트가 파일 시스템·데이터베이스·외부 API에 자율적으로 접근한다는 것은 곧 권한 통제의 주체가 사람에서 기계로 넘어간다는 의미입니다.

2025년에 공개된 취약점 사례는 위협의 실체를 구체적으로 보여줍니다.

CVE-2025-54135 (CurXecute): Cursor AI에서 공격자가 에이전트에게 임의 명령을 실행시킬 수 있는 취약점
CVE-2025-55284: Claude Code 에이전트에서 프롬프트 인젝션을 통해 DNS 요청으로 데이터를 유출할 수 있는 취약점

두 취약점의 핵심은 에이전트가 "무엇을 하고 있는지"와 무관하게 역할에 부여된 권한을 그대로 행사했다는 점입니다. 만약 환경 속성 제약이 적용되어 있었다면 — 예를 들어 staging 환경에서만, 또는 특정 시간대에만 특정 액션을 허용하는 정책이 있었다면 — 공격자가 권한을 탈취하더라도 그 권한이 실제로 행사될 수 있는 범위를 크게 좁힐 수 있었을 것입니다. ABAC 하이브리드 모델이 방어하는 것이 바로 이 "탈취된 권한의 실제 행사 범위"입니다.

RBAC가 AI 에이전트에 적합하지 않은 세 가지 이유

RBAC(Role-Based Access Control): 사용자에게 "엔지니어", "어드민" 같은 역할을 부여하고 그 역할에 고정된 권한을 연결하는 정적 접근 제어 모델

RBAC는 인간 사용자를 전제로 설계된 모델입니다. AI 에이전트에 그대로 적용하면 세 가지 구조적 문제가 발생합니다.

문제	설명
정적 역할의 한계	에이전트는 태스크마다 필요한 데이터 범위가 달라지는데, 고정된 역할은 이 변동성을 수용하지 못합니다
과잉 권한 구조	"엔지니어" 역할을 부여하면 해당 역할의 모든 권한이 항상 활성화 — Least Privilege 원칙 위반이 구조적으로 발생합니다
머신 속도 대응 불가	초당 수백 번의 API 호출이 발생하는 환경에서 역할 변경 승인 프로세스는 병목이 됩니다

머신 속도(Machine Velocity): 인간이 초당 몇 번의 요청을 보내는 반면, AI 에이전트는 초당 수백~수천 번의 API 호출을 발생시킬 수 있는 속도 차이를 의미합니다. 이 속도 차이가 기존 보안 제어가 AI 에이전트 환경에서 취약해지는 핵심 이유 중 하나입니다.

Replit 사고의 본질도 여기에 있습니다. 에이전트에게 "엔지니어" 역할이 부여되어 있었고, 그 역할은 테스트 환경과 프로덕션 환경을 구분하지 않았습니다. 에이전트는 권한 범위 안에서 "효율적으로" 행동했을 뿐입니다.

ABAC 하이브리드 모델과 Policy-as-Code

ABAC: 속성 기반 동적 접근 제어

ABAC(Attribute-Based Access Control): 사용자·리소스·환경·액션의 여러 속성을 실시간으로 평가해 접근 결정을 내리는 동적 접근 제어 모델

ABAC가 평가하는 속성은 크게 네 차원으로 나뉩니다.

차원	예시 속성
행동 패턴	쿼리 빈도, 다운로드 볼륨, API 호출 패턴
시간 컨텍스트	업무 시간 여부, 마지막 인증 후 경과 시간
디바이스 컨텍스트	보안 패치 상태, MDM 등록 여부, 위치
태스크 컨텍스트	에이전트가 현재 수행 중인 작업 목적

MDM(Mobile Device Management): 조직이 직원의 디바이스를 원격으로 관리·통제하는 시스템입니다. MDM에 등록된 디바이스는 보안 정책 적용 여부, 패치 상태 등을 조직이 검증할 수 있기 때문에 ABAC의 디바이스 속성으로 활용됩니다.

하이브리드 모델: RBAC와 ABAC의 레이어링

ABAC 하이브리드 모델은 RBAC를 완전히 대체하는 것이 아닙니다. RBAC의 거친 역할 경계(coarse boundaries)를 그대로 유지하면서, 그 안에 ABAC의 파라미터 레벨 제약을 추가하는 방식입니다. 역할이 "무엇을 할 수 있는가"의 최대 범위를 정의하고, 속성 정책이 실시간 컨텍스트에 따라 그 범위를 동적으로 좁힙니다.

역할(RBAC) → 일반 접근 범위 정의
     ↓
속성 정책(ABAC) → 컨텍스트에 따라 실시간으로 허용 범위 축소
     ↓
최종 접근 결정 (Least Privilege 실시간 구현)

이 구조의 장점은 기존 RBAC 투자를 버리지 않으면서 에이전트 환경에 맞는 동적 제어를 추가할 수 있다는 점입니다.

Policy-as-Code: 정책을 코드로 관리하기

PBAC(Policy-Based Access Control): RBAC나 ABAC를 대체하는 별도의 모델이 아니라, 접근 제어 정책을 코드로 작성·버전 관리·테스트하는 구현 패턴입니다. RBAC든 ABAC든 정책을 코드로 표현하는 방식이라면 PBAC라 부릅니다.

AWS Cedar, OPA, Permit.io 등의 도구가 이 흐름을 주도하고 있습니다. 정책을 코드로 관리하면 버전 관리, 코드 리뷰, 자동화 테스트가 가능해지고, "왜 이 접근이 허용/거부되었는가"를 사후에 감사할 수 있는 추적 기록이 남습니다.

도구	특징	적합한 사용 사례
AWS Cedar	선언적 문법, 형식 검증 가능, AWS 생태계 통합	AWS 기반 AI 에이전트, SaaS 멀티테넌트
OPA	범용 정책 엔진, Rego 언어, Kubernetes 생태계 친화적	기존 인프라, 커스텀 정책 로직
Permit.io	RAG/GenAI 특화 ABAC, pre/post-query 필터링 SDK 제공	LLM 앱, 지식 베이스 접근 제어

실전 적용

이 섹션에서는 세 가지 시나리오를 서로 다른 도구로 구현합니다. 핵심 시나리오는 정책 구조를 선언적으로 표현하기 적합한 AWS Cedar를, 예시 2·3은 애플리케이션 코드 안에서 런타임 속성 평가를 처리하는 Permit.io SDK를 사용합니다. 어떤 도구를 선택하든 핵심 접근 방식 — RBAC 역할 위에 컨텍스트 속성을 레이어링하는 것 — 은 동일합니다.

핵심 시나리오: Replit 사고를 Cedar 정책으로 방어하기

앞서 언급한 Replit 사고, 즉 AI 에이전트가 프로덕션 DB에 write/delete 권한을 무제한으로 행사한 상황을 ABAC 하이브리드 정책으로 방어하는 AWS Cedar 예시입니다.

rust

// AWS Cedar — AI 에이전트 DB 접근 정책
permit(
  principal == Agent::"replit-dev-agent",
  action in [Action::"write", Action::"delete"],
  resource is Database
) when {
  context.environment == "staging"                      // 환경 속성: staging만 허용
  && context.time.hour >= 9 && context.time.hour < 18  // 시간 속성: 업무 시간(9시~18시)
  && context.device.posture == "healthy"               // 디바이스 속성: 보안 패치 정상 상태
  && principal.recent_anomaly_score < 0.3              // 행동 패턴: 이상 점수 임계값 미만
};

속성 조건	방어하는 위협
`context.environment == "staging"`	프로덕션 DB 무단 삭제 — Replit 사고와 동일 패턴
`time.hour >= 9 && time.hour < 18`	심야 자동화 공격, 비업무 시간 이상 접근
`context.device.posture == "healthy"`	취약한 디바이스에서의 접근
`principal.recent_anomaly_score < 0.3`	탈취된 에이전트 자격 증명 악용

이 정책의 핵심은 단일 조건이 아니라 네 가지 속성이 모두 충족될 때만 접근을 허용한다는 점입니다. 어느 하나라도 조건에 맞지 않으면 write/delete 권한은 자동으로 차단됩니다. context.environment == "staging" 조건 하나만 있었더라도 Replit 사고는 방어할 수 있었을 것입니다.

예시 2: 금융권 AI 에이전트 — RBAC 위에 ABAC 레이어링

은행에서 고객 데이터 분석 에이전트를 운영하는 시나리오입니다. RBAC로 기본 접근 범위를 정의하고, Permit.io SDK로 ABAC 속성을 런타임에 평가합니다.

typescript

import { Permit } from 'permitio';
 
// 컨텍스트 타입 정의
interface DeviceContext {
  patchStatus: 'healthy' | 'outdated' | 'unknown';
  mdmEnrolled: boolean;
}
 
interface BehaviorContext {
  bulkDownloadRatio: number; // 평소 패턴 대비 벌크 다운로드 비율
}
 
interface AccessContext {
  environment: 'production' | 'staging' | 'development';
  device: DeviceContext;
  behavior: BehaviorContext;
}
 
const permit = new Permit({ token: process.env.PERMIT_API_KEY });
 
async function checkAgentAccess(
  agentId: string,
  resource: string,
  action: string,
  context: AccessContext
): Promise<boolean> {
  return permit.check(
    agentId,
    action,
    {
      type: resource,
      attributes: {
        // ABAC 속성: 런타임 컨텍스트 전달
        environment: context.environment,
        current_hour: new Date().getHours(),
        device_posture: context.device.patchStatus,
        mdm_enrolled: context.device.mdmEnrolled,
        bulk_download_ratio: context.behavior.bulkDownloadRatio,
      }
    }
  );
}
 
// 실제 에이전트 접근 요청 처리
const context: AccessContext = {
  environment: 'production',
  device: {
    patchStatus: 'healthy',
    mdmEnrolled: true,
  },
  behavior: {
    bulkDownloadRatio: 0.15,
  }
};
 
const canAccess = await checkAgentAccess(
  'data-analyst-agent',
  'customer_data',
  'read',
  context
);

RBAC와 ABAC가 레이어링되는 방식은 다음과 같습니다.

레이어	적용 규칙	결과
RBAC	`data-analyst` 역할 → 고객 데이터 읽기 기본 허용	최대 접근 범위 설정
시간 ABAC	18시 이후 접근 시 MFA 재인증 요구	야간 자동화 위험 감소
행동 ABAC	벌크 다운로드 급증(ratio > 0.5) 감지 시 세션 즉시 차단	데이터 유출 시도 차단
디바이스 ABAC	MDM 미등록 또는 패치 미적용 시 읽기 전용으로 강등	비관리 디바이스 위험 격리

Zero Trust: "어떤 사용자도, 어떤 디바이스도, 네트워크 내부에 있더라도 기본적으로 신뢰하지 않는다"는 보안 원칙입니다. AI 에이전트 환경에서는 "어떤 에이전트도 역할을 부여받았다고 해서 항상 신뢰하지 않는다"로 확장됩니다. 로그인 시 한 번 인증하는 방식이 아니라 매 요청마다 현재 컨텍스트를 검증하는 것이 핵심입니다.

예시 3: RAG 지식 베이스 접근 제어

AI 에이전트가 내부 지식 베이스를 검색할 때, 검색 전후로 ABAC 필터를 적용하는 Python 패턴입니다.

python

import asyncio
import os
from typing import List
from permitio import Permit
 
permit = Permit(token=os.environ["PERMIT_API_KEY"])
 
async def filtered_rag_search(
    agent_id: str,
    query: str,
    user_attributes: dict
) -> List[Document]:
 
    # Pre-query 필터: 검색 전 접근 가능한 네임스페이스 범위 결정
    accessible_checks = await permit.bulk_check([
        {
            "user": agent_id,
            "action": "read",
            "resource": {
                "type": "knowledge_base",
                "tenant": ns,
                "attributes": user_attributes  # 부서, 직급, 프로젝트 소속
            }
        }
        for ns in ALL_NAMESPACES
    ])
 
    allowed_namespaces = [
        ns for ns, allowed in zip(ALL_NAMESPACES, accessible_checks)
        if allowed
    ]
 
    # 허용된 네임스페이스만 대상으로 검색
    raw_results = await vector_store.search(
        query=query,
        namespaces=allowed_namespaces
    )
 
    # Post-query 필터: asyncio.gather로 병렬 권한 검사 후 미허가 문서 제거
    check_results = await asyncio.gather(*[
        permit.check(agent_id, "read", doc.resource_id)
        for doc in raw_results
    ])
    filtered_results = [
        doc for doc, allowed in zip(raw_results, check_results)
        if allowed
    ]
 
    return filtered_results

Pre/Post-query 필터링: 검색 전 단계에서 접근 불가능한 데이터 소스를 아예 검색 대상에서 제외하고(pre-query), 검색 후에는 결과 중 권한 없는 문서를 추가로 제거(post-query)하는 이중 방어 전략입니다. 에이전트가 아무리 광범위한 쿼리를 보내도 사용자 속성(부서·직급·프로젝트)에 맞는 정보만 반환됩니다.

장단점 분석

장점

항목	내용
컨텍스트 인식 제어	동일한 에이전트라도 업무 시간/심야, 회사 디바이스/개인 디바이스에 따라 다른 권한을 적용할 수 있습니다
Least Privilege 실시간 구현	현재 태스크에 필요한 최소 권한만 동적으로 부여하고 완료 후 자동 회수됩니다
감사 추적 품질 향상	모든 접근 결정이 평가된 속성과 함께 기록되어 "왜 허용/거부됐는가"를 사후 분석할 수 있습니다
Zero Trust 실현	에이전트를 역할만으로 신뢰하지 않고 매 요청마다 컨텍스트를 검증하는 구조가 만들어집니다
RBAC 기존 투자 보존	기존 역할 체계를 폐기하지 않고 위에 ABAC 레이어만 추가하는 방식입니다

단점 및 주의사항

항목	내용	대응 방안
정책 복잡성 폭발	속성 조합이 늘수록 정책 유지 관리 부담이 기하급수적으로 증가합니다	정책 테스트 자동화, 시뮬레이션 도구(Knostic) 도입
행동 기준선 구축 시간	이상 탐지를 위한 "정상" 행동 학습에 수 주~수 개월이 소요되며 초기 오탐이 발생할 수 있습니다	보수적인 고정 임계값(예: 평시 대비 쿼리 볼륨 2배 초과 시 차단)으로 시작한 뒤, 기준선 안정화 후 통계 기반 동적 임계값으로 점진 전환
속성 소스 신뢰성	디바이스 상태·위치 정보 등 컨텍스트 수집 파이프라인 자체가 공격 대상이 될 수 있습니다	속성 소스에 대한 별도 무결성 검증, 서명된 attestation 활용
레이턴시 영향	매 요청마다 다수의 속성을 실시간 평가하면 응답 지연이 발생합니다	TTL 기반 단기 캐싱, 비동기 정책 평가, 경량 로컬 캐시 도입

Attestation(검증): 디바이스나 소프트웨어의 무결성을 암호학적으로 증명하는 방법입니다. TPM(신뢰 플랫폼 모듈) 같은 하드웨어 보안 모듈을 통해 디바이스 상태가 변조되지 않았음을 서버가 검증할 수 있습니다. ABAC 정책에서 디바이스 속성의 신뢰성을 보장하는 핵심 메커니즘입니다.

실무에서 가장 흔한 실수

1. ABAC를 처음부터 전면 도입하려는 시도

모든 속성을 한 번에 정의하려다 정책 복잡성에 압도되어 프로젝트가 중단되는 경우가 많습니다. 환경(environment) 속성 하나부터 시작해 점진적으로 확장하는 것이 현실적입니다. context.environment == "staging" 조건 하나로도 가장 치명적인 시나리오인 프로덕션 DB 삭제를 방어할 수 있습니다.

2. 행동 기준선 없이 이상 탐지 임계값을 고정값으로 설정

"다운로드 1GB 초과 시 차단"처럼 고정값을 쓰면 정상 배치 작업도 차단하거나, 반대로 점진적으로 증가하는 데이터 유출은 탐지하지 못합니다. 기준선 구축에 시간이 필요하다면, 먼저 스테이징 환경에서 실행 트레이스를 수집해 정상 패턴을 파악한 뒤 프로덕션에 적용하는 순서를 권장합니다.

3. 속성 수집 파이프라인 보안을 간과

디바이스 상태나 위치 정보를 조작하면 ABAC 정책 전체를 우회할 수 있습니다. 속성 소스 자체의 무결성 검증 없이 ABAC를 도입하면 오히려 허위 보안감(false sense of security)을 줄 수 있습니다. ABAC 도입과 함께 속성 수집 파이프라인에 대한 별도의 보안 검토를 병행하는 것이 중요합니다.

마치며

RBAC가 AI 에이전트의 정적 신뢰 경계를 대체하지 못하는 이유는 단순합니다 — 에이전트는 역할이 아니라 컨텍스트로 행동하기 때문입니다. ABAC 하이브리드 모델은 이 간극을 메우는 가장 현실적인 접근법으로, 기존 RBAC 투자를 유지하면서 실시간 행동·시간·디바이스 속성으로 에이전트를 지속적으로 검증하는 구조를 만들어줍니다.

지금 바로 시작해볼 수 있는 3단계입니다.

현재 AI 에이전트의 접근 권한 목록을 점검해보시기 바랍니다. 에이전트에 부여된 역할과 그 역할로 접근 가능한 리소스 목록을 정리하면 과잉 권한이 시각적으로 드러납니다. aws iam simulate-principal-policy 또는 클라우드 IAM 분석 도구를 활용할 수 있습니다.
가장 위험한 리소스 하나를 골라 환경 속성 하나만 추가해보시기 바랍니다. Cedar나 Permit.io로 context.environment == "staging" 조건 하나를 추가하는 것으로도 Replit 사고와 같은 시나리오를 방어할 수 있습니다. AWS Cedar Playground에서 정책 문법을 바로 테스트해볼 수 있습니다.
에이전트의 행동 로그 수집을 시작해보시기 바랍니다. 소규모 팀이나 초기 단계라면 Obsidian Security 같은 SaaS 솔루션으로 빠르게 시작할 수 있고, 충분한 엔지니어링 리소스가 있는 팀이라면 기존 로깅 인프라에 에이전트 행동 컬럼을 추가하는 자체 구현도 현실적인 선택입니다. API 호출 패턴·시간대·볼륨을 로깅하면 행동 기준선 구축의 출발점이 됩니다. AgentGuardian 논문(arXiv:2601.10440)의 스테이징 단계 학습 방법론도 참고해보실 수 있습니다.

시리즈 안내

다음 글: Policy-as-Code 실전 가이드 — AWS Cedar와 OPA로 AI 에이전트 정책을 코드로 테스트하고 CI/CD 파이프라인에 통합하는 방법

참고 자료