Audit Logs

Every action in Conto, creating agents, executing payments, changing policies, and freezing accounts, is recorded in a database-enforced append-only audit log with SHA-256 hash chains for tamper detection in normal operation. When the external archive is enabled, Conto also writes signed daily checkpoints to S3 Object Lock in COMPLIANCE mode, independently protecting prior chain heads from privileged database changes or backup restoration.

What Gets Logged

Payment decision receipts

Conto captures payment evidence at the database boundary for every PaymentRequest, Transaction, and ApprovalRequest lifecycle change. This includes successful payments and intermediate or terminal decisions such as approval required, approved, denied, executing, confirmed, failed, cancelled, and expired. Each receipt can correlate the payment request, transaction, and approval request and records:

what was requested: amount, currency, recipient, purpose, category, agent, and wallet;
the decision at that point: status, policy result, approval requirement, reasons, violations, and denial reason;
the controls in force: assigned policy versions and rules, wallet limits, counterparty posture, and the approval workflow configuration;
who acted and when: user, agent, API credential, or Conto system attribution with timestamp; and
execution evidence: transaction ID, chain transaction hash, block, confirmation, failure, and review status when available.

Database triggers make lifecycle capture independent of which application, worker, payment rail, or retry performed the write. No-op updates are suppressed so the trail represents decisions and state transitions rather than incidental database activity.

Actions

Action	Description
`CREATE`	Resource created (agent, wallet, policy, etc.)
`UPDATE`	Resource modified
`DELETE`	Resource removed
`APPROVE` / `REJECT`	Approval decision made
`SUSPEND` / `ACTIVATE`	Agent frozen or unfrozen
`FUND` / `WITHDRAW` / `TRANSFER`	Wallet balance changes
`PAYMENT_EXECUTED`	Payment submitted onchain
`PAYMENT_REQUEST`	Payment requested and controls snapshotted
`PAYMENT_APPROVED`	Payment approved
`PAYMENT_EXECUTING`	Payment execution started
`PAYMENT_CONFIRMED`	Payment confirmed onchain
`PAYMENT_DENIED`	Payment blocked by policy
`PAYMENT_FAILED`	Payment transaction failed
`PAYMENT_CANCELLED` / `PAYMENT_EXPIRED`	Payment closed without execution
`APPROVAL_REQUESTED`	Approval workflow receipt created
`APPROVAL_STATUS_CHANGED`	Approval decision or progress recorded
`EXTERNAL_PAYMENT_APPROVAL`	External wallet payment approved
`EXTERNAL_PAYMENT_CONFIRMED`	External wallet payment confirmed
`POLICY_VIOLATION`	Policy rule triggered
`ASSIGN_POLICY` / `REMOVE_POLICY`	Agent policy assignment changed
`LINK_WALLET` / `UNLINK_WALLET`	Agent wallet connection changed
`TRANSACTION_RETRY`	Payment retry requested
`TRUST_SCORE_UPDATE`	Counterparty trust assessment refreshed
`ALERT_CREATED` / `ALERT_RESOLVED`	Alert lifecycle
`SETTINGS_CHANGED`	Organization settings modified
`PERMISSION_GRANTED` / `PERMISSION_REVOKED`	Role or scope changes
`LOGIN` / `LOGOUT`	User session events
`INVITE_MEMBER` / `UPDATE_ROLE`	Team access changed
`PLAN_CHANGED` / `INVOICE_PAID`	Billing lifecycle
`AUDIT_LOG_EXPORTED`	Audit log data exported
`AUDIT_CHAIN_BASELINED`	Historical evidence baseline attested

Resources

Logs track actions on agents, wallets, transactions, policies, organization members, API and SDK keys, alerts, counterparties, approval workflows, payment and budget requests, billing, and supported x402 or MPP payment records.

Log Entry Fields

Customer audit responses and exports provide these fields for understanding and reconciling an event:

Field	Description
`id`	Stable audit entry reference
`action`	Customer-visible action
`resource`	Customer-visible resource type
`actorType`	Who performed it: USER, API, AGENT, or SYSTEM
`createdAt`	When the event occurred
`resourceReference`	Supported resource ID, dashboard label, and link
`changes`	Safe before-and-after values for supported customer fields
`transaction`	Related payment reference and status, when the event has one
`paymentEvidence`	Request, decision reasons, applied policies, and workflow

resourceReference.id is present when the affected record has a supported customer reference, so you can reconcile an audit entry with API records or a support request. Authentication sessions and generic settings records intentionally return a null reference ID.

{
  "id": "log_01JZ...",
  "action": "AGENT_FROZEN",
  "resource": "agent",
  "actorType": "USER",
  "createdAt": "2026-07-15T18:00:00.000Z",
  "resourceReference": {
    "id": "agent_123",
    "label": "Procurement Agent",
    "href": "/agents/agent_123"
  },
  "changes": [
    {
      "field": "status",
      "label": "Status",
      "before": "Active",
      "after": "Suspended"
    }
  ],
  "transaction": null
}

Change Detection

When a resource is updated, changes includes only documented customer fields such as status, name, role, limits, and alert resolution. Arbitrary metadata, network request details, authentication data, and unsupported state fields are not returned in audit responses or exports.

Tamper-Evident Hash Chain

Conto maintains a SHA-256 integrity chain for audit entries, so modifying an earlier entry causes a later verification check to fail. New entries use a canonical, length-prefixed hash payload that covers the actor, organization, payment and transaction correlation, request and decision states, network attribution, idempotency key, timestamp, and predecessor hash. Owners and admins can verify chain integrity for a selected date range from Audit Logs in the signed-in dashboard. The same verification shows whether an external immutable checkpoint is configured, current, pending, or behind newer activity. Response:

{
  "verified": true,
  "totalLogs": 1247,
  "verifiedLogs": 1247,
  "verifiedAt": "2026-08-12T08:14:22.000Z",
  "historicalCoverage": {
    "status": "complete"
  },
  "externalAnchor": {
    "configured": true,
    "status": "verified",
    "receipt": {
      "id": "anchor_01K2...",
      "manifestHash": "2ffb83...e704",
      "signingKeyId": "v1",
      "storageProvider": "s3-object-lock",
      "coveredThroughSequence": 1247,
      "anchoredAt": "2026-08-12T02:15:00.000Z",
      "retainUntil": "2033-08-10T02:15:00.000Z"
    }
  }
}

The external receipt exposes the manifest hash and coverage but not the storage bucket, object key, credential details, or raw internal evidence. In the exceptional case of a reviewed legacy evidence gap, historicalCoverage.status is attested_gap. The response then discloses the missing ranges, surviving-evidence digest, attestation reason and time, and the first sequence in the complete post-baseline chain. Conto does not resequence or rehash surviving entries, and does not describe the pre-baseline history as complete. The signed external checkpoint includes the same baseline disclosure.

External Immutable Checkpoints

The daily integrity job first recomputes every audit hash and checks sequence continuity. It writes a checkpoint only after that verification passes. Each checkpoint contains:

the organization and exact audit sequence range;
the final audit-chain hash and previous checkpoint hash;
any immutable historical-baseline disclosure and surviving-evidence digest;
canonical manifest and object SHA-256 checksums;
an HMAC-SHA256 signature and signing-key identifier;
the S3 object version; and
the confirmed COMPLIANCE retention deadline.

The checkpoint object is written before its append-only database receipt. S3 Versioning and Object Lock must already be enabled on the bucket; Conto rejects a write that does not return a version ID or the requested retention. COMPLIANCE retention cannot be shortened or bypassed by an ordinary storage administrator. Before each checkpoint, Conto lists the retained object versions for that organization and compares the newest external sequence and hash with the database head. This makes a database rollback detectable even if its local anchor receipts were rolled back too. The external archive is deployment configuration, not an automatic property of every Conto installation. If Audit Logs → Verify says “External immutable storage is not configured,” the database trail remains append-only and tamper-evident but must not be represented as externally immutable. Signing keys use explicit IDs. On rotation, operators retain retired IDs and secrets in AUDIT_ANCHOR_VERIFICATION_KEYS; this allows seven-year receipts to remain verifiable without using an old key for new checkpoints. The audit-integrity-sweep Inngest job runs daily at 02:15 UTC. Failures remain visible per organization in the app, while operations receives one aggregate email when an incident opens or changes, at most one reminder every 24 hours, and one recovery email. An independent Vercel watchdog checks the heartbeat at 08:00 and 20:00 UTC and returns a failing cron status when the sweep is missing, stale, or unsuccessful. It shares the same notification ledger, so it cannot duplicate the incident email. After a later sweep verifies the affected chain or external checkpoint, Conto resolves the corresponding incident and appends an ALERT_RESOLVED system event to that organization’s audit chain. If either the alert update or its audit evidence cannot be persisted, the sweep remains unhealthy.

Viewing Logs

Dashboard

Go to Audit Logs in the sidebar. Filter by:

Action type
Resource type
Actor (user or API key)
Date range

Agents that need their own audit trail can use the SDK route:

curl "https://conto.finance/api/sdk/audit-logs?resource=payment_request&limit=20" \
  -H "Authorization: Bearer $CONTO_API_KEY"

IP Attribution

Audit logs record the client IP address supplied by Conto’s trusted network boundary when one is available. This helps security investigations without requiring clients to send an IP field.

Start

Products

Build

Guides

Reference

Changelog

Audit Logs

Audit Logs

What Gets Logged

Payment decision receipts

Actions

Resources

Log Entry Fields

Change Detection

Tamper-Evident Hash Chain

External Immutable Checkpoints

Viewing Logs

Dashboard

IP Attribution

​Audit Logs

​What Gets Logged

​Payment decision receipts

​Actions

​Resources

​Log Entry Fields

​Change Detection

​Tamper-Evident Hash Chain

​External Immutable Checkpoints

​Viewing Logs

​Dashboard

​IP Attribution

Audit Logs

What Gets Logged

Payment decision receipts

Actions

Resources

Log Entry Fields

Change Detection

Tamper-Evident Hash Chain

External Immutable Checkpoints

Viewing Logs

Dashboard

IP Attribution