아크젯의 데이비드 마이튼 CEO와의 인터뷰 시리즈

데이비드 마이튼, 아크젯의 설립자이자 CEO는 개발자 중심의 보안 스타트업을 이끌고 있으며, 2023년 6월부터 개발자들이 애플리케이션 코드에 강력한 보호를 직접 내장할 수 있도록 도와주고 있습니다. 그는 또한 콘솔을 공동 설립했으며, 시드캠프의 전문가로 활동했으며, 스택패스의 제품 엔지니어링을 담당했습니다. 그는 또한 기술에 대한 관심을 가지고 있으며 지속 가능한 컴퓨팅에 대한 글을 작성하고 있습니다.

아크젯은 “보안을 코드로”라는 철학을 가지고 있으며, 개발자들이 애플리케이션을 보호하기 위해 단순한 SDK 통합을 통해 보안 로직을 비즈니스 로직과 함께 배치할 수 있도록 합니다. 이는 낮은 지연 시간과 컨텍스트에 따른 의사 결정이 가능하며, 별도의 인프라가 필요하지 않습니다. 플랫폼은 봇 차단, 속도 제한, 민감한 데이터 필터링과 같은 보호를 지원하며, 로컬 AI 보안 모델과 확장된 프레임워크 지원과 같은 기능으로 지속적으로 발전하고 있습니다.

서버 덴시티를 설립했을 때, 인프라를 대규모로 운영하는 것은 오늘날보다 표준화가 덜되어 있었습니다. 그 경험에서 개발자를 위한 소프트웨어를 구축하고 프로덕션 시스템을 운영하는 것에 대해 가장 중요한 교훈은 무엇이었나요? 어떻게 하면 그 경험을 통해 소프트웨어에 대한 생각을 바꿀 수 있었나요?

대부분의 개발자 도구는 데모에서는 이기지만 프로덕션에서는 지는 경우가 많습니다. 개발자가 새로운 것을 설치하도록 하는 것은 어렵기 때문에 “퀵 스타트”는 마찰이 없어야 합니다. 하지만 실제 실패 모드는 “작동한다”라는 후에 발생합니다. 제품이 제한되면 심각한 팀은 빠르게 좌절하고 제품을 제거합니다.

아크젯의 코드 내 애플리케이션 보안은 두 가지 현실을 위해 설계되었습니다. 즉, 즉각적인 해결책이 필요하며, 또한 고급 제어로의 탈출구가 필요합니다. 즉, 사용자당 할당량, 위험 기반 규칙, 컨텍스트에 따른 의사 결정이 필요합니다. 모든 것을 다시 작성하지 않고도 이러한 제어가 가능해야 합니다.

제품은 사용자 인터페이스가 아닙니다. 제품은 런타임 동작, 에지 케이스, 예제, 참조 문서입니다. 개발자가 이러한 문서를 신뢰할 수 있어야 합니다.

그 경험에서 아크젯을 시작하기로 결정한 이유는 무엇이었나요? 그리고 왜 애플리케이션 보안의 다음 주요 변화를 코드 자체에서 이루어야 하는 것으로 생각했나요?

주변 보안은 잘못된 것을 최적화합니다. 개발자는 대시보드가 아닌 코드에서 빌드하고 출품합니다. AI 코딩 에이전트는 애플리케이션을 보호하기 위해 보안 콘솔을 클릭하지 않습니다.

보호가 코드로 표현되지 않으면, 풀 리퀘스트에서 검토되고, CI에서 테스트되고, 애플리케이션과 함께 배포되지 않으면, 그것은 “개발자 우선 보안”이 아닙니다.

아크젯은 보안이 애플리케이션 계층에 속한다는 이유로 존재합니다. 즉, 버전 관리, 테스트, 관찰, 비즈니스 로직과 가까운 곳에 있어야 합니다.

아크젯은 애플리케이션 요청 핸들러에 직접 AI 기반 위협 탐지를 내장합니다. 기술적인 관점에서, 이 로컬, 코드 내 접근 방식은 전통적인 주변 기반 보안 도구와 비교하여 어떤 이점을 제공합니까?

요청 핸들러 내에서 身份, 세션 상태, 구매 기록, 계정 연령, 기능 플래그, 데이터베이스 진실과 같은 정보를 얻을 수 있습니다. 예를 들어, “이것은 이상하지만, 충성 고객이므로 차단 대신 검증을 강화합니다”라는 결정을 내릴 수 있습니다. 네트워크 프록시는 고객이 무엇인지 알 수 없기 때문에 이를 수행할 수 없습니다.

목표는 최대 차단이 아닙니다. 목표는 컨텍스트에 따른 보안으로 거짓 양성 오류를 최소화하는 것입니다. 가장 비싼 보안 실수는 합법적인 체크아웃을 차단하거나 실제 사용자를 잠그는 것입니다.

AI는 봇 스크래핑, 스팸 가입, 자동 API 악용과 같은 남용의 경제학을 크게 변화시켰습니다. 현재 프로덕션에서 가장 자주 발생하는 공격 유형은 무엇이며, 공격자가 더 발전된 AI 시스템을 채택함에 따라 어떻게 진화하고 있습니까?

AI의 생산성 향상은 공격자에게도 도움이 됩니다! 큰 변화는 볼륨과 반복 속도입니다. 즉, 더 많은 자격 증명_stuffing, 자동화된 가입 스팸, 더 많은 봇 스크래핑, 더 많은 API 프로빙, 더 빠른 취약점의 “무기화”입니다.

또한 공격자가 방어를 테스트하고, 프롬프트와 페이로드를 적응시키고, 인프라를 회전시키고, 계속해서 들어가려고 하는 것을 보는 것이 중요합니다. 현재 속도보다 복잡성이 더 중요합니다.

또한 여전히 많은 사람들이 최선의 관행을 따르지 않고 있습니다. 즉, 비밀번호 관리자를 사용하고, 피싱에 강한 자격 증명인 패스키 또는 하드웨어 키와 함께 2요소 인증을 배포하고, 종속성을 최신 상태로 유지하는 것입니다. 공격 볼륨이 증가함에 따라 이것이 더 중요해질 것입니다.

보안을 유지하면서 개발 속도를 유지하는 가장 큰 긴장감 중 하나입니다. 아크젯을 사용하는 팀은 어떻게 보안을 워크플로에 통합하면서 빠른 릴리즈 주기를 유지할 수 있었나요?

아크젯은 모든 환경에서 실행할 수 있습니다. 즉, 프로덕션에 배포하지 않고도 개발자가 테스트할 수 있습니다. 이는 개발자가 특별한 권한이나 프로덕션에 영향을 미치지 않고도 검증하고 통합을 시연할 수 있기 때문에 큰 이점입니다. 이는 보안 팀이 개발자의 작업을 방해하는 도구를 채택하도록 강요하는 klasik 문제를 해결합니다.

아크젯은 초기 트랙션을 AI 네이티브 제품과 전자 상거래 플랫폼에서 얻었습니다. 이러한 환경은 왜 현대적인 자동화 공격에 특히 취약한가요? 그리고 왜 레거시 방어는 부족한가요?

이 두 범주는 유사성을 공유합니다. 즉, 모든 남용 요청에 직접 비용이 발생합니다.

AI 제품은 토큰과 추론에 대해 지불하며, 공격자는 스크래핑, 자동화, 무료 티어 농업을 통해 마진을 게임으로 만듭니다. 전자 상거래는 사기, 차지백, 재고 남용, 계정 탈취에 대해 지불합니다. 두 경우 모두 거짓 양성 오류에 매우 민감합니다. 즉, 실제 사용자를 차단하는 것은 실제 수익 손실입니다.

레거시 방어는 주로 대역폭과 인프라를 보호합니다. 현대의 공격자는 비즈니스 로직을 대상으로 합니다. 즉, 가입 흐름, 체크아웃 흐름, 프로모션 로직, 계정 복구, API 엔드포인트입니다. 이것이 왜 제네릭 주변 제어와 “CAPTCHA로 해결”이 점점 더 부족해지는 이유입니다.

보안 소프트웨어를 구축하는 것은 관찰성 또는 모니터링과는 매우 다른 트레이드오프를 가지고 있습니다. 보안 제품을 개발하는 것에 대해 가장 놀랐던 것은 무엇이었나요? 그리고 그것은 이전의 인프라 툴링 경험과 어떻게 다른가요?

관찰성의 경우 고객이 사용 가능하다고 신뢰합니다. 보안의 경우 고객이 안전하다고 신뢰하며, 공급망의 새로운 취약점이 되지 않도록 신뢰합니다.

보안 제품을 구축하는 것은 보안 회사를 운영하는 것을 의미합니다. 우리는 SOC 2와 같은 프레임워크를 사용하며, 제3자 종속성을 최소화하고, 개발자의 랩톱과 도구에 대한 액세스를 프로덕션 자산으로 취급합니다. 이는 많은 모니터링과 잠재적인 문제에 대한 빠른 반응을 의미합니다.

애플리케이션이 사용자를 대신하여 작동하는 AI 에이전트에越来越 많이 의존하는 경우, 개발자는 어떻게 애플리케이션 계층에서 身份, 의도, 신뢰와 같은 개념을 재고해야 합니까?

AI 에이전트가 사용자를 대신하여 작동할 때, 身份는 이진 로그인 상태가 아닌 위임 문제가 됩니다. 즉, 누가 행동하고, 누구를 대신하여, 어떤 권한으로, 얼마나 오래, 어떤 제약으로 행동하는지 결정해야 합니다.

개발자는 계속해서 검증해야 합니다. 즉, 컨텍스트에 따라 요청에 대한 신뢰 결정을 내립니다. 즉, 사용자 기록, 디바이스 신호, 세션 동작, 행동 위험과 같은 정보를 고려해야 합니다. “의도”는 헤더에서 주장하는 것이 아니라 행동에 따라 추론됩니다.

이는 높은 위험 동작(예: 비밀번호 재설정, 체크아웃, 토큰 생성) 주변에 단계별 모멘트(검증, 속도 제한, 마찰)를 구축하는 것을 의미합니다. 이러한 제어는 코드 내에서 있어야 하며, 애플리케이션이 충성 고객과 봇을 구별할 수 있어야 합니다.

앞으로 AI 생성 트래픽이 계속 증가하는 경우, 코드 내 컨텍스트에 따른 보안의 역할은 어떻게 발전할까요?

주변 도구는 사라지지 않을 것입니다. 그러나 네트워크에서 처리하는 것이 가장 좋은 것들(예: DDoS 공격)에 대한 粗 필터로 사용될 것입니다. 정교한 결정은 애플리케이션 내에서 발생할 것입니다. 즉, 실제 컨텍스트를 사용하여 결정할 것입니다.

애플리케이션 보안의 기본 모델이 되는 경우, 프로덕션 시스템에서 보안을 테스트, 배포, 이유하는 방식은 어떻게 변경될까요?

보안이 기본 모델이 되는 경우, 팀은 오류를 테스트하는 것과 마찬가지로 남용을 테스트할 것입니다. 즉, 보안 유닛 테스트, 재생 가능한 공격 시뮬레이션, 위험한 엔드포인트에 대한 CI 검사를 수행할 것입니다.

더 큰 변화는 AI 코딩 에이전트가 코드로 보안을 구현할 것입니다. 즉, 대시보드 구성이 아닌 코드로 보안을 구현할 것입니다. 에이전트는 보호를 제안하고, 검토하고, 검증할 수 있지만, 제어는 저장소에 있어야 합니다. 즉, 정책, 규칙, 테스트, 기strumentation이 저장소에 있어야 합니다. “보안 계층”이 웹 UI인 경우, 에이전트는 안전하게 변경 사항을 테스트할 수 없습니다.

그것이 “코드 내 보안”이 이기는 실제 이유입니다. 즉, 현대적인 소프트웨어(및 현대적인 AI 지원 개발)가 실제로 구축되는 방식에 적합하기 때문입니다.

이 인터뷰에 감사드립니다. 더 많은 정보를 원하는 독자는 아크젯을 방문하십시오.