Paquete de evidencias

El paquete de evidencias es un único ZIP para seguridad, cumplimiento o tu auditor. Lleva cada decisión de la política en un rango de fechas, quién aprobó qué y cuándo, quién cambió las reglas y los cambios de acceso que Burnbound registra. Un manifiesto guarda el SHA-256 de cada fichero, y el SHA-256 del manifiesto queda en la auditoría, así que cualquiera puede comprobar después que nadie ha tocado el paquete.

Sale de la auditoría, que solo se añade. Te ayuda a documentar controles; no es una certificación.

¿Quién puede descargarlo?

Solo un owner o un admin con sesión en el panel, en Team o Business.

• En el panel. Informe mensual en la barra lateral (/app/informe), bloque Paquete de evidencias: elige el primer y el último día y descárgalo. El resto de roles ve una línea que dice que solo owners y admins pueden descargarlo.
• Por la API. GET /v1/reports/evidence.zip?from=YYYY-MM-DD&to=YYYY-MM-DD con la sesión de un owner o admin. Una clave de org o de agente recibe 403.

El fichero se llama burnbound-evidence-<from>-to-<to>.zip. El README.md de dentro va en el idioma de quien lo exporta, inglés o español.

¿Qué fechas cubre?

Errores de la API:

¿Qué lleva el paquete?

Los CSV van en UTF-8 con marca de orden de bytes. decisions.csv y policy-changes.csv van del más antiguo al más reciente; approvals.csv, en el orden en que se cerraron las aprobaciones y después las aún abiertas; access.csv lleva las filas de auditoría, luego las de claves y luego las de miembros, cada bloque del más antiguo al más reciente. Una celda de texto que empieza por =, +, -, @, un tabulador o un retorno de carro lleva una ' delante, para que la hoja de cálculo la muestre y nunca la ejecute. Todo sale de la auditoría ya redactada, de los registros de pagos y de los de claves y miembros: ni secretos, y de una clave solo su id, su prefijo y su etiqueta.

¿Qué columnas tiene decisions.csv?

Una fila por evento de decisión: payment.authorized, payment.denied, payment.step_up_required, los eventos card.authorization.* y action.executed o action.failed.

• createdAt, eventId, type y decision: allow, deny, step_up o, en tarjetas y acciones, released, captured, refunded, executed, failed.
• Quién: agentId, agentName, personId, personEmail, teamId, teamName, costCenter. La persona, el subequipo y el centro de coste son los sellados en el pago al reservarlo. Una decisión sin pago, como una denegación, muestra los del agente el día del exporte.
• Qué: intentId, method, host, payTo (o el comercio de la tarjeta), amountUsd, currency, originalAmountMinor (unidades menores de la moneda original), asset, network.
• Por qué: codes (los códigos del motivo, separados por espacios), matchedRules (ruleId:outcome de cada regla que casó) y policyVersion.

¿Qué columnas tiene approvals.csv?

• approvalId, requestedAt, agentId, agentName, intentId, amountUsd, host.
• reason (por qué se pidió, threshold si no se dice otra cosa), policyVersion, matchedRules.
• decision (approved o denied), decidedByUserId, decidedByEmail, decidedAt, secondsToDecision, note.
• finalStatus: denied, expired, consumed (la usó el pago), approved (y aún sin usar) o pending. closedAt es cuándo se denegó, caducó o se usó.

¿Qué columnas tiene policy-changes.csv?

createdAt, eventId, type, actor, actorUserId, actorEmail, agentId, agentName, scope (org o agent:<id>), ruleId, previousVersion, newVersion y change: el evento redactado en JSON.

Entran las reglas creadas, cambiadas o borradas, los límites, los hosts, las redes, la política base y sus ajustes, las reglas de ámbito, los hosts añadidos desde el catálogo, las reglas añadidas desde el chat y el webhook de decisión creado, cambiado, borrado o con su secreto de firma rotado. Las llamadas y las pruebas del webhook no cambian nada y se quedan fuera.

¿Qué columnas tiene access.csv?

createdAt, eventId, source, type, actorUserId, actorEmail, subjectUserId, subjectEmail, agentId, agentName, teamId, teamName, details (JSON).

source dice de dónde sale cada fila:

¿Cómo compruebo que un paquete está intacto?

1. Calcula el SHA-256 de cada fichero y compáralo con files en manifest.json.
2. Calcula el SHA-256 de manifest.json y búscalo en el evento report.evidence_exported de ese exporte, en el campo manifestSha256.

El panel hace el paso 2 por ti: después de la descarga enseña el SHA-256 del manifiesto y te dice si ya está en la auditoría. La tabla Exportes del mismo bloque lista cada paquete con su ventana, sus filas y el hash del manifiesto. Por la API, los mismos eventos están en GET /v1/audit?type=report.evidence_exported.

Desde un terminal (macOS; en Linux, sha256sum en vez de shasum -a 256):

unzip burnbound-evidence-2026-01-01-to-2026-06-30.zip -d evidencias
cd evidencias
jq -r '.files | to_entries[] | "\(.value.sha256)  \(.key)"' manifest.json | shasum -a 256 -c
shasum -a 256 manifest.json

La primera orden escribe OK por cada fichero cuyo hash coincide. La segunda escribe el hash del manifiesto, que tiene que ser el manifestSha256 del evento.

Un manifest.json tiene esta forma (con los hashes recortados):

{
  "evidenceFormat": 1,
  "org": { "id": "…", "name": "Acme" },
  "window": {
    "requested": { "from": "2026-01-01", "to": "2026-06-30" },
    "effective": {
      "from": "2026-01-01T00:00:00.000Z",
      "until": "2026-07-01T00:00:00.000Z"
    },
    "clippedToRetention": false,
    "retentionDays": 365
  },
  "generatedAt": "2026-07-01T09:30:00.000Z",
  "generatedBy": { "userId": "…", "email": "…", "role": "owner" },
  "plan": "team",
  "files": {
    "README.md": { "rows": null, "bytes": 3120, "sha256": "…" },
    "decisions.csv": { "rows": 1284, "bytes": 402113, "sha256": "…" },
    "approvals.csv": { "rows": 58, "bytes": 14220, "sha256": "…" },
    "policy-changes.csv": { "rows": 31, "bytes": 18904, "sha256": "…" },
    "access.csv": { "rows": 17, "bytes": 5031, "sha256": "…" }
  }
}

manifest.json va guardado en el ZIP sin comprimir, para que el panel lo pueda leer de la descarga. Un cambio de ficheros o de columnas sube evidenceFormat.

La auditoría solo se añade, así que el hash que quedó al exportar no se puede cambiar después. Una descarga que falla o se cancela no registra ningún evento.

¿Qué no cubre todavía?

access.csv no es una lista completa de quién tuvo acceso. Solo enseña lo que Burnbound registra hoy:

• Bajas. Las bajas de personas no se auditan, así que no salen.
• Invitaciones. Tampoco se auditan.
• Cambios de rol. No se auditan, salvo el paso a viewer.
• Altas. Salen de los registros de miembros: una persona que entró y ya se fue no aparece, y el rol es el de hoy, no el que tenía al entrar.
• Claves. Salen de los registros de claves: las de un agente borrado desde entonces no aparecen.

¿Qué controles ayuda a documentar?

El paquete te ayuda a enseñar a tu auditor cómo se controla el gasto de los agentes. No certifica nada: no es una opinión de auditoría, ni una certificación, ni una garantía de cumplimiento de ninguna norma o ley.

Para el exporte de gasto del día a día y el informe mensual, mira Conceptos.