Skip to main content

​
Security Philosophy

We believe security should be built-in, not bolted-on. Every component of AIde has been designed with security as a primary consideration, implementing a zero-trust architecture where no component trusts any other without verification. Our systems operate under the principle of least privilege, ensuring each service has only the minimal required permissions. This defense-in-depth approach creates multiple security layers to protect against various attack vectors, while our commitment to encryption everywhere means data is protected at rest, in transit, and in memory wherever possible.

​
Credential Security Architecture

​
Overview

The most critical security challenge AIde faces is securely storing and using third-party credentials like DeltaMath login information. We’ve implemented application-level envelope encryption using Google Cloud KMS to ensure that even if our database is compromised, credentials cannot be recovered without both KMS access and correct IAM permissions.

​
Core Encryption Concepts

Our encryption system relies on several key components working together. The Data Encryption Key (DEK) is a random 256-bit AES key generated per user and provider record, used exclusively to encrypt that user’s credentials. The Key Encryption Key (KEK) is a symmetric key stored in Google Cloud KMS that is used only to wrap and unwrap DEKs and never leaves the KMS environment. Associated Authenticated Data (AAD) ties each ciphertext to a specific context using the pattern aide|creds|userId|provider|v2, preventing cut-and-paste attacks. The complete envelope encryption process encrypts credentials with the DEK, then encrypts the DEK itself with the KEK in KMS, storing only the ciphertext and wrapped DEK.

​
Storage Model

Each credential record in Redis contains a comprehensive set of encrypted data and metadata. The record includes an encryption version number, the KMS key reference, base64-encoded AAD, the KMS-wrapped DEK, and separate encrypted username and password fields. Each field uses its own 12-byte nonce and 16-byte authentication tag to prevent replay attacks and ensure integrity. Critically, no plaintext credentials are ever stored anywhere in our system, and version tracking enables future cryptographic upgrades without breaking existing data. 
{
  "enc_v": "2",
  "kms_key": "projects/.../locations/<region>/keyRings/aide-keys/cryptoKeys/aide-cred-kek",
  "aad_b64": "<base64 AAD>",
  "dek_wrapped_b64": "<base64 KMS ciphertext of DEK>",
  "username_ct_b64": "<base64 nonce|ciphertext|tag>",
  "password_ct_b64": "<base64 nonce|ciphertext|tag>",
  "username_tag_hex": "<optional HMAC for lookup>",
  "created_at": "ISO-8601",
  "updated_at": "ISO-8601"
}

​
Credential Encryption Flow

​
IAM Security Controls

Our security model implements a critical separation of duties through distinct service account roles. The API service account has roles/cloudkms.cryptoKeyEncrypter permissions, allowing it to wrap DEKs but never decrypt existing data. This account handles user credential submission but cannot access any previously stored credentials. Conversely, the worker service account uses roles/cloudkms.cryptoKeyDecrypter permissions to unwrap DEKs and process jobs requiring credential access, but cannot encrypt new credentials into the system. This separation ensures that API breaches cannot decrypt existing credentials, worker compromises cannot inject malicious data as legitimate credentials, and attackers need both KMS access and correct IAM permissions for any credential access. The architecture creates multiple independent failure points that must be compromised simultaneously for a successful attack.

​
Additional Encryption Protections

Memory security is handled through aggressive zeroization practices where DEKs and plaintext credentials are wiped from memory immediately after use. We never cache credentials, instead decrypting them fresh for each job to minimize exposure time. Critical data uses secure memory allocation wherever the platform supports it. Key rotation operates automatically through KMS for KEKs, with versioned encryption allowing old key versions to decrypt legacy data during transition periods. Credentials are gradually re-encrypted to new key versions during normal user activity, ensuring the system stays current without service interruption. Our audit and monitoring systems log all KMS encrypt and decrypt operations, implement volume-based alerting for unusual decryption patterns, and maintain comprehensive failed access logs for both debugging and security monitoring purposes.

​
Platform Security

​
Infrastructure Protection

AIde leverages Vercel’s enterprise-grade platform security, which provides automatic DDoS protection at the edge, web application firewall filtering of malicious requests, API rate limiting to prevent abuse and brute force attacks, global CDN infrastructure with built-in security features, and automatic security headers including HSTS, CSP, and X-Frame-Options. Our network security ensures HTTPS everywhere with all traffic encrypted using TLS 1.3, HTTP Strict Transport Security preventing downgrade attacks, automatic certificate management through Vercel, and complete network isolation between production and development environments.

​
Application Security

Authentication and authorization are handled entirely through Firebase Authentication for all user login flows. We use JWT tokens for secure session management, OAuth 2.0 support for third-party authentication providers like Google, automatic token refresh to prevent session hijacking, and comprehensive role-based access control implemented through Firestore security rules. Input validation and injection prevention benefit from our NoSQL-only database architecture, eliminating SQL injection risks entirely. Firestore security rules validate all client-side database operations, parameterized queries are used where applicable, and input sanitization occurs at all application boundaries. Cross-site protections include CSRF protection through SameSite cookies and Firebase Auth integration, XSS prevention via Content Security Policy headers, output encoding for all user-generated content, and secure cookie configuration with HttpOnly and Secure flags.

​
Database Security

​
Firestore Security

Data segregation in Firestore ensures complete user data isolation where users can only access their own records. Admin privilege escalation allows administrators to modify access controls but maintains separation from regular user data access patterns.

​
Redis Security

Redis operates with backend-only access patterns, making it completely inaccessible from client applications. Service-to-service authentication secures communication between AIde components, while Upstash’s managed security platform provides enterprise-grade protection for our Redis infrastructure. Data protection in Redis centers on encrypted credential storage using our envelope encryption system. TTL management ensures sensitive temporary data has appropriate expiration, while our design principle of no persistent sensitive data means credentials stay encrypted and job data includes built-in expiration. Queue isolation segments jobs by user and priority level to prevent cross-contamination.

​
Development Security

​
Code Security

Source code protection relies on private repositories hosted on GitHub with strictly controlled access permissions. Branch protection rules require code review for all changes, while CodeRabbit provides automated security issue scanning. GitHub’s secret scanning prevents credential commits, and dependency vulnerability alerts through GitHub Security keep us informed of supply chain risks. Our development workflow mandates pull request requirements for all code changes, includes automated security scanning as part of our CI/CD pipeline, maintains complete environment segregation between development and production systems, and implements comprehensive secret management to prevent hardcoded credentials or API keys in source code.

​
Dependency Management

Vulnerability monitoring operates through GitHub Dependabot, which automatically scans for vulnerable packages in our dependency tree. We receive automated security alerts for critical vulnerabilities, maintain regular dependency updates to preserve our security posture, and conduct license compliance checking for all open source components we incorporate.

​
Current Security Limitations & Future Plans

​
Current Limitations

Database backups are currently disabled due to cost constraints, with recovery procedures relying on provider redundancy and fault tolerance. We have planned future enhancements for encrypted backups with proper retention policies once our revenue supports the additional infrastructure costs. Security monitoring currently operates at a basic level with fundamental alerting in place. Analytics expansion is actively under development, and advanced threat detection capabilities are planned for future implementation as our monitoring infrastructure matures. Our compliance framework does not currently pursue formal standards like SOC 2 or ISO 27001, instead following industry best practices informally. Future compliance evaluation will occur as our business scales and enterprise customer requirements evolve.

​
Security Incident Response

​
Current Procedures

Detection mechanisms include KMS audit log monitoring for unusual encryption and decryption patterns, GitHub security alerts for vulnerable dependencies, comprehensive platform monitoring through Vercel and Firebase dashboards, and user-reported security issues through our support channels. Our response procedures begin with immediate assessment of all reported security issues, credential rotation capabilities when compromise is suspected, user notification protocols for security-relevant incidents, and system isolation capabilities for containing potential breaches.

​
Reporting Security Issues

If you discover a security vulnerability in AIde, please follow our responsible disclosure process:
  1. Do NOT create a public GitHub issue
  2. Email immediately: N0ct7i5@proton.me with subject “SECURITY”
  3. Include details: Steps to reproduce, potential impact, affected systems
  4. Coordinated disclosure: We will work with you on responsible disclosure
We take security reports seriously and will respond within 24 hours with an initial assessment.

​
Security Best Practices for Users

​
Account Security

Users should maintain strong, unique passwords for their AIde accounts and enable any available two-factor authentication options in their account settings. Regular review of account activity through the dashboard helps identify suspicious behavior, and any unusual activity should be reported immediately to our support team.

​
Credential Management

Best practices include using unique passwords for DeltaMath and other connected services, regularly rotating credentials for all connected platforms, monitoring for unauthorized access in connected accounts like DeltaMath, and removing stored credentials from AIde when they are no longer needed.

​
Privacy Protection

Users should regularly review permission settings in their accounts, understand data sharing practices as outlined in our Privacy Policy, use trusted networks when accessing AIde, and ensure complete logout on shared or public computers.
For questions about our security practices or to report security concerns, contact: N0ct7i5@proton.me