Security at Deflected

Our security philosophy

Deflected exists to secure the AI layer for other organizations. That mission only holds if our own house is in order, so we hold ourselves to the same standard we ask of our customers: security is the product, not a compliance checkbox.

Three principles shape every decision we make about how data moves through our systems:

• Defense-in-depth. No single control is trusted to be sufficient. We layer network, application, cryptographic, and monitoring controls so that the failure of any one of them does not become a breach. An attacker who gets past one boundary still faces several more.
• Least privilege. Every person, service, and system is granted the minimum access required to do its job, and no more. Access is scoped, time-bound where practical, and reviewed rather than assumed.
• Secure by default. The safe configuration is the one you get without asking. Encryption, isolation, and logging are on out of the box; there is no privileged mode that quietly turns protections off.

We treat security as an engineering discipline with owners, budgets, and measurable outcomes — not as a document reviewed once a year.

Encryption

Encryption at Deflected is post-quantum by default. We do not offer post-quantum protection as a premium tier; it is the baseline for every byte we handle. This matters because of a threat that is already in motion: adversaries can capture encrypted traffic today and store it to decrypt later, once a large quantum computer can break classical public-key cryptography. This is the harvest-now, decrypt-later problem, and it means any data that will still be sensitive years from now needs post-quantum protection today.

We use the algorithms standardized by the U.S. National Institute of Standards and Technology (NIST):

• ML-KEM-1024 (FIPS 203) for key encapsulation, exchanging session keys at a high quantum security level.
• ML-DSA-87 (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures that remain unforgeable against quantum-capable adversaries.
• Hybrid X25519 + ML-KEM key exchange, which runs a proven classical algorithm alongside the post-quantum one. If either scheme is ever weakened, the other still protects the exchange.
• AES-256-GCM for symmetric encryption of data both at rest and in transit.

The practical result is a guarantee few vendors can make honestly: the data you place with us is protected not only against the attackers of today, but against the cryptographic threats of the coming decade.

Data protection & privacy

We protect data by collecting as little of it as possible and isolating what we do hold. Our data-handling controls are built around four commitments:

• Data minimization. We collect and retain only the data required to deliver the service, and we set retention limits rather than keeping data indefinitely by default.
• Tenant isolation. Each customer's data is logically segregated so that one tenant can never read, infer, or reach another tenant's data. Isolation is enforced in the data model and access layer, not merely by convention.
• Encryption everywhere. The post-quantum and AES-256 protections described above apply to data at rest, data in transit, and internal service-to-service traffic — not just the public edge.
• No training on your data. Customer data is not used to train shared or foundation models. Your data is used to provide your service, and it stays within your tenant.

For the full detail on what we collect, how long we keep it, and your rights over it, see our Privacy Policy.

Application & infrastructure security

Strong cryptography is only as good as the systems around it. We secure the software we ship and the infrastructure it runs on with controls that operate continuously.

Secure development lifecycle

Security is built into how we write software, not inspected in at the end. Changes go through peer code review, automated dependency and vulnerability scanning, and testing before release. We track and remediate known vulnerabilities in our dependencies on a defined cadence, prioritized by severity.

Hardened cloud infrastructure

Our systems run on reputable cloud infrastructure with hardened baseline configurations. Environments are separated, network access is restricted to what each service requires, and administrative surfaces are not exposed to the public internet.

Access controls

Access to production systems follows least privilege and requires strong authentication. Permissions are role-scoped, granted on a need-to-know basis, and reviewed rather than left to accumulate.

Monitoring & audit logging

We monitor our systems for anomalous and unauthorized activity, and we maintain audit logs of significant actions so that events can be investigated and reconstructed. Logging is designed to give us — and, where appropriate, you — a defensible record of what happened and when.

Compliance alignment

Security that cannot be demonstrated is incomplete. We map our controls and evidence to the frameworks that enterprise buyers, auditors, and regulators rely on. To be precise about what this means: our program is aligned to and mapped against these frameworks. We describe our posture accurately and do not claim certifications we cannot substantiate.

• NIST AI Risk Management Framework (AI RMF) — mapped as the basis for identifying and managing AI-specific risk across the lifecycle.
• EU AI Act — controls aligned to the obligations of a risk-based approach to AI systems.
• SOC 2 — controls aligned to the trust-services criteria that enterprise procurement teams use to evaluate vendors.

For how we help customers reach the same standard in their own AI programs, see our Compliance page.

Responsible disclosure

We welcome the security research community and treat external reports as a valued part of our defense. If you believe you have found a vulnerability in a Deflected system, please report it to security@deflected.ai with enough detail for us to reproduce and validate the issue.

Our commitments to researchers who engage with us in good faith:

• We will acknowledge your report and work it in good faith toward a resolution.
• We ask for coordinated disclosure: please give us reasonable time to investigate and remediate before any public discussion.
• Please avoid privacy violations, data destruction, and service disruption while researching, and only test against accounts and data you own or are authorized to access.

We will not pursue good-faith research conducted within these guidelines. If you are unsure whether a specific test is acceptable, ask us first.