Seguridad
Qué puede ver el asistente, qué no, y cómo acotarlo.
El MCP no abre una puerta nueva
Es una capa delgada sobre la API pública: la misma llave, los mismos permisos, el mismo
rate limit. Todo lo que el asistente puede hacer, podría hacerlo un curl con esa llave — ni
más ni menos.
permiso efectivo = permisos de la llave ∩ tu plan ∩ los negocios de la llaveCómo acotarlo
Autorízalo con un clic, no con una llave
Si tu cliente habla OAuth, no hay ningún secreto que se pueda pegar donde no debe. Ver Conectar con un clic.
Una llave aparte para el asistente
Si vas con llave, no reuses la de tu ERP. Cuando quieras cortarle el acceso, revocas una sola cosa y no tumbas la integración que sí funciona.
Solo lectura al principio
Marca únicamente los permisos .read. Ampliarlos después no te obliga a cambiar el secreto.
Acotada a una sucursal
Si el asistente lo usa el encargado de un local, la llave puede ver solo esa sucursal.
Con fecha de vencimiento
Para una prueba o una consultoría, ponle caducidad desde el principio en vez de confiar en que alguien se acuerde de borrarla.
Lo que el asistente nunca ve
- Tu llave — y si conectaste con un clic, directamente no existe ninguna.
- Tu contraseña: entras en Verifika, no en la aplicación.
- Correos ni fotos de perfil del equipo:
list_team_membersdevuelve nombre, teléfono, rol y sucursal, nada más. - Números de cuenta completos: las cuentas de recaudo se identifican por su alias y los últimos cuatro dígitos.
- Otros negocios: fuera de los de la llave no existe nada, aunque el asistente adivine un id.
Lo que sí conviene tener presente
Un asistente puede equivocarse de argumento
Si le das permisos de escritura, puede crear un gasto con el valor mal o borrar una categoría que no era. No es malicia, es que interpreta lenguaje natural. Por eso: escritura solo cuando la necesites, y en un negocio donde un movimiento de más se pueda corregir.
Lo que no puede pasar, por diseño:
- Marcar un pago como verificado. Ninguna llave puede: solo el cruce con el aviso real del banco cambia ese estado.
- Editar un ingreso que nació de un comprobante o de un aviso del banco: son inmutables.
- Crear otra API key. La administración de llaves exige una sesión de una persona en el panel, precisamente para que una llave filtrada no pueda emitir otra con más permisos.
- Borrar una categoría con gastos: se desactiva, y el histórico se conserva.
Si algo sale mal
Cada llamada queda con su requestId, y la llave registra cuándo y desde qué IP se usó por
última vez. En el panel, la columna «último uso» te dice si esa llave se está usando desde
donde esperabas.
Para cortar el acceso: revocar la llave en el panel, o quitar el acceso a la aplicación
en Integraciones → Aplicaciones si la conectaste con un clic. Las dos cosas son inmediatas —
no hay caché ni ventana de gracia salvo que rotes una llave con periodo de gracia a propósito.
Con una aplicación autorizada, «inmediato» quiere decir en la siguiente petición, aunque su permiso de acceso todavía no hubiera vencido: lo que manda es lo que sigue concedido, no lo que diga un token emitido hace media hora.