AI 코딩 도구를 실제 데이터에 연결하는 것은 생성된 코드의 정확도를 획기적으로 높여주는 설정입니다. 하지만 개발자들이 망설이는 질문은 이것입니다: 에이전트(agent)가 실제로 어느 정도의 권한을 가져야 하는가?

정답은 당신이 무엇을 달성하려 하는지에 따라 다르지만, 원칙은 일관됩니다: 에이전트는 작업에 필요한 최소한의 액세스 권한만 가져야 하며, 에이전트가 우회할 수 없는 계층에서 이 권한이 강제되어야 합니다.

중요한 리스크

에이전트 자체가 주요 위협 모델은 아닙니다. Claude Code, Cursor, Codex는 로컬 도구입니다. 이들은 외부 당사자에게 데이터를 유출하지 않으며, 당신이 명시적으로 설정하지 않는 한 당신의 승인 없이 자율적으로 행동하지 않습니다. 실제적인 리스크는 다음과 같습니다:

• 잘못된 위치에 있는 관리자 자격 증명 (Admin credentials). 만약 서비스 역할 키(service role key)나 관리자 토큰(admin token)을 사용하여 에이전트를 데이터베이스에 연결했는데, 해당 자격 증명이 생성된 파일, 셸 히스토리(shell history), 또는 커밋되는 .env 파일에 나타난다면 — 그것은 노출된 것입니다.
• 에이전트가 작성해서는 안 될 것에 쓰는 경우. 프로덕션 데이터에 쓰기 권한(write access)이 있는 에이전트는 레코드를 삭제하거나, 값을 덮어쓰거나, 라이브 데이터베이스에 테스트 데이터를 삽입할 수 있습니다. 이것은 악의적인 행동이 아니라 실수입니다.
• 과도하게 광범위한 읽기 (Over-broad reads). 멀티 테넌트(multi-tenant) 시스템의 모든 데이터를 읽을 수 있는 에이전트는 응답, 로그 또는 생성된 모의 데이터(mock)에 의도치 않게 다른 사용자의 데이터를 포함할 수 있습니다.
• 애플리케이션 로직 우회. 원시 데이터베이스 액세스 권한을 가진 에이전트는 검증 로직(validation logic), 비즈니스 규칙(business rules), 감사 추적(audit trails)을 건너뛰는 레코드를 작성할 수 있으며, 이는 유효해 보이지만 실제로는 그렇지 않은 데이터를 생성합니다.

이러한 문제들은 적절한 아키텍처를 통해 해결 가능합니다.

레이어 1: 직접적인 데이터베이스 액세스를 위해 범위가 제한된 읽기 전용 자격 증명 사용

Postgres MCP 서버 또는 이와 유사한 직접 연결을 통해 에이전트를 데이터베이스에 연결하는 경우, 필요한 최소한의 권한만 가진 전용 자격 증명을 생성하십시오:

• 스키마 조사(schema inspection) 및 쿼리 작업을 위한 경우: SELECT 및 스키마 조사(schema introspection) 쿼리만 실행할 수 있는 읽기 전용(read-only) 역할만 부여하고, 그 외의 권한은 일절 허용하지 마십시오.
• 에이전트 연결 시 서비스 역할(service role)이나 관리자 키(admin key)를 절대 사용하지 마십시오. 이러한 키들은 모든 보안 정책을 우회하며 에이전트에게 제한 없는 접근 권한을 부여합니다.
• 하드코딩된 값 대신 환경 변수(environment variables)를 사용하십시오. 자격 증명은 커밋될 가능성이 있는 MCP 설정 파일이 아니라, .env 파일(.gitignore에 추가됨) 또는 비밀 관리자(secret manager)에 보관되어야 합니다.

Postgres 역할 설정 예시:

CREATE ROLE ai_agent_readonly;
GRANT CONNECT ON DATABASE your_db TO ai_agent_readonly;
GRANT USAGE ON SCHEMA public TO ai_agent_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_agent_readonly;
이 역할을 사용하면 에이전트는 모든 테이블을 읽을 수 있지만, 쓰기, 삭제 또는 스키마를 수정할 수는 없습니다. 이는 스키마 조사 및 쿼리 개발에 사용하기에 안전합니다.

레이어 2: 데이터베이스 계층에서의 행 수준 보안 (Row-Level Security)

읽기 전용 자격 증명은 에이전트가 수행할 수 있는 작업(operations)을 제한합니다. 행 수준 보안 (Row-Level Security, RLS)은 해당 작업 내에서 에이전트가 볼 수 있는 행(rows)을 제한합니다.

멀티 테넌트(multi-tenant) 애플리케이션 — 즉, 서로 다른 사용자가 각자의 데이터를 가지는 모든 앱 — 에서 전체 주문(orders) 테이블에 대한 읽기 권한을 가진 에이전트는 현재 사용자에게 속한 주문뿐만 아니라 잠재적으로 모든 주문을 반환할 수 있습니다. 만약 해당 데이터가 생성된 응답, 로그 파일 또는 오류 메시지에 나타난다면, 이는 데이터 노출(data exposure)에 해당합니다.

RLS는 쿼리 결과가 애플리케이션에 도달하기 전, 데이터베이스 계층에서 필터를 강제함으로써 이 문제를 해결합니다. "user_id = current_user_id()인 행만 반환하라"는 정책은 쿼리가 인간 개발자, 애플리케이션 계층, 또는 AI 에이전트에 의해 작성되었는지 여부와 관계없이 적용됩니다.

핵심적인 속성은 다음과 같습니다: RLS (Row-Level Security) 강제 적용은 애플리케이션이 아닌 데이터베이스 수준에서 발생합니다. 테넌트 격리(tenant-isolated) 시스템에서 모든 주문을 반환하는 쿼리를 작성하는 에이전트라 할지라도, 현재 인증된 컨텍스트(authenticated context)가 볼 수 있도록 권한이 부여된 행만 받게 됩니다. 에이전트는 올바르게 구성된 RLS 정책을 우회하는 쿼리를 생성할 수 없습니다.

레이어 3: 직접적인 데이터베이스 액세스 대신 서버 측 로직이 있는 백엔드 사용

프로덕션 애플리케이션의 경우, 가장 깔끔한 아키텍처는 에이전트에게 데이터베이스에 직접 액세스 권한을 주는 것이 아니라, 그 앞에 있는 제어된 API 접점(API surface)에 대한 액세스 권한을 주는 것입니다.

이것이 Momen이 사용하는 모델입니다. 에이전트를 가공되지 않은 Postgres에 연결하는 대신, 다음과 같은 기능을 갖춘 자동 생성된 GraphQL API에 연결합니다:

• 명시적으로 구성한 작업만 노출 (가능한 모든 테이블 액세스가 아님)
• 모든 요청에 대해 Momen의 RBAC (Role-Based Access Control) 및 데이터베이스 계층의 RLS를 강제 적용 — 에이전트가 영리한 쿼리를 작성하여 이를 우회할 수 없음
• 검증 로직, 비즈니스 규칙 및 감사 추적(audit trails)을 포함하는 서버 측 Actionflows를 통해 뮤테이션(mutations)을 라우팅
• 에이전트 액세스를 위해 전체 서비스 키가 아닌, 범위가 제한된 Admin Bearer Tokens를 발급

에이전트는 이 API 접점을 통해 실제 데이터를 읽고 쓸 수 있지만, API가 허용하는 작업만 수행할 수 있습니다. 레코드를 추가하면 인간 사용자가 트리거하는 것과 동일한 Actionflow가 트리거되며, 여기에는 해당 플로우에 포함된 모든 검증 및 비즈니스 로직이 포함됩니다.

Momen의 권한 문서는 RBAC와 RLS 계층이 어떻게 함께 작동하는지 다룹니다. AI 에이전트 개요는 서버 측 에이전트가 동일한 권한 경계 내에서 어떻게 작동하는지 보여줍니다.

이 아키텍처가 중요한 이유는 구체적인 이유가 있습니다. 즉, 에이전트의 작업이 시스템의 다른 모든 행위자와 동일한 규칙에 의해 로그가 기록되고, 검증되며, 제한된다는 것을 의미합니다. 보안 모델을 우회하는 "에이전트 예외"란 존재하지 않습니다.

실제로 구성해야 할 것

개발 / 스키마 작업을 위해:

• RLS (Row-Level Security) 정책이 적용된 읽기 전용 자격 증명 (Read-only credential)
• 직접적인 데이터베이스 MCP (Model Context Protocol)는 괜찮습니다 — 에이전트는 스키마를 읽고 쿼리를 작성해야 하기 때문입니다.
• 자격 증명은 설정 파일(config files)이 아닌 환경 변수 (environment variables)에 보관하세요.

프로덕션 데이터 접근의 경우:

• 직접적인 데이터베이스 접근 대신 백엔드 API (GraphQL, REST 또는 Actionflows)를 사용하세요.
• 에이전트 접근을 위해 관리자 키 (admin key)가 아닌 범위가 제한된 토큰 (scoped token)을 발급하세요.
• API가 프로덕션 시스템과 동일한 RLS 정책을 강제하는지 확인하세요.
• 에이전트가 호출할 수 있는 Actionflows를 감사 (Audit) 하세요 — 모든 Actionflow가 에이전트에게 접근 가능해서는 안 됩니다.

멀티 테넌트 (multi-tenant) 애플리케이션의 경우:

• 에이전트에게 프로덕션 테이블에 대한 읽기 권한을 부여한다면, 데이터베이스 계층에서의 RLS는 타협할 수 없는 필수 사항입니다.
• 프로덕션 데이터에 연결하기 전에, 에이전트의 쿼리가 테넌트 격리 (tenant isolation)를 올바르게 준수하는지 테스트하세요.
• 대표성을 띠지만 민감하지 않은 데이터를 가진 스테이징 환경 (staging environment)에서 시작하는 것을 고려하세요.

에이전트 키에 관한 참고 사항

Momen의 Admin Bearer Token 모델은 에이전트 접근 시나리오를 위해 특별히 설계되었습니다. 에이전트에게 전체 관리자 자격 증명을 주는 대신, 정의된 범위 (scope)를 가진 Bearer Token을 발급합니다. 즉, 특정 Actionflows를 호출하고 특정 테이블을 읽을 수 있을 뿐, 그 외의 것은 할 수 없습니다. 범위가 잘못되었거나 변경이 필요한 경우, 근본적인 자격 증명이 아닌 토큰을 교체 (rotate) 합니다.

이는 우수한 API 보안이 모든 외부 호출자에게 사용하는 것과 동일한 패턴입니다: 범위가 지정되고 교체 가능한 자격 증명을 통한 최소 권한 접근 (least-privilege access) 방식입니다. 에이전트 역시 또 다른 외부 호출자일 뿐입니다.

요약

안전한 AI 데이터 접근을 위한 실질적인 설정은 세 가지 계층으로 구성됩니다:

• 범위가 지정된 자격 증명 (Scoped credentials) — 가능한 경우 읽기 전용으로 사용하며, 절대 관리자 키를 사용하지 말고, 항상 환경 변수에 보관합니다.
• 행 수준 보안 (Row-Level Security) — 데이터베이스 계층에서 강제하여 에이전트가 데이터를 과도하게 노출하는 쿼리를 작성할 수 없도록 합니다.
• 직접적인 데이터베이스 접근 대신 API 접점 (API surface) 사용 — 프로덕션 시스템의 경우, 비즈니스 규칙과 감사 추적 (audit trails)을 강제하는 제어된 API에 에이전트가 접근할 수 있도록 합니다.

목표는 에이전트에게 접근 권한을 전혀 주지 않는 것이 아닙니다. 제한된 접근 권한은 환각 (hallucinations)과 저품질의 출력을 생성합니다. 목표는 에이전트에게 경계가 지정된 접근 권한 (bounded access)을 부여하는 것입니다. 즉, 작업을 올바르게 수행할 수 있을 만큼 충분하면서도, 실수가 사고로 이어지지 않도록 제약이 걸린 접근 권한을 제공하는 것입니다.