Security and trust

How AIM protects organizational data

The application, identity, tenant-isolation, audit, AI-processing, and operational controls that protect AIM's enterprise assessment and governance record.

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 six operating roles plus three separately designated approval authorities. Permissions are checked server-side and at the database boundary — UI gating alone is never sufficient.

Owner

Full control: contract entitlements, members, audit logs, all assessment actions.

Admin

Manage members, view audit logs, all assessment actions.

Engineer

Author assessment inputs, system inventory, architecture working copies, and technical analysis.

Program Analyst

Develop procurement artifacts, affordability evidence, and governed acquisition records.

Reviewer

Review and disposition governed artifacts without becoming their author.

Viewer

Read authorized organizational records and exports without modifying governed data.

Procurement Approval Authority

Designated secondary budget and procurement approval official.

System Authority / DAO

Designated technical, security, and architecture risk-acceptance official.

Executive Sponsor / CTO

Designated leadership authority for final design and investment alignment.

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 duplicating compute or creating a second evidentiary 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]