비밀 브로커는 에이전트의 워크로드를 인증하고 외부 요청 경계에서만 범위가 지정된 권한을 주입하여 자격 증명이 프롬프트에 들어가지 않도록 합니다.
홈 AI 에이전트는 캘린더를 읽거나 백업을 업로드해야 할 수 있지만, API 키를 프롬프트, 메모리, 환경 또는 도구 출력에 넣으면 인젝션을 통해 접근할 수 있게 됩니다. 브로커는 워크로드의 신원과 승인된 작업 컨텍스트를 확인하고, 단기간 유효한 자격 증명을 발급받아 제어되는 프록시 또는 도구 어댑터 내부에 연결한 뒤 서비스 결과만 반환합니다.
워크로드 신원이 정적 키의 소지를 대체합니다
에이전트는 승인된 프로세스, 컨테이너, 서비스 계정 또는 서명된 워크로드 중 무엇이 요청을 보내는지 증명합니다. 브로커는 생성된 코드나 모델 컨텍스트가 읽을 수 있는 곳에 저장된 전달자 키를 신뢰하는 대신 해당 신원을 정책에 매핑합니다.
에이전트를 위한 워크로드 신원에 대한 분석은 영구 자격 증명을 보유해서는 안 되는 에이전트를 위한 증명과 머신 간 인증을 설명합니다. 신원 증명을 통해 권한 부여는 대화상의 주장보다 런타임 워크로드에 따라 결정됩니다. 이러한 차이는 이후 가정 환경 테스트에서도 확인할 수 있습니다.
신원만으로 모든 서비스에 대한 권한이 부여되는 것은 아닙니다. 정책은 여전히 워크로드를 사용자, 대상, 작업, 리소스 범위 및 시간 창에 연결합니다. 자동화가 진행되기 전에 중간 결과를 계속 검사할 수 있어야 합니다.
브로커는 범위가 좁고 단기간 유효한 자격 증명을 발급하거나 주입합니다
정책 승인 후 브로커는 신원을 범위가 지정된 토큰으로 교환하거나 보호된 메모리에서 비밀을 가져옵니다. 프록시는 모델이 생성한 매개변수를 검증한 후 외부 요청에 인증 헤더를 추가합니다.
단기간 유효한 브로커 발급 자격 증명에 대한 보안 지침은 자격 증명이 없는 상태에서 시작하고, 브로커를 사용해 특정 작업에 필요한 단기간 유효한 토큰을 제공할 것을 권장합니다. 이렇게 하면 노출 기간과 침해 후 수행할 수 있는 작업을 모두 제한할 수 있습니다. 이러한 경계는 현실적인 운영 조건에서 별도로 측정해야 합니다.
모델에는 토큰이 아니라 도구 스키마와 정제된 응답만 표시됩니다. 로그, 오류, 추적 정보, 명령줄 및 재시도 과정에서도 인증 자료를 마스킹해야 합니다. 그렇지 않으면 아키텍처가 단순히 유출 지점을 옮긴 것에 불과합니다. 여러 소스가 제한된 컨텍스트를 두고 경쟁할 때 이러한 실질적인 결과가 나타납니다.
정책과 폐기가 자격 증명 오용을 제한합니다
대상 허용 목록, 메서드 제한, 리소스 식별자, 사용자 승인, 속도 제한, 대상 사용자 지정, 만료 및 일회용 토큰은 주입된 권한을 사용할 수 있는 방식을 제한합니다. 브로커는 프롬프트나 이미지를 다시 빌드하지 않고도 향후 발급을 폐기할 수 있습니다.
자격 증명 주입 경계에 대한 설명은 컨텍스트 창에 들어온 모든 비밀이 노출될 수 있으므로 자격 증명 처리를 에이전트 외부에 두어야 한다고 주장합니다. 이 패턴은 제어된 인증 호출을 유지하면서 정보 공개 위험을 줄입니다. 이 종속성은 최종 인터페이스에서 명시적으로 유지해야 합니다.
실패가 발생하는 경계는 지나치게 광범위한 브로커 정책이나 에이전트가 임의로 선택한 요청에 서명하는 프록시입니다. 자격 증명을 숨겨도 프롬프트 인젝션을 받은 에이전트가 합법적인 권한을 오용하는 것을 막을 수 없으므로 요청의 의미와 부작용도 계속 검증해야 합니다.
신원부터 만료까지 하나의 자격 증명을 추적합니다
각 에이전트 도구에 대해 워크로드 신원, 요청 사용자, 대상, 허용된 작업, 리소스 범위, 승인 상태, 토큰 대상 사용자, 유효 기간, 주입 지점, 응답 마스킹, 감사 식별자, 폐기 경로 및 대체 동작을 문서화합니다. 따라서 결과를 원본 증거와 대조해야 합니다.
에이전트 도구 권한과 이 제어 방식을 비교합니다. 비밀 요청, 환경 덤프, 리디렉션된 대상, 만료 후 재생, 확장된 리소스 ID, 오류 로깅, 도구 재시도 및 침해된 샌드박스 프로세스를 대상으로 프롬프트 요청을 테스트합니다. 이러한 차이는 이후 가정 환경 테스트에서도 확인할 수 있습니다.
원시 자격 증명이 모델에 표시되는 데이터에 절대 들어가지 않고, 승인되지 않은 요청 변형이 브로커 또는 프록시에서 실패할 때만 통과시킵니다. 토큰은 단기간 유효하게 유지하고, 정책은 작업별로 지정하며, 로그는 마스킹하고, 되돌릴 수 없는 작업은 독립적으로 연결된 승인을 거치게 합니다. 자동화가 진행되기 전에 중간 결과를 계속 검사할 수 있어야 합니다.
기술 및 AI 허브
더 읽어보기

임베딩 드리프트란 무엇이며, 프라이빗 검색 인덱스를 언제 다시 구축해야 할까요?
모델, 전처리, 코퍼스 및 쿼리 드리프트를 해석하고, 모니터링과 비호환성을 구분하며, 프라이빗 인덱스를 언제 재구축해야 하는지 판단하세요.

토크나이저 호환성이란 무엇이며, 모델 전환을 중단시킬 수 있는 이유는 무엇인가요?
로컬 모델 전환을 위한 어휘 식별자, 특수 토큰 의미, 채팅 템플릿, 캐시된 토큰, 어댑터 및 호환성 검사를 해독합니다.

모델 상주성이란 무엇이며, 로컬 AI 서비스는 언제 가중치를 로드된 상태로 유지해야 할까요?
가중치 상주, 캐시 수준, 콜드 스타트, 축출, 멀티플렉싱, 메모리 압박, 그리고 홈 AI 서비스를 웜 상태로 유지해야 하는 시점을 설명합니다.

