Support

Security

How AIM protects your data and what you can expect from our security posture.

Scope & Data Model

AIM is a recommendations and project-tracking tool. We do not need PII/PHI/PCI to operate. Please avoid entering sensitive data; if it is entered, it is protected by the controls below.

  • Expected data: system names, constraints, vendors, modernization metadata.
  • Not expected: PII, PHI, payment data. Keep it out of free-text fields and uploads.

Infrastructure boundary:

  • AIM Application — Core app logic and APIs (Next.js on Vercel)
  • Supabase — Database, authentication, file storage (SOC 2 Type II)
  • Vercel — Application hosting (SOC 2 Type II)
  • Anthropic — LLM inference only, server-side; API data not used for model training (Security)

• Data encrypted at rest (AES-256) and in transit (TLS 1.2+)

• Data residency: US regions (Supabase, Vercel)

• DPAs available with Supabase and Vercel upon request

Shared Responsibility

  • You: Control what data you enter; avoid sensitive data; manage org membership; report issues.
  • AIM: Enforces auth, org scoping, RLS, role-based access control, validation, headers/CSP, server-only AI calls, rate limiting, and a cryptographic audit trail.
  • Vendors: Supabase (data/auth, encryption, RLS), Vercel (hosting, TLS), AI providers (model processing). We rely on their security attestations.

Key Controls

  • Supabase Auth + organization scoping + Row Level Security on every table.
  • Secrets in environment variables only; no service-role keys are ever exposed to the client.
  • TLS in transit; AES-256 encryption at rest via Supabase; security headers and CSP via Next.js middleware.
  • Input validation (Zod) and strict prohibition of eval, Function, and raw innerHTML with untrusted input.
  • All AI model calls are server-side only; no API keys are exposed to the browser.
  • Rate limiting on AI-intensive routes (recommendations, report generation) to prevent runaway usage.
  • Project Pulse public embeds use sanitized data, short-lived tokens, and a domain allowlist.

Role-Based Access Control

Every organization in AIM enforces a four-tier role model. Permissions are checked server-side on every API route — UI gating alone is never sufficient.

Owner

Full control: billing, members, audit logs, all assessment actions.

Admin

Manage members, view audit logs, all assessment actions.

Member

Create and work assessments; cannot manage members or billing.

Viewer

Read and export only; cannot generate reports, trigger AI, or modify any data.

External guest collaborators access individual assessments via email OTP — no platform account required. Guests cannot trigger AI pipelines, generate reports, or view other assessments. Every guest session is token-scoped and logged.

Cryptographic Decision Auditability

Every recommendation run and report generation produces a tamper-evident audit record. Reviewers can independently verify that outputs match the inputs that produced them.

  • Input hash: SHA-256 of normalized assessment inputs (constraints, environment, scope areas, staffing profile). Keys are sorted deterministically before hashing to guarantee reproducibility.
  • Output hash: SHA-256 of ranked recommendations with RAO scores and dimension breakdowns.
  • Decision snapshots: Each unique input/output pair is stored once (content-addressed). Identical inputs return the cached snapshot without consuming a credit or creating a new record.
  • Append-only audit log: Every run is written to a decision_runs table that records who ran it, when, which methodology version was used, data freshness at the time, and the full explainability payload.
  • Attestation hashing: Project Pulse milestone attestations are independently hashed for tamper detection.
Why this matters: In government procurement and regulated environments, decision-makers need to prove that a recommendation was produced by the inputs stated — not adjusted after the fact. AIM's cryptographic trail provides that assurance without requiring a third-party auditor.

Audit & Activity Logging

Comprehensive audit logging is active across the platform:

  • Decision runs: Every recommendation and report generation is logged with actor, timestamp, methodology version, and hashes.
  • Assessment changes: Field-level edits to assessment data are logged with before/after values.
  • Collaborator access: Every guest collaborator invite, access, and revocation is logged at the assessment level.
  • Org-wide activity: Owners and Admins can view a full organization activity log from the Team dashboard.
  • Per-assessment access log: The Collaborators panel in each assessment workspace shows a complete access history, visible to Owners and Admins.

Compliance Posture

  • SOC 2 Type I → Type II: in progress; evidence collection and control mapping underway.
  • NIST CSF: maintaining a crosswalk to show coverage and gaps.
  • Vendor attestations: leverage Supabase, Vercel, and AI provider security reports in a shared-responsibility model.

Questions?

If you have questions about our security practices or need additional documentation for compliance purposes, please reach out.

Contact: [email protected]