문제: 에이전트는 여러분의 플랫폼이 모델링할 수 있는 속도보다 더 빠르게 도착하고 있습니다
여러분은 내부 개발자 플랫폼을 운영하고 있습니다. 서비스 카탈로그, IdP, 코드형 인프라(infrastructure as code), GitOps 조정(reconciliation), 그리고 엔지니어들이 실제로 여는 포털을 갖추고 있습니다. 이러한 기계 장치가 존재하는 이유는 다름 아니라, 중요한 어떤 것도 모델링되지 않은 채로 실행되지 않게 하기 위함입니다 — 소유자 없는 서비스도, 정책 없는 액세스도, 디프(diff) 없는 변경도 없도록 말입니다.
AI 에이전트는 그 계약을 깨뜨립니다. Claude Code 세션, MCP 서버, 스케줄링된 자율 에이전트 — 각각은 여러분의 서비스가 접근하는 동일한 데이터베이스, 객체 스토어, API에 걸쳐 읽고 쓸 수 있지만, 이들은 카탈로그 바깥에서 나타납니다. 이들은 여러분이 프로비저닝하는 것이 아니라 개발자들이 띄웁니다. 그리고 대개는 공유 서비스 계정으로 인증합니다. 게다가 하이퍼스케일러들은 에이전트 아이덴티티를 서로 호환되지 않는 세 가지 레지스트리에서 GA(정식 출시) 프리미티브로 만들어 놓음으로써 이 문제를 더욱 악화시켰습니다.
시장의 신호는 노골적입니다. Gartner는 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 예상하며(Gartner, 보도자료), IBM의 Cost of a Data Breach 2025 연구(Ponemon)는 AI 관련 침해를 겪은 조직 중 약 97%가 적절한 AI 액세스 통제를 갖추지 못했음을 발견했습니다. NANDA 프로젝트에서 나온 MIT의 예비 연구 결과 — the GenAI Divide, Fortune 경유, 2025년 8월, 아직 동료 심사를 거치지 않음 — 는 GenAI 파일럿의 약 95%가 측정 가능한 손익(P&L) 영향을 보이지 못했으며, 외부에서 구매한 도구가 내부에서 구축한 것보다 약 두 배 더 자주 성공했다고 보고합니다. 플랫폼 팀의 임무에 비추어 읽으면, 이는 같은 방향을 가리킵니다. 거버닝되지 않고 모델링되지 않은 에이전트의 난립이야말로 가치가 새어 나가고 리스크가 스며드는 지점입니다.
Olivares AI가 이미 운영 중인 플랫폼에 어떻게 맞아 들어가는가
Olivares AI는 여러분의 인프라 위에 있는 AI 에이전트를 발견하고, 각 에이전트가 무엇을 읽고 쓸 수 있는지 매핑하며, 그 액세스를 거버닝하고 감사하는 개방형 자체 호스팅 가능 플랫폼입니다. 플랫폼 팀을 위한 설계 목표는 또 하나의 콘솔이 아니라, 에이전트를 이미 운영 중인 플랫폼의 일급 시민으로 만드는 것입니다.
카탈로그의 일급 엔터티로서의 에이전트
플랫폼은 에이전트, MCP 서버, 세션, 비인간 아이덴티티를 발견하고 액세스 맵을 구축합니다. 이는 모든 에이전트 → 데이터베이스 / 스토어 / API 엣지로 이루어진 그래프이며, 각 엣지는 읽기(R) 또는 읽기-쓰기(RW)로 표시됩니다. 그 그래프야말로 에이전트가 처음부터 가졌어야 할 카탈로그 항목입니다 — 그것이 무엇인지, 무엇에 접근하는지, 그리고 접근하는 대상이 허용된 대상과 일치하는지를 담습니다.
그 마지막 구분이 이 제품의 핵심입니다. 엣지는 permitted vs observed로 분류되므로, 최소 권한 원칙으로부터의 드리프트(drift)가 짐작이 아니라 가시화됩니다. 액세스 맵과 개념 페이지 permitted vs observed를 참고하십시오.
여기서 솔직한 단서가 중요하며, 우리는 이를 공개적으로 유지합니다. R/RW 충실도(fidelity)는 **계층화(tiered)**되어 있습니다.
네이티브 감사가 가능한 소스에서는 커버리지가 clean, 엣지가 거친 경우 lossy,
그리고 수동적인 읽기/쓰기 신호가 전혀 없는 경우 opaque입니다. 귀속은 소스가 에이전트별 아이덴티티를
담고 있을 때 firm이고, 공유 계정이 이를 가릴 때 approximate입니다. 맵은
확실성을 위장하는 대신 그 계층을 그대로 보여 줍니다 — fidelity를 참고하십시오.
코드로서의 관리: Terraform/OpenTofu 프로바이더
플랫폼 팀에게 코드형 구성(config-as-code)은 기본 전제입니다. Olivares AI는
terraform-provider-olivares를 함께 제공하며, 이는 여러분 자체 호스팅 컨트롤 플레인을
그 안정적인 API에 대해 선언적으로 관리합니다. 이 프로바이더는
에이전트, 정책, 배포, 에이전트 아이덴티티
바인딩, 예산, 역량 구성, 알림 라우트에 대한 리소스와 데이터 소스를 노출하며, import, plan/apply,
드리프트 처리를 지원합니다 — 그리하여 여러분이 거버닝하는 에이전트는 ArgoCD나 Flux가 이미
여러분의 나머지 자산을 조정하는 것과 동일한 방식으로 조정됩니다.
커넥터 SDK와 다르기 때문에 정확히 짚어 둘 라이선스 세부 사항이 하나 있습니다. 이 프로바이더는 Apache-2.0가 아니라 AGPL-3.0-only입니다.
resource "olivares_agent" "billing_assistant" {
name = "billing-assistant"
# ...managed alongside the rest of your platform, as code
}
resource "olivares_policy" "billing_least_privilege" {
# least-privilege intent, versioned in Git, reconciled like everything else
}위 HCL은 형태를 예시하기 위한 것이며 그대로 복사-붙여넣기 하는 계약이 아닙니다 — 프로바이더 자체가 공개한 스키마에 맞춰 생성하십시오. 이 제품은 pre-1.0입니다. 리소스 커버리지는 API 표면을 따라가는 것으로 간주하고, 오늘 시점에 무엇이 연결되어 있는지는 모듈 레퍼런스에서 확인하십시오.
여러분의 IdP와의 적합성 — 대체가 아니라 페더레이션
Olivares AI는 아이덴티티 프로바이더가 아니며 그것이 되려 하지도 않습니다. 에이전트 아이덴티티를 읽기 전용으로 페더레이션합니다. Microsoft Entra Agent ID, AWS AgentCore Identity, Google Agent Identity에서 로스터를 읽어들이고, 이를 SPIFFE/WIF 로스터와 대조하여 액세스 맵의 각 엣지가 firm 또는 approximate 귀속 정보를 담도록 합니다. 전용 에이전트 및 워크로드 아이덴티티는 firm 귀속으로 해석되며, 블루프린트 프린시펄, 자격 증명 프로바이더, 서비스 계정 에이전트는 조작된 아이덴티티로 승격되지 않고 approximate 상태로 유지됩니다. 어떠한 자격 증명도 발급하지 않으며 해당 레지스트리에 아무것도 다시 기록하지 않습니다 — 페더레이션은 엄격하게 읽기 전용입니다.
또한 플랫폼 보안에 유용한 드리프트 분류를 노출합니다. 즉, 단기(short-lived) 자격 증명을 지향하는
Five Eyes 2026 가이던스에 발맞추어, 에이전트 아이덴티티에서 탐지된 장기 정적(static) 자격 증명을 노출합니다. SVID 기반 OAuth 클라이언트 인증(draft-ietf-oauth-spiffe-client-auth
작업)은 design-toward로 구현되어 있습니다 — 인가
서버가 그에 대응하는 플로를 게시하기 전까지는 어떠한 적합성(conformance) 주장도 하지 않습니다. identity & federation을 참고하십시오.
포털 연동: Backstage, 읽기 우선
여러분의 개발자들이 Backstage 안에서 생활한다면, 에이전트 인벤토리도 그곳에 있어야 합니다. 설계 목표는 네이티브 읽기 우선 플러그인입니다 — 인벤토리, 라이브 세션, 그리고 R/RW 액세스 맵을 포털 내부에 렌더링하고 컨트롤 플레인에 대해 인증하는 것이며, iframe도 아니고 별도의 두 번째 대시보드도 아닙니다. 읽기 우선은 의도된 선택입니다. 이는 (아래에 설명할) 제품의 태도와 부합하며 포털 통합을 저위험으로 유지합니다.
CLI 우선, 그 밑에는 안정적인 API
플랫폼 전체는 채워진 액세스 그래프 상태로 부팅되는 단일 Go 바이너리 controlplane입니다.
웹 콘솔은 API와 동일한 오리진(origin)에 임베드되어 있습니다. UI에서 할 수 있는 모든 것을
CLI나 OpenAPI 3.1 표면에서 구동할 수 있으며, 이것이 바로 Terraform
프로바이더, Backstage 플러그인, 그리고 여러분 자신의 자동화가 모두 그 위에 구축되는 토대입니다. 먼저
구성 레퍼런스,
CLI 워크플로,
MCP 거버넌스 표면부터 시작하십시오.
이것이 무엇인가 — 그리고 무엇이 아닌가
이는 보안 성격의 제품이므로, 우리는 주장하는 바에 대해 엄격한 선을 지킵니다.
- 읽기 우선, 그리고 deny-closed. Olivares AI는 넓게 관찰하고 거버닝하지만, 넓게
액추에이트(actuate)하지는 않습니다. 대부분의 액추에이션은 라이브 온디맨드이거나 선언된 deny-closed 이음새입니다 — 배포
apply는 익스큐터를 프로비저닝하기 전까지 조용한 무동작(no-op)이 아니라503을 반환합니다. permitted vs observed와 honesty & limits 페이지를 참고하십시오. - Pre-1.0, 오픈코어(open-core). 카탈로그는 23개 모듈이며, 기본(stock) 설치에서 약 20개가 연결되어 있습니다. 여기에 적힌 어떤 내용도 23개 전부가 완전히 가동된다는 의미가 아닙니다 — 모듈 레퍼런스가 모듈별 상태를 표시합니다.
- 에어갭(air-gap)은 컨트롤 플레인을 의미하며, Claude를 의미하지 않습니다. 거버넌스 및 관찰 플레인은 완전히 자체 호스팅으로 실행되며 에어갭이 가능합니다. Claude 추론은 결코 자체 호스팅되지 않습니다 — Anthropic은 가중치(weights)를 공개하지 않으므로, 모든 Claude 호출은 API에 도달합니다. 여러분이 진정으로 자체 호스팅하는 모델(vLLM, Ollama)만이 오프라인으로 실행됩니다. security를 참고하십시오.
- 인증되지 않음. EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 등을 지향하여 설계되었으며(designed toward), 추가 전용(append-only)·해시 체인(hash-chained) 원장에서 도출된 감사 증거를 갖추고 있습니다. 하지만 SOC 2 / ISO / EU-AI-Act 인증을 받은 것은 아닙니다. compliance를 참고하십시오.
- 여러분의 컨트롤 타워를 보완하며, 그것을 대체한다고 주장하지 않습니다. 아이덴티티 페더레이션과 포스처(posture) 익스포트는 설계상 읽기 전용입니다.
먼저 아키텍처 전반을 파악하고 싶다면 the architecture를 읽으십시오. 게이트웨이, 관찰 가능성(observability), 에이전트 컨트롤 타워 대비 우리가 어디에 위치하는지 알고 싶다면 the comparison을 참고하십시오. 그리고 라이선스와 오픈코어 경계를 저울질하고 있다면, open source가 솔직한 버전입니다.
관련 페르소나: security leaders, SRE & sysadmin, 그리고 higher education.