Compliance & Regulatory Posture

What this document is (and what it isn’t)

If you need SOC 2 Type II attestation for Lictor as a vendor: that’s planned for Q2 2027. Until then, vendor risk should be assessed against the public source code, this document, and our public Trust Center page (when published).

SOC 2 Trust Services Criteria

Lictor’s products contribute evidence to the following SOC 2 TSC Common Criteria categories. The mapping below is what to put in your control matrix.

CC6: Logical and Physical Access Controls

CC7: System Operations

CC8: Change Management

The Lictor source code is open (Apache 2.0 for OSS components; source-available for Guardian). Every change is tracked in Git with cryptographic signatures from CI. Customers self-verifying our change controls should reference our public commit history at github.com/Raffa-jarrl/Lictor-AI.

CC9: Risk Mitigation

Sentinel + Shield + Guardian are defensive controls. They do not create new attack surface (Sentinel is an in-process middleware; Shield is a read-only browser extension; Guardian is an isolated SaaS). The wire-format privacy invariants ensure Lictor never accumulates the data it would need to be a high-value target itself.

GDPR: Article 32 (Security of processing)

Article 32 requires data controllers and processors to implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk.” Lictor’s products map onto specific Article 32(1) measures:

32(1)(a): Pseudonymisation and encryption

• Sentinel never transmits raw user content to Guardian. All telemetry uses 16-character SHA-256 fingerprints. This is a strong form of pseudonymisation by construction.
• All Sentinel↔Guardian transit is HTTPS (TLS 1.2+).
• Magic-link auth tokens are stored as SHA-256 hashes in the database; raw tokens never persist server-side.

32(1)(b): Confidentiality, integrity, availability, resilience

• Confidentiality: bearer-token authentication on every ingest call; no cross-account read paths in Guardian’s query layer.
• Integrity: append-only audit log enforced via Postgres trigger. UPDATE that modifies audit content + DELETE on audit_log raise a SQL exception.
• Availability: Guardian is a stateless web layer over Postgres; failover is a database-level concern.
• Resilience: documented incident-response runbook (Phase 4 deliverable; tracked in LAUNCH_PLAN.md).

32(1)(c): Restoration of availability

Guardian’s data model is fully reconstructable from Postgres dumps. Sentinel’s events are append-only and idempotent on the wire (events have stable ts + agent_id + content, so retries don’t double-count).

32(1)(d): Regular testing

• Lictor’s test suite covers the privacy invariants. The fingerprint round-trip is verified in CI. The wire-format schema is enforced in code via Zod.
• Public CI runs the full test suite on every commit. Test failures block merges.

32(2): Risks of accidental loss, alteration, disclosure

The wire-format privacy invariants make accidental disclosure of user content categorically impossible. The data Lictor collects cannot be reversed into the data it represents. This is design-level mitigation, not policy-level.

Data subject rights (Articles 15 to 22)

Right to erasure is implemented via cascading foreign keys: deleting an account row removes every related row (incidents, sessions, magic_links). The audit log persists with account_id nullified, which SOC 2 CC7.5 requires (incident communication evidence) but with PII anonymized. One DELETE satisfies Article 17 for a Lictor account.

EU AI Act: the relevant articles

The EU AI Act is in phased enforcement through 2026 and 2027. Lictor’s products are most relevant to providers and deployers of high-risk AI systems (Annex III categories) and to general-purpose AI providers.

Article 9: Risk management system

Article 9 requires high-risk AI providers to “establish, implement, document and maintain a risk management system.” Lictor’s role:

• 9(2)(a) Identification of risks. Sentinel’s check catalog provides a starting taxonomy of AI-specific risks (prompt injection, data exfil, unsafe tool calls, PII leakage). Guardian’s incident timeline tracks observed instances per deployment.
• 9(2)(b) Estimation and evaluation. Sentinel events carry severity (critical/high/medium/low/info); Guardian aggregates by severity for trend analysis.
• 9(2)(c) Post-market monitoring. Guardian is a post-market monitoring system. Audit log export satisfies the documentation requirement.
• 9(2)(d) Risk-management measures. Sentinel’s onTrip: 'block' and 'redact' actions are technical risk-management measures applied at the runtime boundary.

Article 12: Record-keeping

Article 12 requires automatic logging of events relevant to the operation of high-risk AI systems. Guardian’s incident store + audit_log together provide a technical record of the system’s risk-relevant events. Retention is configurable per account.

Article 14: Human oversight

Sentinel’s blocking and redaction modes provide automated detection, but the human-oversight requirement is a property of the deploying organization. Lictor enables Article 14, but it does not satisfy it.

Article 26: Obligations of deployers

Deployers must “monitor the operation of the high-risk AI system.” Guardian provides the monitoring substrate; the Slack webhook + audit log + per-incident drill-down provide the practical monitoring tools.

Article 50: Transparency obligations

For deployers using AI to interact with humans, Article 50 requires that humans be “informed that they are interacting with an AI system.” Lictor Shield can detect AI-agent surfaces on websites and inform end-users; this is one of the few consumer-side products in the AI security category that addresses Article 50 directly.

How Lictor aligns with the NIST AI RMF

The NIST AI Risk Management Framework maps cleanly onto Lictor’s product surfaces:

ISO/IEC 42001 (AI Management Systems)

ISO/IEC 42001 (published 2023) is the first AI-specific management-system standard. Lictor contributes evidence to the following clauses:

• 8.2 (Operational planning and control): Sentinel’s runtime checks
• 8.3 (Risk treatment): Sentinel’s blocking / redaction modes
• 9.1 (Monitoring, measurement, analysis): Guardian’s dashboard
• 9.2 (Internal audit): Guardian’s audit log export

ISO/IEC 42001 certification for the Lictor company itself is a Q3 2027 target, contingent on revenue.

What Lictor itself does for compliance

We’re a security company. Walking the talk:

• Open source where it doesn’t conflict with the business model. Apache 2.0 on core/, shield/, sentinel/, sentinel-py/. The patent grant in Apache 2.0 is what enterprise legal teams want to see.
• Source-available where the product IS the operations. guardian/ is published for review but licensed for hosted use only.
• Privacy-by-design wire format. No raw user content ever crosses the Sentinel→Guardian boundary; the architecture prevents data accumulation that would itself become a high-value target.
• CI enforced on every commit. cargo fmt --check, clippy with -D warnings, full test suite, both native and WASM targets.
• Append-only audit logs. Database triggers prevent tampering with audit content, even by a privileged operator. The only allowed UPDATE is FK-driven account_id = NULL (for GDPR Article 17).
• Coordinated disclosure policy. See SECURITY.md.

Trust Center (planned, Q1 2027)

Once Guardian has paying customers, the public Trust Center at lictor-ai.com/trust will publish:

• Real-time uptime / SLA metrics
• Vendor list (sub-processors)
• SOC 2 Type II attestation report (under NDA)
• Pen-test results (under NDA)
• Security questionnaire (CAIQ) pre-filled

If you need any of the above for vendor risk review and Lictor doesn’t yet have them: tell us. We prioritize Trust Center maturity by which deal it unblocks.

Questions / contact