Security model

Encryption, container isolation, OAuth token handling, and the engineering commitments behind Ajeris's trust posture.

Ajeris, Information Security Policy

Document Owner: Sarah Mitchell, Founder Contact: hi@ajeris.com Effective Date: October 14, 2025 Last Reviewed: October 14, 2025 Review Frequency: Annually, or upon significant infrastructure changes

1. Purpose

This policy defines the information security practices, procedures, and controls that Ajeris employs to protect consumer financial data, personally identifiable information (PII), and system infrastructure. It applies to all systems, services, and personnel involved in the development, deployment, and operation of the Ajeris personal agent platform.

2. Scope

This policy covers:

Consumer data collected via Plaid (bank accounts, transactions, balances, credit reports)
OAuth tokens and API credentials for third-party services (Google, Spotify, Philips Hue, Twilio, etc.)
User identity data (phone numbers, names, addresses)
Agent conversation history and memory data
All infrastructure components (databases, application servers, CI/CD pipelines)

3. Data Classification

Classification	Description	Examples
Restricted	Financial data, credentials, PII	Plaid access tokens, credit reports, OAuth tokens, phone numbers, bank balances
Confidential	Internal business data	API keys, encryption keys, system configuration
Internal	Operational data	Conversation logs, agent prompts, usage metrics

All consumer-facing data defaults to Restricted unless explicitly classified otherwise.

4. Encryption

4.1 Data in Transit

All client-server communication uses TLS 1.2 or higher
All third-party API calls (Plaid, Twilio, Anthropic, Google, Spotify) use HTTPS exclusively
Railway hosting platform enforces HTTPS on all deployed services
No plaintext HTTP endpoints are exposed in production

4.2 Data at Rest

Sensitive credentials (OAuth access tokens, refresh tokens, Plaid access tokens) are encrypted using PostgreSQL pgcrypto symmetric encryption (pgp_sym_encrypt) before storage
Encryption keys are stored as environment variables, never in source code or version control
Database storage is encrypted at the infrastructure level (Railway managed PostgreSQL)
The .env file containing secrets is gitignored and never committed

4.3 Key Management

Encryption keys are generated as 32+ byte random strings
Keys are stored exclusively in environment variables (Railway environment, local .env)
Key rotation procedure: generate new key, re-encrypt all stored values, deploy, verify, revoke old key
No encryption keys are shared across environments (development, production)

5. Access Control

5.1 Infrastructure Access

All infrastructure accounts (GitHub, Railway, Twilio, Plaid, Anthropic) require multi-factor authentication (MFA)
SSH key authentication is used for all remote access; password authentication is disabled
Database access is restricted to application service accounts and the administrative account, both with strong passwords
Production database is not publicly accessible; connections are restricted to Railway's internal network

5.2 Application Access

Each user is identified by a stable UUID (users.id), with phone number as a mutable claim
User data isolation is enforced at the application layer: all database queries are scoped by userId
Row-Level Security (RLS) is implemented via withUserContext() for transaction-scoped queries
The agent process runs with isolation flags (settingSources: [], autoMemoryEnabled: false) to prevent cross-user data leakage

5.3 Third-Party Service Credentials

All OAuth tokens are stored encrypted (pgcrypto) and scoped per user (@@unique([userId, service]))
Token refresh is handled automatically; expired tokens are refreshed before use and re-encrypted on save
No third-party service credentials are logged or exposed in API responses

6. Secure Development Practices

6.1 Source Code Management

All source code is stored in a private Git repository
Secrets are excluded via .gitignore (.env, *.p8, credentials files)
Code changes are reviewed before deployment
Dependencies are monitored via npm audit

6.2 Input Validation

All MCP tool inputs are validated using Zod schemas before processing
User-supplied data (SMS messages, voice queries) is processed by Claude's agent framework, not executed as code
SQL injection is prevented by Prisma's parameterized queries; no raw SQL is constructed from user input
Twilio webhook requests are validated using Twilio's request signature verification

6.3 Dependency Management

Node.js dependencies are locked via package-lock.json
npm audit is run periodically to identify known vulnerabilities
Critical vulnerability patches are applied within 7 days of disclosure

7. Infrastructure Security

7.1 Hosting

Application is hosted on Railway, a SOC 2 Type II certified platform
Each user's agent runs in an isolated container
No shared state between user containers except the central database (with RLS)

7.2 Network Security

All production services communicate over encrypted channels (TLS 1.2+)
Database connections use SSL
External API webhooks (Twilio, Alexa) are validated using signature verification before processing

7.3 Monitoring

Application logs are collected and monitored for errors and anomalies
Usage tracking records per-user token consumption and API call counts
Scheduled health checks run via the heartbeat scheduler

8. Incident Response

8.1 Detection

Application errors are logged with structured logging (Winston)
Unusual patterns (spike in API errors, authentication failures) are monitored

8.2 Response Procedure

Identify, Determine the scope and nature of the incident
Contain, Isolate affected systems (revoke compromised credentials, disable affected accounts)
Eradicate, Remove the root cause (patch vulnerability, rotate keys)
Recover, Restore normal operations and verify integrity
Notify, Inform affected users within 72 hours if personal data was compromised
Review, Document lessons learned and update this policy

8.3 Contact

Security incidents should be reported to: hi@ajeris.com
Target initial response time: 4 hours during business hours

9. Data Retention and Deletion

Consumer financial data (account balances, transactions) is retained as long as the user's account is active
Users can request deletion of all their financial data at any time via the agent ("disconnect my accounts")
Upon account deletion, all user data is cascade-deleted from the database (onDelete: Cascade on all user-scoped models)
Plaid access tokens are revoked via the Plaid API upon account disconnection
Conversation history is retained for agent context; users can request full deletion
Backups follow the hosting provider's retention schedule (Railway managed backups)

10. Privacy

Consumer data is never sold to third parties
Consumer data is never used to train AI models
Consumer data is never shared with advertisers
Data sharing is limited to the minimum required for service operation (Plaid for account data, Twilio for SMS delivery, Anthropic for agent processing)
A consumer-facing privacy policy will be published before public launch

11. Compliance

FCRA: Consumer credit data is accessed only with written consumer consent (permissible purpose under Section 604(a)(2)). Consumers can dispute information through the agent.
FDCPA: Debt validation letters comply with FDCPA requirements. No harassment, deception, or unfair practices in creditor communications.
CROA: Ajeris is positioned as a consumer DIY tool, not a credit repair organization. No advance fees are charged for credit repair services.

12. Policy Review

This policy is reviewed:

Annually at minimum
Upon any significant infrastructure change
Upon any security incident
Before onboarding new third-party data providers

Next scheduled review: April 2027