Speedle AI · Patrones

Patrones de políticas para construir y ejecutar IA

El motor de políticas de Speedle se aplica dondequiera que los sistemas de IA interactúan con datos, modelos, herramientas y otros agentes: en la fase de construcción, antes de que el modelo esté en servicio, y en la fase de ejecución, mientras sirve y actúa. Estos son patrones de solución, no integraciones predeterminadas con ninguna plataforma de ML o agentes.

Cada ejemplo de SPDL a continuación fue analizado y evaluado con el almacén de archivos de Speedle frente a casos de autorización y denegación. Los nombres, rutas y atributos son ilustrativos; su aplicación proporciona los atributos al solicitar una decisión. El punto de aplicación de políticas debe pasar cada atributo al que hace referencia una condición.

Construcción

Antes de servir un modelo: datos, entrenamiento y lanzamiento

01 / Datos y entrenamiento

¿Qué canalizaciones pueden entrenar con qué datos?

Los trabajos de entrenamiento leen conjuntos de datos, usan computación y escriben puntos de control. La aplicación consulta antes de cada lectura de datos, inicio de trabajo y exportación de punto de control, pasando sensibilidad, inquilino, consentimiento y región como atributos.

Sujetos
Canalizaciones de entrenamiento como entidades; ingenieros de ML y sus equipos.
Recursos y acciones
Conjuntos de datos: read. Trabajos de entrenamiento: start. Puntos de control: export.
Punto de aplicación
El cargador de datos antes de abrir un conjunto de datos, el programador de trabajos antes de asignar computación y el almacén de artefactos antes de una exportación.
training.spdlEjemplo de SPDL
[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

Consentimiento y región verificados por conjunto de datos, datos restringidos denegados directamente y un límite de horas de GPU al iniciar el trabajo.

02 / Lanzamiento de modelos

¿Quién puede publicar un modelo?

Registrar, aprobar, promover y revertir modelos son acciones independientes con responsables distintos. La separación de funciones impide que quien entrenó un modelo lo apruebe.

Sujetos
Ingenieros de ML, gestores de lanzamientos e identidades de servicio de las canalizaciones de lanzamiento.
Recursos y acciones
Modelos y puntos de conexión: register, approve, promote, rollback.
Punto de aplicación
El registro de modelos y la canalización de lanzamiento, antes de cada cambio de estado de un modelo o punto de conexión.
release.spdlEjemplo de SPDL
[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

Los ingenieros registran pero no pueden promover; un gestor de lanzamientos no puede aprobar un modelo cuyo trained_by sea el usuario solicitante.

Ejecución

Mientras la IA sirve y actúa: recuperación, agentes, herramientas y otros agentes

03 / Inferencia y RAG

Solo entra en el prompt lo que el usuario puede leer

Usuarios, aplicaciones e inquilinos invocan modelos. Para el RAG con reconocimiento de permisos, el recuperador consulta a Speedle sobre cada documento o colección antes de que su contenido entre en el prompt, de modo que el modelo solo ve lo que la persona detrás de la solicitud puede leer.

  1. 1El recuperador encuentra documentos candidatos.
  2. 2Consulta a Speedle por documento o colección, con el inquilino y autorizaciones del usuario.
  3. 3Solo el contenido permitido pasa al prompt.
Sujetos
El usuario detrás de la solicitud, con sus grupos; aplicaciones cliente e inquilinos como entidades.
Recursos y acciones
Colecciones y documentos: retrieve. Modelos: invoke.
Punto de aplicación
El recuperador antes de que un documento entre en el prompt, y la puerta de enlace de API o servicio de inferencia antes de enrutar una solicitud.
rag.spdlEjemplo de SPDL
[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

Un documento se recupera solo dentro del inquilino del usuario y con una etiqueta para la cual el usuario tiene autorización; los documentos con retención legal se deniegan y las aplicaciones solo invocan los niveles de modelo de su plan.

04 / Agentes que actúan para usuarios

¿Qué puede hacer un agente de IA en nombre de un usuario?

El agente tiene su propia identidad, y la delegación del usuario se demuestra mediante un token de delegación firmado, no por afirmaciones en la solicitud. El punto de aplicación verifica el token, luego consulta a Speedle dos veces y permite solo si ambas comprobaciones pasan: el agente dentro del alcance del token y el usuario delegante con sus propios permisos actuales. Si el usuario pierde un permiso después de emitirse el token, el agente lo pierde en la siguiente solicitud. Un reembolso superior a 100 también necesita una aprobación humana registrada por alguien que no sea el usuario.

  1. 1Verificar el token: firma, emisor, caducidad y que fue emitido a este agente.
  2. 2Alcance del agente: consultar a Speedle con el agente como sujeto y el alcance del token como atributos.
  3. 3Delegante actual: consultar a Speedle con el usuario delegante, indicado por el reclamo sub del token, como sujeto.
Sujetos
El agente como entidad para la comprobación de alcance; el usuario delegante, tomado del token verificado, para la segunda comprobación.
Recursos y acciones
Tickets: read, update; pedidos: refund (con el monto como atributo). Todo limitado a las acciones y recursos en el alcance del token.
Punto de aplicación
El entorno de ejecución del agente o el backend de la aplicación, antes de que la acción llegue al sistema empresarial. Verifica el token y pasa solo reclamos verificados a Speedle.
Aprobación humana
El punto de aplicación verifica el registro de aprobación firmado para el reembolso y pasa su aprobador como approved_by en la segunda comprobación. El aprobador no debe ser el usuario.
Opción autohospedada
Una comprobación, con el token y el delegante evaluados por las funciones personalizadas DelegationValid y DelegatorAllowed. Speedle Cloud no ejecuta funciones personalizadas.
agents.spdlEjemplo de SPDL
[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

La comprobación 1 otorga al agente su rol en tres pasos, de modo que solo es válido antes de que caduque el token y solo para las acciones y recursos del token. La comprobación 2 consulta solo sobre el usuario, por lo que revocar el rol del usuario deniega al agente en la siguiente solicitud. Un reembolso superior a 100 pasa la comprobación 2 solo con un aprobador distinto del usuario.

Ejemplo ejecutable de ambos patrones en GitHub

05 / Llamadas a herramientas (MCP)

¿Puede este agente de IA llamar a esta herramienta MCP con estos argumentos?

Cada llamada a una herramienta se comprueba antes de ejecutarse. La herramienta es el recurso, la llamada es la acción y los argumentos se convierten en atributos, por lo que los límites como el monto de reembolso forman parte de la política.

Sujetos
Agentes, cada uno con su propia identidad de entidad y rol, por lo que los privilegios permanecen por agente y por herramienta.
Recursos y acciones
Herramientas: call (con los argumentos de la herramienta como atributos).
Punto de aplicación
El host del cliente MCP, o una puerta de enlace frente a los servidores MCP, antes de que se ejecute la herramienta.
mcp.spdlEjemplo de SPDL
[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

Búsqueda web para el agente de investigación, reembolsos de hasta 100 para clientes verificados para el agente de facturación y herramientas de administración denegadas al agente de investigación.

06 / Llamadas de agente a agente (A2A)

¿Qué agente puede llamar a qué agente?

Se verifica cada salto en una cadena de delegación. El destinatario solo puede recibir alcances que el emisor ya posee, y la cadena tiene un límite de saltos, por lo que la delegación solo restringe los permisos.

Sujetos
Agentes emisores, identificados como entidades.
Recursos y acciones
Otros agentes y sus habilidades: call (con los alcances solicitados, los alcances del emisor y el recuento de saltos como atributos).
Punto de aplicación
El agente emisor antes de enviar una tarea, o el agente receptor antes de aceptarla. La aplicación deriva los alcances del emisor a partir de la delegación recibida.
a2a.spdlEjemplo de SPDL
[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 rechaza cualquier alcance solicitado que el emisor no posea, y se deniega un tercer salto.

07 / Privilegios permanentes cero · Autohospedado

Los tokens Just-in-Time respaldan un patrón de privilegios permanentes cero

Bajo las condiciones adecuadas de emisión y control, las credenciales Just-in-Time, de corta duración y de alcance restringido, combinadas con las decisiones de políticas de Speedle y la aplicación del lado del cliente, pueden respaldar un patrón de privilegios permanentes cero. El ejemplo comprueba la vida útil, no antes de y el estado del token; la producción también necesita un componente de confianza que verifique el token, vincule sus reclamos con el sujeto, recurso, acción y alcance de la tarea, y un consumo atómico para credenciales de un solo uso.

zsp.spdlEjemplo de SPDL
[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

Ejemplo ejecutable completo en GitHub

Parte 01Planificado

Flujo objetivo para la detección de riesgos de IA

El enfoque se está explorando y construyendo, aún no está disponible como producto. Agrega escrutinio sobre la decisión de política determinista, y una señal de riesgo no puede convertir una denegación de política en una autorización.

Flujo conceptual objetivo

Política primero. Señales de riesgo segundo. Veto intacto

Planificado
  1. 01 / SOLICITUD

    Describir la acción

    Agente, usuario, datos, acción y contexto de la tarea forman la solicitud.

    Antes de ejecutar nada
  2. 02 / DECISIÓN DE POLÍTICA

    Aplicar el límite determinista

    La política devuelve la decisión precisa. La denegación se detiene aquí; solo una autorización puede continuar.

    VETO · LA DENEGACIÓN ES DEFINITIVA
  3. 03 / SEÑALES DE RIESGO DE IA

    Examinar relaciones más amplias

    El enfoque que se está construyendo analiza más dimensiones y relaciones para detectar riesgos adicionales.

    PLANIFICADO
  4. 04 / DECISIÓN FINAL

    Agregar protección, nunca acceso

    Las señales de riesgo pueden agregar escrutinio o protección. El resultado de la política y su veto permanecen intactos.

    VETO DE POLÍTICA PRESERVADO

Una señal de riesgo no puede convertir una denegación de política en una autorización. Este diagrama muestra el enfoque en construcción; no representa una funcionalidad de detección de riesgos de IA lanzada.

Volver a la página de inicio de Speedle AI