Compliance Evidence Export

When a regulator, auditor, or enterprise customer asks "show me your AI agent governance", the answer should not be a screenshot tour. The compliance evidence export produces one dated JSON document - the evidence pack - that captures what agents run in your tenant, what they are allowed to touch, what they actually did, and how long the activity trail is retained.

The pack is built for the regulations EU organizations are answering to today:

• EU AI Act, Article 26 (deployer duties, applicable December 2, 2027 but already requested in procurement): an inventory of the AI systems in use and the oversight arrangements around them, including Article 26(6) log retention of at least six months under the deployer's control.
• EU AI Act, Article 50 (transparency, in force since August 2, 2026): which agents interact with people, and what disclosure state you can attest for each - name, publisher, whether its instructions are captured.
• NIS2 and the Polish KSC act (as amended, in force since April 3, 2026): supply chain evidence - third-party apps and agents with access, their permission grants, and the activity trail behind them.
• The Polish AI act (Dz.U. 2026 poz. 1003): the same inventory and oversight evidence; section labels and framework names are included in Polish alongside English.

Getting the packCopy Anchor Link

From the dashboard: open Agents and choose Compliance evidence. The pack is generated on the spot and downloads as a JSON file named 1security-agent-evidence-<date>.json. Generating and downloading it is admin-only. The pack is always one document per tenant - in a combined multi-tenant dashboard ("All tenants"), switch to the member tenant first and generate a pack for each member you need to evidence.

From the API: auditors and GRC tooling can pull the identical document without dashboard access:

curl -H "Authorization: Bearer $ONESEC_API_KEY" \
  "https://api.1security.ai/api/v1/evidence/agents"

Requires a key with the evidence:read scope - see the API reference for keys, authentication, and rate limits. Optional from and to query parameters (ISO-8601) bound the covered activity period; the default window is the trailing 183 days. An optional framework parameter (a registry key such as dora) scopes the legend and sections to one framework. The response is { "data": <pack> } with no pagination - the pack is one document.

Both paths produce the same document, so the pack an auditor pulls through the API matches the one your admin downloaded byte for byte.

What is in the packCopy Anchor Link

{
  "packType": "1security.agent_evidence_pack",
  "version": "1.9.0",
  "metadata": {
    "tenantId": "01H…",
    "tenantName": "Contoso",
    "azureTenantId": "…",
    "generatedAt": "2026-09-02T09:15:00.000Z",
    "generatedBy": "admin@contoso.com",
    "coveredFrom": "2026-03-03T09:15:00.000Z",
    "coveredTo": "2026-09-02T09:15:00.000Z",
    "retention": { "...": "see Retention attestation below" }
  },
  "frameworks": [
    { "id": "EU-AI-Act-26(6)", "name": "…", "namePl": "…", "reference": "…" }
  ],
  "sections": [
    {
      "key": "inventory",
      "label": "AI agent inventory",
      "labelPl": "Inwentarz agentów AI",
      "frameworks": [
        "EU-AI-Act-26",
        "PL-AI-Act",
        "ISO42001-A.3",
        "KSC-access-control"
      ],
      "rowCount": 42,
      "truncated": false,
      "rows": ["…"]
    }
  ]
}

Three parts:

• metadata - who generated the pack, when, for which tenant, the covered period, and the retention attestation.
• frameworks - the legend: every framework id used anywhere in the pack, with its full name in English and Polish and the legal reference. The list is open by design and already spans the EU AI Act, NIS2, GDPR, the Polish KSC and KRiBSI acts, DORA, ISO/IEC 42001, ISO/IEC 27001, SOC 2, NIST CSF 2.0 and HIPAA - a future framework arrives as new legend entries and new ids on sections, never as a format change.
• sections - the evidence itself. Every section carries a frameworks array naming exactly which articles it evidences, so an auditor can walk from an article to the data that answers it without interpreting anything.

Sections and what each one evidencesCopy Anchor Link

Every section reports rowCount and truncated. Sections are capped (2,000 rows for most, 10,000 for permissions) so the pack stays a document rather than a database dump; truncated: true tells the reader the cap was hit, and narrowing the covered period with from/to brings the rest into view.

Retention attestationCopy Anchor Link

Article 26(6) of the EU AI Act requires deployers to keep automatically generated logs for at least six months. The pack does not assert a policy - it measures the actual state:

"retention": {
  "frameworks": ["EU-AI-Act-26(6)", "PL-AI-Act-logs", "KSC"],
  "retentionTargetDays": 183,
  "retentionTargetMet": true,
  "logHistoryDays": 412,
  "oldestLogAt": "2025-07-18T06:02:11.000Z",
  "newestLogAt": "2026-09-02T09:14:48.000Z",
  "tenantConnectedAt": "2025-07-17T14:30:00.000Z"
}

retentionTargetMet is true when the oldest retained activity log row is at least 183 days old. A tenant connected to 1Security more recently than 183 days ago will report retentionTargetMet: false even though nothing was deleted - tenantConnectedAt is included precisely so the reader can tell a short history apart from a retention gap.

StabilityCopy Anchor Link

The pack is a stable contract, like the rest of the public API: fields may be added over time, existing fields are not removed or renamed without notice, and version in the pack identifies the generator that produced it. Store the downloaded packs as-is - a dated series of packs is itself evidence of ongoing oversight.

NextCopy Anchor Link