Skip to content

Evidence workflow

Operational Evidence Vault

Some security controls cannot be proven by a repository or URL scan. The Operational Evidence Vault collects, reviews and versions the proof for the seven evidence-required Vibe Security 50 controls.

Last reviewed:

See the 7 evidence controlsRead the methodology

How evidence becomes assurance

  1. 01

    Submit

    Attach an attestation and encrypted artifacts for a control.

  2. 02

    Review

    A reviewer accepts, rejects or requests a revision.

  3. 03

    Version

    Every action creates a new version; the prior record stays frozen.

  4. 04

    Snapshot

    Accepted evidence is frozen into the private assurance report.

The seven evidence-required controls

These are the Vibe Security 50 controls a scanner cannot establish on its own. Each one becomes a card in the vault.

  1. Missing audit trails

  2. Missing monitoring and alerts

  3. Missing backup and recovery proof

  4. Missing agent sandbox and egress controls

  5. AI-generated test fabrication and blind spots

  6. Multi-agent propagation

  7. No accountable human review or threat model

What stays private

Encrypted artifacts
Files are encrypted before they reach object storage. The API never returns a raw storage URI.
Workspace isolation
RLS policies enforce that evidence is visible only inside the workspace that owns it.
Append-only versions
Revisions and reviews create new versions instead of overwriting prior evidence.
Checksum-bound snapshots
A private assurance report is written once per scan and report type, so it records the evidence state at creation time; public shared reports omit it entirely.

Questions

Why can't these controls be scanned?

Seven controls describe operational practice, not code: audit trails, monitoring, backup tests, sandboxing, test independence, multi-agent trust and accountable review. A scanner can ask for evidence of these, but it cannot safely observe or prove them on its own.

What does the Operational Evidence Vault do?

It creates an append-only, workspace-scoped record for each evidence-required control. You submit an attestation and any supporting files; a reviewer accepts, rejects or requests a revision; and every change creates a new version rather than overwriting the last.

Are artifact files stored securely?

Artifacts are encrypted before storage and never returned with a raw storage URI. The dashboard and API expose only sanitized metadata — filename, media type and byte length — inside the workspace RLS boundary.

Does accepted evidence mean the app is secure?

No. Accepted evidence means the submitted proof was reviewed and found adequate for that control. It is one input into an assurance report, not a guarantee that the app is secure, a formal attestation or proof against every possible threat.

Does this make LyraShield SOC 2 compliant, certified or adversarially robust?

No. LyraShield does not claim SOC 2 compliance, certification, security guarantees, AI safety testing (without a named framework) or adversarial robustness. Each of those requires external attestation, a reproducible evaluation corpus, a defined threat model or a formal certificate. The evidence vault supports the launch gate; it does not produce those claims.

What you can submit

Each control takes an attestation plus any supporting files. These are the artifacts reviewers most often accept.

Missing audit trails
A retention policy plus a sample export from your audit log covering a real change, with the timestamp and actor fields visible.
Missing monitoring and alerts
The alert rules you run and one alert that fired, showing the condition, the notification target and the time to acknowledge.
Missing backup and recovery proof
A restore runbook and a dated record of a restore test, including how long it took and what was verified after it finished.
Missing agent sandbox and egress controls
The sandbox and egress configuration your agents run under, plus one example of an outbound request that was denied.
AI-generated test fabrication and blind spots
A sample of AI-written tests next to the code they cover, with a note on which behaviours you verified by hand.
Multi-agent propagation
A trust map for your agents: which agent may call which, what each is allowed to change and where a human confirms before a write.
No accountable human review or threat model
A named reviewer or role, the approval step they own and a threat model or review checklist the team actually uses.

Start with a free check

Run a passive Lite Check, then start a free trial to collect evidence for the controls that matter most.

Run free Lite CheckStart free trial