MCP 프롬프트
MCP 프롬프트는 MCP 클라이언트가 이름으로 호출할 수 있는 재사용 가능한 워크플로우 가이드입니다. 동작을 수행하는 도구이나 데이터를 노출하는 리소스와 구분됩니다. Alpacon의 각 프롬프트는 정적인 안내 텍스트를 반환하며, 인자는 그 안의 맥락만 좁혀줍니다. 이 텍스트는 Alpacon을 안전하게 운영하는 데 필요한 규율을 AI 에이전트에게 안내합니다. 모든 인프라 작업은 승인된 Work Session 안에서 이루어지고, 에이전트는 MFA 실사용자 인증이 없으므로 승인은 항상 사람에게 전달되며, 거부 결과는 에이전트가 무작정 재시도하지 않고 스스로 수정할 수 있도록 구조화되어 있습니다. 4개의 프롬프트는 Alpacon의 접근 모델인 ACCESS→EXECUTION→AUDIT를 그대로 반영합니다.
프롬프트 자체는 Alpacon API를 호출하지 않습니다. 에이전트가 이어서 실행할 지침 텍스트만 반환하며, 실제 실행은 해당하는 도구가 담당합니다. MCP 클라이언트가 프롬프트를 어떻게 노출하는지는 시작하기를 참고하세요.
요약
| 프롬프트 | 단계 | 인자 |
|---|---|---|
work_session_workflow | ACCESS | intent(필수), servers(선택) |
guarded_execution | EXECUTION | work_session_id(필수) |
incident_response | 시나리오 | server_id(선택), workspace(선택) |
security_audit | AUDIT | work_session_id(선택), server_id(선택) |
work_session_workflow
인프라 작업을 수행하기 전, Work Session의 범위를 정하고 여는 단계에서 사용하는 프롬프트입니다. 목표(intent)와 선택적으로 대상 서버 UUID 목록(servers)을 받아, 다음 순서로 에이전트를 안내합니다.
- 목표를 세션의
description으로 선언하고, 필수 인자인workspace,scopes,servers,expires_at을 채워work_session_create를 호출합니다. 이때 워크스페이스 전체가 아니라 실제 대상 서버로만 범위를 좁힙니다. 에이전트가 직접 요청할 수 있는 scope(command,webftp,tunnel)와 항상 사람의 승인으로 이어지는sudo, 그리고 MFA 실사용자 인증이 필요해 에이전트가 아예 사용할 수 없는 scope(websh,editor)를 구분해 안내합니다. - 결과를 status별로 처리합니다.
pending_approval이면 재시도하지 말고 사람에게 요청을 전달한 뒤 기다려야 하며,explain_approval_decision으로 왜 사람이 별도 채널에서 조치해야 하는지 설명할 수 있습니다. gatecode가 포함된error이면next_action을 읽고 범위를 좁혀 신중하게 재시도합니다. - 세션이
active가 되면(work_session_get으로 확인) 실제 작업을 위해guarded_execution프롬프트로 넘어갑니다.
사용자의 요청이 명령 실행, 파일 전송, 터널 열기 등 인프라를 건드리는 작업이고 아직 열려 있는 Work Session이 없을 때 이 프롬프트를 사용하세요.
guarded_execution
Work Session(work_session_id)이 활성화된 뒤, 그 안에서 명령과 파일 전송을 올바르게 실행하는 단계에서 사용하는 프롬프트입니다. 다음 순서로 에이전트를 안내합니다.
- 아무 작업도 하기 전에
work_session_get으로 세션이active상태인지 확인합니다. 이때 top-level 호출 결과의status가 아니라data.status를 읽습니다. - 범위가 지정된 모든 호출에
work_session_id를 전달합니다.execute_command,execute_command_multi_server,webftp_download_file이 해당하며,webftp_upload_file은 로컬 모드 전용이라 원격/OAuth 환경에서는remote_mode_unsupported를 반환합니다. - 모든 작업에 위험도 판정이 따른다고 예상합니다. HIGH 위험 명령과 모든
sudo호출은 human-in-the-loop로 이어지며, 에이전트는 스스로 승인할 수 없습니다. - 거부 시 구조화된
code/next_action을 읽고, 거부된 명령을 그대로 재실행하는 대신 스스로 수정합니다. - 작업이 끝나면
work_session_close를 호출합니다. 이는 세션에 대한 AI 보안 분석도 함께 트리거합니다.
Work Session이 활성화된 직후 진행하는 모든 명령 실행과 파일 전송에 이 프롬프트를 사용하세요.
incident_response
알림 또는 신고된 인시던트에 대응할 때, 조치 이전에 먼저 트리아지를 거치도록 하는 프롬프트입니다. 선택적으로 server_id 또는 workspace를 받아, 다음 순서로 에이전트를 안내합니다.
- Work Session이 필요 없는 읽기 전용 트리아지를 먼저 수행합니다. 활성 알림, 서버 개요와 CPU/메모리 사용량, 최근 이벤트를 확인해 원인을 먼저 파악합니다.
- 조치에 명령 실행이 필요하면 직접 실행하지 않고,
work_session_workflow프롬프트를 통해 영향을 받은 서버로만 범위를 좁히고commandscope로 Work Session을 엽니다. guarded_execution에 따라 조치를 실행하며, 재시작·sudo·파괴적 명령 같은 위험한 단계는 사람의 승인으로 이어질 것으로 예상합니다.- 인시던트가 해결되면
work_session_close로 세션을 닫아 감사 기록을 완결합니다.
사용자가 서버 문제를 신고하거나 알림 조사를 요청할 때 이 프롬프트를 사용하세요.
security_audit
사용자가 권한 있는 활동에 대해 감사 또는 포렌식 질문을 할 때, 어떤 도구를 호출해야 할지 추측하는 대신 알맞은 관점을 고르도록 돕는 프롬프트입니다. 선택적으로 work_session_id 또는 server_id를 기준점으로 받아, 5가지 질문 유형을 각각에 맞는 도구로 매핑합니다.
- 세션 포렌식(“이 세션에서 무슨 일이 있었나?”):
work_session_timeline - 세션 간 이벤트 포렌식(“모든 sudo 호출”, “/etc/* 의 모든 전송 이력”):
list_server_logs,list_webftp_logs,search_events - 결정 감사(“누가 승인했나, 언제 철회됐나?”):
list_approval_requests,get_approval_request - 변경 감사(“역할·토큰·정책에서 무엇이 바뀌었나?”):
list_activity_logs,get_activity_log - AI 기반 분석(공격 패턴, MITRE ATT&CK 매핑):
list_session_analyses,get_session_analysis_detail
또한 세션이 감사 스토리의 기본 단위이므로, 발견한 내용을 각 이벤트가 속한 Work Session으로 다시 연결하도록 안내합니다.
워크스페이스 활동에 대해 “무슨 일이 있었나”, “누가 승인했나”, “의심스러운 행동이었나” 같은 질문에 이 프롬프트를 사용하세요.