compliance · SOC 2
Wytness and SOC 2
Common Criteria evidence for the AI-agent activity in your audit scope.
A Type II audit asks whether controls operated effectively over time. Where those controls touch AI agents, Wytness produces the evidence: your CPA firm reads Evidence Packs into their working papers and runs the audit against your environment. Wytness itself is not SOC 2 certified — a separate attestation that wouldn't change what your auditor reviews; the vendor attestations we do hold are at /security.
the artefact
What's in the pack
Agent inventories, role-and-access snapshots, anomaly history with resolutions, signed event samples per control, and a control-by-control narrative your CPA firm can drop into their working papers. Period defaults to the trailing 12 months.
Every claim in the pack is traceable: each control cites the events behind it, and each event carries the signature your own key produced. The pack is sealed, so an auditor can confirm it reached them unaltered.
A real sealed pack is published — nothing here is a mock-up. Download the specimen and check it yourself on the verify page, in your browser, without uploading it.
// What the pack asserts about itself:
// control_mapping[] — 12 criteria, each carrying
// its evidence and a metric measured over your period:
…// + 8 more, in the table below
// Every control cites events an auditor can re-verify:
the mapping
What we map to what
| Control | Criterion | What Wytness provides |
|---|---|---|
| CC1 | Control environment | Customer-visible Roles & Permissions documentation at /docs/roles-permissions (four-tier RBAC: viewer / member / admin / owner, enforced server-side via require_role()); audit catalog at /docs/audits showing which audits Wytness runs and on what cadence; superadmin role is platform-level and audit-logged via platform_audit_log on every action. |
| CC2 | Communication and information | In-app notification bell with severity classification (critical / high / medium / low / info) and per-user read tracking; transactional emails (account verification, password reset, security alerts) routed via dedicated transactional-email provider; platform_audit_log gives the customer a tamper-evident communication-of-controls record for every admin action. |
| CC3 | Risk assessment | Per-org anomaly rate visible on Overview + Anomalies page; chain-integrity status surfaced via the customer's Verify page with explicit TAMPERING_DETECTED / VERIFICATION_PENDING / VERIFIED states; Agent Registry auto-discovers new agents into a pending-review queue (auto_discovered → pending_review → approved/deprecated) so the customer's compliance team can risk-classify new agents (minimal / limited / high / prohibited under EU AI Act conventions, applied for any framework). |
| CC4 | Monitoring activities | Data integrity checker runs three-way reconciliation every 4 hours across ingest counts, ClickHouse query store, and Blob durable archive; integrity_summary per org exposes degraded/critical state with reasons; customer-facing DataIntegrity banner surfaces gaps without requiring operator action; the audit run registry shows each audit's last-run state and findings. |
| CC5 | Control activities | Role-based access control enforced server-side (no UI-only gates); ConfirmActionDialog on destructive actions requires typed resource name + password re-entry; every admin write (plan change, role promotion, deactivate, key revoke, chain-break resolution) appends an audit-log row with actor + target + IP + user-agent + approval-chain metadata. |
| CC6.1 | Logical access security | API key authentication (hashed at rest, constant-time comparison), per-org data isolation enforced via the WHERE-clause linter, Ed25519 event signing with customer-held private keys. |
| CC6.6 | System boundaries | SDK-level signing before events leave the customer environment, ingest schema validation, org-scoped data isolation with pinned cross-tenant test coverage. |
| CC7.1 | Detection of anomalies | 7 anomaly detection rules (from the platform's published anomaly-rule catalogue) covering first-time tool use, frequency spikes, error rates, restricted-data access, off-hours activity, hash-chain breaks, and capability-profile deviation; a separate integrity checker adds two three-way data-integrity reconciliation rules (query-store and archive gap detection). |
| CC7.2 | Monitoring system components | Synchronous event processing on POST /ingest → ClickHouse + Blob archive, per-event Ed25519 signature verification before persistence, cryptographic hash chain verification per agent (live + on-demand via /verify). |
| CC7.3 | Evaluation of anomalies | Anomaly acknowledge workflow with severity classification (critical / high / medium / low), 4 terminal resolution statuses (approved / sdk_restart / false_positive / other), password-gated terminal moves, full audit trail of every state change. |
| CC8.1 | Change management | Agent version tracking via sdk_version field on every event; agent_instance_id pins per-deployment identity; Agent Registry with approval workflow; signing-key registry with retire/revoke + time-windowed verification. |
| CC9 | Risk mitigation | chain_break_resolutions workflow gives the customer triage tooling for cryptographic anomalies (signature_invalid = tampering proof; chain_link_mismatch = SDK-restart class); retention reaper enforces customer-promised retention windows on PG-side metadata; poison-events DLQ preserves events that failed processing so nothing is silently lost; rebuild-from-blob path (operator-initiated) restores ClickHouse from the durable archive when needed. |
the boundary
What Wytness does not cover
- —Wytness covers the AI-agent activity subset of your SOC 2 scope. It does not replace your broader SOC 2 control evidence (HR controls, vendor management, physical security).
- —SOC 2 attestation requires controls operating over a period (typically 6 to 12 months). Wytness evidence supports that audit; the audit itself is done by a CPA firm we don't replace.