APX에서 알 수 없는 Telegram 발신자는 게스트(Guest)로 유지되어야 합니다

Telegram 봇은 모든 새로운 메시지를 신뢰할 수 있는 운영자 입력으로 취급해서는 안 됩니다.

당연한 소리처럼 들리겠지만, 많은 에이전트(agent) 설정들이 여전히 신원(identity), 채팅 멤버십(chat membership), 그리고 도구 접근 권한(tool access)을 모호하게 처리하고 있습니다. 누군가 봇에게 메시지를 쓰고 봇이 응답하면, 얼마 지나지 않아 동일한 인물이 실제 동작을 트리거할 수 있게 되는데, 이는 런타임(runtime)이 **대화(conversation)**와 역량(capability) 사이에 명확한 선을 긋지 않았기 때문입니다.

APX는 의도적으로 그 선을 긋습니다.

APC는 휴대 가능한 컨텍스트 레이어(portable context layer)입니다. 이는 프로젝트 계약(project contract)을 리포지토리(repo)에 유지합니다: AGENTS.md, .apc/, 에이전트 정의(agent definitions), 기술(skills), 명령(commands), 그리고 MCP 힌트(MCP hints) 등이 포함됩니다. APX는 일상적으로 사용하는 런타임 및 툴링 레이어(runtime and tooling layer)입니다. APX는 해당 프로젝트 컨텍스트를 읽고, 에이전트 루프(agent loop)를 실행하며, 세션(sessions), 메시지(messages), 승인(approvals), 채널 신원(channel identity)과 같은 런타임 상태를 리포지토리 외부에서 처리합니다.

그 신뢰 결정(trust decision)은 APC가 아닌 APX의 몫입니다.

게스트 우선, 도구는 나중에

APX의 Telegram 신원 로직(identity logic)은 명시적입니다.

연락처는 chat_id가 아닌 발신자의 고유한 Telegram user_id를 기준으로 키(key)가 지정됩니다. 이는 동일한 인물이 여러 채팅방에 나타날 수 있는 반면, 그룹 채팅에는 많은 사람이 포함될 수 있기 때문에 중요합니다. APX는 해당 인물을 전역적으로 저장하며, 특정 채널의 소유자가 누구인지 표시하기 위해서만 owner_user_id를 사용합니다.

그 후 다음과 같은 간단한 규칙을 적용합니다:

• 채널 소유자(channel owner)는 owner 권한을 가집니다.
• 설정된 연락처(configured contacts)는 사용자 정의 역할(custom role)을 가질 수 있습니다.
• 알 수 없는 발신자(unknown senders)는 guest가 됩니다.

마지막 단계가 가장 중요합니다.

resolveAllowedTools()에서 APX는 소유자에게 "*"를 부여하고, 알려진 역할에 대해서는 telegram.roles에서 도구 허용 목록(tool allowlists)을 읽으며, 그 외의 경우에는 빈 목록을 반환합니다. 즉, 게스트는 '실패 시 차단(fail closed)' 방식으로 작동합니다. 그들은 봇과 대화할 수는 있지만, 단순히 채팅방을 찾았다는 이유만으로 도구 사용 권한을 얻지는 못합니다.

이것은 낙관적 신뢰(optimistic trust)보다 더 나은 기본 설정입니다.

이러한 분리가 중요한 이유

Telegram 대화에는 두 가지 별개의 질문이 있습니다:

1. 이 사람은 누구인가?
2. 이 사람이 무엇을 트리거할 수 있는가?

만약 런타임 (runtime)이 이 두 가지를 하나의 단계로 통합해 버린다면, 권한을 과도하게 부여하는 경향이 생깁니다. "답변하기에 충분히 알려진" 상태가 조용히 "행동하기에 충분히 알려진" 상태로 변질되는 것입니다.

APX는 그렇게 하지 않습니다.

모델 프롬프트 (prompt)에 입력되는 관계 블록 (relationship block) 또한 엄격합니다. 게스트 발신자의 경우, APX는 모델에게 권한이 없는 게스트와 대화하고 있음을 알리고, 상대가 누구인지 정중하게 물어보도록 지시합니다. 이를 통해 모델이 스스로 액세스 권한을 부여할 수 있는 것처럼 가장하지 않으면서도 사회적 흐름을 자연스럽게 유지합니다.

따라서 실제로 협력하여 작동하는 세 가지 계층이 있습니다:

• 런타임 신원 확인 (runtime identity resolution)
• 해당 신원에 대한 프롬프트 컨텍스트 (prompt context)
• 도구 허용 목록 강제 적용 (tool allowlist enforcement)

이러한 조합이 동작을 단순히 친절한 수준이 아닌 안전한 수준으로 만듭니다.

작은 예시

하나의 APX 프로젝트에 고정된 새로운 프로젝트 봇 (project bot)을 상상해 보세요.

소유자가 없는 채널에서의 첫 번째 개인 메시지는 소유권을 주장할 수 있습니다. 그 이후에 동일한 봇에게 메시지를 보내는 다른 발신자는 대화가 비공개라는 이유만으로 승격되지 않습니다. APX는 해당 인물을 게스트로 기록합니다.

나중에 해당 연락처가 더 많은 일을 수행하기를 원한다면, APX 설정(config)이나 웹 관리자(web admin)를 통해 역할을 할당하면 됩니다. 여기서 각 역할은 call_agent 또는 list_tasks와 같은 구체적인 도구 목록에 매핑됩니다.

즉, 신뢰 등급의 상향은 의도적이며 검토 가능함을 의미합니다.

특히, APX는 사용자 이름이 익숙해 보이거나, 사용자가 채팅에 참여했거나, 또는 모델이 해당 인물이 "정당해 보인다"고 판단했다는 이유만으로 권한을 부여하지 않습니다. 권한 경계 (permission boundary)는 런타임이 소유합니다.

왜 APC가 관여해서는 안 되는가

이것은 지속적인 프로젝트 컨텍스트 (project context)가 아닙니다. 이는 실시간 런타임 정책 (runtime policy)입니다.

APC는 프로젝트, 에이전트 (agents), 기술 (skills), 그리고 여러 머신과 런타임을 가로질러 이동할 수 있는 기타 리포지토리 소유 컨텍스트 (repo-owned context)를 설명해야 합니다. 일시적인 채널 신뢰나 개인 메시지 액세스 권한을 프로젝트 계약 (project contract)에 포함시켜서는 안 됩니다.

Telegram 역할, 소유권 주장, 발신자 등록은 현재 누가 봇을 운영하고 있는지에 따라 달라집니다. 이는 머신 로컬 (machine-local)이며 런타임에 의해 관리되는 상태입니다. APX가 이를 관리하기에 적합한 장소입니다.

이 경계를 놓치기 쉽지만, 이는 매우 중요합니다.

만약 APC가 이러한 종류의 메시징 신뢰(messaging trust)를 직접 저장한다면, 이식성(portability)은 악화되고 의도치 않은 노출은 더 쉬워질 것입니다. APC를 이식 가능하게 유지하고 APX가 채널 식별(channel identity)을 책임지게 함으로써, 프로젝트 계약(project contract)은 깔끔하게 유지되는 동시에 런타임(runtime)은 주의를 기울인 상태를 유지할 수 있습니다.

이것이 바로 진정한 설계 포인트입니다. APC는 프로젝트의 의미가 무엇인지를 말하고, APX는 Telegram을 통해 누가 그것으로 무엇을 할 수 있는지를 결정합니다.