Ajeris , Access Controls Policy
Document Owner: Sarah Mitchell, Founder Contact: hi@ajeris.com Effective Date: April 15, 2026 Last Reviewed: October 3, 2026 Review Frequency: Annually, or upon significant infrastructure changes
1. Purpose
This policy defines how Ajeris controls access to production systems, consumer data, and administrative interfaces. It establishes the principle of least privilege, enforces multi-factor authentication on every infrastructure account, and specifies how user data is isolated from other users and from operators.
It applies to every person, service, and automated process that interacts with Ajeris infrastructure, code, or consumer data.
2. Scope
Covers:
- Administrative access to source code repositories, deployment platforms, and third-party service consoles
- Application-level access controls that isolate one user's data from another
- Authentication of inbound webhooks and API calls
- Authentication of end users
- Handling of third-party service credentials (OAuth tokens, API keys) on behalf of users
- Automated process-to-process authentication inside our services
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Founder / Administrator | Owns all infrastructure accounts. Responsible for MFA enforcement, key rotation, and access reviews. |
| Application services (gateway, agent) | Enforce per-user data isolation at every query boundary. No service acts on behalf of a user without a valid, authenticated identity claim. |
| 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, tokens, and memory. |
Ajeris currently operates as a solo founder + LLM-assisted engineering model. When additional personnel are onboarded, this section will be updated with named individuals and their scoped roles.
4. Identity model
4.1 User identity
Every user is identified by a stable internal UUID. The phone number is a mutable claim, not an identity. Changing phone numbers does not change the user's identity or cause data loss.
4.2 First-time registration
- An unknown phone number sends an SMS to the Ajeris Twilio number.
- The gateway validates the webhook signature using Twilio's HMAC before any business logic runs.
- The gateway mints a 192-bit cryptographically random setup token and stores a pending-registration record with a 24-hour TTL.
- A setup link with the token is SMS'd back to the user.
- The user opens the link on their phone. Possession of the phone is the possession factor that proves the identity claim.
- The onboarding web app validates the token (exists, not consumed, not expired), the user completes setup, and the user record is created atomically with the token marked consumed.
Setup tokens are single-use. An attacker who observes a token after consumption cannot reuse it. Tokens expire in 24 hours regardless of consumption.
4.3 Current authentication posture
Consumer authentication today is SMS-based possession verification. The act of receiving a link on a phone number and tapping it proves ownership of that number. This is not phishing-resistant MFA per NIST SP 800-63B.
WebAuthn / passkey support is on the roadmap. Until implemented, consumer authentication should be understood as single-factor possession.
5. Application-layer data isolation
5.1 Per-user scoping
Every database table that holds user data carries a userId foreign key. Every read and write scopes by userId. There is no application code path that reads across users.
5.2 Row-Level Security
PostgreSQL Row-Level Security is enforced for every user-scoped table. Application queries run inside transactions whose session variables are set to the current user's identity, so RLS policies authoritatively filter every read and write. A query bug at the application layer cannot return another user's row; the database itself enforces the boundary.
5.3 Agent isolation
One shared agent service serves every user. Each request is isolated to the account it serves:
- It runs inside a transaction scoped to that user's identity, so Row-Level Security limits every read and write to that user's rows.
- The agent process does not inherit configuration from the parent environment.
- It keeps no state of its own between requests; everything it remembers about a user lives in that user's rows.
5.4 OAuth token isolation
Every OAuth access token (Google, Spotify, Hue, Uber, Slack, Plaid, and others) is stored uniquely per user-and-service combination. Tokens are encrypted with industry-standard symmetric encryption before storage. The refresh flow re-encrypts on save. Tokens are never logged or returned in API responses.
6. Infrastructure access controls
6.1 Administrative accounts
Every account that can touch production is protected by multi-factor authentication:
| Provider | Use | MFA required |
|---|---|---|
| GitHub | Source code, CI, Dependabot | Yes |
| Railway | Production hosting, database, environment variables | Yes |
| Twilio | SMS gateway, phone numbers | Yes |
| Plaid | Financial data access | Yes |
| Anthropic | LLM inference | Yes |
| AWS (Alexa) | Alexa skill hosting | Yes |
MFA is enforced at the provider level. Account reviews are conducted annually or on personnel change.
6.2 Remote access
SSH key authentication only. Password authentication is disabled on every remote system. Keys are generated on a per-machine basis and revoked immediately when a machine is retired.
6.3 Production database
The production PostgreSQL database is hosted on Railway.
- Not publicly accessible. Connections restricted to Railway's internal network.
- SSL required on every connection.
- Application service accounts use unique credentials. Administrative access uses a separate credential with MFA on the Railway console.
- No shared database across users. RLS (see §5.2) protects data even from administrative console queries.
6.4 Secrets management
- Encryption keys, API keys, and database credentials live only in environment variables.
- Never committed to source.
.env,*.p8, and credentials files are.gitignored. - Railway environment variables are scoped per-service and not exposed to other services.
- Development and production use different encryption keys. No cross-environment key reuse.
7. Webhook and API authentication
7.1 Inbound webhooks
- Twilio: every inbound SMS webhook request is validated against Twilio's HMAC signature before any business logic runs.
- Alexa: every Alexa skill request is validated against the Alexa request signature before dispatch.
- OAuth callbacks: each OAuth provider uses its own signed redirect + state-parameter CSRF protection.
Unsigned requests are rejected with 401 before reaching application code.
7.2 Internal service-to-service
The agent service receives HTTP requests only from the gateway and our other internal services, authenticated with a shared internal secret. External traffic cannot reach the agent service directly.
8. Access provisioning and de-provisioning
8.1 Granting access
- New infrastructure accounts are created with the minimum permission set needed for the role.
- MFA is enforced before any action can be taken in the account.
- Keys / tokens are issued per-person; shared credentials are not permitted.
8.2 Revoking access
- Compromised credentials are revoked within 4 hours of discovery.
- When a person leaves the team, every account is revoked the same day and passwords on shared services are rotated.
- When a user deletes their account, all OAuth tokens for that user are immediately revoked at the provider (Plaid, Google, and others) and the encrypted token rows are cascade-deleted.
8.3 Access review
Access across all providers is reviewed:
- Annually at minimum
- Upon any personnel change
- Upon any security incident
The review confirms who has access, to what, and whether the access is still necessary. Stale access is removed during the review.
9. Audit and logging
- Gateway and agent services emit structured logs for every authenticated action. Logs record what happened, never the content of users' messages.
- Failed authentication attempts (bad Twilio signature, expired token, invalid setup token) are logged at
warnlevel with enough context to detect patterns. - Infrastructure console access (GitHub, Railway, Plaid, Twilio) is audited by the provider; logs are reviewed after any security incident.
10. Policy review
This policy is reviewed:
- Annually
- Upon any significant change to the identity, authentication, or isolation model
- Upon any security incident
- Before onboarding any new third-party data provider
Next scheduled review: April 2027.
11. Contact
Security concerns, access-control questions, and incident reports:
hi@ajeris.com , Sarah Mitchell, Founder Target initial response time: 4 hours during business hours.