Palana (Part 2): Architecting Isolation, Identity, and Auditability for AI Agents
Author: Grab Engineering | Source: Grab Engineering Blog | Published: 2026
한 줄 요약
Palana의 under-the-hood 아키텍처 — operator가 사용자 요청을 namespace·RBAC·storage·network policy로 변환하고, proxy-mediated secret·LiteLLM 라우팅·L3/L4 + L7 이중 네트워크 제어로 “useful autonomy를 boring하게(attributable·inspectable·revocable·recoverable)” 운영.
핵심 주장/내용
- 요청 경로: 사용자가
pcli/portal로 에이전트 생성 → UserAgent/Agent custom resource → operator가 namespace·service account·role binding·storage·network policy·ingress 생성 → admission webhook이 proxy 환경변수 주입·pod 제약 강제 - identity: 인증은 Concedo OIDC(PKCE). raw user identity(이메일)를 authoritative owner로 유지(RBAC subject 매칭), sanitized form은 K8s 객체명·Vault path에만 — display-safe ID가 authorization subject가 되는 버그 방지. 향후 SPIFFE/SPIRE로 “agent on behalf of user”(user + agent instance id) 통합
- secrets: Vault
kv/agents/{user}/{agent}(agent-readable) vskv/proxy-secrets/...(proxy만). placeholder는 approved proxy 경로 통과 시만 유효 - LLM: litellm-proxy-wrapper가 K8s context로 agent identity 도출(client 헤더 불신) → Vault에서 per-agent 자격증명 → 라우팅. 에이전트는 raw upstream 자격증명 불필요, 트래픽 attributable
- 네트워크 이중 제어: L3/L4(NetworkPolicy + Cilium — containment, default-deny) + L7(proxy + OPA — host/method/identity별, audit). “기본은 nothing, 필요한 internal service만”
- idle shutdown: reaper가 gateway/proxy·Git·Slack·Prometheus 신호로 최근 활동 추적 → idle 시 compute 정지,
/data·RBAC·Vault 상태 보존(“stop compute, keep state”)
주요 수치 / 사실
- namespace
agent-{user}-{agent}, EFS PVC/data, Concedo browser auth - 교훈: 보안은 플랫폼 레이어에(prompt guardrail만으론 부족), UX가 control만큼 중요, “credential 읽기”와 “credentialed 요청 유발” 분리가 high-leverage, namespace boundary가 compound, 장기 에이전트엔 lifecycle 관리 필요
- 운영 에이전트가 Palana 로그로 OOM 등 진단 후 사용자에게 조언
관련 위키
Source: 원문 보기