접근 결정 방식

같은 명령어도 실행하는 사람에 따라 바로 실행되거나 승인을 기다릴 수 있고, 다른 서버에서는 거부될 수 있습니다. Alpacon은 누가 어떤 계정과 권한으로 무슨 작업을 하려는지 확인합니다. 일부 판단에는 AI 위험도도 쓰지만, 위험도만으로 접근 권한을 부여하지는 않습니다.

사람, AI 에이전트, 자동화와 Alpamon#

CLI는 접속 수단이며 작업 주체의 종류가 아닙니다. 로그인한 CLI 클라이언트는 사람도 AI 에이전트도 사용할 수 있습니다. 개인 API 토큰이나 MCP로 요청한 세션, 에이전트임을 선언한 CLI 또는 식별되지 않은 클라이언트가 요청한 세션은 에이전트 모드로 처리합니다. 세션 요청을 참고하세요.

사용자 신원과 서버 계정#

워크스페이스의 사용자 신원에 따라 요청할 수 있는 작업이 정해집니다. 서버 계정은 세션에서 사용할 계정입니다. 서버에 접근할 수 있다고 해서 그 서버의 모든 계정을 쓸 수 있는 것은 아닙니다.

본인 계정, 공유 계정, 서비스 계정은 승인 요건이 다를 수 있습니다. 다른 사람의 개인 계정은 관리자나 advisory 모드에서도 항상 거부합니다. 규칙이나 승인으로 이 제한을 해제할 수 없습니다. sudo, su, runuser로 계정을 전환할 때도 같은 제한이 적용됩니다.

실제 절차는 서버 계정 선택을, 기본값과 배포 환경별 조건은 접근 규칙 참조를 참고하세요.

작업 세션과 토큰의 허용 범위#

작업 세션에는 서버, 기능, 계정, 유효 시간을 지정합니다. Alpacon은 세션을 시작해도 되는지 판단한 뒤, 세션 안의 명령어와 sudo를 별도로 검사합니다. 세션을 승인받았다고 임의의 root 명령어를 실행할 수는 없습니다. sudo 규칙을 적용받으려면 먼저 세션에 sudo 기능이 있어야 합니다.

서비스 토큰은 애플리케이션에 승인된 접근 범위 안에서 작업 세션 없이 자동화 작업을 실행할 수 있습니다. 이때는 사람의 세션 승인 기본값 대신 토큰 규칙을 적용합니다. 토큰으로 실행하는 명령어를 작업 세션에 연결하면 세션의 제한도 적용되며, 세션의 명령어 승인 절차를 따를 수 있습니다. 자격 증명을 선택하기 전에 토큰 종류를 비교하세요.

접근 규칙, 위험도와 신호#

위험도를 평가하는 작업에서는 적용할 규칙, AI가 판단한 위험도, 관련 신호를 함께 확인합니다. 세션의 목적을 벗어나거나 평가받은 명령어보다 더 많은 작업을 실행하면, 위험도만으로는 허용될 상황에서도 사람의 검토가 필요할 수 있습니다.

각 작업의 승인 규칙에서는 켜져 있고 만료되지 않은 워크스페이스 규칙 중 처음 일치한 규칙을 기본 규칙보다 우선 적용합니다. 규칙을 기본값보다 엄격하게 하거나 완화할 수 있지만, 모든 검사를 없앨 수는 없습니다. 범위와 계정 제한은 계속 적용되며, 검토받지 않은 심각 위험도의 sudo를 허용 규칙만으로 자동 승인할 수 없습니다.

웹 터미널에 입력한 명령어는 제출형 명령어처럼 하나씩 평가하지 않습니다. sudo는 별도로 검사하며, 터미널 활동은 기록해 나중에 검토합니다. 웹 터미널 영역의 안내를 따르세요. 여기서 실행하는 sudo도 명령어 규칙으로 판정해요.가 표시되면 CLI·API의 sudo 규칙이 웹 터미널 sudo도 결정합니다.

Presence, MFA와 승인#

MFA는 사람이 직접 작업 중임을 확인합니다. 승인은 요청한 접근이나 작업을 허용할지 결정합니다. 어느 하나가 항상 다른 하나를 대신하지는 않습니다. 예를 들어 터미널 sudo를 승인받아도 MFA가 필요할 수 있습니다.

최근 MFA 확인이 해당 작업에 더 이상 유효하지 않으면 다시 인증해야 합니다. 비대화형 명령어에서는 인증 화면을 띄울 수 없으므로, MFA를 지원하는 클라이언트에 로그인해 인증한 뒤 다시 실행하세요. AI 에이전트에게 사람이 해야 할 MFA를 요구하는 대신, 승인된 에이전트 세션을 근거로 처리합니다.

작업마다 다른 기본값#

세션 승인, sudo, 명령어 실행은 판단 대상이 서로 다릅니다. 슈퍼유저의 세션은 자동 승인되더라도 그 안의 sudo는 검토가 필요할 수 있습니다. 에이전트의 세션은 기본적으로 사람의 승인을 기다리지만, 승인된 세션 안에서는 일부 명령어가 자동 실행될 수 있습니다. 서비스 토큰에는 별도의 위험도 기본값이 적용되며, sudo 승인을 같은 방식으로 기다릴 수 없습니다.

주체와 작업별 정확한 결과는 기본 결정 표를 확인하세요. 사람과 에이전트의 위험도별 차이는 sudo의 기본 위험도 판단에 해당하며, 모든 접근에 적용되는 공통 규칙은 아닙니다.

Advisory와 enforce#

Enforce는 해당 실행 제어 결정을 적용합니다. Advisory는 판단 결과를 기록하되 그 판단 때문에 작업을 보류하거나 거부하지 않습니다. Advisory에서는 세션 시작, sudo, 명령어 실행에 대한 승인 요청을 만들지 않습니다. 아직 보유하지 않은 권한을 요청하는 경우에는 상시 sudo 정책, 서비스 토큰 발급·변경, 사용자명·계정 승인 등을 평소처럼 승인자에게 보냅니다. 새 세션은 실행 제어 승인을 기다리지 않지만, 계정 거부는 계속 적용됩니다. 범위 제한, 자격 증명 권한, 자격 증명 노출 검사에서 허용하지 않는 작업도 계속 거부합니다.

Advisory는 상시 sudo 권한을 부여하지 않습니다. 필요한 권한이나 일치하는 정책이 없는 터미널 sudo는 sudo_no_authority로 거부합니다. 모드를 바꾸기 전에 대기 중이던 요청은 기존 만료 규칙에 따라 계속 대기합니다. 바뀐 모드를 적용받으려면 새 요청을 제출하세요.

한 세션에 승인된 sudo#

상시 sudo 정책은 허용할 사람, 서버, 명령어를 지정합니다. 세션에 연결한 정책은 그 작업 세션에서만 유효하며, 지정한 명령어에 대해 세션 승인이 반복적인 MFA를 대신하도록 할 수 있습니다. 세션이 끝나면 정책도 효력을 잃습니다. 계정, 서버, 명령어, 시간 제한은 계속 적용됩니다.

이는 보류된 명령어 하나를 승인하는 것과 다릅니다. 개별 명령어 승인은 승인 화면의 명령줄에 명시된 sudo까지 허용할 수 있지만, 범위와 계정, 워크스페이스 제한은 그대로 적용됩니다. 스크립트 안에 숨은 권한 상승이나 나중에 실행하는 별개의 명령어까지 허용하지는 않습니다.

MFA로 sudo 사용과 sudo 명령 패턴을 참고하세요.

판단 결과 확인과 문제 해결#

접근 규칙에서는 규칙이 누구에게 적용되고 어떤 결과를 내는지 미리 확인할 수 있습니다. 이미 시도한 작업은 명령어, sudo, 승인 기록에서 확인하세요. 다시 실행하기 전에 표시된 사유와 현재 요청 상태를 확인해야 합니다. 거부 코드만으로 승인이 아직 대기 중이라고 판단할 수는 없습니다.

관련 오류 코드는 세션 범위, MFA, 권한, 위험도 판단에 따른 거부를 구별합니다. 거부 원인에 맞춰 필요한 부분을 바꾸세요. 같은 요청을 그대로 반복해도 부족한 권한이 생기지는 않습니다.