[ Legal ]

Security practices

Effective July 9, 2026. Last updated July 9, 2026.

PrivacyTermsCookiesSecurity

[ Summary ]

A public overview of how IdonAI protects customer data, operates infrastructure, and handles vulnerability reports — practices and targets, not absolute guarantees.

This page is provided for transparency. It is not a substitute for legal advice. If you need a signed DPA, custom terms, or a security review packet, contact legal@idonai.com or use the enterprise form.

1. Commitment and scope

IdonAI ("IdonAI," "we," "us," or "our") builds AI products — including Quark at https://quark.idonai.com, related APIs, models, and the website at https://idonai.com — that customers and developers trust with prompts, code, research workflows, and account data. Security is treated as an engineering discipline: layered controls, least privilege, continuous monitoring, and clear escalation paths when something goes wrong.

This page is a public security overview. It describes the types of technical and organizational measures we maintain for the Services. It is not a warranty, service-level agreement, penetration-test report, or certification. Contractual security commitments for enterprise customers are set out in the applicable order form, MSA, DPA, or security exhibit. Product-specific behavior (for example, data retention for model training) is governed by our Privacy Policy, Terms of Service, and any product documentation that applies to your plan.

Last updated: July 9, 2026. Effective for this public overview as of July 9, 2026. Governing law for this document: the laws of New South Wales, Australia; venue: the courts of New South Wales, Australia, except where mandatory law provides otherwise or an enterprise agreement specifies a different governing law.

Scope of this overview generally includes: the IdonAI marketing site, Quark and authenticated product surfaces, API endpoints we operate, identity and account systems we control, and supporting cloud infrastructure under our management. It does not cover third-party applications that call our APIs, customer-managed environments, or networks outside our control.

2. Encryption

In transit. Client connections to IdonAI web properties and APIs are protected with TLS. We target modern TLS configurations (TLS 1.3 preferred; older insecure protocols and weak ciphers disabled where our edge and platform controls allow). Certificates are managed through our hosting and edge providers with automated renewal where available.

At rest. Customer and system data stored in managed databases, object storage, and backups is encrypted at rest using industry-standard algorithms provided by our cloud and platform vendors (typically AES-256 or equivalent). Encryption keys for managed services are handled according to those providers’ key-management practices, with IdonAI access limited to operational necessity.

Secrets and credentials. API keys, service credentials, and similar secrets are stored in controlled secret stores or environment configuration — not in source control. We rotate credentials when personnel change roles, when a suspected exposure occurs, and on a periodic basis for sensitive production secrets.

Additional protections. Where product features support it, we encourage customers to use strong authentication, protect API keys as secrets, and terminate unused keys. Enterprise customers may discuss additional encryption, key-management, or residency requirements under a separate agreement.

3. Access control

We apply least privilege to production systems. Human and service access is granted based on role, reviewed when responsibilities change, and revoked when no longer needed.

  • Role-based access control (RBAC): production administrative access is limited to personnel whose job functions require it; broad “always-on” admin rights are avoided.
  • Multi-factor authentication (MFA): MFA is required for access to critical internal systems and cloud consoles used to operate the Services.
  • Separate environments: development, staging, and production are separated so that day-to-day engineering work does not require standing production data access.
  • Authentication for customers: account access to Quark and related surfaces uses modern authentication flows (including session cookies managed via our auth infrastructure). Customers should protect credentials and enable available account-security features.
  • API authentication: API access is authenticated with customer-managed keys or tokens; customers are responsible for scoping, rotating, and storing those credentials securely.
  • Auditability: privileged actions and administrative access are logged where platform capabilities allow, supporting investigation and accountability.

We do not use shared personal passwords for production access. Service accounts are purpose-scoped. Vendor access, when required for support, is time-bounded and monitored according to the vendor’s and our contractual controls.

4. Infrastructure and isolation

IdonAI runs on reputable cloud and platform providers. We use managed services for compute, data stores, edge delivery, and identity where they improve reliability and security posture relative to undifferentiated self-hosting.

  • Network controls: production services are placed behind hardened edges, firewalls, and/or private networking patterns appropriate to each workload. Public exposure is limited to intended interfaces (web, API, documentation).
  • Isolation: tenant data is logically separated in application design; administrative tooling that can access customer content is restricted and audited.
  • Availability and resilience: we use redundant configurations, health checks, and status communication (see our status page) to reduce single points of failure. Backups are taken for critical data stores according to platform schedules.
  • Dependency on subprocessors: core hosting, authentication, and delivery partners are selected for security capability and contractual data-protection terms. A current subprocessor list is available to enterprise customers on request (see Section 11).
  • Quark and API surfaces: product traffic to quark.idonai.com and api.idonai.com is terminated on TLS-enabled endpoints with rate limiting and abuse controls intended to protect availability and account integrity.

Physical security of data centers is provided by our cloud vendors under their compliance programs. IdonAI personnel do not operate private data-center facilities for the standard multi-tenant Services.

5. Application security

We integrate security into how we design, build, and ship software — proportionate to our stage and risk profile, and improving continuously.

  • Secure development lifecycle (SDLC): changes are reviewed before merge; sensitive paths (auth, billing, data export, admin) receive heightened scrutiny. We prefer small, reviewable changes over large unreviewed deployments.
  • Dependency hygiene: we track third-party packages, apply security updates for known critical vulnerabilities in a timely manner, and avoid abandoned or unmaintained dependencies where practical alternatives exist.
  • Input handling: APIs and web surfaces validate and sanitize untrusted input; we design against common web risks (injection, XSS, CSRF where session cookies are used, insecure direct object references) using framework defaults and explicit checks.
  • Secrets in code: automated and manual review practices aim to prevent credentials from landing in repositories; if an exposure is discovered, we rotate and investigate.
  • Configuration: production configuration is environment-separated; debug modes and verbose error detail are not exposed to public clients.
  • Abuse and misuse: rate limits, anomaly detection signals, and acceptable-use enforcement help protect the platform and other customers from automated abuse.

We may engage third-party assessments (for example, penetration tests or architecture reviews) as the program matures. Summaries or letters of attestation may be shared with enterprise customers under NDA when available — not as public marketing claims of perfection.

6. Logging and monitoring

Operational visibility is essential to detecting misuse, diagnosing outages, and investigating incidents.

  • Application and infrastructure logs: we collect logs for authentication events, API errors, administrative actions, and system health, retained for periods appropriate to security and operational needs (and described further in our Privacy Policy where personal data is involved).
  • Monitoring and alerting: health checks, error budgets, and alerting pipelines notify on-call personnel of availability and security-relevant anomalies.
  • Access to logs: log access is restricted to personnel with a need to know; logs are not used for advertising.
  • Customer-visible status: we publish service status information so customers can distinguish platform incidents from local issues.

Logging is balanced against privacy. We avoid retaining unnecessary sensitive content in logs and apply redaction or minimization where feasible. Customers should avoid placing secrets in prompts or support tickets when not required.

7. Incident response

We maintain an incident-response process for security and privacy events that may affect the confidentiality, integrity, or availability of the Services or customer data.

  1. Detect and triage: alerts, employee reports, customer reports, and researcher disclosures are assessed for severity and scope.
  2. Contain: limit ongoing risk (for example, revoke credentials, isolate affected components, apply emergency patches, or disable abused endpoints).
  3. Eradicate and recover: remove the root cause where identified, restore service, and verify that mitigations hold.
  4. Notify: where legally required or contractually agreed, we notify affected customers and regulators without undue delay, with information reasonably available at the time and updates as the investigation progresses.
  5. Learn: post-incident reviews identify corrective actions (process, code, monitoring) and track them to completion.

To report a suspected security incident involving your account or an active exploitation in progress, contact security@idonai.com immediately with “INCIDENT” in the subject line. For privacy incidents or data-subject concerns, also involve privacy@idonai.com as appropriate.

Enterprise agreements may define additional notification timelines, contacts, and cooperation duties. Those contractual terms control for covered customers.

8. Vulnerability disclosure and responsible disclosure policy

We welcome good-faith security research that helps us protect customers. This section describes how to report vulnerabilities in IdonAI-operated Services and the expectations we set for coordinated disclosure.

How to report. Email security@idonai.com with a clear subject such as “Vulnerability report — [brief title].” Do not use public issue trackers, social media, or community forums for first disclosure of unfixed vulnerabilities.

What to include. To help us reproduce and prioritize quickly, please provide:

  • A concise description of the issue and its potential impact.
  • Affected URL(s), API endpoint(s), product surface (for example, quark.idonai.com, api.idonai.com, idonai.com), and environment (production vs. other) if known.
  • Step-by-step reproduction instructions, including request/response samples where safe to share.
  • Proof-of-concept materials that demonstrate the issue without destroying data or harming other users.
  • Your assessment of severity (optional) and any suggested remediation (optional).
  • A contact method for follow-up and whether you wish to be credited if we publish an acknowledgment.

Safe harbor for good-faith research. If you make a good-faith effort to comply with this policy, avoid privacy violations, service disruption, and data destruction, and do not exploit a vulnerability beyond what is necessary to demonstrate it, IdonAI will not pursue legal action against you for that research under the computer-crime or similar laws we can control as a complainant. Safe harbor does not authorize:

  • Accessing, modifying, or exfiltrating data that is not yours without authorization beyond minimal proof.
  • Denial-of-service attacks, resource exhaustion, or spam against the Services or our providers.
  • Social engineering, phishing, or physical attacks against IdonAI personnel, offices, or customers.
  • Research against third-party systems that are not operated by IdonAI.
  • Extortion, ransom demands, or threats of disclosure timed to coerce payment.

Coordinated disclosure. Please do not publicly disclose vulnerability details, exploit code, or indicators that would enable abuse until we have confirmed a fix (or mutually agreed on a disclosure date). We are committed to working with researchers in good faith. If a deadline is important to you, tell us when you report so we can plan.

Response timeline targets (not guarantees). We aim to:

  • Acknowledge receipt of a valid report within 3 business days.
  • Provide an initial severity/triage assessment within 10 business days of acknowledgment when sufficient detail is provided.
  • Keep you informed of material status changes while remediation is in progress.
  • Coordinate on disclosure timing after a fix is deployed or a mitigating control is in place.

Out of scope (typical). Reports that are purely informational without a security impact, findings limited to missing best-practice headers without a demonstrated exploit path, self-XSS requiring unlikely user interaction, and issues in end-of-life or explicitly unsupported environments may be closed as informational. We still appreciate thoughtful reports.

Bug bounties. IdonAI may offer recognition or discretionary rewards for high-quality reports but does not currently operate a public paid bug-bounty program with fixed payouts. Terms of any private bounty or Hall of Fame recognition will be communicated separately. Questions: security@idonai.com.

9. Compliance posture

We align our security and privacy practices with widely recognized frameworks and legal requirements relevant to our customers. We do not claim certifications we have not earned.

  • SOC 2 Type II: in progress. We are working toward a SOC 2 Type II examination. When a report is available, enterprise customers may request it under NDA. Until then, treat “in progress” as a program status — not a completed attestation.
  • GDPR-aligned practices: we design processes intended to support GDPR principles (lawfulness, fairness, transparency, purpose limitation, minimization, integrity/confidentiality, and accountability) for personal data we process as a controller or processor, as described in our Privacy Policy and Data Processing Addendum where applicable.
  • Australian privacy: we operate with regard to the Australian Privacy Principles and ${LEGAL_META.governingLaw} as applicable to our entity and offerings.
  • ISO/IEC 27001 and similar: we do not currently claim an ISO 27001 (or similar) certification. Mapping our controls to ISO-style domains may occur internally or for enterprise questionnaires without implying formal certification.
  • Customer questionnaires: enterprise security reviews (SIG, CAIQ-style, or custom) can be supported via ${LEGAL_META.emails.security} or your IdonAI enterprise contact.

Compliance artifacts, subprocessors, and penetration-test summaries shared with customers are confidential and may be outdated the moment they are issued; always confirm the report date and scope.

10. Customer responsibilities

Security is shared. IdonAI secures the platform; customers secure how they use it, what they send to it, and how they manage access on their side.

  • Protect account credentials, MFA devices, and API keys; rotate keys after personnel changes or suspected exposure.
  • Apply least privilege within your organization (workspace roles, key scoping) and revoke access promptly when users leave.
  • Avoid submitting regulated or highly sensitive data unless your plan, configuration, and legal agreement support that use case.
  • Validate outputs before relying on them in production systems; AI outputs can be incorrect or unsafe if used without human review in high-stakes contexts.
  • Keep client libraries, SDKs, and integrations you control up to date.
  • Configure your own networks, endpoints, and logging for applications that call IdonAI APIs.
  • Promptly report suspected account compromise or abuse involving your tenant to ${LEGAL_META.emails.security} or ${LEGAL_META.emails.support}.
  • Comply with our Terms of Service and Acceptable Use requirements; do not attempt to probe or attack the Services except under the responsible disclosure policy in Section 8.

Failure to follow customer-side security practices may increase risk to your data and organization even when IdonAI controls operate as designed.

11. Subprocessors

We use carefully selected subprocessors for hosting, authentication, email delivery, analytics (if enabled), error monitoring, and related infrastructure necessary to operate the Services.

Enterprise customers may request a current list of material subprocessors, including the purpose of processing and general location, by contacting us. We provide that list under reasonable confidentiality expectations and update it as our stack evolves. Where a Data Processing Addendum applies, it governs notice periods and objection rights for subprocessor changes.

Subprocessors are bound by data-protection obligations appropriate to their role. Use of a subprocessor does not reduce IdonAI’s responsibility to customers under applicable agreements.

12. Limitations

This overview describes practices we believe are appropriate for our Services as of the last updated date. It does not:

  • Guarantee that the Services will be uninterrupted, error-free, or immune from unauthorized access, hardware failure, software bugs, or zero-day exploits.
  • Create contractual SLAs, credits, or audit rights unless expressly stated in a signed agreement.
  • Extend to third-party sites, models, or tools that you choose to connect to IdonAI, or to customer-operated infrastructure.
  • Replace the Privacy Policy, Terms of Service, or product documentation.
  • Constitute legal, compliance, or certification advice for your organization.

Threats evolve. Controls that are adequate today may need reinforcement tomorrow. We update practices over time and may revise this page accordingly. Where an enterprise agreement conflicts with this public overview, the agreement controls for that customer.

14. Contact

Use the following channels depending on your request:

Company: IdonAI. Website: https://idonai.com. Product: Quark at https://quark.idonai.com. Governing law: the laws of New South Wales, Australia. Venue: the courts of New South Wales, Australia.

For urgent production incidents, include severity, affected product, approximate start time, and any request IDs or account identifiers that help us locate logs — without pasting long-lived secrets into email.

Related