이미 AI gateway나 하이퍼스케일러의 Guardrails에 투자하셨다면, 가장 먼저 솔직하게 말씀드려야 할 것은 그대로 유지하십시오. Olivares AI는 이를 대체하려는 것이 아닙니다. Gateway의 역할은 모델 호출 — 라우팅, 캐싱, 밸런싱, 예산 관리입니다. Guardrails의 역할은 해당 호출에 대한 콘텐츠 안전성입니다. 둘 다 실질적이고, 둘 다 자신의 영역에서 뛰어나며, 둘 다 Olivares가 하는 일이 아닙니다.
TL;DR: Olivares AI는 AI gateway가 아닙니다. 모델 트래픽의 핫 패스에서 라우팅, 캐싱, 로드밸런싱을 하지 않으며, 앞으로도 그럴 것입니다. 귀사의 gateway 옆과 뒤에 거버넌스 및 증거 플레인으로 위치합니다: 에이전트 런타임 내부의 인프로세스 enforcement, 변조 방지 증거 원장, 비인간 신원 라이프사이클, 활성 세션에 대한 human-in-the-loop / break-glass / kill-switch. 귀사의 gateway는 요청을 거버넌스합니다; Olivares는 에이전트와 에이전트가 접촉하는 모든 것을 거버넌스하고, 감사인에게 이를 증명합니다.
Gateway와 Guardrails가 잘하는 것 (이 용도로 사용하십시오)
이것들은 표준화되어 잘 알려진 기능이며, 벤더들이 명확하게 설명합니다:
- AI gateway는 모델 호출을 위한 요청 경로 관리자입니다. LiteLLM은 “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM); Cloudflare AI Gateway는 “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare); Portkey는 “records real-time API requests, including cost” (Portkey)를 제공합니다. 라우팅, fallback, 캐싱, 가상 키, 키별 예산, 요청 로깅 — 이것이 이들의 영역입니다.
- 하이퍼스케일러 Guardrails는 콘텐츠 안전 필터입니다. Bedrock Guardrails는 *“provides configurable safeguards to help you build safe generative AI applications”*이며 “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — 콘텐츠 필터, 거부 주제, 단어 필터, PII 마스킹, 맥락 기반 그라운딩 및 자동 추론 검사를 수행합니다 (AWS).
문제가 *“여러 모델에 하나의 엔드포인트를 제공하되, 예산, 캐싱, 콘텐츠 필터링을 갖추는 것”*이라면, 이 스택으로 해결되며 컨트롤 플레인이 필요하지 않습니다. 우리는 이 패턴과 통합하지, 재구현하지 않습니다.
이들이 남기는 거버넌스 격차
Gateway는 요청을 봅니다. Guardrails는 콘텐츠를 봅니다. 둘 다 에이전트를 보지 못합니다 — 시간에 걸친 신원, 데이터 플레인에서 접근한 대상, 위험한 행위의 승인자, 이 중 무엇이라도 나중에 증명할 수 있는지. 이것이 Olivares가 메우는 격차입니다.
| Gateway / Guardrails가 남기는 격차 | 중요한 이유 | Olivares AI가 제공하는 것 |
|---|---|---|
| 에이전트 런타임에서의 enforcement | Gateway는 요청 경계에서 적용합니다; 이를 경유하지 않는 로컬 Claude Code tool-call은 차단할 수 없습니다 | 에이전트 내부의 deny-closed 인프로세스 PEP: 확정 신원 게이트, 정책 disposition, 라이브 정책 오버레이 — 모두 도구 실행 전에 적용 |
| 변조 방지 증거 | Gateway와 Guardrails는 로그 — 변경 가능한 요청 기록을 내보냅니다; 감사인은 불변의 증거를 원합니다 | Append-only, 해시 체인, Ed25519 서명 원장, 오프박스 검증 가능, OSCAL 증거로 내보내기 가능 |
| 비인간 신원 라이프사이클 | Gateway의 “가상 키”는 예산 버킷이지, 프로비저닝, 귀속, 로테이션, 오프보딩되는 신원이 아닙니다 | NHI 라이프사이클: 노후화 → 차단, 오프보딩 연쇄, 로테이션 듀얼 컨트롤, 접근 맵에 바인딩 |
| 활성 세션 개입 | 로그와 예산은 사후 조치입니다; 조사 대상 도구 중 세션을 실행 중간에 중단하는 것은 없습니다 | HITL 승인, break-glass, 그리고 듀얼 컨트롤 재활성화까지 모든 거버넌스 대상 실행을 거부하는 kill switch |
| 인프라 전체의 ground truth | Gateway는 자신을 경유하는 호출만 봅니다; 에이전트는 DB, 오브젝트 스토어, MCP, 파일에도 직접 접근합니다 | Read-first R/RW 접근 맵과 네이티브 감사와 대조한 Permitted-vs-Observed 드리프트 |
| 주권 | SaaS gateway와 클라우드 Guardrails는 해당 트래픽을 자사 클라우드에서 처리합니다 | Self-hosted / air-gapped; 데이터 플레인은 귀사의 경계를 벗어나지 않습니다 |
이 중 라우팅 기능은 없습니다. 이것이 핵심입니다: 격차는 더 나은 라우팅이 아니라, 요청 경로가 제공하도록 설계되지 않은 거버넌스입니다.
Guardrails에 대해 구체적으로: 콘텐츠 안전은 hook이지, 경쟁자가 아닙니다
Bedrock Guardrails는 두 가지 방식으로 적용할 수 있습니다 — Bedrock 추론 호출 중
인라인으로, 또는 *“directly through the ApplyGuardrail API without invoking the
foundation models”*로, 이는 *“with any foundation model whether hosted on Amazon
Bedrock or self-hosted models”*에서 작동합니다
(AWS). 이는 진정으로 유용하며,
Olivares는 콘텐츠 안전을 플러그인하는 검출기로 취급합니다. Guardrails
대신에 선택하라고 요구하는 벽이 아닙니다. 두 가지 솔직하고 구별되는 사실:
- 인라인 추론 프록시는 **콘텐츠 검사 심(seam)**을 노출합니다 — 콘텐츠 / DLP 검출기가 판정을 반환하면 deny-closed 결정기가 이에 따라 행동하는 플러그 가능 지점입니다. 콘텐츠 안전은 경쟁 필터로 재구현되는 것이 아니라 파이프라인의 그 자리에 속합니다.
- Olivares는 귀사의 Guardrails가 내린 자체 결정을 read-first로 읽어들입니다.
AWS 커넥터는 Bedrock guardrail 결정을 CloudWatch / S3 로그에서 포스처와 증거로
수집합니다; 의도적으로 유료
ApplyGuardrail런타임 자체를 호출하지 않습니다. 귀사의 콘텐츠 판정은 변조 방지 기록의 일부가 됩니다.
따라서 콘텐츠 안전은 이미 운영 중인 것과 조합됩니다. Guardrails가 문서화하지 않는 것 — 그리고 거버넌스 격차가 열려 있는 곳 — 은 에이전트 수명의 나머지입니다: Bedrock 페이지는 에이전트 신원, 세션 관리, 인간 승인, 비용 거버넌스를 문서화하지 않습니다(해당 페이지에서 미문서화, 2026-06-21 확인). Olivares는 정확히 그 보완재입니다: 신원, 세션 제어, 승인, 증거를 담당하며; 콘텐츠 필터는 이미 있는 곳에 머무릅니다.
구성 방법
건전한 구성은 각 도구를 자신의 영역에 유지합니다:
- 귀사의 gateway를 유지하십시오 (LiteLLM / Portkey / Kong / Cloudflare) — 모델 호출 플레인으로서 라우팅, 캐싱, 가상 키, 요청에 대한 예산을 담당합니다.
- 귀사의 Guardrails를 유지하십시오 (Bedrock / Azure Content Safety) —
콘텐츠 안전 검출기로서, Olivares PEP는 콘텐츠 검사 심에서 플러그 가능 검출기를
실행하고 귀사의 Guardrails 자체 결정을 read-first로 증거로 읽어들입니다;
ApplyGuardrail을 자체적으로 호출하지 않습니다. - Olivares를 그 옆에 추가하십시오 — 거버넌스 및 증거 플레인으로서: 귀사의 gateway를 경유하지 않는 에이전트에 대한 인프로세스 PEP, 전체 인프라에 걸친 접근 맵, 변조 방지 원장, 그리고 라이브 HITL/break-glass/kill 제어를 제공합니다.
Olivares가 추론에 관여하는 유일한 지점은 좁고 명시적입니다 — 원시 SDK/curl
호출자를 위한 API-key 전용 gateway 경로이며,
구독 인증 에이전트 거버넌스에
설명되어 있습니다. 귀사의 다른 도구가 도달할 수 없는 트래픽을 거버넌스하기
위해 존재하며, 라우팅에서 경쟁하기 위해 존재하지 않고, 절대로 구독
자격 증명을 전송하지 않습니다.
귀사의 gateway로 충분한 경우
솔직함은 양방향으로 작동합니다. 귀사의 에이전트가 모두 gateway를 통해서만 모델을 호출하고, 콘텐츠 안전 요구가 Guardrails로 충족되며, 데이터베이스 / 오브젝트 스토어 / MCP에 직접 접근하는 self-hosted 또는 노트북 에이전트가 없고, 주권 또는 변조 방지 증거 요건이 없다면 — 귀사의 gateway와 해당 로그, 그리고 Guardrails만으로 충분할 수 있으며, 컨트롤 플레인을 그 자체로 추가할 필요가 없습니다.
Olivares는 질문이 인프라 전체적이고 적대적이 될 때 그 가치를 발휘합니다: 어떤 에이전트가 존재하고 각각이 실제로 무엇에 접근했는지, 잘못된 행위를 에이전트 단에서 deny-closed로 중단할 수 있는지, 위험한 행위를 누가 승인했는지, 감사인에게 불변의 증거를 전달할 수 있는지 — 이 모든 것을 타사 클라우드로 보내지 않고 수행할 수 있는지. 인접한 두 비교의 심층 분석은 vs AI control towers 및 vs LLM observability를 참조하십시오.