AzterDocs

Estándares

Seguridad y scopes

Un agente con acceso a tu operación comercial necesita el mismo rigor que un empleado con llaves: identidad clara, permisos mínimos, verificación server-side de dinero y una traza revisable de cada decisión.

Autenticación

  • OAuth 2.1 para clientes MCP: discovery, registro dinámico de cliente, PKCE S256 y rotación de refresh tokens. El consentimiento elige el workspace y se muestra qué podrá hacer el cliente.
  • API keys (azter_live_…) emitidas y revocables desde la consola, con scopes explícitos. Solo se almacena un hash: si pierdes la clave debes generar una nueva.
  • Los webhooks entrantes de proveedores se verifican con HMAC fail-closed y los pagos se confirman consultando al gateway, nunca confiando en el payload.

Scopes

Permiso mínimo por defecto. Cada capability declara los scopes que exige (todos o alguno de ellos, según su contrato); una credencial sin el scope requerido recibe un error de autorización sin revelar la existencia de la operación.

catalog:readConsultar productos, variantes y precios del catálogo.
inventory:readConsultar stock y disponibilidad por SKU.
customers:readLeer contactos y sus datos comerciales.
customers:writeActualizar datos de contactos.
conversations:readLeer conversaciones e historial de mensajes.
conversations:writeEscribir mensajes en conversaciones.
quotes:readLeer cotizaciones.
quotes:writeEmitir cotizaciones.
orders:readLeer órdenes.
orders:writeCrear órdenes.
payments:createGenerar cobros y links de pago.
payments:readConsultar estado de pagos.
refunds:createSolicitar reembolsos.
invoices:createEmitir documentos tributarios.
integrations:readVer conexiones e integraciones.
agents:invokeInvocar y delegar a agentes.
audit:readConsultar la traza de decisiones.

Idempotencia

Las operaciones con side effects se identifican por intento lógico —no por el contenido del mensaje— y quedan registradas de forma durable: repetir el mismo intento devuelve el resultado previo sin re-ejecutar, y reutilizar una identidad con un payload distinto se rechaza como conflicto.

Timeouts honestos

Si un command excede su tiempo y no se sabe si el efecto ocurrió, queda en estado unknown con bloqueo temporal del intento: nunca se afirma un éxito ni un fallo que no se pueden demostrar.

Datos y aislamiento

  • Aislamiento por empresa (workspace) en todos los caminos de ejecución.
  • Los datos de tu operación no se usan para entrenar modelos de terceros.
  • El contenido que llega por canales se trata como dato, nunca como instrucción (defensas de prompt injection en memoria y contexto).
  • Las credenciales de integraciones se guardan cifradas y nunca se exponen al navegador ni aparecen en logs.

Auditoría

Cada ejecución deja evidencia: quién la invocó, qué capability corrió, con qué versión, cuánto demoró y con qué resultado. La traza es consultable desde la consola (Traces y Auditoría).

Ejemplo de registro

traza (forma)
{
"capability": "inventory.check",
"version": "1.0.0",
"actor": { "kind": "agent", "id": "run_••••" },
"status": "ok",
"latency_ms": 74,
"trace_id": "••••-••••"
}

Consulta por API

La exportación de auditoría por API llegará con el REST; hoy la traza se consulta en la consola.