에이전트가 데이터베이스에 질의하게 하세요,
허락하기 전까지는 읽기 전용으로

MySQL과 MariaDB, 그 둘뿐입니다. 클라이언트가 MySQL 와이어 프로토콜을 사용하고 MariaDB는 그것과 호환되므로 둘 다 동작합니다. 직접 연결해도 되고, SSH 터널이나 AWS SSM 포트 포워딩 세션을 통해도 됩니다. PostgreSQL, MongoDB, SQL Server, SQLite를 비롯한 나머지는 오늘 기준 지원하지 않습니다. 그중 하나가 필요하다면 공개 백로그에 요청하세요. 목록은 사람들이 실제로 요청하는 것에 따라 늘어납니다.

아니요. 에이전트가 질의에 쓰는 MCP 도구인 db_query는 연결이 무엇을 허용하든 읽기 전용입니다. SELECT, SHOW, DESCRIBE, EXPLAIN, WITH는 통과하고, 데이터를 바꾸는 것은 전부 거부됩니다. 연결을 쓰기 가능으로 만들면 쓰기가 열리는 대상은 SQL 콘솔에 있는 사용자이고, 그곳에서는 쓰기마다 명시적으로 확인합니다. 에이전트에게는 열리지 않습니다. 가드레일은 비밀번호가 아니라 구문 위에 앉아 있습니다. DROP을 실행하는 데 필요한 것은 비밀번호가 아니기 때문입니다.

AgentsRoom에 이미 저장한 SSH 및 SSM 연결로 만든 SSH 터널이나 AWS SSM 포트 포워딩 세션으로 연결의 경로를 잡으세요. 앱이 터널이나 세션을 열고 그 너머로 데이터베이스에 연결하므로, 데이터베이스는 공개 인터넷에서 닿지 않는 상태로 남습니다.

아니요. 에이전트는 연결의 이름을 지목해 MCP로 질의합니다. 자격 증명은 AgentsRoom이 보관하고 구문도 앱이 직접 실행하므로, 비밀번호는 에이전트에 반환되지 않고, 질의에 적히지 않으며, 대화에도 남지 않습니다.

아니요. 한 번의 호출에는 정확히 구문 하나만 담깁니다. 세미콜론 뒤에 쌓인 것은 실행되지 않고 거부되며, 그래서 읽기처럼 보이는 것 안에 쓰기를 숨기는 가장 오래된 수법이 통하지 않습니다.

쓰기 전에 요구되는 확인이 더 까다로워집니다. 중요한 데이터베이스가 로컬 사본처럼 행동하지 않게 되죠. 긴 하루의 끝에 있는 당신에게 필요한 것이고, 작업 목록을 훑어 내려가는 에이전트에게는 더더욱 필요한 것입니다.

결과 집합에는 상한이 있습니다. 거대한 테이블을 통째로 반환할 질의는 창이나 에이전트 컨텍스트를 뒤덮는 대신 잘린 채 돌아옵니다. 그래서 넓은 SELECT는 데이터 반출이 아니라 약간의 불편으로 남습니다.

제안은 할 수 있지만 저장은 절대 하지 못합니다. db_connection_new는 호스트, 포트, 사용자, 그리고 데이터베이스에 닿을 SSH 또는 AWS SSM 연결로 미리 채운 생성 폼을 열고, 검토하고 비밀번호를 입력하고 저장하는 것은 사용자입니다. 저장하기 전까지는 아무것도 기록되지 않으며, 자격 증명을 제공하는 것은 결코 에이전트가 아닙니다.

db_schema로 파악합니다. SQL 없이 저장된 연결을 탐색하는 도구입니다. 인자 없이 호출하면 스키마를 나열하고, 데이터베이스를 주면 테이블과 뷰를 나열하며, 테이블을 주면 컬럼과 그 타입, null 허용 여부, 키, 기본값을 반환합니다. 에이전트에게 information_schema를 손으로 질의하게 하는 것보다 비용이 적고 더 안전합니다.