Security is not a feature we ship — it is the foundation we build on. Quills AI processes camera feeds and inference data on behalf of customers in regulated industries: defence, agriculture, transit, and finance. Trust here is non-negotiable. This page describes the controls and practices we use to protect Customer Data and our infrastructure.
Section 01
Our Approach
We design our systems around four principles:
- Defence in depth — multiple, overlapping controls so that the failure of any single layer does not compromise the system.
- Least privilege — every user, service, and process gets only the access it needs to do its job, and nothing more.
- Privacy by design — data minimisation, redaction where possible, and edge-first processing to reduce data movement.
- Continuous improvement — security is reviewed, tested, and updated as part of normal engineering work, not as an afterthought.
Section 02
Infrastructure & Hosting
Production workloads run on industry-leading cloud providers (AWS) in regions appropriate to the customer's data residency requirements. These providers maintain certifications such as ISO 27001, SOC 2 Type II, and PCI DSS, and operate physically secured data centres with redundant power, cooling, and connectivity.
Edge deployments
For products designed to run on customer-managed edge devices (e.g. NVIDIA Jetson, Orin), we ship hardened images, signed updates, and secure boot configurations where the platform supports them. Data may stay on the edge by design — reducing exposure and minimising upstream bandwidth.
Environment separation
Development, staging, and production environments are logically isolated. Customer Data is never used in development or testing without explicit authorisation and appropriate anonymisation.
Section 03
Data Protection
In transit
All traffic between clients, our APIs, and our internal services is encrypted using TLS 1.2 or higher with modern cipher suites. Internal service-to-service traffic uses mutual TLS or equivalent authenticated channels where supported.
At rest
Customer Data stored in our cloud is encrypted using AES-256 with keys managed in our cloud provider's key management service (KMS). Object storage, databases, and backups are all encrypted by default.
Data minimisation
We avoid collecting more data than we need. Where the use case allows it, we process video and image data on the edge and transmit only inference outputs upstream, reducing the personal data ever leaving the customer's premises.
Backups & recovery
Production data is backed up regularly and backups are retained according to defined retention policies. Restore procedures are tested periodically.
Section 04
Application Security
- Secure SDLC — security considerations are built into design reviews, code reviews, and release approvals.
- Code review — production changes require peer review before merging.
- Dependency scanning — automated scans catch known vulnerabilities in open-source dependencies and trigger upgrades.
- Static analysis — linting and SAST tools run on every pull request to catch common classes of bugs and security flaws.
- Secret management — secrets and credentials are stored in secret managers, never in source control. Rotation is enforced for sensitive credentials.
- Penetration testing — we engage third-party security testers periodically and on significant architectural changes.
Section 05
Access Control
- SSO & MFA — employee access to internal systems is gated behind single sign-on with multi-factor authentication.
- Role-based access — internal access to production systems and Customer Data is granted on a need-to-know basis using documented role definitions.
- Just-in-time elevation — privileged access is time-bound and audited.
- Offboarding — access is revoked promptly when an employee or contractor leaves or changes roles.
- Customer access — customer-facing applications enforce strong password requirements; we recommend customers enable MFA where offered.
Section 06
Network & Monitoring
- Network segmentation — production workloads are isolated from corporate networks and from non-production environments.
- Firewalls & security groups — only required ports and protocols are exposed; deny-by-default is the rule.
- Logging — application, infrastructure, and security logs are centralised and retained for analysis and forensics.
- Anomaly detection — automated alerts flag unusual access patterns, failed authentication spikes, and configuration drift.
- DDoS protection — public-facing endpoints sit behind cloud-provider DDoS mitigation.
Section 07
Incident Response
We maintain an incident response plan that defines roles, communication channels, and escalation paths for security events. The lifecycle includes:
- Detection through monitoring, alerting, and reports from employees, customers, or external researchers.
- Triage & containment by an on-call responder to limit impact while preserving evidence.
- Investigation to determine scope, root cause, and affected parties.
- Notification of affected customers and, where required, regulators within applicable timeframes.
- Remediation of the underlying issue and validation that controls hold.
- Post-incident review to update controls, runbooks, and training.
If you believe you are affected by a security incident involving Quills AI, contact security@thequills.ai immediately.
Section 08
Compliance & Frameworks
Our security program is aligned with industry-standard frameworks, including the OWASP Top 10, CIS Controls, and NIST Cybersecurity Framework. We design our processing of personal data to support customer compliance with:
- India's Digital Personal Data Protection Act, 2023 (DPDP Act);
- The EU/UK General Data Protection Regulation (where applicable to our customers);
- Industry-specific obligations communicated by our customers under contract.
Where customers require formal certifications (ISO 27001, SOC 2, etc.), we will work with them on a case-by-case basis. If you need a security questionnaire completed, contact us.
Section 09
People & Training
- Background checks — performed on employees and contractors with access to production systems, where permitted by local law.
- Confidentiality — all employees and contractors sign confidentiality agreements before being granted access to Customer Data.
- Security training — onboarding includes security and privacy fundamentals; refreshers are run periodically and tracked.
- Phishing awareness — engineering and operations teams are trained to recognise and report social engineering attempts.
Section 10
Vendor Management
Before engaging third parties that may process Customer Data on our behalf, we evaluate their security posture and require contractual safeguards including data processing terms, confidentiality, and breach notification. We maintain a register of subprocessors and review them periodically.
A current list of subprocessors used for our Services is available on request from security@thequills.ai.
Section 11
Business Continuity
Critical services are designed for redundancy across availability zones. We maintain documented procedures for incident response, key personnel handover, and disaster recovery. Recovery objectives (RTO/RPO) are reviewed regularly and aligned with the criticality of each service.
Section 12
Responsible Disclosure
We welcome reports from security researchers and the broader community. If you believe you have found a security vulnerability in our products, websites, or infrastructure, please report it to security@thequills.ai.
What to include
- A clear description of the issue and its potential impact;
- Steps to reproduce the issue (proof of concept where possible);
- Affected URLs, IPs, products, or versions;
- Your contact information so we can follow up.
Our commitments
- We will acknowledge receipt of your report within three (3) business days.
- We will investigate in good faith and keep you reasonably informed of progress.
- We will not pursue legal action against researchers who act in good faith and follow this policy.
- With your consent, we will credit you when a fix is published.
Out of scope
- Denial-of-service attacks, brute-force attempts, or large-scale automated scanning.
- Social engineering of Quills AI employees, customers, or vendors.
- Physical security testing of our offices or facilities.
- Issues that require physical access to a victim's device or unrealistic user interaction.
- Reports based solely on automated tool output without analysis or impact assessment.
Please do not access, modify, or destroy data that does not belong to you, and do not disclose vulnerabilities publicly until we have had a reasonable opportunity to investigate and remediate. We do not currently operate a paid bug-bounty program — recognition is via acknowledgement and, where appropriate, a public credit.