Hermes 에이전트는 MCP를 연결할 수 있지만, 팀이 무작위로 한 MCP 구성과 키를 공유해서는 안 됩니다. MCP의 위험은 '도구가 얼마나 많은지'가 아니라, 도구들이 GitHub, 데이터베이스, 클라우드 계정, 티켓팅 시스템, 로컬 파일에 연결되어 있는지에 관한 것입니다. 프로젝트, 멤버, 권한 수준은 별도로 설정해야 합니다.
언제 공유할 수 있을까요?
읽기 전용, 저위험, 비민감성 데이터 도구(예: 공용 문서 검색, 형식 변환, 내부 허가 없는 상태 페이지 등)를 공유할 수 있습니다. 도구가 권한을 쓰고, 삭제하고, 게시하고, 지불하고, 변경할 수 있는 한, 모든 에이전트에 대해 단일 공개키를 사용하는 것은 적합하지 않습니다.
엉망으로 하지 않고 해체하는 방법
프로젝트별로 해체하는 것이 개인 이름으로 해체하는 것보다 유지하기가 더 쉽습니다. 각 프로젝트는 자체 MCP 서버, 환경 변수, 자격 증명 소스를 유지합니다; 에이전트가 프로젝트에 들어오면 해당 도구만 로드됩니다. 팀원들이 프로젝트를 떠날 때는 에이전트를 어느 기기에서 실행했는지 추측하는 대신 프로젝트 키를 회전시키세요.
설정 전에 세 가지 질문
이 도구가 실제 데이터를 바꿀 수 있나요? 통화 기록을 어디서 확인할 수 있나요? 누수 후 키를 빠르게 취소할 수 있나요? 세 가지 질문 모두 답할 수 없다면, 자주 사용하는 프로필에 추가하지 마세요.
많은 사람들이 처음에 MCP를 '기능이 많을수록 더 좋다'는 확장 시장으로 보지만, 에이전트에게는 허가가 핵심입니다. 더 안정적인 전략은 먼저 읽기 전용 도구와 연결한 뒤, 완전히 설정된 후에 쓰기 권한을 추가하는 것입니다; 처음에는 테스트 프로젝트용으로, 그다음에는 생산 프로젝트용으로; 먼저 한 명의 에이전트가 시도하게 하고, 그 다음에 팀 공유를 고려하세요. 이 설정은 다소 느리지만, 문제가 발생하면 찾아내어 해제하고 검토할 수 있습니다.
간단한 판단은 다음과 같습니다: 동일한 MCP 자격 증명 세트가 테스트 라이브러리, 생산 라이브러리, 고객 데이터에 동시에 접근할 수 있다면, 더 이상 공유에 적합하지 않습니다. 먼저, 읽기, 쓰기, 게시 허가 세 가지 범주를 분리한 후 에이전트가 이를 사용하도록 하세요. 이후 감사와 철회가 훨씬 수월해질 것입니다.
