# Audit evidence export

> One signed bundle of what Badge holds about an agent for a period, with a plain table of which audit controls it can help answer, and which it cannot.

> **Not generally available yet.** The audit evidence export is switched off for every Badge deployment today. There is no Export button and no export endpoint to call. This page describes what it will do, so you can judge it before it ships. The mapping table below is a draft that has not been through its final read.

An auditor, an insurer or a buyer's security team asks the same thing about an agent: show me the evidence for this agent for last quarter. Today you would assemble that by hand from several Badge screens. The audit evidence export packages it for you: one bundle for one agent and one period, signed so the reader can check nobody edited it.

A bundle is **evidence for a reader to assess**. Badge does not certify that you, your agent or your vendor comply with any framework. The mapping table shows which requests the evidence can help answer, and says plainly where it cannot.

What a bundle contains [#what-a-bundle-contains]

You choose an agent and a period. A period is a start and an end date in UTC, counted from the start up to but not including the end, and it can be at most 366 days. A bundle holds only what falls inside the period.

| Part                     | What it is                                                                                                                                                                                              |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cover                    | One page saying what the bundle is, for which agent and period, when it was made, and which version of the mapping table it uses.                                                                       |
| Signed Agent Records     | Each [Signed Agent Record](/docs/methodology/validation#signed-agent-record) signed in the period, in the same form the public [/verify](/verify) page shows.                                           |
| Approvals                | Each [approval](/docs/guides/approvals) decided in the period, with the record-gate decision and the blueprint version it was bound to.                                                                 |
| Signed audit checkpoints | The signed checkpoints of the workspace [audit log](/docs/guides/audit-log) made in the period: sequence number, head hash, time, key and signature. **Checkpoints only. Never the log's events.** |
| Mapping table            | The table on this page, as it stood when the bundle was made, as a readable file (`mapping.md`) and a machine-readable one (`mapping.json`).                                                            |
| Manifest                 | `manifest.json` lists every file in the bundle with its SHA-256 hash and size, and carries Badge's signature over that list.                                                                            |

A bundle never contains audit log events, other agents' activity, blueprint version hashes or prompt text.

What the three statuses mean [#what-the-three-statuses-mean]

Each row of the mapping table starts as **not covered**. The bundle builder moves a row up only by looking at what that bundle really contains. A person never marks a row by hand.

| Status      | Meaning                                                                                          |
| ----------- | ------------------------------------------------------------------------------------------------ |
| provided    | The bundle holds every piece of evidence the row asks for. You still judge whether it is enough. |
| partial     | The bundle holds some relevant evidence. The row's limits say what it does not show.             |
| not covered | Badge holds no evidence for this control. This is the default.                                   |

Each row also has a **highest status**: the most the bundle can ever claim for that control, however much evidence it holds. Where a control is about the agent's own runtime, such as its tool calls or its outputs, Badge does not sit in that path, so the highest status is "not covered". In this first version no row has a highest status of "provided". That is deliberate.

Five kinds of evidence are named in the table: a Signed Agent Record, an approval, a signed audit checkpoint, a benchmark-pack score, and a summary of screening runs with drift history. A row is "partial" or "provided" only when the bundle holds the kinds its rule names for the period.

Version v0 bundles carry Signed Agent Records, approvals and signed audit checkpoints only. Pack scores and run summaries arrive in a later version, so a row whose rule can only be met with one of them reads "not covered" until then, whatever its highest status says. Records on secret tasks are counted but not embedded, because their signed bytes carry exact cost.

The mapping table [#the-mapping-table]

This is version v0. It covers three frameworks and only these three:

* **AIUC-1**, the standard behind the combined AICPA and AIUC assurance offering announced on 19 October 2026. Pilots are running and a full launch is expected in early 2027. Control ids are the published ids.
* **CSA Agentic STAR**, a draft certification scheme from the Cloud Security Alliance. It defines no numbered controls and no evidence format, so rows use its category names as ids.
* **EU AI Act, Article 12 and Article 26**, at paragraph level. Article 12 is a duty on the provider of a high-risk system to have it record events. Article 26 sets duties on its deployer.

The descriptions are our own short summaries. They are not the standards' wording, so read the standard itself for what a control requires.

| Framework        | Control                       | What it asks                                                                                                            | Highest status | Limits                                                                                                                          |
| ---------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| AIUC-1           | `E015`                        | Keep records of what the AI system and its agents did, protected against tampering, for investigations and audits.      | partial        | Badge logs workspace actions and signs the log head. It does not hold the agent's own tool calls or outputs.                    |
| AIUC-1           | `E004`                        | Name who is accountable for significant changes to an AI system and keep approval records with the supporting evidence. | partial        | Approvals tie named approvers to one blueprint version. Code signing of models and artifacts is not covered.                    |
| AIUC-1           | `C002`                        | Test the AI system internally before deployment and keep the test and approval records.                                 | partial        | Screening scores show performance, reliability and cost. They are not a full multi-risk test programme or a CI deployment gate. |
| AIUC-1           | `C008`                        | Keep monitoring the system's behaviour across risk categories and record what the monitoring found.                     | partial        | Covers score and drift history from screenings. It does not sample production outputs or feed a security tool.                  |
| AIUC-1           | `C007`                        | Route high-risk outputs to a person for review before anyone relies on them.                                            | not covered    | Approvals review an agent version before production. Badge does not see or flag individual outputs.                             |
| AIUC-1           | `D003`                        | Put technical limits on the tool calls an AI system can make, with logs and human approval for sensitive actions.       | not covered    | Badge does not sit in the tool-call path, so it holds no tool authorization config or tool-call logs.                           |
| AIUC-1           | `B006`                        | Stop an agent acting outside its intended scope or privileges, with monitoring and runtime containment.                 | not covered    | Runtime access limits, sandboxing and pre-execution checks live in the customer's own stack, not in Badge.                      |
| AIUC-1           | `E009`                        | Record and watch access by third parties, and assign an owner to unusual activity.                                      | not covered    | Badge does not record third-party sessions or API calls made to the agent.                                                      |
| CSA Agentic STAR | `identity-and-authorization`  | The agent has a distinct identity, and who may do what with it is defined.                                              | partial        | A Signed Agent Record identifies the agent and version in Badge. Credentials and access reviews are outside Badge.              |
| CSA Agentic STAR | `runtime-behavior-governance` | The agent's behaviour is watched in operation, and drift from its baseline raises an alert.                             | partial        | Screening and drift history only. Badge has no production behaviour telemetry.                                                  |
| CSA Agentic STAR | `tool-permission-governance`  | Tool permissions follow least privilege, and changes to their scope go through approval.                                | partial        | Shows approvals and signed workspace-change history. It does not show which tool permissions the agent holds at runtime.        |
| CSA Agentic STAR | `tool-permission-grant-logs`  | Grants of tool permission are kept in durable, tamper-evident logs.                                                     | partial        | Signed checkpoints cover Badge's workspace log. Grants made in the customer's own systems are not in it.                        |
| CSA Agentic STAR | `tool-invocation-logs`        | Every tool the agent calls is logged, kept for at least 90 days and reviewed.                                           | not covered    | Badge does not receive the agent's production tool-call logs.                                                                   |
| CSA Agentic STAR | `adversarial-testing`         | The agent has been tested against adversarial cases suited to its system type.                                          | not covered    | Badge benchmark scores are not an adversarial test suite.                                                                       |
| CSA Agentic STAR | `human-escalation`            | There is a defined path for the agent to hand a case to a person.                                                       | not covered    | Badge approvals gate versions, not live hand-offs inside the agent's workflow.                                                  |
| EU AI Act        | `art-12-1`                    | Article 12(1): a high-risk system records events automatically over its lifetime.                                       | partial        | A provider duty about the system's own event logs. Badge holds signed records and workspace checkpoints, not those logs.        |
| EU AI Act        | `art-12-2`                    | Article 12(2): the logs let the system's operation be traced for risk, monitoring and deployer oversight.               | not covered    | Needs the system's runtime event logs, which Badge does not hold.                                                               |
| EU AI Act        | `art-26-2`                    | Article 26(2): a deployer gives human oversight to people with the right competence and authority.                      | partial        | Shows who approved an agent version under the workspace policy. It does not show their training or authority.                   |
| EU AI Act        | `art-26-5`                    | Article 26(5): a deployer watches the system in use and reports risks and serious incidents.                            | partial        | Screening and drift history show performance over time. Incident reporting to providers or authorities is not covered.          |
| EU AI Act        | `art-26-6`                    | Article 26(6): a deployer keeps the system's automatic logs for an appropriate period.                                  | not covered    | Badge's checkpoints are not the system's logs, so retaining them does not meet this.                                            |

Control ids and what they ask were read from the published sources on 25 October 2026. The sources are:

* [AIUC-1 standard](https://standard.aiuc-1.com) and its control pages.
* [CSA Agentic STAR scheme, v1 page](https://labs.cloudsecurityalliance.org/agentic/agentic-star-ai-certification-scheme-v1).
* [Article 12, Record-keeping](https://artificialintelligenceact.eu/article/12/) and [Article 26, Obligations of deployers of high-risk AI systems](https://artificialintelligenceact.eu/article/26/).

What a bundle does not show [#what-a-bundle-does-not-show]

* **The agent's runtime.** Badge screens agents and records decisions about them in Badge. It does not receive the agent's production tool calls, outputs or logs, so it cannot show them.
* **Compliance.** No row says an agent complies with anything. A "partial" row is a pointer to evidence, not a finding.
* **Other frameworks.** ISO/IEC 42001 and SOC 2 are not in this version.
* **Events.** The audit log's events stay in the workspace. A bundle holds only the signed checkpoints.

Who can export, and when the button appears [#who-can-export-and-when-the-button-appears]

Exporting needs the **Team** plan, and only the workspace owner can export, because the audit checkpoints in a bundle are limited to the owner in the audit log itself. A bundle is capped at 10 MB, and a period that would pass the cap is refused with a request to narrow it. Each export is written to the audit log as one entry that names the agent, the period and the counts, never the content.

A bundle embeds the agent's full Signed Agent Records, including the verification hash that the public /verify page withholds for a private agent. That is why only the workspace owner on a Team plan can export one, and why every export is audited. Once exported, anyone holding the file can check every record in it, so share the bundle on purpose.

The Export button on the agent page will stay hidden until one outside reader has looked at a sample bundle. That reader is an auditor, an insurer or a design partner, and what they tell us is missing goes into the next version of the table. If you are one, write to [support@badgeia.com](mailto:support@badgeia.com).

Verify a bundle offline [#verify-a-bundle-offline]

You do not need a Badge account, and you do not need to trust where the file came from.

1. Fetch the public key set from `/.well-known/badge-verification-key.json`. Keys that signed earlier bundles stay published after a rotation, so an old bundle still verifies. Pick the key whose id matches `signature.keyId` in `manifest.json`.
2. Hash every file in the zip with SHA-256 and compare it with the hash listed for it in `manifest.json`. Every file must be listed, and no unlisted file may be present. No entry name may repeat, and every name must be a plain relative path (no `/` at the start, no `..`, no backslash).
3. Rebuild the signed bytes: the ASCII text `badge-evidence-bundle-v1`, one zero byte, then the manifest without its `signature` field as canonical JSON. Canonical JSON means keys sorted at every level, `,` and `:` as separators with no whitespace, and UTF-8 with non-ASCII characters left unescaped. The prefix keeps this key from validating anything else it signs, such as an [SBOM](/docs/guides/sbom) or an audit checkpoint.
4. Check the Ed25519 signature (base64url, in `signature.value`) over those bytes with the key from step 1.

Editing, adding or removing any file makes step 2 or step 4 fail. A valid signature proves Badge issued this exact bundle. It does not prove the agent is safe, and it does not prove the evidence is enough for your purpose.