Palana (Part 1): Why Grab Built a Secure Platform for Autonomous AI Agents
Author: Grab CyberSecurity team | Source: Grab Engineering Blog | Published: 2026
한 줄 요약
AI 에이전트가 챗 인터페이스에서 네트워크·자격증명·도구·메모리를 가진 자율 workload로 진화하며 리스크 모델이 바뀌자, Grab이 “isolation을 trust의 단위”로 삼는 Kubernetes-native 보안 실행 플랫폼 Palana를 구축.
핵심 주장/내용
- 에이전트가 코드 읽기·API 호출·테스트 실행·MR 생성·Slack 응답·장기 상태 유지를 하면 더 이상 챗 인터페이스가 아니라 행동하는 workload. 컨테이너는 런타임 패키징만 해결, 더 어려운 플랫폼 질문(누구를 대신하나, 어떤 자격증명, 타 사용자 상태 볼 수 있나, 인터넷 직결 가능한가, 어떻게 멈추나)엔 답 못함
- Palana 제공: 에이전트당 K8s namespace(RBAC·quota·network policy·storage) + CLI/portal + 영구
/data+ browser/shell 접근 + LiteLLM wrapper(per-agent GrabGPT 자격증명 Vault 주입) + Envoy/ext-authz egress(OPA 정책) + proxy-only secret + Git bastion + kill switch - 설계 원칙:
- isolation이 trust의 단위: 에이전트당 namespace·service account·storage·network policy·Vault scope. 프레임워크가 완벽한 multi-tenant isolation을 가정 안 해도 안전
- 자격증명을 에이전트에 절대 안 줌: agent-readable secret vs proxy-only secret(에이전트는 placeholder
TOKEN_GITHUB_PAT만, proxy가 outbound 시 실제 자격증명으로 교체) — prompt injection·의존성 침해 시 장수명 자격증명 노출 방지 - egress가 control point: 금지가 아닌 observable·policy-mediated(어떤 에이전트가, 누가 소유, 어디로, allow/deny)
- control plane은 에이전트 밖에: kill switch가 에이전트에 멈추라고 요청하면 feature, 네트워크 경로를 제거하면 safety control
- K8s primitive 활용(custom resource, operator)
주요 수치 / 사실
- 수백 개 에이전트 운영(remote dev 환경, Slack automation, OpenClaw worker, Hermes 등)
- 이름 Palana는 보호·유지·돌봄을 뜻하는 산스크리트 어원 — “에이전트의 brain이 아니라 contain·observe·sustain하는 환경”
- “안전한 경로가 self-service·ergonomic하면 팀이 쓴다”
관련 위키
Source: 원문 보기