Ajeris, Information Security Policy
Document Owner: Sarah Mitchell, Founder Contact: hi@ajeris.com Effective Date: October 14, 2025 Last Reviewed: October 3, 2026 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 industry-standard symmetric encryption before storage
- Encryption keys are stored as environment variables, never in source code or version control
- Database storage is encrypted at the infrastructure level (AES-256, per our hosting provider)
- Files containing secrets are 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 internal UUID, with phone number as a mutable claim
- User data isolation is enforced at the application layer: every database query is scoped to the requesting user
- Row-Level Security in the database authoritatively filters reads and writes via transaction-scoped session variables, so a query bug at the application layer cannot return another user's row
- One shared agent service serves every user. Each request runs in the requesting user's database context, so Row-Level Security limits it to that user's data, and the agent process does not inherit parent environment configuration or keep state of its own between requests
5.3 Third-Party Service Credentials
- All OAuth tokens are stored encrypted and scoped per user-and-service combination
- 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 from version control via gitignore rules
- Code changes are reviewed before deployment
- Dependencies are monitored continuously for known advisories
6.2 Input Validation
- All tool inputs are validated against strict schemas before processing
- User-supplied data (SMS messages, voice queries) is processed as content, not executed as code
- SQL injection is prevented by 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
- Dependencies are pinned via lockfiles
- Automated audits run on every change to identify known vulnerabilities
- Critical vulnerability patches are applied within 7 days of disclosure (see the Vulnerability Management Policy for full SLAs)
7. Infrastructure Security
7.1 Hosting
- Application is hosted on Railway, a SOC 2 Type II certified platform
- All services share one database, in which Row-Level Security separates every account's data
- Hosting is in the United States
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 on every service
8. Incident Response
8.1 Detection
- Application errors are logged with structured logging
- 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
- 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
10. Privacy
- Consumer data is never sold to third parties
- Credentials, connected-account data and the other data the privacy policy lists are never used to improve or train AI models; the policy also explains how conversations may be used to improve Ajeris and how to switch that off
- Consumer data is never shared with advertisers
- Data sharing is limited to the minimum required for service operation; every provider that processes personal data is named in the privacy policy
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