이제 접근 규칙을 문장을 완성하듯 직관적으로 만들고, 실제 요청이 들어오기 전에 어떻게 적용될지 미리 시험해 볼 수 있습니다. 승인 카드와 감사 기록에는 각 요청을 결정한 규칙이 남고, Alpacon을 거치지 않은 직접 로그인은 확인이 필요한 것만 검토 대기열에 올라옵니다.
접근 규칙을 직관적으로 만들고, 한눈에 확인합니다
Privileged access와 Approval rules에서 각각 관리하던 규칙이 이제 Admin > Policies > Access rules 한 페이지로 모였습니다. 규칙을 누르면 "AI 에이전트가 이 서버에서 세션을 열면 승인자에게 묻는다" 같은 문장으로 열리고, 밑줄 친 부분을 눌러 빈칸을 고르면 규칙이 됩니다. 세션, sudo, 명령어 규칙을 모두 이렇게 만들고, 순서는 목록에서 끌어서 바꿀 수 있습니다.
미리보기에서는 사람이나 에이전트가 특정 서버에서 어떤 작업을 하면 어떻게 처리될지 확인할 수 있습니다. 예를 들어 아래 화면처럼 "관리자와 그룹 관리자가 alpacon 그룹 서버에서 세션을 열면"을 고르면, 누구의 승인이 필요한지와 함께 어떤 규칙이 해당되지 않았고 어떤 규칙이 결정했는지가 순서대로 표시됩니다. AI 에이전트를 고르고 Claude Code 같은 이름을 붙여 시험할 수도 있습니다. 실제 요청은 만들어지지 않으며, 편집 중인 규칙도 저장하기 전에 시험해 볼 수 있습니다. 그래서 에이전트가 예상과 다르게 막히거나 통과되는 일을 미리 잡을 수 있습니다.
목록 맨 위의 규칙보다 먼저 확인하는 항목(Checks before your rules)에는 어떤 규칙으로도 바꿀 수 없는 제한이 표시됩니다. 예를 들어 다른 사람의 개인 계정으로는 세션을 열 수 없습니다.
이렇게 만든 규칙이 누구에게 어떻게 적용되는지는 개요(Overview) 탭에서 한눈에 볼 수 있습니다. 관리자와 그룹 관리자, 일반 멤버, AI 에이전트, 서비스 토큰에 적용되는 처리 방식이 요청 종류와 위험도별로 한 표에 나오고, 칸을 누르면 그 결과를 정한 규칙이 나옵니다.
CLI, MCP, API 토큰으로는 더 이상 sudo 정책을 만들거나 권한 범위를 넓힐 수 없습니다. 이러한 변경은 사람이 콘솔에서 직접 해야 합니다. 에이전트는 sudo를 요청할 수 있지만, 자신의 토큰으로 권한을 줄 수는 없습니다. Access rules는 모든 플랜에서 사용할 수 있으며, 요청자가 아닌 다른 승인자를 요구하는 설정은 Essentials 플랜 이상에서 제공됩니다.
승인 카드에 요청을 결정한 규칙이 표시됩니다
Access rules에서 정한 규칙은 실제 요청이 들어오면 승인 카드에 그대로 나타납니다. 승인자가 Execution > Pending approvals에서 요청을 열면, 맨 위에 어떤 규칙 때문에 승인을 요청했는지가 나옵니다. Evidence 탭에는 결정한 규칙, 왜 내가 승인자인지, 에이전트가 스스로 밝힌 이름이 정리되어 있고, 요청자 유형이 검증됐는지는 별도 항목으로 표시됩니다.
요청을 결정한 규칙은 sudo 승인, 보류된 명령어, Work Session 페이지, sudo 이력에도 기록됩니다. 요청이 왜 허용됐는지 기록에서 바로 확인할 수 있습니다.
Alpacon을 거치지 않은 로그인 중 확인이 필요한 것만 골라 알려줍니다
External access는 Alpacon을 거치지 않고 SSH 키나 콘솔로 서버에 바로 들어온 로그인(직접 로그인)을 기록합니다. 이제는 그중 확인이 필요한 로그인만 골라 검토 대기열에 올리고, 검토자가 내린 결정도 기록으로 남깁니다.
Alpacon은 SSH, 콘솔, su 로그인을 허용된 직접 접근 목록과 대조합니다. 예상된 로그인은 상시 허용 항목으로 묶고, 예상 밖의 로그인만 검토 대기열에 올립니다. 공유 계정을 쓰거나 처음 보는 출발지에서 들어온 고위험 로그인이 생기면 검토자에게 이메일과 Slack으로 바로 알림이 갑니다.
검토자는 각 항목을 허용, 위반, 오탐 중 하나로 결정하고 사유를 남긴 뒤 검토를 마칩니다. 반복해서 생기는 정상 접속은 상시 허용 항목으로 등록해 추가 알림을 막을 수 있습니다. 검토 결과는 요약 탭의 증거 내보내기로 받아 감사 자료로 쓸 수 있습니다. 증거 내보내기는 Essentials 플랜부터 사용할 수 있습니다. 감사에서 "Alpacon을 거치지 않은 접속은 어떻게 관리하나요?"라는 질문을 받으면, 이 검토 기록으로 답할 수 있습니다.
직접 로그인 탐지는 로그인을 기록만 하고 막지는 않으며, Admin > Policies > Server access에서 직접 로그인 탐지를 켜면 시작됩니다.
그 밖의 업데이트
- 승인 대기 화면에서 요청이 한 줄씩 표시됩니다. 요청을 선택하면 목록 옆에 결정 카드가 열려, 화면을 벗어나지 않고 승인하거나 거절할 수 있습니다. 설정, 테마 변경, 로그아웃은 사이드바 맨 아래 계정 메뉴로 옮겼습니다.
- Websh에서 승인이 필요한 sudo 명령어는 실패하지 않고 승인을 기다렸다가, 승인되면 실행됩니다. self-hosted 환경에는 Alpacon 2.44.0, Alpamon 2.8.4, alpamon-pam 1.2 이상이 필요합니다.
- 서버마다 Alpacon을 통한 sudo 제어가 실제로 적용되는지 표시되어, 적용된 줄 알았지만 PAM 모듈이 빠져 있는 서버를 찾아 바로 설치할 수 있습니다.
- 모든 멤버가 사용량 페이지에서 플랜 한도를 확인할 수 있습니다.
- 워크스페이스 소유자는
Workspace settings > General에서 가명 처리한 세션 기록을 Alpacon AI의 탐지 개선에 쓸지 정할 수 있습니다. 기본값은 켜짐이며, Enterprise 플랜으로 시작한 워크스페이스는 꺼짐입니다. - 이번 릴리스에는 보안 개선 사항이 포함되어 있습니다. self-hosted 환경을 운영하는 고객에게는 업데이트를 권장합니다.
동작 변경 사항
- CLI, MCP, API 토큰으로 sudo 정책을 만들거나 권한 범위를 넓히면
sudo_policy_console_only오류가 납니다. 범위를 줄이거나 정책을 삭제하는 작업은 어느 경로에서든 계속 할 수 있습니다. alpacon approval ls는 내가 결정할 수 있는 요청을 보여줍니다. 내가 보낸 요청은--my로 확인할 수 있습니다.- 서버를 만든 사람이 자동으로 maintainer가 되지 않습니다. root 권한과 관리 권한은 maintainer 역할을 따릅니다.
- Windows에서 에이전트가 재시작되면 실행 중인 명령어가 종료됩니다. 오래 걸리는 작업은 예약 작업이나 서비스로 실행하세요.
