En este artículo
Vendo para SaaS: aislamiento de clientes y aprobaciones
Base de evidencia: Documentación revisada el 8 de octubre de 2026. Esta es una guía de implementación investigada. El piloto se propone para tu equipo; no hemos ejecutado estas evaluaciones ni medido el rendimiento de los proveedores.
¿Qué sigue siendo responsabilidad del SaaS?
Tu backend decide qué registros puede leer o cambiar cada usuario. Las pantallas generadas, el sandbox y la tarjeta de aprobación no sustituyen autorización en la API. Empieza con un panel cuyos tools ya limiten acceso por cliente. Añade acciones cuando esa frontera supere comprobaciones independientes.
El producto es Vendo en vendo.run, la capa de personalización del repositorio oficial runvendo. Añade funciones y microaplicaciones dirigidas por agentes a un producto existente. Otras empresas llamadas Vendo no forman parte de esta guía.
¿Cómo resolver identidad y aislamiento?
La documentación de autenticación de Vendo usa la identidad existente y recomienda un sujeto inmutable. Su ejemplo sin autenticación asigna el mismo usuario de demostración a todo visitante. No sirve para una integración productiva con varios clientes.
Comparte un resolver de sesión fiable del servidor entre Vendo y tus rutas. Obtén membresías desde el backend y compruébalas en cada herramienta con datos de negocio. Un ID de organización proporcionado por el modelo no prueba acceso. Los usuarios de dos organizaciones también necesitan un contexto activo explícito.
¿Qué debe demostrar un piloto con dos clientes?
Crea organizaciones sintéticas A y B, cada una con administrador y miembro de solo lectura. Ambas tienen una factura con igual número local e identificadores internos distintos. Propón una vista de facturas vencidas y una acción de recordatorio. Estos casos son objetivos de aceptación, no resultados observados de Vendo.
| Intento | Resultado requerido | Comprobación independiente |
|---|---|---|
| A solicita la factura de B por ID | Denegación sin revelar campos | Respuesta API y registro de acceso |
| A cambia de organización activa | Solo aparece el contexto autorizado | Volver a consultar y abrir la app guardada |
| Miembro de lectura envía recordatorio | Bloqueado salvo permiso explícito | Registro de envíos sin cambios |
| Administrador pierde rol tras aprobar | Se vuelve a comprobar el permiso | Ningún envío tras revocar |
| Dos workers reanudan la misma acción | Un solo efecto lógico | Clave durable y registro de entregas |
| Reinicio del proceso | Persiste estado autorizado; no reviven permisos caducados | Almacenamiento y repetición de acción |
Prueba acceso directamente en las herramientas y mediante la UI. Ocultar un botón no prueba autorización.
¿Vendo pide permiso antes de cada escritura?
No. La guía de aprobaciones documenta lectura y escritura automáticas por defecto; operaciones destructivas o sin clasificar piden permiso. Define políticas explícitas para escrituras sensibles, como mensajes o facturación. Una operación crítica puede requerir aprobación aunque no esté clasificada técnicamente como destructiva.
La guía distingue reanudación interna y MCP: tras aprobar, el agente externo debe volver a llamar en la misma sesión MCP. Prueba ambos caminos si los clientes usan ambos. Vincula aprobación a la acción concreta y revisa permisos al ejecutar. Aprobar no permite saltarse autorización.
¿Qué debe sobrevivir a un reinicio?
La documentación de persistencia describe almacenamiento cloud de hilos, apps, grants, aprobaciones, auditoría y ejecuciones. Persistencia no demuestra ejecución única de una escritura del SaaS. Conserva un registro durable con cliente, actor, argumentos aprobados, clave de operación y resultado conciliado.
Si el resultado externo es incierto, inspecciona el destino antes de reintentar. Un recordatorio entregado seguido de un fallo antes de guardar la respuesta puede duplicarse al crear otra operación. Prueba ese punto exacto de interrupción.
¿Basta con pasar vendo doctor?
No. La lista de producción indica que doctor lee código y entorno sin llamar a la app desplegada. Detecta problemas de conexión y después prueba staging para identidad, streaming, webhooks verificados, aprobaciones y reinicios. Cloud cubre parte de la infraestructura; varias fronteras de seguridad siguen siendo tuyas.
¿Cuándo encaja Vendo?
Cuando clientes necesitan vistas distintas o flujos acotados sobre una API autorizable. Un copilot propio puede ser más simple para una única tarea sin apps creadas por usuarios. Asigna mantenimiento de esquemas, funciones guardadas y recuperación antes de ampliar. Lleva una función y su matriz de permisos para definir la integración de agentes en tu SaaS.
Guías de implementación relacionadas
Arquitectura de autorización MCP para empresas: un diseño de referencia multi-tenant. AgentMail para SaaS: Aislamiento y recuperación de envíos duplicados.
Fuentes verificadas
Independencia y marcas: Wavect publica esta página y es también un proveedor, así que tenemos un interés comercial en ella. No estamos afiliados a las demás empresas nombradas aquí, no contamos con su respaldo y no somos socios suyos, y todos los nombres de empresa, marcas y marcas registradas de terceros pertenecen a sus respectivos titulares. Las afirmaciones sobre otros proveedores proceden de fuentes públicamente accesibles, sobre todo de sus propias páginas publicadas, en la fecha de revisión indicada en esta página, y pueden haber cambiado desde entonces. Verifícalas directamente antes de decidir. Esta página se ha redactado según nuestro leal saber y entender, con la intención de mantenernos objetivos. Si crees que algo aquí es inexacto o injusto, escríbenos y lo corregimos: [email protected]