Security & Compliance Overview

How the Stryke platform protects dealer and consumer data, mapped to the AICPA SOC 2 Trust Services Criteria. Prepared for dealers, partners, and auditors. Last updated September 8, 2026.

What this document is. This is Stryke's system description and control matrix, prepared as part of our SOC 2 readiness program. Every control listed cites where it is implemented in our infrastructure-as-code or application code, so it can be independently verified. Stryke has not yet completed an independent SOC 2 examination; where a control is not yet in place we say so plainly and track it in the roadmap. When we engage an audit firm, this document will serve as the basis of the system description in that report.

TL;DR

Stryke is a multi-tenant SaaS platform that helps auto dealers respond to sales leads over SMS with an AI assistant that is supervised by humans by default.
All infrastructure is defined as code (SST on AWS) and deployed through CI — there are no hand-built resources. Every tenant's data is partitioned by organization ID at the database-key level.
No consumer-facing message is sent autonomously until a dealer explicitly enables it; even then an automated reviewer scores every draft, and the system fails closed (holds for human approval) when the reviewer is unavailable.
Self-service signup is disabled platform-wide: organizations and their first user are provisioned only by Stryke staff, and staff access uses a separate, Google-federated identity pool restricted to Stryke's corporate domain.
Consumer opt-out is enforced in code, not by the AI. Every outbound text passes through a single gate that checks consent at the moment of send, honors keyword and natural-language opt-outs, respects quiet hours, and refuses to send when consent is unknown. See §6.
Every administrative action — provisioning a dealership, changing a role, suspending an account, changing autonomy — is recorded in an append-only audit trail with actor, source IP, and before/after values.
Known gaps (MFA enforcement, data-retention schedules, monitoring/alerting, guaranteed capture of failed background work) are disclosed in the gap register with remediation status — we would rather show you an honest roadmap than an inflated checklist.

1. System overview

Stryke ("the platform") receives sales leads for auto dealerships (via CRM webhook, ADF email, or manual entry), opens SMS conversations with consenting consumers, and drives them toward appointments and offers. An AI sales agent drafts replies; dealership staff supervise, approve, and can take over any conversation at any time from the web dashboard.

Compute

Serverless: AWS Lambda per API route group, Fargate container tasks for AI agents and their tools, EventBridge cron jobs. No servers to patch.

Data stores

Amazon DynamoDB (single-table, org-partitioned), Amazon S3 (documents, inbound lead emails), Neptune Analytics (analytics knowledge graph).

Identity

Amazon Cognito: one user pool for dealer users, a separate Google-federated pool for Stryke staff. JWT authorizers at the API gateway.

AI models

Anthropic Claude via AWS Bedrock (agents), Anthropic API (draft-review judge, inventory extraction). See §5.

Messaging

Twilio Programmable Messaging with automated A2P 10DLC carrier registration per dealer. See §6.

Delivery

Everything is infrastructure-as-code (SST v4, infrastructure/) deployed by GitHub Actions. Production deploys only on versioned releases.

The platform runs in AWS region us-west-2. Production and development are separate SST stages with separate resources, domains (*.strykeauto.com vs dev.*.strykeauto.com), and secrets; production resources are protected from deletion (sst.config.ts protect/retain).

Lead arrives
CRM webhook / ADF email → Customer + conversation created
org-partitioned DynamoDB → AI drafts reply
Bedrock agent + tools → Draft reviewed
judge score + autonomy stage → Human approves
or auto-send if dealer enabled → SMS via Twilio
A2P-registered number

2. Data inventory & classification

We maintain a typed catalog of every record the platform stores (packages/core/src/entities.ts). The categories relevant to a dealer's risk assessment:

Category	Examples	Contains	Where
Consumer identity	Customers, leads, lookups	Name, phone, email, address, lead notes	DynamoDB
Conversations	SMS/chat threads, messages	Full message bodies, delivery status	DynamoDB; previews (≤200 chars) projected to the analytics graph
Appointments	Test drives, service visits	Customer name, phone, email, notes	DynamoDB
Dealer business data	Inventory, pricing rules, deal history	VINs, pricing, gross figures, lender names	DynamoDB
Carrier registration	A2P 10DLC business profile	Legal name, EIN, business address, authorized representative contact	DynamoDB → Twilio TrustHub
Dealer users	Accounts, memberships, invites	Name, email, phone, per-org role	Cognito + DynamoDB (invite tokens stored as SHA-256 hashes only)
Raw lead emails	ADF intake (production)	Full inbound email MIME	S3
Operational telemetry	Agent turn metrics, daily rollups	Token counts, latencies, confidence scores — no message content	DynamoDB

Tenant isolation. Tenant data is keyed under ORGANIZATION#{organization_id} in the database partition key, so every organization-scoped query is tenant-bound by construction. Every authenticated business-data request re-resolves the caller's membership in the target organization on the server — the client-supplied organization ID is never trusted without an active membership row (packages/core/src/auth/context.ts requireActiveContext; covered by unit tests in tests/unit/auth-context.test.mjs). Records not keyed by organization (e.g. conversation messages) are only reachable through a parent lookup that is org-checked first.

Encryption. All data stores encrypt at rest with AWS-managed keys (DynamoDB, S3, Neptune Analytics defaults). All traffic — browser, API, webhooks, model calls — is TLS; public endpoints use ACM certificates on strykeauto.com domains. Customer-managed KMS keys are on the roadmap.

3. Subprocessors

Third parties that process dealer or consumer data on Stryke's behalf:

Subprocessor	Purpose	Data shared
Amazon Web Services	All hosting, storage, and model inference (Bedrock)	All platform data
Twilio	SMS delivery, phone numbers, A2P 10DLC carrier registration	Consumer phone numbers and message bodies; dealer business profile (legal name, EIN, representative contact) for carrier registration
Anthropic	Draft-safety judge; inventory-feed text extraction	Recent conversation excerpts, customer first/last name, and the draft reply (judge); public dealer-website inventory text (extraction). No consumer data is used to train models under our API terms.
MarketCheck	Vehicle valuation and market comps	VIN, year/make/model, mileage, ZIP code — never consumer name or contact info
Google	OAuth sign-in (optional for dealer users; required for Stryke staff)	Email, name, profile photo of the signing-in user
Resend	Transactional email to dealer staff (invitations, notification digests)	Dealer user email address and name; notification subject and body, which may include a customer name and a message preview
Browser push services (Apple/Google/Mozilla)	Dealer-staff web notifications	Notification payloads (may include customer name and a message preview)

4. Control matrix — Trust Services Criteria

Status legend: In place implemented and verifiable in code Partial implemented with known limits Planned tracked in the roadmap.

Security — logical access (CC6)

Control	Implementation	Status
No self-service signup	Cognito pre-signup trigger rejects all signups except admin-created accounts and Google federation onto pre-created accounts (`handlers/triggers/pre-signup.ts`). Organizations and their first admin are provisioned only by Stryke staff.	In place
API authentication	API Gateway JWT authorizers validate signature, issuer, audience, and expiry against Cognito before any handler runs (`infrastructure/api.ts`).	In place
Staff/customer identity separation	Stryke staff use a separate Cognito pool, federated to Google only, with signup restricted to approved corporate email domains (`handlers/triggers/employee-pre-signup.ts`). Customer tokens cannot reach `/admin` routes and vice versa.	In place
Per-request tenant authorization	Membership + `active` status re-checked server-side on every business-data request; org-management actions additionally gated by role (admin/manager) with last-admin protection (`packages/core/src/auth/context.ts`, `handlers/api/organizations/…`).	In place
Invite lifecycle	Invites carry a random token stored only as a SHA-256 hash, expire automatically (7 days), are revocable, and only activate for the invited email (`packages/core/src/organizations/invites.ts`; unit-tested).	In place
Webhook authentication	Twilio webhooks are HMAC signature-validated with constant-time comparison and rejected otherwise (`packages/core/src/sms/twilio.ts` `validTwilioSignature`; unit-tested). CRM/ADF intake endpoints require a pre-shared secret and fail closed when unset.	Partial
Least-privilege IAM	Workload roles are scoped to specific resources, including DynamoDB partition-key-prefix conditions on the AI agents' role (`infrastructure/agentcore.ts`). Some wildcard grants remain and are being tightened.	Partial
Secrets management	Secrets held in SST secret store / SSM SecureString; container workloads hydrate from SSM at startup; no secrets committed to the repository.	In place
MFA enforcement	Not yet enforced on either identity pool.	Planned
Tenant lifecycle & suspension	Each dealership carries an explicit lifecycle state (invited / onboarding / live / suspended). Suspending an account blocks it at every entry point: dealer API requests, organization-management actions, and outbound messaging — the last of these matters because inbound SMS does not pass through the request-authorization path (`packages/core/src/auth/context.ts` `requireActiveContext`, `requireOrgMembership`; `packages/core/src/sms/delivery.ts` `evaluateSendGates`; unit-tested).	In place
Staff role tiers	Stryke staff hold one of four internal roles (superadmin / ops / support / readonly) resolved from identity-provider group membership, and every staff endpoint declares the capability it requires. Only superadmin may create or suspend a dealership. The internal role namespace is separate from dealer roles and never bridges them (`packages/core/src/auth/employee-capabilities.ts`, `packages/core/src/auth/context.ts` `requireEmployee`; unit-tested). Until group assignment is complete, a staff member with no assigned group is treated as superadmin and the event is logged — see §7.	Partial
User/member deprovisioning	Roles can be changed, invites revoked, and an entire dealership suspended. A per-member removal + session-revocation path is not yet built.	Partial

Change management (CC8) & SDLC

Control	Implementation	Status
Infrastructure as code	Every AWS resource is declared in `infrastructure/` (SST); no console-built resources. Changes ship only through version control.	In place
CI quality gate	Pull requests run full TypeScript typechecking across the API, shared libraries, and every web app, Python compilation checks, and the unit-test suite (`.github/workflows/ci.yml`, `tests/`).	In place
Automated tests	Unit tests pin the security-critical contracts: webhook signature validation, tenant-isolation middleware, invite token lifecycle, AI autonomy defaults, consumer consent and send-gate ordering, staff capability enforcement, and audit-record structure (`tests/unit/`). Three of these are enforced by tests that scan the source tree and fail the build if a new code path bypasses a control — the single outbound message path, staff capability gating on every administrative route, and route registration. They run on every PR and block both development and production deploys. Coverage is expanding with each feature.	Partial
Gated production deploys	Production deploys only when a semantic release is cut from `main` (`.github/workflows/production.yml`); deploys are serialized, and a deploy-marker system prevents partially-registered releases (`scripts/ci-deploy-marker.sh`).	In place
Peer review	Work lands via pull request; formal branch-protection and code-owner enforcement is being turned on.	Partial
Dependency hygiene	Lockfile-pinned installs (`npm ci`) in CI; automated dependency updates and vulnerability scanning are planned.	Partial

Monitoring & incident handling (CC7)

Control	Implementation	Status
Message-delivery monitoring	Every outbound SMS gets a delivery status from the carrier; failures are stamped onto the message and surfaced to the dealer in the conversation thread with a plain-language reason (`handlers/api/sms/status`, `handlers/workers/invoke-agent.ts`).	In place
Structured logging	All workloads log to CloudWatch; jobs emit structured error records per failed item and continue (no all-or-nothing sweeps).	In place
Alerting & on-call	No automated alerting on error rates or job failures yet; operational review is manual.	Planned
Administrative audit trail	Every sensitive administrative action is written to an append-only log that is never updated or deleted: dealership provisioning and lifecycle changes, member role changes, invite issue/revoke/accept, messaging-number and carrier-registration changes, autonomy changes, and lead-intake address changes. Each record carries the actor, actor type (staff / dealer user / system), source IP, target, and before/after values, and is retrievable platform-wide or scoped to a single dealership, with CSV export (`packages/core/src/admin/audit.ts` `recordAuditEvent`, `listAuditEvents`; unit-tested). A test prevents credentials from being written into audit detail.	In place
AWS account audit trail	CloudTrail / GuardDuty configuration is being formalized as code. This is separate from the application audit trail above.	Planned
Log retention limits	CloudWatch retention policies not yet set (currently unlimited).	Planned

Availability (A1)

Control	Implementation	Status
Managed, multi-AZ services	Lambda, DynamoDB, S3, API Gateway, Cognito are AWS-managed and span availability zones within `us-west-2` by default.	In place
Production deletion protection	Production stacks are protected and retained on removal (`sst.config.ts`); the analytics graph has deletion protection in production.	In place
Self-healing jobs	Recurring jobs (inventory sync, carrier-registration sweep, attention sweep) are idempotent, claim work with conditional writes, and heal transient failures on the next cycle (`handlers/jobs/`).	In place
Point-in-time recovery	DynamoDB PITR and a documented backup/restore procedure are not yet enabled.	Planned
Deferred message durability	A message that cannot be sent immediately because of quiet-hours rules is not dropped: it is persisted to a work registry and retried by a recurring job, which re-checks consent and refuses to send anything still awaiting human approval (`packages/core/src/sms/delivery.ts` `enqueueDeferredSend`, `flushDueDeferredSends`; unit-tested).	In place
Capacity limits & headroom	All compute is on-demand and managed. A low account-level concurrency limit was found to be causing request throttling under normal use; an increase has been requested. Automated alarming on capacity headroom is not yet in place — see §7.	Partial
Guaranteed capture of failed async work	Background work (AI agent turns, notification fan-out) is invoked asynchronously and retried automatically by the platform, and recurring jobs heal transient failures on the next cycle. Work that still fails after its retries is delivered to a dedicated failure queue with 14-day retention rather than discarded, so it can be inspected and replayed (`infrastructure/async-failures.ts`, `infrastructure/workers.ts`, `infrastructure/notifications.ts`). Automated alerting on queue depth is not yet in place — see §7.	In place

Processing integrity (PI1)

Control	Implementation	Status
Human approval before send	See §5 — new dealers start fully supervised; approval uses atomic conditional writes so a draft can never be sent twice or sent after being replaced (`handlers/api/conversations/…/approve`).	In place
Single outbound message path	Every outbound text — AI-generated, human-approved, or typed by the dealer — leaves the system through one function, which is where consent, carrier-registration, and quiet-hours checks live. A test scans the codebase and fails the build if any other module can send a message, so a new feature cannot bypass the checks (`packages/core/src/sms/delivery.ts` `deliverSms`).	In place
Carrier-compliance gating	Outbound SMS is blocked until the dealer's A2P 10DLC registration is carrier-approved; blocked sends are recorded with the reason rather than silently dropped (`packages/core/src/sms/delivery.ts` `evaluateSendGates`).	In place
Inbound de-duplication	Inbound SMS is deduplicated by carrier message ID so retries never create duplicate conversations or double agent replies (`handlers/api/sms/inbound`).	In place
Contract tests	The signature-validation, tenant-authorization, invite, autonomy-default, consent, send-gate, audit-record, and staff-capability contracts are pinned by the unit suite run on every change (`tests/unit/`).	In place

Confidentiality (C1) & Privacy (P)

Control	Implementation	Status
Tenant data separation	Organization ID in the partition key; per-request membership checks (see §2).	In place
Staff access boundary	Cross-tenant administration is restricted to the corporate-domain staff pool. Per-staff role tiers and access audit logging are now in place (see CC6 and CC7); what remains is completing group assignment so that an unassigned staff member is denied rather than defaulted to full access.	Partial
Analytics graph scoping	The knowledge graph is read-only to agents at the IAM level with write verbs blocked; per-tenant query enforcement inside the graph is being hardened.	Partial
Consumer consent records	Texting consent is recorded per consumer phone number per dealership, so one dealer's consent never implies another's, and the record is partitioned under that dealership like all other tenant data. Every state change appends an immutable event capturing the previous and new state, what caused it, and the consumer's own words where applicable — the record of whether and when an opt-out was honored (`packages/core/src/sms/consent.ts` `setConsent`, `listConsentEvents`; unit-tested).	In place
Data retention schedules	Short-lived operational records already expire automatically (invites, dedupe and lookup rows). Retention schedules for consumer PII (customers, leads, conversations, raw lead emails) are not yet defined.	Planned
Deletion & offboarding	Conversations are deletable with cascading message deletion. A full tenant-offboarding purge and consumer data-subject deletion (CCPA/GDPR-style) are not yet built.	Planned
PII minimization in logs	Happy-path logs record lengths/counts, not message content; a sweep to remove remaining PII from error logs is in the roadmap.	Partial

5. AI agent controls

Dealers evaluating Stryke consistently ask one question first: can the AI text my customers something wrong? The autonomy system is designed so the honest answer is: not without a human seeing it first, unless you have explicitly earned and enabled a higher autonomy stage.

Phased autonomy — supervised by default

Supervised (default): every AI draft is held for human approval. This is the state for every new dealer — the default applies even when no configuration exists, so an org can never accidentally start auto-sending (packages/core/src/conversations/autonomy.ts; unit-tested).
Semi-automated: an independent automated reviewer (a separate Anthropic model) scores every draft for safety and correctness; drafts at or above the dealer's confidence threshold send, the rest hold for approval. If the reviewer errors or times out, the draft holds — the system fails closed (handlers/workers/invoke-agent.ts, packages/core/src/conversations/confidence.ts).
Fully automated: opt-in per dealer, changeable only by dealer admins/managers; every turn is still scored and recorded for review.

Additional safeguards

Atomic approval: approving a draft is a conditional state transition (held → approved) that happens before the send; double-clicks and stale drafts are rejected, and a failed send reverts the draft to held.
Human takeover: staff can take over any conversation instantly; while active, the agent is fully suppressed and inbound messages route to the human.
Revision loop: staff can send feedback instead of approving; the revised draft is always re-held for review regardless of autonomy stage.
Escalation: the agent has an explicit escalate-to-human tool, and dealer staff are notified when it is used or when a send fails.
Audit trail: every agent turn durably records the final text, tools invoked (with previews), token/latency/cost telemetry, the reviewer's confidence score and rationale, who approved it and when, the carrier message ID, and delivery outcome — reviewable per conversation and in daily rollups.

Models and data flow

Agents run Anthropic Claude via AWS Bedrock inside Stryke's AWS account boundary; agent tools reach data through an authenticated MCP gateway (Cognito machine-to-machine JWT), and the agents' AWS role is partition-key-scoped in DynamoDB and read-only on the analytics graph.
The draft reviewer and inventory extraction call the Anthropic API directly (see §3 for exactly what is shared).
The agent sees the conversation history, the lead context supplied by the dealer's CRM, and what its tools return — dealer inventory, negotiation settings, schedules. Content-level guardrails beyond the reviewer (e.g. Bedrock Guardrails, prompt-injection hardening of lead free-text) are on the roadmap.

6. SMS compliance (A2P 10DLC / TCPA)

Carrier registration is built in: Stryke automates the full A2P 10DLC chain per dealer — TrustHub business profile, brand, campaign, and number attachment — and a recurring sweep advances registrations and notifies dealers of failures (packages/core/src/sms/a2p.ts, packages/core/src/sms/a2p-registration.ts).
No unregistered sending: agent and manual sends are blocked while a dealer's registration is not carrier-approved, with the block recorded on the message (packages/core/src/sms/delivery.ts evaluateSendGates).
Delivery accountability: per-message carrier delivery receipts, with failures shown in-thread to the dealer.
Opt-out is enforced in code, not by the AI. Consent is a stored, per-dealership record — not a model behavior and not a prompt instruction — and it is checked inside the single function through which every outbound message passes. If a consumer has opted out, or if there is no consent on record at all, the message does not send. This holds regardless of what the AI decides, what a dealer types, or what a scheduled follow-up was queued to do (packages/core/src/sms/delivery.ts evaluateSendGates, packages/core/src/sms/consent.ts).
Consent is re-checked at the moment of send. A consumer can reply STOP while a message is already drafted or queued. Checking consent only when the message was composed would still deliver it; the check happens immediately before the message leaves the system, so that race is closed.
Both keyword and natural-language opt-outs are honored. Standard keywords (STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT, and equivalents) are matched deterministically in code. Phrasings that carriers do not treat as keywords — "stop texting me", "take me off this list", "leave me alone" — are additionally classified, and a request to be contacted another way is still treated as revoking SMS consent. In every case consent is written and the AI is not invoked, so it cannot reply to an opt-out (packages/core/src/sms/consent-rules.ts matchConsentKeyword, packages/core/src/sms/opt-out-classifier.ts).
Ambiguity resolves against sending. Where intent is unclear, or where the classifier is unavailable, the conversation is held for a human rather than answered automatically, and a probable opt-out is honored rather than deferred. No uncertain case resolves toward continuing to text.
Quiet hours: messages are restricted to 8:00 AM–9:00 PM in the consumer's local time, resolved from the consumer's location and otherwise the dealership's. Where the time zone cannot be established, the most restrictive plausible window is used rather than a guess. A message outside the window is deferred to the next permitted time, not dropped (packages/core/src/sms/consent-rules.ts quietHoursVerdict).
Carrier opt-outs are reconciled back. If a consumer opts out at the carrier and Twilio rejects a send, that rejection is written into our own consent record, so the rest of the platform — scheduled follow-ups included — immediately knows the consumer is unreachable.
Consent history is immutable. Every change appends a permanent record of the prior state, the new state, the cause, and the consumer's own words where applicable. Nothing overwrites or deletes it. See §4 — Confidentiality & Privacy.

What this means in practice. Before these controls, stopping outreach depended on the AI behaving correctly and on Twilio's own block list. It now depends on neither: an opted-out consumer cannot be messaged by any path in the system, and the record of when and why we stopped is permanent and exportable. This closes what was previously the highest-priority item in our gap register.

7. Gap register & roadmap

Maintained honestly and reviewed as part of our SOC 2 readiness program. "Near-term" items are actively being scheduled; "mid-term" items follow. Items are removed from this register only when the corresponding control appears in §4 with a citation. Platform-enforced SMS opt-out suppression, per-consumer consent records, and quiet hours were previously the highest-priority item here and have shipped — see §6.

#	Gap	Criteria	Horizon
1	Enforce MFA for dealer users and Stryke staff; explicit password/account-recovery policy	Security	Near-term
2	Complete staff role-group assignment so an unassigned staff member is denied by default rather than granted full access	Security / Confidentiality	Near-term
3	DynamoDB point-in-time recovery + documented backup/restore procedure	Availability	Near-term
4	Per-member removal/deactivation with session revocation (dealership-level suspension is in place)	Security	Near-term
5	CloudWatch alarms and error alerting (including failure-queue depth and capacity/concurrency headroom), and an on-call/incident-response runbook	Monitoring / Availability	Near-term
6	Data-retention schedules and TTLs for consumer PII; tenant-offboarding purge; DSAR deletion. Consent records are deliberately excluded from deletion, as they are the evidence that an opt-out was honored	Privacy	Mid-term
7	Eliminate long-lived deploy credentials in favour of short-lived role assumption, and tighten remaining wildcard IAM grants	Security	Near-term
8	CloudTrail/GuardDuty as code; CloudWatch log-retention policies; PII log-scrubbing sweep	Monitoring / Privacy	Mid-term
9	Per-tenant enforcement inside the analytics graph; per-tenant intake credentials	Confidentiality	Mid-term
10	Branch protection + required review enforcement; automated dependency/vulnerability scanning	Change mgmt	Mid-term
11	Inbound rate limiting and abuse/cost-exhaustion controls on public message and lead-intake endpoints	Security / Availability	Mid-term
12	AI content guardrails beyond the reviewer; prompt-injection hardening of lead free-text; adversarial testing program	PI / Security	Mid-term
13	Expand unit/integration test coverage beyond the security-critical core	Change mgmt	Ongoing
14	Customer-managed KMS keys; WAF on public endpoints; multi-region resilience assessment	Security / Availability	Mid-term

8. Maintaining this document

This document is only useful if it stays true. Conventions that keep it maintainable:

Evidence is cited by file path and symbol name, never line numbers, so citations survive refactors. If you rename or move a cited file, update the citation in the same PR.
When a feature PR adds, strengthens, or weakens a control, update the relevant row (and the gap register) in that PR — the doc lives in the repo precisely so it rides the same review process as the code.
When a roadmap item ships, move it into the control matrix with its citation and delete the gap row. Never mark something "In place" without a citation.
Bump the "Last updated" date in the header on every substantive edit; review the whole document quarterly even if nothing forced an edit.

Prepared from a direct review of the platform's infrastructure-as-code and application code. Questions, evidence requests, or security reports: engineering@strykeauto.com.