AI 에이전트가 운영 DB를 날릴 뻔해서 방화벽을 직접 만들었습니다.
My AI agent almost deleted our entire production database. So I built a firewall for it.
핵심 요약
AI 에이전트의 위험한 DB 조작을 방지하기 위해 승인 절차와 감사 로그를 포함한 미들웨어 'Suraksha'를 개발했습니다.
- 에이전트 사고 방지 — 에이전트가 의도치 않게 운영 DB를 삭제하는 위험을 방지하기 위한 미들웨어 개발.
- Suraksha 미들웨어 — 데코레이터를 사용하여 함수 호출 시 위험도를 평가하고 승인 절차를 강제함.
- 운영 안전성 강화 — 고위험 작업 시 Slack 알림을 통해 사람이 직접 승인하거나 거부할 수 있도록 설계됨.
- 오픈소스 공개 — MIT 라이선스로 코드를 공개하여 실제 에이전트 개발 환경에서의 유용성을 검증받고자 함.
운영 DB 정리 작업을 처리하기 위해 자율 에이전트를 테스트하고 있었습니다. 테스트 실행 중에 에이전트가 완전히 스스로 판단해서, 건드려서는 안 될 테이블에 DELETE 명령을 실행하기로 결정했습니다. 다행히 아무 일도 일어나지 않았지만, 정말 간담이 서늘했습니다.
무서운 점은 에이전트와 데이터베이스 사이에 아무것도 없었다는 것입니다. 가드레일도, 승인 단계도 없었습니다. 그저 LLM이 파괴적인 쿼리를 환각하지 않기를 바랄 뿐이었죠.
AI 에이전트와 에이전트가 호출하는 도구(데이터베이스, API, 파일 시스템) 사이에 위치하여 실행 전에 작업을 가로챌 수 있는 무언가를 찾아봤습니다. 하지만 간단하게 적용할 수 있는 것을 찾을 수 없었습니다.
그래서 Suraksha(산스크리트어로 '보호'라는 뜻)를 만들었습니다. AI 에이전트를 위한 미들웨어 계층입니다. 데코레이터를 사용하여 모든 함수를 감쌀 수 있습니다:
@guard(policy="no_destructive_db_ops", require_approval_above_risk=0.7)
async def delete_records(table: str, where: str):
await db.execute(f"DELETE FROM {table} WHERE {where}")
이제 모든 호출이 평가됩니다. 저위험 작업은 자동으로 통과됩니다. 고위험 작업은 일시 중지되고 Slack 메시지를 보내 사람이 승인하거나 거부하도록 요청합니다. 모든 작업은 감사를 위해 기록됩니다.
이게 다른 사람들도 겪는 실제 문제인지, 아니면 저만 편집증적인 건지 궁금합니다.
AI 에이전트로 개발하는 분들께 드리는 몇 가지 솔직한 질문입니다:
- 에이전트가 운영 환경에서 예상치 못한 행동을 하거나, 거의 할 뻔한 적이 있나요?
- 현재 "이 에이전트가 무엇을 할 수 있는지"를 어떻게 관리하고 계신가요? 수동 코드 검사인가요? 프롬프트인가요? 아니면 아무것도 안 하시나요?
- 이런 드롭인 방식의 계층이 실제 개발 방식에 잘 맞을까요, 아니면 오버헤드처럼 느껴지시나요?
무언가를 팔려는 게 아닙니다. 실제 코드를 보고 싶으시다면 저장소는 공개되어 있습니다(MIT 라이선스): github.com/Pannagaperumal/Suraksha
정말 냉정한 피드백을 듣고 싶습니다. 이게 실제 문제를 해결하는 건가요, 아니면 아무도 원하지 않는 걸 제가 만들고 있는 건가요?
