0. 통제 관점 한줄 정리
Discovery - “내 에이전트가 어디에 있나”
•
AI Agent Registry: Self-built / 로컬 AI 도구 등록
•
AI Agent Import: Agent builder(Agentforce/AWS Bedrock/MS Entra)
•
Shadow AI Agent Discovery: 브라우저 확장 + OAuth consent grant 모니터링으로 미등록 에이전트 발견
Onboard/Identity - 신원 부여
•
first-class identity: UD에 에이전트를 정식 신원으로 등록
•
Owner = 누가 책임지나 + 켤 수 있나(게이트)
•
Credentials = 에이전트가 스스로를 증명하는 열쇠
•
User sign-on = 사용자가 에이전트에게 권한을 빌려줌
•
Resoucre Connections = 에이전트가 무엇에 접근할 자격을 Okta로부터 받을지
→ 공통적으로 “자격은 Okta가 발급/검증, 에이전트는 요청만” 구조를 구성
1. Okta가 관리하지 않는 것
•
Okta에서 AI Agent를 Deactivate(kill switch)하면 에이전트가 토큰/시크릿을 못 받아 아무것도 못하게 되지만, 그 프로세스가 로컬/클라우드에서 사라지는 건 아니다.
•
Okta는 “열쇠를 회수”해서 무력화하는 거지, 실행 중인 코드를 삭제하진 않는다.
대상 | 누가 관리하나 |
에이전트 코드/모델/비즈니스 로직 | 개발자/빌더 플랫폼 |
에이전트 런타임/배포/프로세스(어디서 실행되나) | 로컬 호스트/AWS Bedrock AgentCore 등 |
에이전트 프로세스 자체를 죽이는 것 | 호스트/플랫폼 |
2. 에이전트 수동 등록
2-1. 에이전트 수동 등록
경로: Directory → AI Agents → Register AI agent
•
Import from AI agent providers(외부 빌더 플랫폼에서 만든 에이전트): Agentforce/Bedrock/Entra 등 third-party 플랫폼에서 이미 생성된 에이전트를 Okta로 동기화(sync) 해 중앙 가시성·통제 확보
•
Register manually(직접 만든 커스텀 에이전트): 사내 개발/자체 제작 에이전트를 Okta에 수동으로 신규 등록
•
Name: 에이전트 이름
•
Description(옵션): 에이전트에 대한 용도 설명
•
User sign-on application(옵션): 사용자가 에이전트에게 권한을 위임
◦
연결하는 OIDC 앱은 “사용자가 실제로 로그인하는 입구”가 된다. Agent 혼자서는 이 사용자가 어떤 사용자인지 알 수 없어서 OIDC 앱을 이용해서 ID Token을 통해 사용자의 맥락을 주입해주는 역할을 한다.
◦
이 앱에 로그인한 사용자는 에이전트에게 위임할 수 있다.
업무의 연속성을 위해 최소 2명 이상의 책임자를 지정해야함•
에이전트에 대한 책임소재(accountability) + 생애 주기 관리(비활성화/삭제 등) 책임자
•
owner가 에이전트의 리소스 접근 권한을 정하는 게 아님, 접근 권한은 Resource Connections가 담당.
•
Owners: 에이전트 거버넌스 책임자 설정
◦
Assign individual owners: 에이전트 거버넌스에 대한 책임자를 계정별로 선택
◦
Assign a group owner: 에이전트 거버넌스에 대한 책임자를 그룹으로 선택
에이전트를 생성하게 되면 Staged 상태로 등록이 완료됨
2-2. 자격증명 추가
•
Okta는 “요청하는 에이전트가 자기 개인키로 서명했는지”를 반드시 확인한다.
•
등록시 에이전트가 보관한 private key → 교환 요청 때, client_assertion을 서명하는데 씀
•
Okta는 저장해둔 public key로 그 서명을 검증
•
이전과 다른 핵심 변화
◦
예전엔 공유 정적 시크릿/API 키(유출/회전 취약) → 이제 비대칭 키 기반 신원
▪
private key가 에이전트 밖으로 안나감
▪
okta는 서명만 검증(공유 비밀 불필요)
▪
token exchange/XAA의 client assertion이 바로 이 개인키 서명
경로: 등록한 AI Agent 클릭 → Credentials → + Add public key
•
Private Key는 JSON/PEM 방식으로 복사 가능
2-3. AI Agent 활성화
Owner 없으면 활성화 불가, owner 지정 후 Activate 전환
2-4. AI Agent에 리소스 연결
•
에이전트가 리소스용 자격증명/토큰을 Okta로부터 받을 수 있게 허용 + 범위(Scope) 지정
•
런타임에 에이전트가 Resource Indicator로 Okta에 요청 → Okta가 허용 시 토큰/secret 발급 → 에이전트가 그것으로 리소스 호출
◦
Resource Indicator: 에이전트가 요청 시 쓰는 식별자. 실제 secret ID가 아니라 이 지시자를 참조 → secret 회전/교체해도 코드 수정 불필요
▪
토큰을 요청하는 순간에만 쓰임
3. 관리자 관점 변화
구분 | 기존 (등록 전) | 등록 + 활성화 후 |
가시성 | 콘솔에 안 보임.
에이전트 존재/개수/용도 파악 불가 | Directory > AI Agents 인벤토리에 등재, 추적 가능 |
책임 소재 | 누가 만들었고 책임지는지 불명확 | human owner(개인/그룹) 매핑 → accountability |
인증 방식 | .env의 정적 Dooray 토큰/API 키를 코드가 직접 보유 | JWK 기반 인증 + Okta 발급 단명(short-lived) 토큰.
정적 시크릿 제거 |
접근 범위 | 토큰 권한만큼 무제한, 통제 지점 없음 | 앱 연결/정책으로 최소 권한 적용, "무엇에 연결 가능"이 거버넌스 대상 |
운영 통제 | 끄려면 시크릿 폐기·코드 수정 | 콘솔에서 Deactivate(=kill switch) 한 번으로 즉시 차단 |
감사 | 에이전트 행위 추적 어려움 | audit log / telemetry, access review·certification 대상 |