Sean Blanchfield, Jentic의 공동 창립자 및 CEO – 인터뷰 시리즈

Sean Blanchfield, Jentic의 공동 창립자 및 CEO는 수십 년의 대규모 소프트웨어 및 인프라 기업을 구축한 시리얼 기술 기업가입니다. 더블린에 기반을 두고 있으며, 그는 현재 Jentic을 이끌면서 아일랜드의 AI 자문위원회에서 정부에 인공 지능 정책을 자문하고 있습니다. 그의 경력 초기에는 DemonWare를 공동 창립했으며, DemonWare는 주요 비디오 게임 퍼블리셔를 위한 대규모 온라인 서비스 플랫폼으로 Activision Blizzard (ATVI )에 인수되었습니다. 또한 PageFair를 공동 창립했으며, PageFair는 광고 차단 분석에 중점을 둔 벤처 지원 스타트업으로 Blockthrough에 인수되었습니다. 그는 또한 여러 스타트업을 설립하거나 이끌었으며 Techpreneurs와 같은 이니셔티브를 통해 아일랜드의 스타트업 생태계를 계속 지원하고 있습니다.

Jentic은 기업 시스템 및 API와 안전하게 상호 작용할 수 있는 보편적인 통합 계층을 개발하고 있습니다. 이 플랫폼은 조직이 내부 도구, 외부 서비스 및 운영 워크플로우와 AI 모델을 연결할 수 있도록 하면서도 거버넌스, 인증 및 감독을 유지합니다. Jentic은 분산된 API를 구조화된 인터페이스로 변환하여 AI 에이전트가 신뢰할 수 있는 방식으로 사용할 수 있도록 하여, 복잡한 소프트웨어 환경에서 대규모 AI 기반 자동화를 구현하는 것을 도와줍니다.

您는 여러 기술 회사에서 공동 창립자 및 CEO를 역임했습니다. DemonWare(Activision Blizzard에 인수됨)에서 PageFair 및 현재 Jentic까지, 그리고 아일랜드의 AI 자문위원회에서도 활동하고 있습니다. Jentic에서 인프라 계층을 다시 구축하게 된 동기를 무엇으로 보시나요? 또한, 다른 사람들이 놓친 점은 무엇이라고 생각하시나요?

세 번째에 해당하는 패턴을 발견했을 때, 그것을 심각하게 받아들여야 합니다. DemonWare에서 모든 사람이 온라인 멀티플레이어에 대해 이야기했지만, 실제로 어려운 문제는 네트워크 인프라였습니다. AI 에이전트도 마찬가지입니다. 모델은 놀랍습니다. 병목 현상은 통합 계층에 있습니다. AI 에이전트는 API에서 실행되며, 이러한 API는 인간을 위해 문서화되고, 인간을 위해 보안이 설정되며, 인간을 위해 구조화되었습니다. 자율 에이전트를 해당 인프라에 연결하면 빠르게 고장ナります. 기업 AI 파일럿은 모델이 작업을 잘못 이해해서 실패하는 것이 아닙니다. 에이전트가 필요한 시스템에 신뢰할 수 있는 방식으로 연결할 수 없기 때문에 실패합니다. 생성적 AI는 통합을 코드 문제가 아닌 지식 문제로 다루는 새로운 방법을 제공합니다. 이러한 통찰력이 나를 끌어들였습니다.

Jentic을 2024년에 시작했을 때, 에이전트 보안이 첫 번째 설계 철학이었나요? 아니면 실제로 조직이 생산 환경에서 자율 에이전트를 배포하는 방식을 관찰하면서 초점이 더 선명해졌나요?

첫 번째 스레드는 자격증명이었습니다. 에이전트가 수십 개의 시스템에 대한 자격증명을 필요로 하는 시나리오를 상상했습니다. 모든 이러한 비밀은 LLM 컨텍스트 창으로 흐르고, 유출되었습니다. 答案은 20년 전과 동일했습니다. 인증 및 권한을 중앙화하십시오. 그러나 그 스레드를 당길 때마다 다음 문제로 이어졌습니다. 전통적인 통합 툴링을 사용하여 중앙화를 수행하면 정적 커넥터로 돌아가게 됩니다. 에이전트는 정적이지 않습니다. 비전을 구체화한 것은 능력 검색이 접근 제어와 긴밀하게 결합되어야 한다는 깨달음이었습니다. 즉, 에이전트에게 능력이 제공되어야 하는 경우에만 실제로 권한을 부여받았는지 확인해야 하며, 검색을 제공하는 시스템이 또한 강제 및 관찰의 단일 지점이 될 수 있습니다.

최근에 인터넷에 노출된大量의 에이전트 인스턴스가 오케스트레이션과 자격증명이 동일한 신뢰 경계를 공유하는 문제를 강조했습니다. 이러한 모델의 핵심 아키텍처 결함은 무엇이라고 생각하시나요?

결함은 간단합니다. 에이전트(LLM의 프롬프트에서 실행되는 시스템)는 또한 자격증명을 보유하고 API 호출을 수행하는 시스템입니다. 에이전트를 손상시키면 모든 것을 얻을 수 있습니다. 초기 웹 시대에 우리는 편의를 위해 슈퍼유저 데이터베이스 액세스를 가진 애플리케이션 서버를 만들었습니다. Jentic은 에이전트와 호출하는 API 사이의 계층으로 존재합니다. 에이전트는 자격증명을 보유하지 않습니다. 관리형 실행 계층을 통해 요청을 발급하고, 자격증명을 서버 측에서 주입하고, 정책을 적용하며, 모든 호출을 로깅합니다. 그리고何か 잘못되면 단일의 kill 스위치가 있습니다. 하나의 동작으로 해당 에이전트의 모든 연결 시스템에 대한 액세스를 동시에 중단할 수 있습니다.

오케스트레이션과 실행을 분리하여 블래스트 반경을 포함하는 방법에 대해 실제적인 용어로 설명해 주시겠습니까?

플랫 모델에서 LLM은 무엇을 해야 하는지 이유를 제공하고 직접 자격증명을 사용하여 API를 호출합니다. LLM을 손상시키면 실행 계층을 제어할 수 있습니다. 분리에서는 LLM이 의도를 발급합니다. “이 매개변수와 함께 스트라이프 청구 API를 호출하십시오” 관리형 실행 계층은 요청을 정책에 대해 검증하고, 자격증명을 서버 측에서 주입하고, 호출을 수행합니다. LLM은 자격증명을 절대 터치하지 않습니다. 실제로는 다음과 같습니다. 수평 이동이 훨씬 더 어려워지고, 블래스트 반경은 해당 에이전트 ID에 대해 실행 계층이 허용하는 것으로 제한되며, kill 스위치가 있습니다. 하나의 토글로 모든 연결 시스템에 대한 에이전트의 액세스가 중단됩니다. 에이전트는 여전히 조작될 수 있지만, 조작은 더 이상 전체 자격증명 손상을 의미하지 않습니다.

실제 기업 배포에서 중앙화된 자격증명 관리와 즉시 취소는 어떻게 보시나요? 그리고 대부분의 팀이 현재 에이전트에 대한 API 키와 토큰을 처리하는 방식과 어떻게 다르나요?

오늘날 대부분의 팀은 개발자가 API 키를 프로비저닝하고, .env 파일에 저장하고, 에이전트 시작 시 로드합니다. thường적으로 개발자는 어떤 에이전트가 어떤 자격증명을 보유하고 있는지에 대한 전체적인 그림을 가지고 있지 않습니다. 누군가가 떠나면 프로비저닝된 키가 회전하지 않습니다. 에이전트가 이상하게 행동할 때는 무슨 일이 발생했는지 재구성할 수 있는 감사 추적이 없습니다. Jentic에서는 개발자가 원시 자격증명을 다루지 않습니다. 개발자는 에이전트가 필요로 하는 액세스를 선언하고, 플랫폼이 범위가 지정된 액세스를 프로비저닝하며, 에이전트는 기본 자격증명을 보지 않고 실행 계층을 통해 호출합니다. 즉, 에이전트별 즉시 취소, 조사 중 액세스를 일시 중지하는 기능 및 타임스탬프가 있는 모든 API 호출에 대한 감사 추적을 얻을 수 있습니다. 그것은 “API 키를 .env 파일에”와는 상당히 다릅니다.

많은 팀이 판매, 엔지니어링, 데이터 과학을 위한 에이전트 프레임워크를 실험하고 있습니다. 조직이 실험에서 생산으로 이동할 때 보안에서 가장 일반적인 실수를 무엇이라고 생각하시나요?

同じ 패턴이 반복됩니다. 프로토タイプ에 사용된 관리자 자격증명을 여전히 보유한過剰한 에이전트; 프롬프트 또는 컨텍스트 창에서 자격증명을 전달하여 로그, 텔레메트리 및 잠재적으로 훈련 데이터에 끝나게 하는 것; 여러 에이전트 인스턴스에 걸친 공유 자격증명으로 단일 악의적 에이전트를 분리할 수 없는 경우; 에이전트를 중지하지 않고 더广い 시스템을 중단하지 않는 kill 스위치가 없는 경우; 이름값만 하는 감사 추적; 프롬프트 주입이 심각하게 받아들여지지 않는 경우 – 에이전트가 이메일을 읽거나 문서를 처리하거나 웹을 브라우징할 때 적대적으로 제작된 콘텐츠를 마주칠 수 있기 때문입니다. 공통된 스레드는 이러한 팀이幸せな 경로를 위해 구축하고 이제는 생산이 대부분幸せ하지 않은 경로라는 것을 발견하고 있다는 것입니다.

Jentic은 에이전트 프레임워크와 외부 시스템 사이의 관리형 실행 계층으로 자리잡고 있습니다. 개발자에게 부담을 주거나 에이전트의 유연성을 줄이지 않고 거버넌스를 어떻게 강제하나요?

에이전트를 50개의 다른 API에 연결하는 대신 개발자는 하나의 엔드포인트에 연결합니다. 그 엔드포인트는 API 기능의 전체 카탈로그를 검색하고, 세부 정보를 로드하고, 모든 호출을 실행하기 위한 도구를 노출합니다. 이것은 유연성을 최대화하면서, 하나의 통일된 인터페이스를 통해 무제한의 API에 대한 액세스를 제공합니다. 또한, 플랫폼에서 관리되는 거버넌스를 가능하게 합니다. 즉, 어떤 에이전트가 어떤 API에 액세스할 수 있는지, 어떤 조건에서, 어떤 제한으로 결정할 수 있습니다. 실행 계층은 패스스루입니다. 에이전트는 여전히 멀티 스텝 워크플로우를 구성하고, 호출을 체인하고, 동적으로 오류를 처리할 수 있습니다. 무마無의 거버넌스는 어렵습니다.捷徑은 개발자에게 부담을 전가하는 것입니다. 인프라는 그 반대로 작동해야 합니다. 즉, 개발자가 하지 않아도 되는 복잡성을 흡수해야 합니다.

정보를 훔치는 악성 코드가 현재 에이전트 구성 파일과 저장된 자격증명을 대상으로 하고 있습니다. 공격자가 AI 인프라를 새로운 고가치 표면 영역으로 집중하는 것으로 보이시나요?

絶對적으로 – 그리고 논리는 명백합니다. 에이전트 구성 파일은 효과적으로 멀티 서비스 슈퍼키입니다. 이메일 시스템, CRM, 청구 플랫폼, 내부 API 및 GitHub 계정의 자격증명이 포함됩니다. 한 번의 성공적인 정보 훔치기 실행으로 회사의 모든 외부 시스템에 걸쳐 몇 개월 동안 액세스를 얻을 수 있습니다. 그것은 개별 서비스를 분리하여 공격하는 것보다 훨씬 더 높은 수익을 제공합니다. 또 다른 차원은 연속적으로 생산에서 실행되는 에이전트가 지속적이고 자격증명을 가진 존재라는 것입니다. 사용자가 로그인하고 로그아웃하는 것이 아닙니다. 손상된 에이전트는 장기적인 발판으로 служ을 수 있습니다. 이는 감지 임계값 아래에서 작동할 수 있습니다. 불편한 현실은 공격 표면이 방어 도구보다 더 빠르게 진화하고 있다는 것입니다. Jentic은 자격증명 공격 표면을 크게 줄일 수 있지만, 에이전트가 부여된 범위 내에서 잘못된 사용을 방지할 수는 없습니다. 더 어려운 문제는 모델 수준에서 해결되어야 합니다. 가드레일 및 프롬프트 주입 감지와 함께.

단일 프레임워크를 넘어서, 조직이 대규모로 에이전트 AI를 안전하게 배포하려면 어떤 보다广い 보안 원칙을 채택해야 합니까?

대부분의 관리되는 조직은 비결정적 시스템을 가장 중요한 비즈니스 프로세스에 배포할 수 없습니다. 은행이나 보험사는 자율 에이전트를 청구 시스템에 연결하고 “그것을 찾아보세요”라고 말할 수 없습니다. 그렇다면 어떻게 혁신을 하지 않고 위험한 자세를 취하지 않을 수 있나요? 答案은 샌드박스입니다. API 부동산과 동일한 구조 및 워크플로우를 갖춘 디지털 쌍을 생성하되, 생산 자격증명이나 결과는 없습니다. 에이전트를 배포하고, 탐색을 허용하고, 무슨 일이 발생하는지 관찰합니다. 성공한 경로는 구조화된 결정적 워크플로우 자동화로 캡처됩니다. OpenAPI Initiative 내에서 개발된 Arazzo라는 오픈 워크플로우 사양을 사용하여 감사 가능하고, 반복 가능하며, 모든 컴플라이언스 팀에 의해 검토할 수 있습니다. 이것은 샌드박스에서 AI 속도로 이동하고 기업 속도로 생산에서 이동할 수 있음을 의미합니다. 그리고 두 모드는 공존합니다. 다른 원칙은 여전히 적용됩니다. 최소 특권, 감사 추적, kill 스위치, 오케스트레이션과 실행의 분리. 그러나 샌드박스는 기업 팀이 실제로 걸리는 질문에 대한 구조적인 答案입니다. 즉, 비결정적 AI와 함께 어떻게 혁신을 하지 않고 컴플라이언스 자세를 벗어나는 것에 베팅하지 않습니까? 비결정성을 배포하지 마십시오. 통제된 조건에서 가치를 추출하고, 결정적 출력만 배포하십시오.

위대한 인터뷰에 감사드립니다. 더 많은 정보를 원하는 독자는 Jentic을 방문하십시오.