Seguridad y controles de ejecución
Define las condiciones en las que pueden actuar los agentes.
Recuriant aplica la política configurada antes de que las acciones modifiquen sistemas externos. Esta página explica los controles de ejecución, las aprobaciones humanas y los límites actuales de identidad y registros.
Aplica políticas antes de ejecutar.
Los pasos de un flujo, las acciones de conectores y las llamadas MCP usan la misma vía de ejecución. Con una política declarada, las acciones que modifican sistemas se evalúan después de resolver sus entradas y antes de ejecutarse.
Si una política configurada no se puede cargar, se bloquean las acciones que modifican sistemas. Las lecturas omiten la verificación de nivel de política, pero siguen sujetas a las comprobaciones de permisos que correspondan. Un espacio sin política declarada opera sin estos controles.
- agent:hotfix-author github.comment #4412 L1 · permitido
- verify-hotfix stripe.refund.create 412.00 USD rechazado · scope_missing
- hotfix stripe.refund.create 412.00 USD L2 · en espera
- persona oncall approval verdict=approve aprobado
- nightly-triage github.label.add stale rechazado · policy_unavailable
Clasifica las acciones por reversibilidad e impacto.
Una acción declara qué tan reversible es y cuál es su impacto. Las acciones reversibles de bajo impacto son L1. Las irreversibles de impacto medio o alto, o las difíciles de revertir de alto impacto, son L3. Las demás acciones que modifican sistemas son L2, incluidas las que no tienen clasificación.
Permitir la acción.
La política configurada permite ejecutar la acción.
Esperar aprobación humana.
La acción espera a que una persona autorizada resuelva su aprobación. El estado de aprobación debe guardarse antes de que la acción continúe.
Rechazar la acción.
La acción no se ejecuta. El rechazo se puede consultar cuando el registro de la decisión está disponible.
Tu política asigna permitir, solicitar aprobación o rechazar a cada nivel. Las acciones financieras pueden esperar aprobación y no se pueden configurar para ejecutarse sin supervisión. Los límites de gasto diarios y por campaña configurados pueden elevar el nivel de una acción.
Conserva las decisiones humanas junto al trabajo.
Un paso en espera pausa la ejecución persistente. La espera sobrevive a reinicios y despliegues; tras la aprobación, el flujo se reanuda en ese paso.
- Una aprobación es de un solo uso y corresponde al paso de la acción.
- Solo la persona designada para aprobar o un administrador pueden resolverla mediante una sesión de usuario. Una clave API no puede aprobar.
- La identidad de quien aprueba se guarda con la decisión.
- La espera dura 24 horas de forma predeterminada o el tiempo que defina tu política. Al vencer, el paso se rechaza, salvo que la política indique aprobarlo o escalarlo.
Configura una identidad para cada rol de agente.
Cuando una identidad de rol está declarada y habilitada, Recuriant solicita un token de corta duración con los permisos de ese rol antes de asignar trabajo. Si el token no se puede emitir, la asignación no inicia. Las acciones llamadas con esa identidad se verifican contra sus permisos.
Límites actuales de identidad
- Los espacios sin política declarada y los roles sin una identidad declarada y habilitada aún pueden usar una credencial compartida.
- Los flujos creados por agentes se validan al guardarse. Las acciones se verifican con la identidad presentada al ejecutarse.
- La API de asignación de trabajo no permite que un agente asigne trabajo directamente a otro. Esta vía aún no usa intercambio de tokens delegados.
Consulta las ejecuciones y decisiones de política.
Las ejecuciones muestran los resultados de sus pasos. Las decisiones de política disponibles identifican la acción, las entradas resueltas y la regla aplicada, con datos de aprobación para las acciones que estuvieron en espera. Ambos registros se pueden consultar como JSON mediante la API.
Las escrituras de auditoría para permitir o rechazar acciones no están garantizadas, salvo que formen parte de una operación que requiera persistencia. Si el estado de aprobación no se puede guardar, la acción no se ejecuta; el flujo debe reintentar antes de que se pueda resolver la aprobación.
- execution_id
- la ejecución a la que pertenece
- action, inputs
- la acción y sus entradas resueltas
- decision
- permitir, solicitar aprobación o rechazar
- rule_fired
- la regla que determinó la decisión
- tier
- L1, L2 o L3
- agent_owner
- la persona responsable del agente
- approved_by, approval_consumed_at
- quién la aprobó y cuándo se utilizó
Elige el despliegue con tu equipo.
Recuriant se ejecuta en Kubernetes mediante un chart de Helm, con flujos persistentes, Postgres y Redis. Las identidades de roles usan un proveedor OpenID Connect. Los despliegues Enterprise en el clúster del cliente se acuerdan con el equipo; aún no se publica una guía de instalación.
Revisa el nivel actual de garantías.
Actualmente Recuriant no cuenta con certificaciones SOC 2, ISO 27001 o HIPAA. Cuéntanos qué requisitos debe cumplir tu revisión de seguridad.
Los requisitos de identidad, retención y acceso de cada despliegue se revisan durante una evaluación Enterprise.
Acceso y condiciones del producto.
- El registro no tiene costo. El acceso de pago aún no está abierto al público. Te contactaremos cuando esté disponible.
- Los límites de ejecución y concurrencia de cada plan se confirmarán en el lanzamiento.
- Las ejecuciones y las decisiones de política disponibles se pueden consultar mediante la API. Las escrituras de auditoría para permitir o rechazar acciones no están garantizadas; una espera de aprobación requiere que su estado se guarde.
- Recuriant es un producto propietario y su código fuente no es público. El despliegue en tu propio clúster se acuerda mediante Enterprise.
Hablemos de los requisitos de tu flujo.
Solicita acceso de pago. Para una conversación técnica, escríbenos con tu flujo, herramientas y aprobaciones necesarias.