Security Overview
Qinfinite is an enterprise-grade AI-powered platform designed with a security-first architecture, ensuring complete tenant isolation, controlled access, full auditability, and governed AI usage.
The platform aligns with SOC 2 Type II controls and AWS security best practices, enabling secure deployment across regulated environments.
Tenant Isolation & Architecture
Each customer is provisioned with fully dedicated infrastructure:
- A dedicated AWS account per customer
- A dedicated Kubernetes cluster per customer
No resources are shared between customers:
| Resource | Isolation |
|---|---|
| Compute infrastructure | Dedicated per customer |
| Network (VPCs) | Dedicated per customer |
| IAM roles | Dedicated per customer |
| Application layer | Dedicated per customer |
| Storage | Dedicated per customer |
| Network routing | No cross-tenant routing |
This ensures full isolation with zero cross-tenant data exposure and complete regulatory and operational separation between customers.
Identity & Access Management
Qinfinite uses a centralized identity model with a central AWS Admin account as the single identity source.
- Support engineers log into the Admin account with mandatory MFA, then assume least-privilege IAM roles into customer AWS accounts
- No local IAM users exist inside customer accounts
- All access is time-bound, controlled, and traceable
Break-Glass Emergency Access
- One emergency IAM account exists per customer environment
- MFA enforced on all emergency accounts
- Credentials securely stored in a corporate password vault
- Access permitted only in emergency scenarios and fully audited
Secrets & Credentials Management
All credentials and automation secrets are stored in HashiCorp Vault with dynamic, short-lived credentials.
- IAM access keys permitted only for controlled automation workflows and break-glass use
- All access keys are rotated and audited regularly
Network & Infrastructure Security
The platform is protected at multiple layers:
- AWS WAF attached to the Application Load Balancer, mitigating OWASP threats (SQLi, XSS, bot traffic, L7 threat patterns)
- IP allowlisting enforced on Load Balancer security groups to allow only traffic from customer corporate outbound firewall IP ranges
- Administrative access restricted to corporate network or VPN only
Kubernetes Security
- RBAC policies enforced at namespace and role level
- Access flows through a hardened bastion EC2 instance, accessible only from corporate network or VPN
- Strict security group restrictions
- Audit logs enabled for all API server operations
Data Protection
| Protection Layer | Implementation |
|---|---|
| Encryption in transit | TLS 1.2+ on all communications |
| Encryption at rest | AES-256 via AWS KMS-backed services |
| Access controls | IAM and RBAC policies |
| Data isolation | Logically and physically isolated per customer |
Logging, Monitoring & Auditability
Full audit trail across all layers:
| Service | Purpose |
|---|---|
| AWS CloudTrail (all regions) + Insights | API activity logging |
| AWS Config | Configuration compliance |
| GuardDuty with Malware Protection | Threat detection |
| AWS Detective | Investigation workflows |
| VPC Flow Logs | Network tracing |
| ECR image scanning | Container vulnerability detection |
| Kubernetes audit logs | API server operation tracking |
| Bastion session logs | Access session recording |
Activity reviews are completed quarterly to ensure SOC 2 alignment. All engineer actions are logged through CloudTrail, Kubernetes audit logs, and bastion session logs.
Vulnerability Management & DevSecOps
- Annual external penetration testing (VAPT) through certified security firms
CI/CD pipeline includes DevSecOps controls:
| Control | Description |
|---|---|
| SAST | Static Application Security Testing |
| Dependency scanning | Third-party library vulnerability checks |
| Container image scanning | Vulnerability detection in container images |
| Secrets scanning | Prevent credentials from entering codebase |
Builds fail automatically if security thresholds are violated.
Incident Response
Qinfinite follows a structured incident response process aligned with SOC 2 incident management practices:
- Detect -- Automated alerts from CloudWatch, GuardDuty, WAF, and Kubernetes logs
- Contain -- Isolate IAM roles, restrict access, isolate workloads
- Eradicate -- Patch vulnerabilities, remove malicious artifacts
- Recover -- Restore services, validate system behavior
- Notify Customer -- Based on severity and SLAs
AI / LLM Security & Governance
Hybrid LLM Deployment Model
Qinfinite supports two deployment options for AI models:
Self-Hosted Models
- Open-source models (e.g., Mistral) deployed within customer-dedicated environments
- No external data transfer -- all inference happens locally
Managed Models via AWS Bedrock
- Access via secure API (TLS encrypted)
- No training on customer data (provider guarantees)
Data Handling & Isolation
- No cross-customer data sharing
- Inference scoped to customer-specific context
- Data is not used for model training unless explicitly enabled
AI Governance & Controls
- Role-based access to AI capabilities
- Full audit logs of prompts, responses, and actions taken
- Explainability layer for AI-driven decisions
Prompt & Data Security
- Sensitive data masking (configurable)
- Controlled prompt construction
- No exposure of system-level instructions
Compliance & Alignment
- SOC 2 Type II aligned controls across all security domains
- Built on AWS secure infrastructure
- Full audit trail enabling regulatory compliance and forensic analysis
Operational Access & Support
Support team operations are limited to:
- Log analysis
- Pod restarts
- Infrastructure scaling
- Database debugging
- Deployment support
All engineer actions are logged and subject to quarterly SOC 2 compliance reviews.