Audit an Argentine AI corporation, on a single page.

Every AI corporation that uses ar-agents writes each action to an append-only log, signed at write time with HMAC-SHA256. The log is publicly readable (entries don't contain secrets; they contain what happened). The signing key is the operator's private key.

A typical entry looks like:

{
  "id": "2026-05-11T14:23:01.512Z-a1b2c3d4",
  "sessionId": "demo-public-ar-001",
  "ts": "2026-05-11T14:23:01.512Z",
  "tool": "mercadopago.preapproval.create",
  "governance": "audit-logged",
  "input": { "payerEmail": "comprador@ejemplo.com.ar", "amount": 1500 },
  "output": { "preapprovalId": "abc123" },
  "durationMs": 412,
  "hmac": "sha256:a4b1c8f7..."
}

The normative specification of each field (what MUST/SHOULD/MAY appear) is in RFC-004. The reference implementation (TypeScript anyone can read) lives at /architecture/audit-log.

The HMAC signature lets an auditor who does nothave the operator's key still detect whether an entry was modified after writing. The operator can't go back and change "charged $1,500" into "charged $1.5M": the signature breaks.

How to verify it yourself, without installing anything:

1. Open /verify?sessionId=demo-public-ar-001.
2. The server recomputes each entry's signature with its key + shows the count: total / verified / tampered.
3. If you want to verify yourself without trusting the server, download the raw entries from /api/play/audit/demo-public-ar-001 and apply the RFC-004 § 3 algorithm with the public key (v2 asymmetric) or the key-possession challenge-response (v1 symmetric, planned for v1.1).

Verification is computationally deterministic: the same entry with the same key always produces the same signature. The operator can't "fix" an audit log after the fact without breaking the verification.

On regulatory request, the operator is obligated to produce:

• Full JSON: /api/play/audit/demo-public-ar-001
• RFC-4180 CSV with BOM (opens cleanly in Excel): /api/play/audit/demo-public-ar-001/csv
• Verification count: /api/play/audit/demo-public-ar-001?verify=1
• Live stream (Server-Sent Events) for regulatory dashboards: GET /api/play/audit-stream/demo-public-ar-001

Response window: 1 business day from request. The endpoints are automatic; no manual intervention by the operator.

Each entry carries a governance field with one of four values. The assignment of civil liability (RFC-001 § 4) depends directly on this field:

If a productive AI corporation emits an entry with governance: "mocked-upstream", it's a public admission that the side effect did not hit the real system. A regulator reading the log can distinguish a productive operation from a demo by this field alone.

• Session inventory active during a time window.
• Full export of a specific session in JSON + CSV.
• Verification proof: the result of verifying signatures + a key-possession proof (challenge-response without revealing the key).
• Operational narrative: a human-readable summary of what the AI corporation did during the window, generated from the log, not from operator memory. Provided via /play + the CSV.

With a court order, the regulator can additionally compel the chain of custody for the signing key (who held it, where it was stored, when it was rotated), equivalent to compelling the custody chain of a notary's seal.

Every AI corporation built with ar-agents publishes its jurisdictional identity + capabilities at /.well-known/agents.json. For example, for a corporation whose operator is CUIT XX-XXXXXXXX-X:

{
  "$schema": "https://ar-agents.ar/schemas/agents.v1.json",
  "version": "1.0",
  "issuer": {
    "jurisdiction": "AR",
    "type": "sociedad-ia",
    "operatorCuit": "XX-XXXXXXXX-X",
    "operatorName": "Naza",
    "supervisionRegime": "rfc-001-v1"
  },
  "endpoints": {
    "auditRead":   "https://ar-agents.ar/api/play/audit/{sessionId}",
    "auditVerify": "https://ar-agents.ar/api/play/audit/{sessionId}?verify=1",
    "auditCsv":    "https://ar-agents.ar/api/play/audit/{sessionId}/csv",
    "auditStream": "https://ar-agents.ar/api/play/audit-stream/{sessionId}"
  },
  "rfcConformance": ["rfc-001-v1", "rfc-002-v1", "rfc-003-draft", "rfc-004-draft"]
}

The complete discovery convention lives in RFC-002. The idea: you don't have to guess where an AI corporation's endpoints are. There's a standard place.

• RFC-001, Three-layer civil liability framework for AI corporations.
• RFC-004, Normative specification of the operational log. The technical document legislation can cite.
• /architecture/audit-log: Code-level breakdown of the log (code + reasoning, 11 sections).
• /architecture/security, Threat model, 14 scenarios.
• /play, Annotated 5-step demo: run an operation, see how it lands in the log, try to tamper it, see how it's detected.
• /data-room, Live numbers (npm, GitHub, packages, tests). Auto-refreshed every 6 hours.
• /sociedades-ia, Political-legal context of the proposed regime (Apr 28, 2026).

If you'd like to talk about how this stack is used, its real limitations, or how to cite it in a draft bill: 30 minutes by video call, no fees, no commercial agenda. Email naza@naza.ar with a time window that works. The regime is being debated; the code already exists; both sides should be talking.

This page might be wrong. The implementation might have bugs. The specification might have gaps. If you find one, open a public issue at github.com/ar-agents/ar-agents/issues. Every conversation is public; every correction is recorded in the public changelog.

This is a page from an open-source project. It is not an official document from any agency. The sociedad-IA regime was announced on April 28, 2026 by the Argentine Ministry of Deregulation; at the time of this publication, there is no enacted law yet. This infrastructure exists so the legislative conversation has a concrete technical reference to look at.