Appearance
Security Controls v3.9
Last updated: September 30, 2026
Authentication
AI4Love uses passwordless, invite-only authentication in two layers:
- Identity verification — Clerk (SOC 2 Type II) sends a one-time code to the staff member's work email. There are no passwords.
- Session token — After identity verification, the backend issues an AI4Love JWT with a 24-hour expiry. This token governs all subsequent API access.
Access is invite-only. The user's email must exist in the organization's working base or the Admin Accounts table before they can sign in. AI4Love holds no client passwords and no directory credentials; nothing is federated to the client's identity provider.
MCP Access Model
The MCP (Model Context Protocol) server lets AI assistants query supporter data conversationally. See the full MCP Access Model page for the complete tool inventory; the summary relevant to security posture:
- Credentials: Access is granted via an OAuth token (OAuth 2.1 with PKCE, signed in with the staff member's personal access key) or a provisioned per-org API key, not an individual's Airtable login. Tokens are bound to the MCP server's own address, carry the read permission only, expire after 30 minutes, and refresh for at most 30 days from sign-in, with the staff account rechecked on every refresh.
- Timing-safe validation: Keys are compared using constant-time algorithms to prevent timing attacks.
- Revalidation on every request: Both transports check the credential on each request; an SSE session only pins the organization. Removing an API key stops access at the next request. Removing a staff member's access key stops their OAuth session at its next refresh, within 30 minutes.
- Organization isolation: Each request resolves to a specific org, which maps to a dedicated working base and credential set. Users in Org A cannot access Org B's data.
- Read-only: All 40 authenticated MCP tools are read-only by behavior. No MCP tool can create, modify or delete Airtable records, Pinecone vectors or any other data, and there is no write permission to request.
- Sign-in challenge: Unauthenticated or invalid requests receive an HTTP 401 with a standard
WWW-Authenticatechallenge, never data.
Query Safeguards
Individual tools apply their own response bounds (e.g., export_supporters defaults to 100 records per call). A fixed per-key request quota, daily retrieval cap, and automated anomaly detection are not currently enforced in application code across the MCP surface — we're stating that plainly rather than publishing numbers the code doesn't back up. Per-key call volume quotas can be applied at the Vercel layer (deployment-level rate limiting) on request and verified before a number is published for your account; they are not enforced in application code.
OAuth Connection Model
AI4Love connects to external platforms through Nango, an enterprise OAuth gateway.
| Platform | Auth Method | Scopes / Access |
|---|---|---|
| Blackbaud RE NXT | OAuth 2.0 (refresh token) | SKY API read access — constituents, gifts, actions, events |
| Mailchimp | API Key | Read access to member lists, campaigns, activity |
| Environics | OAuth 2.0 (client credentials) | Postal-code-level enrichment (PRIZM, WealthScapes) |
Your organization initiates each connection. AI4Love never connects without explicit staff authorization. All connections can be revoked instantly from the Integrations dashboard.
AI4Love Internal Access Controls
Access to your organization's data by AI4Love personnel is governed by the principle of least privilege.
- No standing access: AI4Love staff do not have persistent access to any organization's working base. Access is granted only when required for support, debugging, or onboarding — and only with your knowledge.
- Role-based access: Internal access is restricted to authorized personnel. Infrastructure credentials are scoped by function (e.g., deployment credentials cannot access Airtable data).
- Time-bound: Support access is granted for the duration of the issue and revoked upon resolution.
- Logged: All administrative actions (deployments, credential rotations, configuration changes) are logged in Vercel and Doppler audit trails.
Rate Limiting
| Scope | Limit |
|---|---|
| Global | 200 requests/minute |
| Auth routes | 10 requests/minute |
| API routes | 60 requests/minute |
| MCP | Tool-specific response bounds only; no fixed per-key application quota currently enforced (see MCP Access Model) |
Audit Logging
1. Application audit stream
Backend [audit] and MCP [MCP] lines are retained in Vercel runtime logs for one day and streamed to Axiom for 30 days on its Personal plan. The Log Drain was added September 14, 2026 and covers ai4love-backend and stilltide-mcp only.
Together, application events and Vercel request metadata record the route or tool, authentication method, organization, status, timestamp, duration, caller IP, and user agent. Staff email addresses are included as the actor identifier for dashboard/API events. The backend line contains timestamp, staff email, organization, HTTP method, path, status, and duration; the MCP line contains tool, authentication type or error code, organization, staff account ID (OAuth), client ID and client host label (for example claude or chatgpt), granted scope, token audience, status, and timestamp. Caller IP and user agent are request metadata, not fields in those application lines. MCP tool-level duration and record counts are not emitted in the [MCP] line. Credentials, request/response bodies, and supporter data are not included in the audit stream.
Coverage gap: Dashboard and API audit lines were not emitting between February 14 and September 9, 2026. They were restored September 9, 2026. MCP audit lines were unaffected. The September 14 Log Drain does not recover events from that gap or extend retention retroactively.
2. Clerk authentication events
Clerk records authentication events, including failed one-time-code attempts and device and IP metadata. These are staff authentication records, separate from the application audit stream; their availability and retention follow Clerk's account controls, not Axiom's 30-day retention.
3. Per-organization Access Log — planned
An Access Log table in the working base is planned and ships before first client go-live. It will record supporter record views, exports, and integration changes with staff identifier, event, record IDs, and timestamp. It is not yet a shipping record-level access history. Retention will follow the working base's active-service period plus the 90-day exit window.
Other operational records
| What Is Logged | Where | Retention |
|---|---|---|
| Integration sync events (platform, record counts, errors) | Backend Vercel runtime logs and Axiom | One day in Vercel; 30 days in Axiom |
| OAuth connection/disconnection events | Nango audit log | Per Nango retention policy |
| Credential access and rotation | Doppler audit trail | 90 days |
| Deployment and configuration changes | Vercel deployment log | Indefinite |
| Agent run costs (tokens, USD, insights generated, model) | Airtable Engine Logs table in the working base | Working-base retention policy |
| Insight verification results (verified/mismatch/unverifiable, field comparisons) | Each Insight record in the working base | Working-base retention policy |
Audit logs are available to your organization on request. AI4Love does not run continuous third-party security monitoring; detection relies on provider logs and reported issues. Automated alerting is on the security roadmap.