Security and evidence

AOS Core governs actions routed through its control plane and runtime, and records evidence for review. Agent messages, tool output and recorded payloads are treated as untrusted data.

Documentation · Getting started · Downloads · Contact

Review evidence safely

The audit console shows recorded event contents as plain text. It does not render agent-supplied HTML, SVG, Markdown or mathematical notation. Direction and control characters that could disguise displayed text are shown as visible escape sequences. The underlying export retains the original values.

The console also applies a browser Content Security Policy that restricts scripts and forms to its own origin. These controls reduce opportunities for agent output to alter the review page. They do not establish that every agent action was observed or that the reviewer’s computer is uncompromised.

Export a matching signed snapshot

When a deployment has configured its signing key, AOS can export the current ordered tenant audit records and a signed checkpoint together. Both describe the same snapshot, even if new events arrive during export.

Use the console’s Audit → Export signed evidence, or use the CLI with your existing server URL, tenant and identity token file:

aos product --output ./audit-evidence.json audit --signed

The console downloads JSON. The CLI writes a private JSON response file and refuses to overwrite an existing file. Neither export executes agent content. Treat exported records as potentially sensitive and keep them out of public issues or marketing analytics.

Signing must be configured by the deployment operator. The default local evaluation does not configure an audit signing issuer; it still produces ordinary evaluation evidence. A request for a signed export fails when signing is unavailable. A download button or a signature alone is not proof that evidence is complete or trustworthy.

Verify outside the viewer

Obtain the expected issuer, tenant and approved key fingerprint through a trusted channel from your administrator. The verifier needs the corresponding public trust bundle. Do not trust a new fingerprint just because it appears beside the evidence you are checking.

With those values configured, run:

aos trust verify-evidence \
  --bundle-file ./audit-evidence.json \
  --trust-bundle ./aos-control-trust-bundle.json \
  --issuer "$AOS_EXPECTED_ISSUER" \
  --fingerprint "$AOS_PINNED_FINGERPRINT" \
  --tenant "$AOS_TENANT_ID"

A successful result includes status: verified and content_verified: true. The check compares the signature, expected tenant and ledger, ordered event count and content digest. Altered, omitted, duplicated or reordered records fail against the retained checkpoint. A failure requires investigation; it should not be “fixed” by approving a different key or generating a new checkpoint over the suspect file.

Verification confirms that the supplied records match a commitment made by the trusted signer. It does not prove that an agent’s claims are true, that bypass actions were recorded, or that the signer and database were trustworthy when the commitment was made.

Retain evidence independently

Keep signed exports and checkpoints in a separately administered evidence store. Restrict agent and runtime identities from writing audit storage, changing monitoring configuration or reading signing keys. Production operators must configure those permissions, storage retention and recovery procedures.

The reference file audit store validates its existing hash chain before reading or appending and rejects damaged or duplicate records. New reference files use private permissions. A valid local hash chain cannot detect an attacker who removes history and rebuilds the entire chain. A fresh signature over altered history cannot replace a previously trusted checkpoint. Independent retention and comparison are required to investigate those changes.

Know the execution boundary

Consequential governed execution requires durable audit admission before the provider is invoked. Audit admission failure blocks that step. Optional telemetry has different failure semantics: its loss is recorded as degradation and does not itself stop execution.

AOS governs the actions routed through it. Operators must restrict alternate credentials and network paths when they require agents to use that boundary exclusively. Start with a non-production integration and verify permitted actions, denied actions, uncertain outcomes and evidence export before expanding authority.

Assurance status

AOS Core is under active development. The evaluation release includes adversarial checks for malicious display content, altered or omitted evidence, tenant mismatches, incorrect trust anchors and damaged reference audit records. These checks are not an independent security audit, certification or production-readiness guarantee.

For a suspected security issue, use the contact form to arrange a private exchange. Include the version and a short description; do not include credentials, private keys, customer records or a complete audit archive in the first message.