AI4Love Trust Center

Appearance

Changelog v3.9 ​

Last updated: September 30, 2026

Real system updates. Not marketing.

2026-09-30 — Trust Center v3.9: Read-Only MCP and OAuth Hardening ​

  • MCP is read-only. AI4Love MCP exposes 40 authenticated tools, all read-only by behavior. Supporter/source-system records and AI4Love working records are not writable through MCP. The two narrowly gated write tools listed since v3.1 (add_to_kindmind and mark_campaign_refined) were removed, along with the per-call approval described in v3.6. There is no write permission a client can request. MCP Access Model, System Architecture, Security Controls, Controls, Data Handling, Overview, Ten Questions Q2 and Sub-Processors (Pinecone) now say so.
  • OAuth tightened. 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. Sign-in uses OAuth 2.1 with PKCE and the staff member's personal access key.
  • HTTP 401 challenge. Unauthenticated or invalid requests to the MCP server now receive an HTTP 401 with a standard WWW-Authenticate challenge instead of an MCP-level error and three diagnostic tools. whoami now requires sign-in. Only /health is public.
  • Revocation wording corrected. Removing an API key stops access at the next request. An assistant signed in with OAuth stops at its next token refresh, within 30 minutes. Earlier text said MCP revocation was immediate, and that an SSE session could outlive its token; both are corrected. Every MCP request, including on SSE, carries and checks a credential.
  • Audit fields. [MCP] lines now also record the staff account ID, client ID and host label, granted scope and token audience. Security Controls, MCP Access Model and Sub-Processors (Axiom) list them.
  • LLM data path clarified. On the MCP path the model is the staff member's own Claude or ChatGPT assistant under their workspace terms; the API-tier terms apply where AI4Love itself calls the providers.

2026-09-15. Trust Center v3.8: Bounded Retention ​

  • Principle renamed Bounded Retention (formerly Zero Custody / Bounded Custody). The working base is held in AI4Love's account as service provider; the client remains the FIPPA-responsible institution.
  • All infrastructure is US-hosted. Canadian data residency is not currently available.
  • Q1, Q9 and internal retention links now match the current model. Owned Copy remains planned.

2026-09-14 — Trust Center v3.7: Residency Correction, Axiom Log Drain, and Audit Logging ​

  • Residency corrected throughout: All AI4Love infrastructure is US-hosted. Canadian data residency is not currently available. Airtable and Pinecone use AWS us-east-1; Vercel functions use iad1; Make uses us2; Axiom uses us-east-1; Anthropic and OpenAI API-tier processing is in the US. Nango and planned organization-mirror wording now states the actual hosting boundaries without implying a Canadian option. Overview navigation, Ten Questions Q9, Sub-Processors, Requests & Contact, and earlier changelog claims are aligned.
  • Axiom added to Sub-Processors: Application audit events and Vercel runtime logs from ai4love-backend and stilltide-mcp only, in AWS us-east-1. Audit fields and request metadata include route or tool, authentication method, organization, status, timestamp, duration, caller IP, user agent, and staff email as the dashboard/API actor identifier. No supporter data. SOC 2 Type II verified on Axiom's Trust Center; Personal-plan retention is 30 days.
  • Vercel corrected: Function region is pinned to iad1 in the backend API and MCP server vercel.json files. The Vercel row links to Axiom. The Log Drain was added September 14, 2026; runtime logs remain available for one day in Vercel and 30 days in Axiom.
  • Airtable plan and snapshots corrected: The live AI4Love workspace is on Team, verified September 14. Snapshot retention is up to one year, per Airtable's current documentation. Data Handling, Sub-Processors, and the IT Security Brief now use that value.
  • Three logging layers documented: Application audit stream (backend [audit] and MCP [MCP] lines with Vercel request metadata), Clerk authentication events (including failed one-time-code attempts and device/IP metadata), and the planned per-organization Access Log in the working base. Security Controls, Ten Questions Q10, MCP Access Model, Controls, and Data Handling now agree on scope and retention. Application fields are distinguished from request metadata; MCP lines do not emit tool-level duration or record counts.
  • Audit-line gap disclosed: Dashboard/API audit lines were not emitting between February 14 and September 9, 2026; restored September 9. MCP audit lines were unaffected. The September 14 drain does not recover missing historical events.
  • Access Log marked planned: Ships before first client go-live; records supporter record views, exports, and integration changes with staff identifier, event, record IDs, and timestamp. Added to Data Retention; follows working-base retention.
  • Cross-page consistency: All 12 pages and the footer now carry v3.7 and September 14, 2026. The repository-wide residency/logging review also corrected the IT Security Brief and backend logging comment, annotated the historical implementation plan, and updated the live verification checks.

2026-09-09 — Trust Center v3.6: Suppression, Identity, Retention, and Live Artifacts ​

This release documents controls that shipped between September 3 and September 9 and closes the gaps found in the August 31 Live Artifacts review. Where a claim on this site was ahead of the code, the entry below says so.

  • Suppression and source deletion (Data Handling, new section): do-not-contact and no-solicitation codes carry over from the source system on the nightly sync, are enforced server-side before any model call, and close open insights for the person. Source-system deletions and merges are removed on request within 5 business days with written confirmation during pilot phase; automatic propagation is on the roadmap. Erasure requests received directly by AI4Love are routed to the client as data controller. Every removal, merge, and suppression close is recorded in an operations log that never holds the person's name or email.
  • Identity (Data Handling, new section): the source constituent/record ID is the primary matching key for CRM sources, email the fallback. Email changes update the record in place; duplicates are merged with suppression flags preserved and merges logged.
  • Retention rows added: Airtable trash (records 7 days, bases 30 days), base snapshots (restore-only, up to 1 year on our Team plan, corrected in v3.7, never queried, logged deletions re-applied before a restored base returns to service), Pinecone (AWS us-east-1, no supporter data, client vault purged at end of service), and device-level artifact caches on staff devices.
  • Residency correction (superseded by v3.7): The residency claim published in this release was incorrect. All AI4Love infrastructure is US-hosted; Canadian data residency is not currently available. See v3.7 above.
  • Sub-processor scope notes: Nango holds source-system OAuth credentials only; Clerk holds staff account data only. Client-side assistant use (a staff member's own Claude or ChatGPT through MCP) is now distinguished from API-tier processing by AI4Love.
  • What the AI sees, one wording everywhere: "a constrained payload: supporter name, detected pattern type, supporting metrics, and the activity timeline."
  • Authentication and logging restated: passwordless, invite-only (Clerk one-time code to the staff member's work email, 24-hour JWT sessions), no client passwords or directory credentials held. Application requests on the dashboard and API are logged as one org-scoped line each in Vercel runtime logs, retained one day, with the external drain not yet added at this release. Axiom was added September 14, 2026 (v3.7). That log line had been removed in a February cleanup and was restored on September 9; MCP request logging was unaffected. AI4Love does not run continuous third-party security monitoring. Incident timeline unchanged (4 hours, 72 hours, 14 days).
  • Content Integrity Policy v2026-09-09: fund, appeal, campaign, and designation codes are giving facts, never motives. Nightly insights that infer a condition, diagnosis, or personal reason behind a gift are discarded server-side; campaign drafts have the sentence removed and the removal reported.
  • Post-generation verification corrected to "each new insight": until September 9 the verification field had no options and every verification write failed silently, so insights written before that date carry no status. The options now exist and new insights are badged. Earlier insights are not backfilled.
  • Per-key call volume quotas: available at the Vercel layer on request; still not enforced in application code, as stated since v3.1.
  • mark_campaign_refined via artifact refresh: requires per-call approval from the staff member.
  • Channel restrictions on person cards and insights: the source system's solicit codes and do-not-contact flag now appear on get_supporter, on insight payloads, and in the agent's timeline, so staff see a channel block before drafting.
  • Requests & Contact: a Removal and erasure procedure row points to the new Data Handling section.

2026-09-03 — Trust Center v3.5: Public Sub-Processor, Ten Questions, and Controls Pages ​

This release moves three documents evaluators ask for most from "available on request" or scattered across pages into public, linkable pages. No system behavior changed. Every claim on the new pages is drawn from text already published here. Where the site is candid about a gap, the new pages repeat the gap.

  • Sub-Processors page (new): The canonical list of every third-party provider, with role, data touched, region, certification, and retention notes. Clerk and Resend appear on this site for the first time.
  • Ten Questions page (new): Short answers to the ten questions IT, privacy, and procurement teams ask first, each linked to the page that documents it.
  • Controls page (new): A one-page list of controls, split into those AI4Love owns in its own code and process and those inherited from providers. It opens by stating that AI4Love holds no SOC 2 or ISO 27001 certification of its own and that penetration testing is on the roadmap.
  • System Architecture provider table replaced with a pointer: The Infrastructure Providers section now links to the Sub-Processors page as the single source of truth, so the two lists cannot drift.
  • Requests & Contact: The Sub-Processor List row now links to the public page instead of "available on request", and the sub-processor list is added to the What Is Never Gated section. The link text "Infrastructure Dependencies" was corrected to "Infrastructure Providers" to match the heading it points to.
  • Privacy mailbox: A dedicated privacy@ai4love.ca mailbox now exists. Document requests, privacy and DPA questions, security questionnaire requests, security concerns, and urgent security reports go there. General inquiries stay with hello@ai4love.ca.
  • Nango residency wording (superseded by v3.7): This release discussed vendor hosting alternatives that AI4Love does not offer. Nango is US-hosted; Canadian data residency is not currently available by AI4Love.

2026-08-19 — Trust Center v3.4: Overview Navigation Correction ​

One line survived yesterday's audit that should not have. The Overview page's navigation table still summarized the Requests & Contact page as offering "SOC 2 reports, pen test results, DPA templates" — pre-v3.3 wording that contradicts what that page (and v3.3 below) actually says: AI4Love holds no SOC 2 certification of its own, and no third-party penetration test has been completed. The summary now reads "DPA templates, sub-processor SOC 2 attestations, and security questionnaire responses," which matches what is genuinely available on request.

2026-08-18 — Trust Center v3.3: Roadmap Honesty Pass ​

This release corrects claims that described planned or partially built capabilities in the present tense. The audit behind it checked every verifiable claim on this site against the actual application code, the Make.com scenario list, and the live deployment.

  • Penetration testing: Previous versions listed "Penetration Test Results" as available under NDA. No third-party penetration test has been completed. Penetration testing is on our security roadmap; results will be shared with partner organizations upon completion, and we welcome scoping input from partner security and privacy teams.
  • Organization mirror ("Owned Copy"): v3.2 described a nightly publisher job syncing records and insights to a file your organization owns. That publisher is designed but has not shipped. it is not running in production, and no organization currently has a mirror. The Overview, Data Handling, System Architecture, and Failure Modes pages now describe it as a planned capability, available to be provisioned per organization. Full exports of the working base remain available on request at any time, and the bounded-retention model (90-day exit window, deletion on request) is unchanged and accurate.
  • Incident detection: "Continuous automated monitoring of error rates, auth failures, and anomalous access patterns" overstated what runs today. Detection currently relies on provider logs (Vercel, Nango, Doppler) and reported issues; automated alerting is on the security roadmap. Containment, notification, investigation, and remediation timelines are unchanged.
  • SSE session expiry: Previous versions claimed SSE sessions end when the underlying OAuth token expires (max TTL 60 minutes). That expiry is not enforced in application code — an SSE session ends on disconnect or serverless instance recycling, and can outlive its token while the connection stays open. The pages now say so and point to disconnection and key removal as the effective controls. Streamable HTTP (the default transport) revalidates credentials on every request, as previously stated.
  • Vendor questionnaires: "Pre-filled responses" to SIG Lite / CAIQ / HECVAT implied finished documents exist. Reworded: responses are completed on request.
  • Insight pattern validation now enforced in code: Previous versions said agent insights were "validated against the pattern type before being saved" — a claim the code only partially backed. That validation now runs server-side on every nightly agent insight before anything is returned for writing: the supporter must be in the batch that was actually analyzed, the pattern must be one that agent detects, the pattern's eligibility thresholds are re-checked against the supporter's real timeline data, and any metrics the insight claims must match reality. Contradicted insights are discarded and logged, not written.
  • Research-enrichment agent status: The seventh core analysis agent (research enrichment) is built and tested but activated per organization — it runs only where research enrichment is in use. Pages that implied all seven agents run nightly for every deployment now say six nightly plus one per-organization.
  • MCP tool table recount: The category table on the MCP Access Model page summed to 39 while the (correct, code-verified) total said 42. The table now lists all 42: 3 diagnostics + 10 supporter/activity + 15 intelligence/operations + 3 research/schema + 1 guidance + 8 visual scenes + 2 gated writes.
  • Requests page stamped: The Requests & Contact page now carries the same version badge and last-updated date as every other page.

2026-07-28 — Contact Address Correction ​

  • Contact mailbox corrected: v3.1 fixed the contact domain (ai4love.org → ai4love.ca) but pointed to info@ai4love.ca, a mailbox that does not exist. The monitored address is hello@ai4love.ca, and the Requests & Contact page now says so. If you emailed info@ and heard nothing back, that is why — resend to hello@ and we will respond.

2026-07-22. Trust Center v3.2: Bounded Retention Model Correction ​

This release corrected the earlier no-storage claim with a working-base model and a planned organization-held copy. The previous framing implied AI4Love holds no independent store of your data at all. That stopped being true once the working base existed to run nightly analysis. and continuing to describe it as no storage was the wrong kind of marketing, not an accurate description of the system.

  • Bounded Retention. the working base: AI4Love operates a dedicated Airtable working base per organization, held in AI4Love's own account, that holds the normalized supporter, activity, insight, and workflow records nightly analysis requires. It exists only while your service is active, plus a 90-day exit window after cancellation. during which you can request reactivation, a full export, or immediate deletion. after which it is deleted. The working base is held by AI4Love as service provider.
  • Owned Copy (planned; earlier shipping claim corrected): This release described a nightly publisher as shipped. That was incorrect. An organization-held mirror is designed but not running in production. A full export of the working base is available on request.
  • Source systems unchanged: Blackbaud, Mailchimp, and Environics remain read-only and are never modified — this was true before and remains true now.
  • Updated throughout: Overview, Data Handling, System Architecture, MCP Access Model, Security Controls, Failure Modes, and Requests & Contact pages have been revised to reflect the two-store model — including the data-flow component list, connection tables, retention tables, permission scoping, and recovery guarantees.

2026-07-21 — Trust Center v3.1: MCP Accuracy Correction ​

This release corrects several claims on the MCP Access Model and Security Controls pages that no longer matched what the code actually enforces. We'd rather publish an accurate, more cautious page than a confident, stale one.

  • MCP tool count and scope: Corrected from "19 read-only tools" / "21 read-only tools" to the current, verified count — 42 tools for authenticated clients (3 diagnostic + 31 supporter/intelligence/research tools + 8 visual-scene tools), of which 40 are read-behavior only. The remaining 2 are narrowly gated write tools — add_to_kindmind (curated research → Pinecone, allowlisted curator orgs only) and mark_campaign_refined (organization-scoped Generated Campaign metadata → Airtable). Neither writes supporter source data. Previous versions of this page claimed MCP was entirely read-only; that stopped being accurate once these two tools shipped, and the trust center wasn't updated to reflect it until now.
  • MCP rate limiting claims removed: Previous versions published specific numbers — 60 requests/minute per key, a 5,000 records/24h daily cap, and automated anomaly detection. None of these are currently enforced in application code. We've replaced the specific (incorrect) numbers with an accurate statement: individual tools apply their own response bounds, but no fixed per-key quota or anomaly detection exists today.
  • MCP audit log fields corrected: Previous versions claimed logs include "records returned" and "response time." The actual log entry contains tool name, org ID, auth type/error code, result status, and timestamp — no record counts, no response times, no credentials, no response bodies.
  • Data minimization framing corrected: Previous versions described MCP as applying a single "allow-list filter" that blocks all undeclared fields, including new ones, across every tool. In practice, most tools hard-code the fields they render (a real, effective projection), but get_schema and export_supporters are intentionally broader — export_supporters in particular accepts a caller-specified field list and is not currently constrained to a fixed allow-list in code. This page now calls that out directly instead of implying uniform filtering.
  • Airtable credential model corrected: Previous versions described a formal Airtable "Service Account" with "Editor" collaborator permissions. The actual model is a scoped Personal Access Token or provisioned service credential issued per organization; write restrictions are enforced by application code, not an Airtable-native permission tier.
  • Data residency claims (corrected in v3.7): This release incorrectly described Canadian hosting options. AI4Love infrastructure is US-hosted; Canadian data residency is not currently available.
  • Vercel log retention corrected: Vercel Pro retains runtime logs for one day. As of September 14, 2026, the Axiom Log Drain also retains backend and MCP audit events for 30 days; see v3.7.
  • Contact domain corrected: From support@ai4love.org to info@ai4love.ca, matching the domain actually used across the codebase and outbound mail.

2026-04-13 — MCP Enrichment & Hallucination Guardrails ​

  • MCP tool count: 19 → 21. Added get_supporter_by_id (record ID lookup) and list_campaigns (browse generated campaigns).
  • Supporter name enrichment: All MCP data tools (get_donations, list_volunteers, list_engagements, get_participation, all 6 insight tools) now resolve linked record IDs to human-readable "Name <email>" format via batch People lookups.
  • Event name resolution: Participation records now resolve event_id linked fields to event names. 551 historical records backfilled.
  • Action generator validation: New validateActionData() post-parse validator runs on all four action types (campaign, message, thank-you, re-engagement) in both streaming and non-streaming paths. Strips invented supporters by cross-checking emails against input data. Corrects hallucinated counts. Verifies recipient identity. Runs server-side before response reaches frontend or Airtable.
  • Prompt guardrails expanded: All four action generator system prompts now include CRITICAL rules prohibiting fabrication of supporter counts, names, emails, and dollar amounts.
  • CI fixes: Backend test glob fixed for Node 20. axios vulnerability patched via npm overrides (>=1.15.0).

2026-04-10 — Trust Center v3.0 ​

  • Content Integrity Policy (v2026-04-07) — All AI generation (agents + campaign generator) now constrained by a published policy prohibiting fabrication of any facts not present in provided data. Policy hosted at ai4love-policies.vercel.app, fetched at runtime, cached 10 minutes.
  • v2 Agent Architecture — Agents 1-5 rebuilt with prefetch proxy pattern: Make.com pulls queue, backend pre-fetches full supporter timelines from Airtable, sends to Claude in one call. No MCP at generation time. Agent 6 writes insights server-side via /api/agent-proxy/direct.
  • Insight Verification — New /api/verify-insight endpoint compares AI-claimed metrics (total_donated, participations, days_silent) against actual Airtable data. Writes verification status (verified/mismatch/unverifiable) back to each insight record.
  • Cost Logging — Per-run cost breakdowns (Anthropic tokens + USD, estimated Make.com operations) written to Engine Logs table for full audit trail.
  • Archived Insight Filtering — All surfaces (MCP tools, dashboard queries, agent inputs, KindMind enrichment) now filter {status} != "Archived". Prevents v1 insights (67% hallucination rate) from resurfacing.
  • Model Upgrade — All agents and campaign generation migrated to claude-sonnet-4-6.
  • Campaign Generation Guardrail — generateAction.js now prepends Content Integrity Policy to all Claude system prompts. Prevents fabricated beneficiary names, programs, or outcomes.
  • Security — Patched lodash prototype pollution and code injection vulnerabilities. 3 remaining alerts are upstream in @nangohq/frontend → axios chain (low practical risk on Vercel).

2026-03-25 — Trust Center v2.6 ​

  • Published Trust Center as the canonical security reference
  • Documented allow-list field filtering for MCP and agent prompts
  • Added daily retrieval cap (5,000 records/key/24h) to MCP safeguards
  • Clarified Service Account Access Token model for Airtable connections
  • Added data minimization section for LLM sub-processor path
  • Documented incident response timelines (4h containment, 72h notification)
  • Added SIEM streaming option for forensic-grade log retention

2026-03-24 — Performance ​

  • Reduced dashboard load time from 20–30s to 3–5s via parallel Airtable calls and query optimization
  • Eliminated O(n^2) lookups in supporter list rendering

2026-03-22 — Security Hardening ​

  • Patched high-severity vulnerabilities in rollup, undici, underscore dependencies
  • Added browser globals to ESLint configuration

2026-03-20 — Agent Optimization ​

  • Parallelized Airtable API calls in agent processing
  • Added streaming to insight generation for reduced timeout risk
  • Added PRIZM and Varonics enrichment fields to MCP tools

2026-03-07 — Auth Migration ​

  • Migrated authentication from Authsignal to Clerk
  • Implemented invite-only access model
  • Added two-layer auth: Clerk identity verification + AI4Love JWT session

Entries reflect meaningful system changes. Routine dependency updates and minor UI fixes are tracked in git history but not listed here.

AI4Love Trust Center v3.9

Last updated: September 30, 2026