참고문서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-1. 에이전트 수동 등록
경로: Directory → AI Agents → Register AI agent
•
Register manually(직접 만든 커스텀 에이전트): 사내 개발/자체 제작 에이전트를 Okta에 수동으로 신규 등록
•
Name: 에이전트 이름
•
Description(옵션): 에이전트에 대한 용도 설명
•
User access and authentication(옵션): 사용자의 엑세스 관리를 해당 앱을 통해 관리할 수 있습니다. 사용하지 않을 경우 Allow user to access this agent 토클을 해제하면 됩니다.
◦
Allow users to access this agent
▪
create a new OIDC app linked to this AI agent: 현재 AI Agent 이름과 동일한 이름으로 새로운 OIDC 앱을 생성하여 자동으로 해당 에이전트에 연결합니다.
▪
Select an existing app: 이미 등록되어 있는 OIDC 앱 중 하나를 선택하여 연결합니다.
업무의 연속성을 위해 최소 2명 이상의 책임자를 지정해야함•
에이전트에 대한 책임소재(accountability) + 생애 주기 관리(비활성화/삭제 등) 책임자
•
Owner가 에이전트의 리소스 접근 권한을 정하는 게 아님, 접근 권한은 Resource Connections가 담당.
•
Owners: 에이전트 거버넌스 책임자 설정
◦
Assign individual owners: 에이전트 거버넌스에 대한 책임자를 계정별로 선택
◦
Assign a group owner: 에이전트 거버넌스에 대한 책임자를 그룹으로 선택
에이전트를 생성하게 되면 Staged 상태로 등록이 완료됨
2-1-2. 에이전트 가져오기
•
Import from AI agent providers(외부 빌더 플랫폼에서 만든 에이전트): Agentforce/Bedrock/Entra 등 third-party 플랫폼에서 이미 생성된 에이전트를 Okta로 동기화(sync) 해 중앙 가시성·통제 확보
•
Okta에서 현재 지원하는 AI Agent Providers는 총 6가지로 추후 업데이트하여 지원하는 서비스들을 늘려나갈 예정입니다.
•
에이전트를 가져올 AI Agent Providers를 선택하며 +Add Integration을 클릭합니다.
•
AI Agent import 탭에서 Enable AI agent import 항목 활성화
•
항목 체크 후 Access key, Secret access key는 AWS 콘솔에서 설정해야하므로 AWS 콘솔 접속 및 로그인
•
AWS 관리 콘솔로 이동하여, Okta 연동 역할을 확인할 수 있는 IAM 사용자를 생성합니다.
•
생성한 IAM 사용자에 대한 권한은 Add permissions 또는 Create inline policy 로 부여할수 있으며, 본 테스트에서는 인라인 정책 생성을 통해 권한을 설정하겠습니다.
•
정책 이름 설정 후, 현재 적용된 정책이 무엇인지 확인 후 이상 없으면 Create policy 버튼 클릭
•
IAM 사용자 목록으로 돌아가 사용자를 클릭한 후 Security credentials 탭에서 access key를 생성합니다.
•
사용하려는 케이스를 선택한 후, Next 버튼을 클릭합니다.
•
Create access key 버튼 클릭합니다.
•
만든 액세스키와 비밀 액세스 키를 복사해서 메모장에 붙여놓습니다.
•
Access key, Secret access key, Platforms, AWS regions를 선택하고 Test API Credentials 버튼을 클릭합니다.
•
테스트가 문제 없이 진행됐다면 Verified 표시를 확인할 수 있습니다.
•
Assign AI Agent owners
◦
Assign individual owners: 개인 사용자 할당, 최대 5명의 사용자를 할당할 수 있으며 할당한 소유자가 오프보딩될 상황에 대비하여 최소 2명 할당 권장
◦
Assign group owner: 그룹을 할당, 그룹 인원도 그룹원이 오프보딩할 상황을 대비하여 최소 2명 필요
◦
Do not pre-assign an owner: Import 시 소유자를 자동으로 할당하지 않음
AI 에이전트 관리 시 소유자를 수동으로 지정할 필요가 있는 환경에서 선택
•
Import schedule(옵션)
◦
Full import schedule: Weekly(주) 또는 Hourly(시간) 단위로 가져올 수 있음
◦
Do not schedule imports: 실제 운영 환경에서 설정을 권장하지 않지만 데모 환경에서는 선택
•
AI Agent import가 완료되면 Directory → AI Agent 으로 이동하면 Source Imported, AI Agent Provider AWS IAM Identity center로 확인할 수 있습니다.
AI Agent가 등록된 후, Managed status는 Staged 상태가 됩니다.
•
Staged: 활성화 대기 및 설정 이전 상태
•
Activate: Okta AI Agent 관리 상태 활성화
•
Deactivate: Okta AI Agent 관리 비활성화
AI Agent 소유자 설정: Owner → Edit 를 선택하면 Owner를 지정할 수 있습니다.
•
Assign individual owners: 특정 개인 계정을 소유자로 직접 지정
◦
최대 5명까지 사용자 지정 가능
◦
담당자가 퇴사/부서 이동을 하더라도 관리 공백이 생기지 않도록 최소 2명 이상 지정하는 것을 권장
•
Assign a group owner: 특정 부서나 팀(그룹 계정)을 통째로 소유자로 지정
◦
그룹은 딱 1개만 지정할 수 있음
◦
그룹 안에 속한 팀원 역시 퇴사/부서 이동을 대비하여 그룹에 최소 2명 이상 포함되어 있어야함
[Client Registration] 탭에서는 AI 에이전트가 서버에 접근하기 전, Okta를 통해 신원과 권한을 검증받을 수 있도록 연동 자격증명(ID-JAG 방식)을 생성합니다. 이를 통해 허가되지 않은 접근을 차단하고, Okta 보안 정책에 따라 안전하게 권한을 제어합니다.
•
Public/Private key 생성 후, Private key를 복사한 다음 “Done”을 클릭합니다.
[User access] 탭은 사용자를 대신하여 에이전트가 작업을 수행할 수 있도록 권한을 부여할 수 있는 사용자, 앱 및 AI Agent를 구성
•
Create a new OIDC app 선택 후 Save를 클릭하면 해당 AI 에이전트가 OIDC 프로토콜 방식으로 연동되어 Okta의 Applications 목록에 추가됨
[machine access] 탭은 AI Agent, 서비스 어카운트 등 비인간 신원이 AI Agent를 통해
연결된 리소스에 접근할 수 있도록 구성하는 항목
[Resource connections]탭은 AI Agent와 연동할 리소스(MCP 서버, 어플리케이션, AI Agent 등)을 등록하여 에이전트와 리소스 간 접근 통제 및 관리를 수행합니다.
해당 AI Agent와 연결할 리소스를 선택 후, Add 버튼을 클릭합니다.
2-2. 자격증명 추가
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 전환•
AI Agent 상태
◦
Stage: 활성화 대기 및 설정 이전 상태
◦
Activate: Okta AI Agent 관리 상태 활성화
◦
Deactivate: Okta AI Agent 관리 비활성화
AI Agent를 등록할때
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 대상 |