AI 에이전트가 문서를 읽을 때는 답변의 정확도가 먼저 보이지만, API를 호출하고 결제를 건드리기 시작하면 남는 질문이 달라져. 누가 어떤 요청을 받아, 어떤 도구를 거쳐, 어떤 데이터를 보고 행동했나가 필요해지지.
Lineation은 이 문제를 여러 모델과 도구를 가로지르는 보안 통제면으로 풀겠다고 말해. OpenAI·Claude·Google Cloud·Microsoft Azure 같은 제공자와 각 실행 지점을 한곳에서 보고, 정책을 작업 흐름과 함께 옮기겠다는 구상이야.1
한 제품 안에 세 겹을 쌓는다
Lineation이 제시하는 순서는 관찰, 통제, 방어야. 첫 번째 층에서는 제공자별 대시보드와 추론·의사결정 로그를 모으고, 조직 안에서 발견하지 못한 AI 사용도 찾고, 에이전트의 행동을 다시 재생하는 기능을 내세워.
두 번째 층은 정책-as-code, 역할 기반 접근 제어, 승인 단계, 에이전트별 기계 신원이야. 세 번째 층에서는 프롬프트 인젝션 정리, 출력 시 개인정보·비밀값 가리기, 샌드박스 실행, 침해 때 멈추는 스위치를 제시해. 관찰만 하다가 끝나는 게 아니라, 위험한 행동을 실제 실행 지점에서 막겠다는 구조지.1
중앙에서 정하고, 실행 지점에서 막는다
구조는 중앙 통제면과 가벼운 엔드포인트 데몬으로 나뉘어 있어. 여러 AI 제공자의 요청은 중앙에서 같은 형식으로 다루고, 데몬은 에이전트가 실제로 실행되는 곳에서 로컬 집행과 외부 반출 통제를 맡는다고 설명해.
고위험 행동에는 기본 거부 정책을 적용하고, 예외가 필요하면 별도 승인 흐름을 둔다고 해. 에이전트의 행동은 프롬프트에서 시작해 도구 호출, 데이터 접근, 정책 결정, 출력, 최종 행위자로 이어지는 사슬로 기록돼. 일반 로그가 “행동이 있었다”를 남긴다면, Lineation은 “왜 그 행동을 했나”를 되짚을 수 있게 하겠다는 셈이야.1
이 방향은 에이전트 작업 흐름이 단순한 프롬프트 묶음이 아니라 도구·권한·검증·사람의 개입 지점을 함께 설계하는 문제라는 설명과 맞닿아 있어. 여러 클라우드와 제공자를 한 화면에 모으는 것만으로 충분하지 않고, 각 행동의 책임과 승인 경계까지 이어져야 한다는 얘기야.
숫자는 성과가 아니라 목표다
Lineation은 설계 파트너 프로그램의 목표로 첫 정책을 하루 안에 켜기, 사고 분석 시간을 기존 약 2시간에서 5분 미만으로 줄이기, 활성 작업 흐름의 80% 이상을 정책으로 덮기, 오탐률을 15% 아래로 낮추기를 제시해. 이 수치는 독립적인 성능 시험 결과가 아니라 회사가 내건 대표 목표로 읽어야 해.1
또 하나의 선도 분명해. 페이지는 OWASP나 NIST의 인증·보증을 받았다고 말하지 않고, SOC 2 Type II·HIPAA·EU AI Act 적합성을 자동으로 보장하지도 않는다고 적어놨어. 프레임워크에 맞춘 템플릿과 매핑은 감사 준비를 돕는 구현 수단이지, 인증서 자체는 아니라는 뜻이야.1
그래서 다음에 볼 것은 기능 목록보다 실제 운영 증거야. 여러 제공자의 에이전트가 정말 같은 정책으로 처리되는지, 엔드포인트 데몬이 빠진 실행을 얼마나 발견하는지, 사고가 났을 때 프롬프트부터 외부 데이터 접근까지 한 흐름으로 재현되는지를 확인해야 해. Lineation이 말하는 통제면은 그 증거가 쌓일 때 비로소 제품 설명을 넘어선 운영 도구가 될 수 있어.
댓글