에이전트 이해: AI 에이전트와 사람 연결하기

핵심 요약

• KYA(Know Your Agent)는 에이전트 이름을 지정한다고 해결되지 않습니다. 영구적인 제어는 인증된 사람, 등록된 클라이언트, 부여된 범위, 조직 컨텍스트 및 각 결과 작업을 연결하는 위임 체인입니다.
• Didit의 호스팅된 MCP(Model Context Protocol) 엔드포인트는 19개 도메인에 걸쳐 115개 도구를 노출하며, PKCE(Proof Key for Code Exchange) 및 동적 클라이언트 등록이 적용된 Open Authorization(OAuth) 2.1을 사용합니다.
• MCP는 로그인한 Didit 사용자 역할을 합니다. 해당 사용자의 조직 역할을 상속하므로 연결된 에이전트는 해당 사람이 이미 가지고 있지 않은 권한을 얻을 수 없습니다.
• 구성 파일에 저장된 애플리케이션 키는 자격 증명 소유를 증명하지만, 특정 작업을 위임한 사람을 증명하지는 않습니다. 공유 키는 여러 운영자와 에이전트를 단일 애플리케이션 ID로 통합합니다.
• 책임에는 시행과 증거가 모두 필요합니다. 작업 전 범위 지정 토큰 및 역할 확인, 그리고 누가 무엇을 변경했는지 보여주는 감사 기록이 필요합니다.

Didit은 이미 이 메커니즘을 출시했습니다. 호스팅된 MCP 서버는 에이전트를 익명의 애플리케이션 비밀 소유자로 취급하는 대신, 로그인한 사용자를 통해 AI 클라이언트를 신원 및 사기 방지 작업에 연결합니다. 이 엔드포인트는 무료이며, 상태 비저장 Streamable HTTP를 사용하고 115개의 도구를 노출합니다. 이 구현은 공개 MIT 라이선스 GitHub 저장소에서도 사용할 수 있습니다.

이 아티팩트는 유용한 질문을 바꿉니다. KYA의 또 다른 정의를 묻는 대신, 에이전트가 검증 세션을 생성하거나, 결정을 읽거나, 작업 공간 데이터를 변경할 때 어떤 사람이 이를 승인했고, 그 사람이 무엇을 허용했으며, 어떤 조직이 그 작업을 수락했는지 무엇이 증명하는지 물어보십시오.

사람 연결은 위임 체인입니다

에이전트 이름, 모델 식별자, 공개 키 또는 소프트웨어 증명은 기계 행위자를 식별하는 데 도움이 될 수 있습니다. 하지만 그 어느 것도 에이전트가 수행하는 작업에 대해 누가 책임이 있는지 단독으로 확립하지 못합니다. 사람 연결에는 별개의 링크가 있는 체인이 필요합니다.

• 주체: 에이전트가 대신하여 행동하는 인증된 사용자 또는 서비스 소유자.
• 클라이언트: 액세스를 요청한 AI 애플리케이션.
• 위임: 해당 클라이언트에 부여된 범위 및 동의.
• 권한 부여 컨텍스트: 요청에 적용된 조직 역할 및 애플리케이션 경계.
• 증거: 작업 및 결과에 대한 검토 가능한 기록.

각 링크는 다른 질문에 답합니다. 인증은 누가 로그인했는지 알려줍니다. OAuth는 어떤 클라이언트가 위임된 액세스를 받았는지 알려줍니다. 범위는 어떤 종류의 작업이 승인되었는지 알려줍니다. 역할은 사용자가 조직 내에서 무엇을 할 수 있는지 알려줍니다. 감사 기록은 실제로 무엇이 일어났는지 알려줍니다. 이러한 제어들을 단일 "검증된 에이전트" 배지로 통합하면 가장 중요한 부분, 즉 권한은 상황에 따라 달라지고 취소될 수 있다는 사실을 숨깁니다.

신뢰할 수 있는 에이전트는 단순히 식별 가능한 것 이상입니다. 책임 있는 주체로부터 특정 허용된 작업에 이르는 끊어지지 않는 경로를 보여줄 수 있어야 합니다.

구성 파일의 키가 책임성 테스트에 실패하는 이유

애플리케이션 API 키는 제어된 서버 간 통합에 적합할 수 있습니다. 하지만 그 자체로 사람-에이전트 연결 메커니즘은 아닙니다. 복사된 키는 일반적으로 한 가지 질문에 답합니다. "이 호출자가 이 애플리케이션에 허용된 자격 증명을 소유하고 있는가?" 누가 에이전트를 시작했는지, 누가 현재 작업을 승인했는지, 또는 동일한 키를 사용하는 두 번의 호출이 다른 사람에게서 왔는지 여부는 답하지 않습니다.

실패 모드는 예측 가능합니다. 팀은 로컬 환경에서 키를 공유합니다. 에이전트 프로세스는 구성 파일에서 이를 상속합니다. 두 번째 에이전트가 복사본을 받습니다. 그러면 로그는 모든 호출을 동일한 애플리케이션 자격 증명에 귀속시킵니다. 해당 자격 증명을 취소하면 이를 사용하는 모든 작업이 중단되지만, 개별 위임 이벤트는 불분명하게 남습니다.

Didit은 호스팅된 MCP 엔드포인트에 대해 의도적으로 애플리케이션 키 경로를 제공하지 않습니다. 백엔드 통합은 Didit의 REST API를 애플리케이션 자격 증명과 함께 계속 사용할 수 있지만, 원격 MCP 액세스에는 사용자 OAuth 흐름이 필요합니다. 이러한 분리는 중요합니다. REST 자격 증명은 애플리케이션 통합을 나타내고, MCP 토큰은 로그인한 사용자로부터 위임된 액세스를 나타냅니다.

OAuth 2.1, PKCE 및 동적 클라이언트 등록

OAuth는 이 설계에서 위임 기본 요소입니다. 이 흐름은 사용자의 암호를 에이전트에 넘겨주지 않으며, MCP 구성에 재사용 가능한 플랫폼 비밀을 배치하지 않습니다. 대신, AI 클라이언트는 사용자가 Didit으로 인증하고 액세스를 승인한 후 제한된 액세스 토큰을 얻습니다.

1. 클라이언트 등록

동적 클라이언트 등록을 통해 호환되는 MCP 클라이언트는 수동으로 미리 프로비저닝된 클라이언트 식별자 없이 Didit 권한 부여 서버에 등록할 수 있습니다. 이는 권한 부여 서버에 액세스를 발급할 수 있는 별개의 클라이언트 등록을 제공합니다. 등록은 OAuth 클라이언트를 식별하지만, 클라이언트의 소프트웨어가 신뢰할 수 있다는 것을 그 자체로 인증하지는 않습니다.

2. 권한 부여 응답을 클라이언트에 바인딩

PKCE는 권한 부여 시도에 대해 일회성 검증자 및 챌린지를 생성합니다. 흐름을 시작하는 클라이언트는 권한 부여 코드를 교환할 때 검증자를 제시해야 합니다. 이는 가로채진 코드의 가치를 제한합니다. 다른 프로세스가 검증자 없이 이를 사용할 수 없기 때문입니다.

3. 인증 및 동의

사용자는 권한 부여 서버 역할을 하는 Didit 비즈니스 콘솔에 로그인하고 요청된 범위를 승인합니다. Didit은 검증 작업에 대해 didit:verification을, 작업 공간 관리에 대해 didit:management를 광고합니다. 클라이언트는 작업에 필요한 범위만 요청해야 합니다.

4. 모든 호출 유효성 검사

호스팅된 MCP 리소스 서버는 도구 호출을 디스패치하기 전에 베어러 토큰의 유효성을 검사합니다. 유효성이 검사된 사용자 토큰 및 조직 컨텍스트는 요청과 함께 Didit으로 전송됩니다. 다운스트림 서비스는 해당 사용자의 기존 역할 및 권한을 평가합니다. 그 결과는 에이전트를 위해 생성된 새로운 슈퍼유저 ID가 아니라 사용자 역할의 의미론입니다.

MCP 인증 가이드는 흐름을 문서화하고, MCP 개요는 호스팅된 엔드포인트 및 클라이언트 모델을 설명합니다.

사용자 역할은 권한을 명확하게 만듭니다

규정 준수 운영자가 AI 클라이언트를 Didit에 연결한다고 가정해 봅시다. 클라이언트는 먼저 didit_context_get을 호출하여 로그인한 사용자가 액세스할 수 있는 조직 및 애플리케이션을 반환합니다. 사용자가 명확한 조직 및 애플리케이션을 하나만 가지고 있는 경우 컨텍스트는 자동으로 해결될 수 있습니다. 여러 개가 사용 가능한 경우, 작업은 명시적인 조직 및 애플리케이션으로 좁혀질 수 있습니다.

그런 다음 에이전트는 didit_session_create를 호출하여 검증 세션을 생성하고 didit_session_get_decision을 호출하여 결과를 검색할 수 있습니다. 이는 현재 MCP 카탈로그의 실제 도메인 우선 도구 이름입니다. 필요한 권한이 없는 사용자는 에이전트를 연결한다고 해서 권한을 얻지 못합니다. 동일한 조직 권한 부여 경계가 여전히 적용됩니다.

이는 공유 애플리케이션 자격 증명과의 핵심적인 차이점입니다. OAuth 모델에서는 요청이 선언된 범위를 가진 등록된 클라이언트를 통해 작동하는 알려진 사용자로 도착합니다. 공유 키 모델에서는 다운스트림 시스템이 애플리케이션 자격 증명을 보지만, 특정 호출 뒤의 사람과 에이전트는 별도의 제어 평면이 해당 컨텍스트를 제공하지 않는 한 구별할 수 없습니다.

감사 가능성: "누가 행동할 수 있는가?"에서 "누가 무엇을 했는가?"로

권한 부여는 범위를 벗어난 작업을 방지합니다. 감사 가능성은 작업이 발생한 후에 이를 설명합니다. Didit은 didit_audit_log_list를 노출하여 권한 있는 사용자가 누가 무엇을 변경했는지 설명하는 애플리케이션 감사 항목을 검사할 수 있도록 합니다. 각 호스팅된 MCP 요청은 로그인한 사용자의 베어러 토큰과 해결된 조직 컨텍스트를 전달하므로, 해당 작업은 익명의 에이전트 프로세스가 아닌 해당 호출자에게 귀속될 수 있습니다.

완전한 포렌식 기록은 에이전트 측 증거도 보존해야 합니다. 영향력이 큰 워크플로의 경우 에이전트 실행 식별자, 클라이언트 등록, 요청된 범위, 대상 조직 및 애플리케이션, 도구 이름, 타임스탬프, 승인 상태, 입력 및 출력의 안전한 표현을 기록하십시오. 액세스 토큰 또는 민감한 신원 페이로드를 기록하지 마십시오. 플랫폼 감사 추적과 에이전트 실행 로그는 비밀 또는 규제된 개인 데이터를 중복하지 않고 상호 연관될 수 있어야 합니다.

귀속은 부인 방지와 동일하지 않으며, 감사 로그는 최소 권한의 대체물이 아닙니다. 제어는 서로를 강화합니다.

• 영구적인 공유 자격 증명 대신 단기 액세스 및 제어된 새로 고침을 사용합니다.
• 가장 좁은 OAuth 범위와 가장 적은 권한의 조직 역할을 부여합니다.
• 파괴적이거나 비정상적으로 영향력이 큰 작업에 대해서는 사람의 확인을 요구합니다.
• 두 개 이상의 대상이 사용 가능한 경우 조직 및 애플리케이션 컨텍스트를 명시적으로 유지합니다.
• 위임이 종료되어야 할 때 사용자 세션 또는 클라이언트 부여를 취소합니다.
• 예상치 못한 행위자, 도구, 대상 또는 타이밍에 대한 감사 기록을 모니터링합니다.

연결이 증명하는 것과 증명하지 않는 것

이 패턴은 인증된 Didit 계정이 OAuth 클라이언트에 범위 지정 액세스를 위임했으며, 각 요청이 해당 사용자의 조직 권한으로 평가된다는 것을 증명합니다. 이는 계정에 대한 실질적인 책임과 플랫폼 작업에 대한 검토 가능한 체인을 생성합니다.

이는 계정 소유자가 검증된 민간 신원을 가지고 있거나, 승인된 클라이언트 바이너리가 수정되지 않았거나, 사람이 모든 단계를 적극적으로 지켜보고 있다는 것을 자동으로 증명하지 않습니다. 이는 추가적인 보증을 필요로 합니다. 법적 신원 보증이 필요한 경우, KYC(Know Your Customer) 제어를 통해 온보딩 중에 주체를 검증하고 그 결과를 계정에 연결하십시오. 소프트웨어 출처가 중요한 경우 클라이언트 증명 및 서명된 릴리스를 추가하십시오. 존재가 중요한 경우 민감한 작업 시 단계별 승인을 요구하십시오.

이 계층화된 관점은 KYA를 정직하게 유지합니다. 에이전트 신원, 사람 신원, 위임된 권한 부여, 런타임 정책 및 감사 증거는 상호 관련 제어이며, 상호 교환 가능한 레이블이 아닙니다.

검토할 수 있는 구현 예시

Didit의 구현은 동일한 책임 경계를 설계하는 팀을 위한 구체적인 참조를 제공합니다. 호스팅된 서버는 로그인한 Didit 사용자로 인증하고, 해당 사용자의 조직 역할을 상속하며, 해당 신원을 모든 도구 호출에 적용합니다. 115개의 호스팅된 도구는 컨텍스트 및 검증 세션부터 워크플로, 조직, 분석 및 감사 로그에 이르기까지 19개 도메인에 걸쳐 있습니다. 현재 도구 카탈로그는 정확한 표면을 나열합니다.

제품 컨텍스트의 경우, 전체 KYC 번들은 0.33달러이며 ID 확인, 수동 생체 인식, 얼굴 일치 및 IP 분석을 결합합니다. Didit은 월 500회 무료 확인을 포함하며, 2,000개 이상의 기업이 프로덕션에서 사용합니다. MCP 서버 자체는 무료이므로 팀은 별도의 커넥터 수수료 없이 위임 및 권한 모델을 평가할 수 있습니다.

이 메커니즘이 더 넓은 에이전트 워크플로에 어떻게 적용되는지 보려면 AI 에이전트용 신원 및 사기 MCP 작동 방식과 Didit MCP 도구 참조를 읽어보십시오.

작업을 신뢰하기 전에 에이전트를 연결하세요

에이전트 신원의 어려운 문제는 소프트웨어에 대한 영구적인 이름을 발명하는 것이 아닙니다. 소프트웨어가 인터페이스를 넘나들며 기계 속도로 작동할 때 사람의 책임성을 보존하는 것입니다. OAuth 2.1은 위임된 액세스를 제공합니다. PKCE는 권한 부여 교환을 보호합니다. 동적 클라이언트 등록은 연결 클라이언트를 식별합니다. 범위와 조직 역할은 권한을 제한합니다. 감사 기록은 결과를 검토 가능하게 만듭니다.

Didit MCP 저장소에서 아키텍처를 검토하거나, 인증 문서를 검토하거나, Didit을 Claude에 연결할 수 있습니다. 유용한 테스트는 간단합니다. 제안된 에이전트 작업에 대해 책임 있는 사용자, 클라이언트, 부여된 범위, 조직 경계 및 결과 감사 증거를 식별할 수 있습니까? 어떤 링크라도 누락되면 에이전트는 완전히 연결되지 않은 것입니다.