인그레스와 이그레스: 모든 엔터프라이즈 에이전트 플랫폼이 필요한 두 개의 게이트웨이

보안팀이 계속 던지는 질문

데모 환경에서 프로덕션으로 에이전트를 옮기는 대부분의 팀은 이제 **인지적 인그레스(cognitive ingress)**에 대한 합리적인 답변을 가지고 있습니다. 즉, 프롬프트를 여러 제공업체(provider)를 거쳐 라우팅하고, 폴백(fallbacks), 토큰 예산(token budgets) 등을 관리하는 것입니다. LiteLLM 같은 도구들이 이를 잘 다루고 있습니다. 오케스트레이션(Orchestration)(계획 루프, 멀티 에이전트 그래프 등) 역시 빠르게 발전하고 있습니다.

하지만 배포를 지연시키는 질문은 반대편에 있습니다.

에이전트가 주변 자격 증명(ambient credentials)을 보유하지 않고 프로덕션 데이터베이스, ERP 또는 내부 API에서 어떻게 작동할 수 있을까요?

오늘날의 일반적인 패턴은 서비스 계정 토큰(service-account token)과 원시 함수 스키마(raw function schema)를 사용하는 것입니다. 이는 모델이 _무엇을 하고 싶어 하는지_와 시스템이 _허용하는 것_이라는 두 가지 것을 혼합합니다. 우리는 이 둘이 분리된 평면(separate planes)이어야 한다고 생각합니다.

네 가지 역할(Role) 지도

우리는 에이전트 플랫폼을 구성 요소별로 보기보다 **역할(role)**로 이해하는 것이 더 쉽다는 것을 발견했습니다. 추상화 수준이 한 단계인 네 가지 역할은 다음과 같습니다:

ORCHESTRATOR            목표, 하위 작업, SLA
      |
WORKER                  추론 + 관찰 루프
...

가장 아래에 있는 두 역할은 스택(stack)이 아니라 **병렬 경로(parallel paths)**입니다. 워커는 이 둘 모두와 통신합니다. 하나는 생각하기 위해, 다른 하나는 행동하기 위해 사용됩니다.

오케스트레이터(Orchestrator). 작업자에게 작업을 계획하고 위임합니다. 작업이 어떻게 수행되는지에 대해서는 입장을 취하지 않으며, 이 글은 어떤 오케스트레이터를 사용해야 하는지에 대해서도 입장을 취하지 않습니다.
작업자(Worker). 도메인 에이전트(지원, 청구, 사고 대응)입니다. 추론하고 관찰합니다. LLM 제공업체 키나 엔터프라이즈 시스템에 대한 자격 증명을 보유하지 않습니다.
인지 브로커(Cognitive broker). 작업자가 모델로 가는 유일한 경로입니다. 라우팅, 폴백(fallbacks), 토큰 예산을 처리하며, 작업자들이 가지지 않는 제공업체 키를 보유합니다. 내부 시스템에는 접근할 수 없습니다. 이것이 인그레스(ingress) 측면이며, 기존 도구들로 잘 다루어지고 있습니다.
신뢰 게이트웨이 + 실행자(Trust Gateway + executor). 에이전트의 의도에서 엔터프라이즈 시스템으로 가는 유일한 경로입니다. 두 부분으로 구성된 하나의 역할입니다: **게이트웨이(gateway)**는 어떤 행동이 허용되는지 결정하고, **실행자(executor)**는 게이트웨이의 결정을 자체적으로 검증한 후 이를 수행합니다. 실행자만이 백엔드 시스템에 접근하며, 이 자격 증명은 에이전트가 절대 볼 수 없습니다.

'Egress'라는 단어에 대한 주의사항: 인지 브로커는 비즈니스 데이터를 LLM 제공업체로 외부 전송하기도 합니다. 프롬프트를 통한 데이터 유출은 실제적인 이그레스(egress) 문제이며, 이는 브로커에서 DLP(Data Loss Prevention)를 사용하거나 모델이 실행되는 위치를 선택함으로써 처리됩니다. 신뢰 게이트웨이는 프롬프트 내용에 관한 것이 아니라 _행동_에 관한 것입니다.

다이어그램에는 없는 의존성: 신원 확인(identity). 각 작업자는 자신이 누구인지 증명해야 하며, 모든 요청은 사용자 또는 오케스트레이터에게 귀속될 수 있어야 합니다. 이것이 사용자를 대리하여 행동하는 에이전트에게 충분한지 여부는 다음 게시물의 주제입니다.

제안하고(Propose), 결정하며(decide), 검증한다(verify)

원칙: 에이전트는 제안하고, 게이트웨이가 결정하며, 실행자가 검증합니다.

제안(Propose). 워커는 제안을 제출합니다: 도구 이름과 인자들입니다.
결정(Decide) (게이트웨이). 게이트웨이는 결정론적 정책에 따라 제안을 평가합니다: 상한선, 허용 목록, 인자 유효성 검사 등을 수행합니다.
결정(Decide) (게이트웨이). 두 번째 확인 단계는 의미론을 살펴봅니다: 데이터가 외부로 유출되는지, 인자가 의심스러운지 여부입니다. 이는 LLM 기반이므로 증거 자료일 뿐, 증명은 아닙니다.
결정(Decide) (게이트웨이). 고위험 작업의 경우 인간의 승인이 필요할 수 있습니다.
승인(Grant) (게이트웨이). 허용될 경우, 게이트웨이는 서명이 된 단일 사용 권한을 발급합니다. 이 권한은 짧은 기간 동안 유효하며 정확한 입력값의 해시 값에 바인딩됩니다.
검증 및 실행(Verify and execute) (실행기). 게이트웨이와 동일한 역할을 하지만 별도로 작동하는 실행기는 승인된 서명과 입력값 해시를 자체적으로 확인합니다. 그래야만 에이전트가 절대 볼 수 없는 자격 증명을 사용하여 엔터프라이즈 시스템을 호출할 수 있습니다.

권한(grant)이 입력값 해시에 바인딩되어 있기 때문에, 승인된 100달러 환불은 5,000달러의 환불로 재사용될 수 없습니다. 또한 실행기가 네트워크 경로를 신뢰하는 대신 검증하기 때문에, 단순히 내부처럼 보이는 요청이라도 유효한 권한 없이는 아무런 효과가 없습니다.

예시 (설명용)

에이전트가 제안합니다:

{
  "tool": "refund.process",
  "args": { "order_id": "A-1042", "amount": 5000, "currency": "EUR" }
...

이 사용자에 대한 위임 권한은 환불액을 1,000 EUR로 제한합니다. 게이트웨이는 이를 거부합니다:

{
  "decision": "deny",
  "reason": "amount 5000 exceeds delegated cap 1000"
...

에이전트는 데이터베이스 자격 증명을 전혀 보지 못했습니다. 거부는 결정론적이며 기록됩니다. 만약 사람이 더 높은 금액을 승인한다면, 반환되는 권한은 해당 정확한 인자들에 대해서만 유효합니다.

도구에서 인증된 기술로 (From tools to certified skills)

여기서는 두 단어에 대한 명확한 정의가 필요합니다. 왜냐하면 저희는 이 둘을 모두 사용하기 때문입니다:

• **도구(tool)**는 단일 호출 가능한 작업입니다. 예를 들어 refund.process와 같습니다. 도구는 이름, 입력 스키마(input schema), 그리고 출력 스키마를 가집니다.
• **스킬(skill)**은 회사 전체를 위해 패키징된 도구(또는 관련 도구의 작은 세트)입니다. 이는 스키마, 결정론적 안전장치(deterministic guardrails), 그리고 격리된 실행기(sandboxed executor)로 구성되며, 소유한 도메인 팀에 의해 한 번 게시되고 인증됩니다.

오늘날 각 에이전트를 구축하는 팀은 자체 커넥터를 작성합니다. 여기서는 PostgreSQL 래퍼를 사용하고, 저기에서는 Jira나 SAP 래퍼를 사용하는 식이며, 각각 고유의 환경 토큰(ambient token)과 사각지대(blind spots)를 가집니다. 트러스트 게이트웨이(Trust Gateway)는 이러한 것들을 공유되고 감사 가능한 스킬로 전환합니다. 도메인 팀은 스킬을 한 번 게시합니다. 그러면 회사 내의 어떤 워커 에이전트도 해당 도구에 대한 호출을 _제안_할 수 있지만, 어떠한 에이전트도 백엔드 서비스에 네트워크 접근이나 자격 증명(credential) 접근 권한을 얻지 못합니다.

메커니즘(스키마, 안전장치, 격리된 실행, 권한 부여)은 존재하며, 검색 기능 또한 존재합니다. 워커는 게이트웨이에 어떤 도구가 자신에게 사용 가능한지 문의하고, 해당 테넌트(tenant)에 대해 활성화된 도구 목록을 받습니다. 아직 존재하지 않는 부분은 그 주변의 카탈로그입니다. 즉, 팀 간의 워크플로우 게시, 인증, 버전 관리가 필요합니다. 이것이 아래에서 다룰 어려운 조직적 문제입니다.

단순히 API 게이트웨이에 정책 엔진만 추가한 것인가?

좋은 질문입니다. API 게이트웨이, MCP 게이트웨이, OPA/Cedar, 그리고 OAuth 토큰 교환 모두 이 문제의 일부를 해결하며, 이러한 요소들로 역할을 구현할 수 있습니다. 우리가 주목하는 차이점들은 다음과 같습니다:

**스코프(scopes)가 아닌 입력에 바인딩되고 단일 사용 가능한 권한 부여(Grants)**입니다.
게이트웨이뿐만 아니라 실행기(executor)도 검증합니다. 실행 측면은 네트워크 경로를 신뢰하지 않으며, 요청이 내부에서 발생했다는 이유만으로 호출자가 합법적이라고 가정하지 않습니다.
에이전트 인식 흐름(Agent-aware flow): 하나의 의사 결정 경로 내에서 제안(proposals), 인간에게 에스컬레이션, 그리고 의미론적 검사를 수행합니다.

만약 현재 운영 중인 시스템으로 요구 사항을 충족한다면 그것을 사용하십시오. 저희의 주장이 맞지 않는 부분이 있다면 알려주시길 바랍니다.

이것이 해결하지 못하는 것들

의도(Intent). 에이전트가 합법적이고 범위 내에 있지만 유해한 행동으로 프롬프트 주입될 경우, 게이트웨이가 피해 범위를 제한합니다. 이는 악의적인 의도를 탐지하지는 못합니다. 의미론적 검사(semantic check)가 도움이 되기는 하지만 보장은 아니며, 신뢰할 수 있는 의도 탐지는 여전히 미해결 문제입니다.
프롬프트 수준 가드(Prompt-level guards)는 취약합니다. 테넌트별 DLP(Data Loss Prevention) 규칙과 같이 모델의 프롬프트에 주입된 지침은 유출을 줄이지만, 모델이 그 지침에서 벗어나도록 설득될 수 있습니다. 하드 경계는 프롬프트가 아니라 게이트웨이입니다.
오염된 결과물(Poisoned results). 도구 결과물이 에이전트의 컨텍스트로 다시 흐릅니다. 출력 필터링은 현재 부분적입니다.
스킬 카탈로그 문제(The skill catalog problem). 중앙 인증 시스템은 거버넌스를 제공하지만, 동시에 병목 현상이기도 합니다. 누가 인증할지, 버전과 공급망을 어떻게 처리할지, 모든 팀이 새로운 스킬을 원할 때 무슨 일이 발생할지가 문제입니다. 샌드박스 및 스키마 메커니즘은 준비되어 있지만, 조직적 프로세스는 설계자가 직접 디자인해야 하는 영역입니다.
키 관리(Key custody)와 작업자 자체 자격 증명(credential). 현재 작업자는 API 키와 테넌트 ID를 사용하여 게이트웨이에 인증합니다. 이 키는 절대 백엔드 시스템에 도달하지 않지만, 여전히 자격 증명입니다. 만약 도난당한다면 공격자가 정책 내에서 해당 작업자로서 호출을 제안할 수 있습니다. 에이전트가 인간 또는 오케스트레이터로부터 위임된 단기 키로 각 제안에 서명하는 것이 매력적인 해결책이지만, 그러한 키가 어디에 저장되고 손상된 에이전트를 어떻게 격리할지는 미해결 설계 문제입니다.
가용성(Availability). 단일 병목 지점은 고가용성(HA), 지연 시간 예산(latency budgets), 그리고 도구별 명확한 실패 시 폐쇄(fail-closed) 대 실패 시 개방(fail-open) 결정이 필요합니다.
전송 과정 중 위임 체인 전체에 걸친 취소(Revocation).

Lianxi가 이를 구현하는 방법

위의 섹션들은 모든 구현체에 적용될 수 있도록 고안되었습니다. 이 부분은 저희의 사례와 현재 실제로 가능한 것을 설명합니다.

상태 범례: 이전 게시물과 마찬가지로 🟢 구현 완료 및 오픈 소스 · 🟡 구현되었으나 비공개 · ⚪ 설계 목표, 아직 구축되지 않음.

인지 브로커(Cognitive broker). 🟡 무상태 모드에서는 대화 상태를 유지하지 않습니다. 상태 저장 모드(응답 체이닝, response chaining)에서는 비즈니스 데이터를 포함할 수 있는 대화 컨텍스트를 저장하므로, 해당 저장소를 민감하게 취급해야 합니다.

워커(Worker). 🟡 참조 워커에서는 코드상 세 가지 불변성(invariants)을 강제합니다: LLM 제공업체 키가 없어야 함 (모든 추론은 브로커를 통해 이루어짐), 로컬 셸이나 사설 데이터베이스 접근이 없어야 함 (모든 부수 효과는 신뢰 게이트웨이를 통해 이루어짐), 그리고 모든 인바운드 요청에 대한 암호화된 신원 증명이 필요합니다. 워커는 하나의 자격 증명만 보유합니다: 게이트웨이에 대한 API 키와 테넌트 ID입니다. 크로스-테넌트 호출자의 경우, 모델 프롬프트에 테넌트별 DLP 규칙을 주입합니다. 작업 상태는 메모리에 있으므로, 실행 중인 작업(in-flight tasks)은 재시작 시 손실됩니다.

오케스트레이터(Orchestrator). ⚪ 저희는 이를 구축하지 않습니다. 워커는 오케스트레이터나 피어 에이전트로부터 서명된 토큰으로 인증된 A2A 작업을 수락합니다.

신원(Identity). 🟡 워커는 OAuth2 클라이언트 자격 증명 토큰을 JWKS 엔드포인트와 대조하여 확인하거나, DID에 바인딩된 Ed25519 서명 세션 토큰으로 호출자를 검증합니다. 게이트웨이는 정적 목록이 아닌 각 테넌트의 발급자(issuer)를 동적으로 해결합니다.

신뢰 게이트웨이(Trust Gateway).

🟢 제안은 MCP tools/call 형태로 도착하며, 게이트웨이 API 키와 테넌트 ID로 인증됩니다.
🟢 결정론적 정책은 캡(caps), 허용 목록(allow-lists) 및 인자 유효성 검사를 다룹니다.
🟢 의미론적 검사는 LLM 기반이며 자문적입니다.
🟢 고위험 작업의 경우 인간 승인이 필요할 수 있습니다.
🟢 권한 부여는 Ed25519 서명 방식이며, 단일 사용(single-use)이고 30초의 TTL(Time To Live), 재전송 방지(replay protection), 그리고 정확한 입력값 해시와 바인딩됩니다.

실행기(Executor). 🟢 게이트웨이나 대상 서비스 중 한 곳에 근접 배치된 Wasm 샌드박스에서 실행됩니다. 자체적으로 권한 부여 서명과 입력 해시를 검증한 후, 에이전트가 결코 볼 수 없는 자격 증명을 사용하여 엔터프라이즈 코어(enterprise core)로 작업을 전송합니다.

스킬(Skills). 🟢 스키마(Schema), 가드레일(guardrails), 샌드박스 실행(sandboxed execution), 권한 부여(grants), 그리고 MCP tools/list를 통한 검색(discovery) 기능. 이는 워커의 테넌트(tenant)에 활성화된 번들들을 반환합니다. ⚪ 카탈로그(Catalog), 발행 워크플로우(publishing workflow), 인증(certification) 및 교차 팀 버전 관리(cross-team versioning).

출력 필터링 및 취소(Output filtering and revocation). 🟡 출력 필터링은 부분적입니다. ⚪ 위임 체인 전반의 비행 중 취소(Mid-flight revocation)는 구현되지 않았습니다. ⚪ 단기 위임 키를 사용한 제안별 서명(Per-proposal signing)은 구현되지 않았습니다.

이는 회사 에이전트가 단순히 백엔드 채널만 되어서는 안 된다는 저희의 이전 게시물에 기반합니다. 개인 에이전트 프로토콜(Personal Agent Protocol) 관련 기사

저희가 이것을 공유하는 이유

에이전트가 프로덕션 환경에서 실패하는 경우는 모델이 추론할 수 없어서는 드뭅니다. 에이전트는 아무도 비결정적 시스템 쓰기 접근 권한(non-deterministic system write access)를 중요 시스템에 부여하는 것에 서명해 주지 못하기 때문에 실패합니다. 저희는 '사고(thinking)'와 '행동(acting)'을 분리하고, 행동 측면을 검증 가능하게 만드는 것이 실용적인 경로라고 생각합니다.

코드: github.com/fcn06/trust_gateway.

여러분께 질문드립니다: 오늘날 프로덕션 환경에 에이전트를 실행할 때, 자신감 있게 잘못된 도구 호출을 막는 것은 무엇입니까? 여러분의 환경에서 이 설계가 깨질 수 있는 부분은 어디입니까?