Speedle AI · 패턴

AI 구축 및 실행을 위한 정책 패턴

AI 시스템이 데이터, 모델, 도구 및 다른 에이전트와 상호 작용하는 모든 위치에 Speedle 정책 엔진을 적용합니다. 모델 제공 전의 빌드 단계와 모델이 제공되고 동작하는 실행 단계 모두에 해당합니다. 이는 솔루션 패턴이며 특정 ML 또는 에이전트 플랫폼과의 완성형 연동 기능이 아닙니다.

아래의 각 SPDL 예제는 Speedle 파일 저장소를 사용하여 파싱되고 허용 및 거부 케이스에 대해 평가되었습니다. 이름, 경로 및 속성은 예시용입니다. 결정을 요청할 때 애플리케이션 측에서 속성을 전달해야 합니다. 정책 집행 포인트는 조건이 참조하는 모든 속성을 전달해야 합니다.

구축

모델 서비스 전: 데이터, 훈련 및 릴리스

01 / 데이터 및 훈련

어떤 파이프라인이 어떤 데이터로 훈련할 수 있는가

훈련 작업은 데이터셋을 읽고, 컴퓨팅을 사용하며, 체크포인트를 저장합니다. 애플리케이션은 각 데이터셋 읽기, 작업 시작 및 체크포인트 내보내기 전에 민감도, 테넌트, 동의 및 리전을 속성으로 전달하여 확인합니다.

주체
엔티티로서의 훈련 파이프라인, ML 엔지니어 및 팀.
리소스 및 액션
데이터셋: read. 훈련 작업: start. 체크포인트: export.
집행 포인트
데이터셋을 열기 전의 데이터 로더, 컴퓨팅을 할당하기 전의 작업 스케줄러 및 내보내기 전의 아티팩트 저장소.
training.spdlSPDL 예제
[service.ml-training]
[policy]
# Pipelines read only consented data from their own region
grant role training-pipeline read expr:^/datasets/ if consent == true && data_region == job_region
# Restricted datasets never enter training
deny role training-pipeline read expr:^/datasets/restricted/
grant role ml-engineer start /jobs/training if gpu_hours <= 64
grant role ml-engineer export expr:^/checkpoints/
[rolepolicy]
grant entity pipeline-churn training-pipeline
grant group ml-team ml-engineer

데이터셋별 동의 및 리전 확인, 제한된 데이터에 대한 직접 거부, 작업 시작 시 GPU 시간 제한 적용.

02 / 모델 릴리스

누가 모델을 릴리스할 수 있는가

모델 등록, 승인, 프로모션 및 롤백은 각기 다른 담당자가 수행하는 독립된 액션입니다. 직무 분리를 통해 모델을 훈련한 사람이 해당 모델을 승인하지 못하도록 방지합니다.

주체
ML 엔지니어, 릴리스 관리자 및 릴리스 파이프라인의 서비스 신원.
리소스 및 액션
모델 및 엔드포인트: register, approve, promote, rollback.
집행 포인트
모델 레지스트리 및 릴리스 파이프라인. 모델 또는 엔드포인트 상태 변경 전.
release.spdlSPDL 예제
[service.model-registry]
[policy]
grant role ml-engineer register expr:^/models/
grant role release-manager approve, promote, rollback expr:^/models/
# Separation of duties: nobody approves a model they trained
deny role release-manager approve expr:^/models/ if trained_by == request_user
[rolepolicy]
grant group ml-team ml-engineer
grant user dana release-manager

엔지니어는 등록할 수 있지만 프로모션할 수 없으며, 릴리스 관리자는 trained_by가 요청 사용자인 모델을 승인할 수 없습니다.

실행

AI 서비스 및 동작 중: 검색, 에이전트, 도구 및 타 에이전트

03 / 추론 및 RAG

사용자가 읽을 수 있는 콘텐츠만 프롬프트에 포함

사용자, 앱 및 테넌트가 모델을 호출합니다. 권한 인식 RAG의 경우, 검색기(retriever)는 각 문서나 컬렉션의 내용이 프롬프트에 들어가기 전에 Speedle에 확인하여, 요청 주체가 읽을 수 있는 권한이 있는 콘텐츠만 모델에 전달되도록 합니다.

  1. 1검색기가 후보 문서를 찾습니다.
  2. 2사용자의 테넌트 및 인가 등급과 함께 Speedle에 문서 또는 컬렉션별로 확인합니다.
  3. 3허용된 콘텐츠만 프롬프트에 전달됩니다.
주체
요청을 보낸 사용자와 해당 그룹. 엔티티로서의 클라이언트 애플리케이션 및 테넌트.
리소스 및 액션
컬렉션 및 문서: retrieve. 모델: invoke.
집행 포인트
문서가 프롬프트에 들어가기 전의 검색기, 요청을 라우팅하기 전의 API 게이트웨이 또는 추론 서비스.
rag.spdlSPDL 예제
[service.rag]
[policy]
# The retriever asks per document, before its content enters the prompt
grant role tenant-user retrieve expr:^/collections/ if doc_tenant == user_tenant && doc_label in user_clearances
# Documents on legal hold never reach a prompt
deny role tenant-user retrieve expr:^/collections/legal-hold/
# Apps call only the model tiers in their tenant's plan
grant role tenant-app invoke expr:^/models/ if model_tier in plan_tiers
[rolepolicy]
grant group acme-staff tenant-user
grant entity acme-helpdesk tenant-app

문서는 사용자의 테넌트 내부이고 사용자가 인가된 레이블인 경우에만 검색됩니다. 법적 보존 문서는 거부되며, 앱은 요금제에 포함된 모델 등급만 호출할 수 있습니다.

04 / 사용자를 대리하는 에이전트

AI 에이전트는 사용자를 대신하여 무엇을 할 수 있는가

에이전트는 고유한 신원을 가지며, 사용자의 위임은 요청의 단순 주장이 아닌 서명된 위임 토큰으로 입증됩니다. 집행 포인트는 토큰을 검증한 후 Speedle에 두 번 확인하고 둘 다 통과할 때만 허용합니다: 토큰 범위 내의 에이전트, 그리고 현재 시점의 위임 사용자 권한. 토큰 발급 후 사용자가 권한을 잃으면 에이전트는 다음 요청에서 즉시 권한을 잃습니다. 100을 초과하는 환불은 사용자가 아닌 제3자의 서명된 승인 기록도 필요합니다.

  1. 1토큰 검증: 서명, 발급자, 만료 시간 및 이 에이전트에게 발급되었는지 확인.
  2. 2에이전트 범위: 에이전트를 주체로, 토큰 범위를 속성으로 Speedle에 확인.
  3. 3현재 위임자: 토큰의 sub 클레임에 명시된 위임 사용자를 주체로 Speedle에 확인.
주체
범위 확인을 위한 엔티티로서의 에이전트. 두 번째 확인을 위해 검증된 토큰에서 가져온 위임 사용자.
리소스 및 액션
티켓: read, update. 주문: refund(금액을 속성으로 전달). 모두 토큰 범위 내의 액션과 리소스로 제한.
집행 포인트
액션이 비즈니스 시스템에 도달하기 전의 에이전트 런타임 또는 백엔드. 토큰을 검증하고 검증된 클레임만 Speedle에 전달.
사람의 승인
집행 포인트는 환불에 대한 서명된 승인 기록을 검증하고 두 번째 확인에서 승인자를 approved_by로 전달. 승인자는 사용자 자신일 수 없음.
자체 호스팅 옵션
커스텀 함수 DelegationValid 및 DelegatorAllowed를 통해 토큰과 위임자를 한 번에 평가하는 단일 검증. Speedle Cloud는 커스텀 함수를 실행하지 않음.
agents.spdlSPDL 예제
[service.crm]
[policy]
# Check 1: the agent, only while its verified token covers the request
grant role in-scope read, update expr:^/tickets/
grant role in-scope refund expr:^/orders/
# Check 2: the delegating user (the token's sub), with their roles now
grant role support read, update expr:^/tickets/
grant role support refund expr:^/orders/ if amount <= 100
# Larger refunds: a verified approval by someone other than the user
grant role support refund expr:^/orders/ if approved_by != request_user
[rolepolicy]
# Check 1 in three steps, each role needing the one before:
# the token has not expired,
grant entity triage-agent in-time if request_time < token_expires
# it lists this action,
grant role in-time in-action if request_action in token_actions
# and it lists this resource
grant role in-action in-scope if request_resource in token_resources
# Check 2: the user's own role
grant user alice support

첫 번째 확인은 에이전트에 3단계로 역할을 부여하여 토큰 만료 전이자 토큰의 액션과 리소스에만 유효하도록 제한합니다. 두 번째 확인은 사용자 자신을 검증하므로 사용자 역할이 취소되면 다음 요청에서 에이전트도 거부됩니다. 100을 초과하는 환불은 사용자가 아닌 승인자가 필요합니다.

GitHub에서 두 패턴의 실행 가능한 샘플 보기

05 / 도구 호출 (MCP)

AI 에이전트가 이 인수로 이 MCP 도구를 호출할 수 있는가

모든 도구 호출은 실행 전에 검증됩니다. 도구가 리소스, 호출이 액션, 인수가 속성이 되어 환불 금액 한도와 같은 제약 조건이 정책의 일부가 됩니다.

주체
에이전트. 각각 고유한 엔티티 신원과 역할을 가지므로 권한은 에이전트별 및 도구별로 엄격히 유지됨.
리소스 및 액션
도구: call(도구 인수를 속성으로 전달).
집행 포인트
도구가 실행되기 전의 MCP 클라이언트 호스트 또는 MCP 서버 앞단의 게이트웨이.
mcp.spdlSPDL 예제
[service.mcp-gateway]
[policy]
# Tool arguments arrive as attributes and are checked before the tool runs
grant role research-agent call /tools/web-search
grant role billing-agent call /tools/issue-refund if amount <= 100 && customer_verified == true
# Admin tools stay out of reach for research agents
deny role research-agent call expr:^/tools/admin/
[rolepolicy]
grant entity agent-research-1 research-agent
grant entity agent-billing-1 billing-agent

연구 에이전트를 위한 웹 검색, 청구 에이전트를 위한 인증된 고객 대상 최대 100 환불, 연구 에이전트에 대한 관리자 도구 명시적 거부.

06 / 에이전트 간 호출 (A2A)

어떤 에이전트가 어떤 에이전트를 호출할 수 있는가

위임 체인의 각 홉이 검증됩니다. 피호출자는 호출자가 이미 보유한 범위만 받을 수 있으며 최대 홉 수 제한이 적용되므로 위임으로 인해 권한이 확장되지 않습니다.

주체
엔티티로 식별되는 호출 에이전트.
리소스 및 액션
타 에이전트 및 스킬: call(요청된 범위, 호출자 범위, 홉 수를 속성으로 전달).
집행 포인트
작업을 전송하기 전의 호출 에이전트 또는 작업을 수락하기 전의 수신 에이전트. 애플리케이션은 전달받은 위임으로부터 호출자의 범위를 도출.
a2a.spdlSPDL 예제
[service.a2a]
[policy]
# A callee gets only scopes the caller already holds, within two hops
grant role planner-agent call /agents/researcher if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
grant role researcher-agent call /agents/writer if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
[rolepolicy]
grant entity planner-1 planner-agent
grant entity researcher-1 researcher-agent

IsSubSet은 호출자가 보유하지 않은 요청 범위를 거부하며, 세 번째 홉은 거부됩니다.

07 / 상시 권한 배제 · 자체 호스팅

적시 토큰으로 상시 권한 배제 패턴을 지원

올바른 발급 및 통제 조건 하에서, Speedle의 정책 결정 및 애플리케이션 측 집행과 결합된 적시(just-in-time)의 단기 유효 제한적 자격 증명은 상시 권한 배제 패턴을 지원할 수 있습니다. 이 예제에서는 유효 수명, 유효 시작 시간 및 토큰 상태를 확인합니다. 프로덕션 환경에는 신뢰할 수 있는 컴포넌트도 필요하며, 토큰을 검증하고, 클레임을 주체, 리소스, 액션 및 작업 범위에 바인딩하고, 단일 사용 자격 증명에 대한 원자적 소비가 필요합니다.

zsp.spdlSPDL 예제
[service.zsp]
[policy]
# A just-in-time token: positive lifetime up to 600 s, inside its validity window, unused
# request_time defaults to the ADS clock; attributes passed by the enforcement point take precedence
# 60 s is the explicit clock-skew allowance
grant role agent-runtime invoke /api/orders if expires_at > issued_at && expires_at - issued_at <= 600 && issued_at <= request_time + 60 && not_before <= request_time + 60 && request_time < expires_at && TokenUnused(token_id)
[rolepolicy]
grant entity agent-billing-1 agent-runtime

GitHub에서 완전한 실행 가능 샘플 보기

파트 01계획됨

AI 위험 감지의 목표 흐름

이 접근 방식은 현재 탐색 및 구축 단계이며 출시되지 않았습니다. 결정론적 정책 결정 위에 추가 정밀 조사를 더하며, 위험 신호가 정책의 거부를 허용으로 바꿀 수는 없습니다.

개념적 목표 흐름

정책 우선, 위험 신호는 차순위. 거부권 유지

계획됨
  1. 01 / 요청

    액션 설명

    에이전트, 사용자, 데이터, 액션 및 작업 컨텍스트가 요청을 구성합니다.

    실행 전
  2. 02 / 정책 결정

    결정론적 경계 적용

    정책이 명확한 결정을 내립니다. 거부는 여기서 중단되며 허용된 경우에만 진행됩니다.

    거부권 · 거부는 최종 결정
  3. 03 / AI 위험 신호

    더 광범위한 관계 검토

    구축 중인 접근 방식은 추가적인 위험을 찾기 위해 더 많은 차원과 관계를 검토합니다.

    계획됨
  4. 04 / 최종 결정

    보호 추가만 가능하며 권한은 추가되지 않음

    위험 신호는 정밀 조사나 보호를 추가할 수 있지만, 정책 결과와 거부권은 그대로 유지됩니다.

    정책 거부권 유지

위험 신호가 정책의 거부를 허용으로 바꿀 수는 없습니다. 이 다이어그램은 구축 중인 접근 방식을 보여주며, 출시된 AI 위험 감지 기능을 나타내지 않습니다.

Speedle AI 한국어 홈으로 돌아가기