AI 에이전트에 통제된 접근 권한 부여
AI 에이전트에 인프라를 맡기기로 했습니다. Claude가 장애 난 서비스를 고치거나, Cursor가 마이그레이션을 돌리거나, 직접 만든 에이전트가 정기 점검을 처리하는 식입니다. 이제 남은 문제는 접근을 줄지 말지가 아니라, 회수할 수 없는 상시 키를 넘기지 않으면서 어떻게 접근을 허용할지입니다.
이 문서는 그 결정을 내리는 사람, 즉 에이전트를 도입하는 워크스페이스 관리자나 팀 리드를 위한 여정입니다. 에이전트를 연결하고, 눈앞의 작업에 맞게 범위를 좁히고, 승인은 사람이 맡고, 작업을 지켜보고, 에이전트가 한 일을 모두 되짚어 보는 흐름을 단계별로 짚으며, 각 단계마다 자세한 내용을 다루는 문서로 연결합니다. 개념부터 잡고 싶다면 AI 에이전트에서 모델을 먼저 이해한 뒤 이 문서로 돌아와 실제 연결을 진행하세요.
한 문단으로 보는 모델
AI 에이전트는 Alpacon에서 사람과 동등한 일급 행위자이며, 사람과 같은 방식으로 통제됩니다. 서버에 직접 접속하지 않고, 범위가 지정되고 시간이 제한되며 기록되는 작업 세션을 열어 그 안에서만 작업합니다. 다만 에이전트에는 사람보다 더 엄격한 규칙이 적용됩니다. Superuser가 본인을 위해 요청한 세션은 자동으로 승인되지만, 에이전트가 요청한 세션은 Superuser가 요청하더라도 항상 사람의 승인이 필요합니다. 사람이 아닌 행위자에게 자동 승인 경로는 존재하지 않습니다. 바로 이 비대칭이 Alpacon 에이전트 거버넌스의 핵심이며, 아래 단계는 모두 이 원칙을 설정하고 운영하는 방법입니다.
1단계: 에이전트 연결
에이전트는 **MCP(Model Context Protocol)**로 Alpacon에 접근하며, 경로는 두 가지입니다.
- 호스팅: MCP 클라이언트를
https://mcp.alpacon.io/mcp로 지정하고 브라우저에서 로그인합니다. 설치할 것도 없고 설정 파일에 API 토큰을 붙여 넣을 필요도 없습니다. 에이전트는 로그인한 계정으로 인증되어 그 계정의 아이덴티티, 역할, 감사 추적을 그대로 물려받습니다. - 로컬: 로컬 프로세스를 선호하는 환경을 위해
uvx alpacon-mcp로 Alpacon MCP 서버를 직접 실행하고 API 토큰으로 구성합니다.
Claude Code에서는 호스팅 경로가 한 줄이면 됩니다.
claude mcp add --transport http alpacon https://mcp.alpacon.io/mcp처음 사용할 때 클라이언트가 브라우저를 열어 로그인하도록 안내하며, claude mcp list로 연결을 확인합니다. 클라이언트별 설정을 여기서 반복하지 않으니, Claude Desktop, Cursor, VS Code와 로컬 서버 구성은 MCP 시작하기에서, 전체 도구 목록은 MCP 레퍼런스에서 확인하세요. 이 여정에서 중요한 점은 이것입니다. 에이전트를 연결해도 SSH 키나 VPN 자격 증명은 넘어가지 않으며, 에이전트는 웹 콘솔·CLI와 동일한 통제된 아이덴티티 계층을 통해 작업합니다.
2단계: 작업에 맞게 범위 좁히기
에이전트를 연결했다고 해서 그 자체로 권한이 생기지는 않습니다. 접근은 여러 겹으로 제한되며, 각 겹은 에이전트가 명령을 실행하기 전에 관리자가 직접 정하는 것입니다.
- 워크스페이스 멤버십: 에이전트는 Alpacon 아이덴티티로 동작합니다. 자신이 대신 일하는 사람이거나, 자동화를 위해 만든 애플리케이션입니다. 그 아이덴티티가 속한 하나의 워크스페이스만 볼 수 있습니다.
- 그룹 기반 서버 자격: 워크스페이스 안에서는 그룹 멤버십이 아이덴티티가 요청할 수 있는 서버를 결정합니다. 아이덴티티에 연결된 그룹이 없는 서버는 그 아이덴티티에게 아예 보이지 않습니다. 사람에게 적용하는 것과 같은 연결 방식이며, 자세한 내용은 서버 접근 제어를 참고하세요.
- 세션 범위(scope): 실제로 작업하려면 에이전트가 작업 세션을 여는데, 이 세션은 목적, 대상 서버, 필요한 기능(웹 터미널, 파일 전송, 명령 실행, 포트 포워딩, 코드 에디터, 권한 상승), 만료 시각을 선언합니다. 이 범위는 넘을 수 없는 상한입니다. 범위 밖의 작업은 거부되고, 세션은 시간이 다 되면 스스로 종료됩니다.
이 방식을 제대로 살리는 원칙은 상시 넓은 권한이 아니라 작업 단위 요청입니다. 에이전트를 모든 그룹에 넣어 두고 습관적으로 네 시간짜리 전체 기능 세션을 열게 하지 마세요. 아이덴티티에는 실제로 필요한 그룹만 부여하고, 세션마다 그 작업에 필요한 서버·기능·시간만 요청하게 하세요. 최소 권한이 기본값입니다. 에이전트는 요청한 것만, 요청한 시간 동안만 얻습니다. 전체 모델은 작업 세션을 참고하세요.
3단계: 승인 순간
에이전트의 세션은 항상 사람을 기다리므로, 팀의 누군가가 그 요청을 보게 됩니다. 작업 세션의 경우 검토자가 요청 관리 큐에서 요청을 열면 요청자의 사유, 요청한 기간, 대상 서버, 요청한 기능을 확인할 수 있습니다. 여기에 AI 사전 검토가 위험도(낮음, 중간, 높음, 심각)를 추천하고, 그 판단 근거를 설명하며, 세션에 필요하다고 본 기능을 강조해 줍니다.
검토자는 단순히 승인·거부만 하는 것이 아닙니다. 승인하기 전에 범위를 좁힐 수 있습니다. 기능을 추가·제거하고, 대상 서버를 추가·제거하고, 세션 시작 전에 에이전트 운영자가 보게 될 권장 사항을 덧붙일 수 있습니다. 그래서 승인 순간은 곧 범위 조정의 순간이기도 합니다. 지나치게 넓은 에이전트 요청을 작업에 딱 맞게 다듬은 뒤 승인할 수 있습니다. 요청 유형별로 무엇을 조정할 수 있는지는 요청 검토와 요청 유형을 참고하세요.
검토자 입장에서 에이전트 요청을 어떻게 읽고 빠르게 판단할지는 이 문서의 짝인 승인자 가이드에서 다룹니다. 큐를 담당하는 사람을 위한 문서입니다.
4단계: 작업 지켜보기
세션이 승인되어 활성 상태가 되면, 세션이 끝날 때까지 기다리지 않고도 무슨 일이 일어나는지 볼 수 있습니다. Live activity(Superuser 전용)는 활성 세션을 실시간으로 스트리밍합니다. 명령이 생성·실행·종료되는 흐름, 터미널이 열리고 닫히는 것, sudo가 요청·승인·거부되는 것, 파일이 오가는 것을 카테고리별로 걸러 볼 수 있습니다.
세션이 진행되는 동안 두 가지는 사람의 손에 남아 있습니다.
- 민감한 작업은 실행되는 순간 보류됩니다. 권한 상승(sudo)을 비롯한 고위험 작업은 그냥 실행되지 않고 사람 승인자에게 전달되며, 에이전트는 결정이 날 때까지 기다렸다가 진행합니다. 기댈 수 있는 상시 권한이 없으므로, 속거나 탈취된 에이전트도 몰래 권한을 끌어올릴 수 없습니다.
- 개입할 수 있습니다. 실시간 화면에서 세션 완료로 세션을 즉시 끝내거나, 승인됐지만 진행되면 안 되는 세션을 세션 철회로 종료할 수 있습니다. 모든 명령과 전송은 실행되는 대로 기록되므로, 기록 없이 벌어지는 일은 없습니다.
5단계: 에이전트가 한 일 되짚어 보기
작업이 끝나면 세션 전체를 다시 검토할 수 있습니다. 사람보다 사람이 아닌 행위자에게 이 점이 더 중요합니다. “내가 뭘 실행했는지 기억한다”에 책임을 기댈 수 없기 때문입니다. 감사는 완전한 기록을 남깁니다.
- 세션: 모든 작업 세션이 한 목록(세션 이력)에 모이고, 운영자 열이 실제로 세션을 실행한 주체가 사용자인지 API 토큰인지 서비스 토큰인지 알려 줍니다. 누가 요청했고, 누가 승인했고, 범위가 무엇이었고, 어떻게 끝났는지 볼 수 있습니다.
- 타임라인과 녹화: 세션 상세에서 명령, 터미널, sudo 승인, 파일 전송을 시간순 타임라인으로 재생하고, 마스킹된 터미널 녹화를 재생해 볼 수 있습니다. 세션 종료 후를 참고하세요.
- AI 사후 분석: 세션이 끝나면 Alpacon이 AI 위험 분석을 더합니다. 위험도, 평이한 요약, 공격 체인·위협 점검, 권장 검증 절차를 제공합니다. 4단계의 실시간 흐름을 보완하는, 사후에 내리는 더 깊은 판단입니다.
사람, 파이프라인, 에이전트가 모두 같은 작업 세션 모델을 거치므로, 이들의 활동은 하나의 타임라인에 모입니다. “어젯밤 prod-web-1에서 무슨 일이 있었나?”라고 물으면, 여기저기 흩어진 로그를 이어 붙이는 대신 사람의 명령, 에이전트의 작업, CI 실행이 함께 담긴 단일 기록으로 답할 수 있습니다. 이 공통 타임라인이 있어 에이전트의 행동도 사람과 같은 기준으로 책임을 물을 수 있습니다.
에이전트가 할 수 없는 일
이 거버넌스 모델은 빠져나갈 만한 구멍을 막습니다. 에이전트는 자신의 작업을 스스로 승인할 수 없습니다. 요청한 아이덴티티가 Superuser라 하더라도, 에이전트가 요청한 세션에는 항상 사람이 필요합니다. 자신이 요청한 채널로 승인할 수도 없습니다. 요청은 제출된 채널에서 승인할 수 없으므로, CLI나 MCP로 일하는 에이전트가 돌아서서 자기 요청을 스스로 통과시킬 수 없습니다. 승인은 웹 콘솔이나 Slack에서 Superuser가 합니다. 또한 사람의 신원 확인을 대신할 수 없습니다. 사람의 다단계 인증(MFA)이 필요한 단계는 에이전트가 충족할 수 없어, 그냥 진행되는 대신 실제 사람에게 넘어갑니다. MFA를 사용한 sudo를 참고하세요.
숨기지 않고 짚어 둘 만한 미묘한 지점이 하나 있습니다. 작업 세션 게이트는 에이전트의 인증 방식에 따라 달라집니다. 앞서 권장한 대로 에이전트가 브라우저 로그인(MCP OAuth)으로 연결하면, 명령 실행이나 파일 전송처럼 인프라를 변경하는 작업은 반드시 활성화된 승인된 작업 세션에 연결되어야 합니다. 반면 정적 API 토큰은 작업 세션에 묶이지 않는 다른 경로를 따릅니다. 따라서 토큰은 게이트를 건너뛰는 수단이 아니라, 소유자와 감사가 명확한 자동화 자격 증명으로 다루세요. 토큰은 애플리케이션에 발급해 그 활동의 범위와 귀속을 분명히 하고, 대화형 에이전트는 브라우저 로그인으로 유지하세요. 정확히 어떤 호출이 세션 범위에 묶이는지는 MCP 레퍼런스를 참고하세요.