VerifikaDocs
MCP

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 llave

Có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_members devuelve 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.

En esta página