AI 에이전트에게 일급 시민으로서의 정체성(First-Class Identities)이 필요한 이유

보통은 무해하게 시작됩니다. 한 팀이 운영 리드(ops lead)의 OAuth 토큰을 사용하여 새로운 지원 에이전트를 공유 편지함에 연결합니다. 모두가 접근할 수 있는 계정이었기 때문입니다. 몇 달 동안은 아주 잘 작동합니다. 그러다 운영 리드가 직무를 변경하고, IT 부서가 액세스 검토 과정에서 그녀의 계정을 비활성화하면, 금요일 밤에 에이전트가 작동을 멈춥니다. 그 편지함에 있는 4,000개의 메시지 중 어떤 것이 사람이 보낸 것이고 어떤 것이 봇이 보낸 것인지에 대한 명확한 기록도 함께 사라집니다. 정확히 누구도 잘못한 것은 없습니다. 에이전트가 자신만의 정체성(identity)을 갖지 못했기에, 다른 사람의 정체성과 함께 사라졌을 뿐입니다.

저는 이러한 실패 모드가 향후 몇 년간의 에이전트 인프라를 정의하게 될 것이라고 생각하며, 그 해결책은 개념적으로는 오래된 것입니다. 서비스들이 엔지니어의 로그인 정보로 실행되는 대신 서비스 계정(service accounts)을 갖게 된 것과 마찬가지로, 에이전트에게도 일급 시민으로서의 정체성(first-class identities)이 필요합니다.

빌려온 자격 증명은 범주 오류(category error)입니다

에이전트가 인간의 자격 증명(credentials)을 통해 작동할 때, 세 가지 속성이 동시에 무너집니다.

주소 지정 가능성 (Addressability). 아무도 에이전트에게 도달할 수 없습니다. '에이전트의' 메시지에 대한 답장은 해당 인간의 실제 메일과 섞여 그 사람의 편지함으로 들어갑니다. 다른 시스템들 — 그리고 점점 더 많아지는 다른 에이전트들 — 은 에이전트의 주소를 알 수 없습니다.

책임 추적성 (Accountability). 에이전트가 취하는 모든 행동은 그 행동을 하지 않은 사람의 탓으로 돌려집니다. 문제가 발생했을 때, 감사 추적(audit trail)에는 _Karen이 이것을 보냈다_라고 기록되며, Karen은 자신이 하지 않았음을 증명해야 합니다.

폭발 반경 (Blast radius). 에이전트는 인간이 할 수 있는 모든 것을 상속받습니다. 후속 이메일을 보내야 하는 에이전트가 연봉 협상 스레드까지 읽을 수 있는데, 이는 토큰이 그 차이를 구분하지 못하기 때문입니다. 에이전트를 위한 보안 가이드라인은 이와 관련된 위험에 대해 직설적으로 경고합니다. 이메일과 연결된 에이전트는 프롬프트 인젝션(prompt injection) — 모델이 따를 수 있는 메시지 본문에 숨겨진 지시 사항 — 에 직면합니다. 빌려온 정체성을 대상으로 한 인젝션은 한 개인의 계정 전체를 노출시키지만, 범위가 제한된 전용 정체성을 대상으로 한 인젝션은 해당 정체성의 편지함 외에는 아무것도 노출시키지 않습니다.

이 모든 것은 가설적인 창의성이 아닙니다. 이는 서비스 계정(service accounts), CI의 로봇 사용자(robot users), 그리고 서비스별 API 키(per-service API keys)를 탄생시킨 것과 동일한 논리입니다. 단지 우리가 아직 에이전트(agents)에게 이를 일관되게 적용하지 않았을 뿐입니다.

일급 에이전트 정체성(first-class agent identity)의 모습

구체적으로, 이는 Agent Accounts 문서가 정의하는 방식처럼 도달 가능하고(reachable), 지속적이며(persistent), 책임 소재가 명확한(accountable) 정체성입니다. 즉, 에이전트를 조직 내의 다른 사용자 중 하나로 생각하는 것입니다. 이는 다음을 의미합니다:

• 자체적인 주소. 필터가 적용된 인간의 편지함이 아닌, support-agent@yourcompany.com과 같은 고유 주소를 가집니다.
• 자체적인 데이터 경계(data boundary). 모든 API 호출은 에이전트에게 부여된 권한(grant) 범위 내로 제한됩니다. 에이전트는 오직 자신에게 속한 데이터만 다룰 수 있습니다.
• 자체적인 감사 추적(audit trail). 에이전트의 보낸 편지함(sent folder) 자체가 에이전트가 수행한 작업의 로그(log)가 됩니다. 웹훅(Webhooks)은 에이전트 자체의 로깅(logging)과는 독립적으로, 모든 전송 및 변경 사항에 대한 서버 측 기록을 제공합니다. 이는 매우 중요한데, 인젝션(injection)에 의해 침해된 에이전트는 자신에 대해 정직하게 로그를 남길 것이라고 신뢰할 수 없기 때문입니다.
• 자체적인 제한 사항. 특정 개인이 아닌 에이전트에게 적용되는 할당량(quota)입니다. 이 아이디어의 호스팅 버전(Agent Accounts, 현재 베타 버전)에서는 무료 플랜 기준 계정당 하루 200개의 메시지 전송 제한과 30일간의 편지함 보관 정책이 적용되며, 정책을 통해 계정별로 더 엄격한 제한을 설정할 수 있습니다. 제어되지 않는 루프(runaway loop)가 발생하더라도 인간의 평판이 아닌 에이전트의 한도에 걸리게 됩니다.

정체성을 프로비저닝(Provisioning)하는 것은 단 한 번의 API 호출로 가능하며, 이 점 자체가 논거의 일부입니다. 이처럼 저렴한 비용의 정체성은 기존 방식을 빌려 쓰는 것에 대한 주요 변명을 제거합니다:

curl --request POST \
  --url "https://api.us.nylas.com/v3/connect/custom" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
...

반론에 대한 진지한 검토

"내 에이전트는 사용자를 대신해 행동한다 — 그러므로 사용자의 정체성(identity)을 사용해야 한다." 때로는 맞는 말입니다! 당신의 목소리로, 당신의 편지함에서, 당신의 관계망을 통해 답장 초안을 작성하는 어시스턴트는 진정으로 당신을 대신해 행동하는 것이며, 위임된 OAuth 권한 부여(grant)는 이를 위한 정직한 모델입니다. 여기서 구분할 가치가 있는 차이점은 다음과 같습니다: 에이전트가 사람으로서 행동하는가, 아니면 자기 자신으로서 행동하는가? 편지함을 요약하는 것은 전자에 해당합니다. 고객 지원 대기열(support queue)을 운영하는 것은 후자에 해당합니다. 대부분의 팀은 현재 두 경우 모두에 위임된 정체성(delegated identity)을 사용하고 있으며, 문제가 발생하는 지점은 바로 두 번째 범주입니다.

"정체성이 많아질수록 관리 오버헤드(management overhead)가 늘어난다." 맞습니다. 프로비저닝(provision)해야 할 계정, 교체(rotate)해야 할 자격 증명(credentials), 관리해야 할 생명 주기(lifecycle)가 늘어납니다. 하지만 오버헤드는 어떤 방식이든 존재합니다. 빌려온 자격 증명은 오프보딩(offboarding) 이벤트가 발생하여 폭발할 때까지 그 오버헤드를 숨기고 있을 뿐입니다. 에이전트의 정체성을 명시적으로 관리하면, 이는 일반적인 인프라가 됩니다: 배포 시 프로비저닝하고, 폐기 시 제거하면 됩니다.

"범위 제한 권한(Scoped permissions)이 별도의 정체성 없이도 이 문제를 해결한다." 범위 제한(Scoping)은 큰 도움이 됩니다. 인간의 검토를 위해 답장 초안만 작성하는 에이전트에게는 전송 권한이 전혀 필요 없으며, 작업에 맞춰 도구(tools)를 반드시 축소해야 합니다. 하지만 인간의 토큰(token)에 범위를 제한하더라도 귀속(attribution)과 주소 지정 가능성(addressability) 문제는 여전히 해결되지 않은 채 남습니다. 폭발 반경(blast radius)은 줄였을지 모르지만, 모든 작업에 여전히 잘못된 이름이 붙어 있는 상태인 것입니다.

"정체성(Identity)이 프롬프트 인젝션(Prompt Injection)을 막지 못한다면, 대체 무슨 의미가 있나요?" 맞습니다. 그리고 이 점을 정확히 짚고 넘어가는 것이 중요합니다. 전용 정체성을 부여한다고 해서 에이전트가 악의적인 지침을 읽는 것 자체를 방지할 수는 없습니다. 인젝션 방어 기제는 이와 별개의 영역(orthogonal)입니다. 모든 메시지 본문과 캘린더 설명을 신뢰할 수 없는 입력값으로 취급해야 하며(이벤트 설명에서도 흰색 글자 트릭이 통합니다), 모델에 도달하기 전에 숨겨진 HTML을 제거하고, 명시적인 확인 절차를 거친 후에만 전송되도록 제한해야 합니다. 보안 문서에서는 바로 이 점을 위해 2단계 전송 확인 기능이 존재하며, 이를 우회해서는 안 된다고 강조합니다. 정체성이 변화시키는 것은 방어 실패 시의 *경계(bound)*입니다. 모든 완화 조치 목록은 결국 한 번은 뚫리기 마련입니다. 방어벽이 뚫렸을 때, "에이전트 자신의 편지함"은 복구 가능한 사고(recoverable incident)이지만, "CFO의 편지함"은 정보 유출(disclosure)입니다. 예방(Prevention)과 봉쇄(Containment)는 서로 다른 계층이며, 두 가지 모두가 필요합니다.

"사람들이 봇의 이메일 주소에 속지 않을까요?" 기만적인 이름을 붙인다면 속을 것입니다. scheduling-agent@와 같은 이름은, 직원의 주소를 도용하여 조용히 발송되는 봇의 이메일보다 훨씬 더 정직합니다. 후자가 바로 우리가 방어하고자 하는 현재의 상태(status quo)입니다.

한 단계 더 높은 수준에서 발생하는, '빌려 쓰기(borrowing)' 문제의 또 다른 조용한 버전이 있습니다. 바로 API 키입니다. 플랫폼 키는 연결된 모든 계정에 대한 접근 권한을 부여하며, 보안 가이드라인에서는 이를 데이터베이스의 루트 비밀번호(root password)처럼 취급하라고 권고합니다. 환경 변수(environment variables)나 비밀 관리자(secrets manager)를 사용해야 하며, 코드에 직접 넣거나, 로그에 남거나, 캐싱되거나, 모델로부터 유도(coax out)될 수 있는 시스템 프롬프트(system prompt) 또는 규칙 파일(rules file)에 절대 포함해서는 안 됩니다. 에이전트 정체성은 하나의 행위자(actor)가 무엇을 건드릴 수 있는지 범위를 지정(scope)하며, 키 위생(key hygiene)은 그 범위 지정이 의미가 있는지 여부를 결정합니다.

방향성 있는 베팅 (The directional bet)

에이전트(Agents)는 단순한 스크립트(scripts)를 넘어 장기적으로 함께 일하는 동료가 되어가고 있습니다. 이들은 며칠간 대화를 이어가고, 회의에 참석하며, 상급자에게 보고(escalated)되기도 합니다. 자신만의 정체성(identity)이 없는 장기 생존 액터(Long-lived actors)는 보안적 측면과 조직적 측면 모두에서 회계상의 구멍(accounting hole)과 같습니다. 정체성은 또한 우리가 다음에 원하는 모든 것의 전제 조건입니다. 즉, 에이전트별 권한(per-agent permissions), 에이전트별 평판(per-agent reputations), 그리고 타인을 사칭하지 않는 에이전트 간 통신(agent-to-agent communication) 등이 이에 해당합니다.

따라서 이번 주에 수행할 가치가 있는 감사는 다음과 같습니다: 이메일이나 캘린더를 사용하는 현재 실행 중인 모든 에이전트 또는 자동화(automation) 목록을 작성하고, 각각의 에이전트가 실제로 누구의 자격 증명(credentials)을 보유하고 있는지 기록하십시오. 만약 그 답변 중 하나라도 "봇의 알리바이(alibi)가 되기로 동의하지 않은 사람"이라면, 그 에이전트가 가장 먼저 마이그레이션(migrate)해야 할 대상입니다. 현재 당신의 에이전트는 누구의 이름을 빌려 쓰고 있습니까?