Security & Responsible Disclosure

1. Our security approach

ColleagueOne is designed for organisations that need AI colleagues to do useful work while people retain oversight. We use layered technical and organisational controls around execution, credentials, model use, data policy, access, and review. These controls reduce risk but do not guarantee that the Service is free from vulnerabilities or that every configuration is appropriate for every workload.

We do not claim SOC 2, ISO 27001, or any other certification on this page. Customers should request the current security materials relevant to their evaluation.

2. Execution isolation and credential handling

One sandbox per colleague

Each colleague runs in its own isolated cloud computer using a Firecracker microVM sandbox. The sandbox is the execution boundary for browsing, file operations, and other enabled tools during work.

Credentials stay in the gateway

Connection credentials are retained by the gateway and are not handed to the AI colleague. The gateway mediates authorised requests to connected vendors. Organisations should still grant each connection only the permissions needed for its intended task.

Scoped model access

Model access is routed through a model gateway using per-run scoped keys. Budgets can be set per colleague and per organisation. ColleagueOne is model-agnostic and can route authorised work to OpenAI, Anthropic, and other enabled providers.

3. Governance and oversight

• Human review: Users review a proposed colleague’s persona, tools, rules, model, and schedule before work begins.
• Approvals: Sensitive actions can pause in “Needs You” for a person to approve, reject, or answer a question.
• Results: Work returns to the workspace for review rather than being treated as inherently correct.
• Roles: Owner, admin, and member roles support separation of responsibilities.
• Identity: Supported sign-in options include Google, Microsoft Entra, SAML, OIDC, email sign-in links, and invite-only access; SCIM provisioning is available for managed membership.
• Data policy: Classification labels and DLP policy controls help organisations govern how information is handled.
• Auditability: Audit logs record relevant activity for review and investigation.
• Memory control: Learned facts can be reviewed, approved, or reverted by users.

4. Data handling and providers

Service infrastructure is hosted with DigitalOcean in Bangalore, India. Google processes sign-in data when Google sign-in is selected. Prompts and relevant content may pass through OpenRouter and to the model provider selected for a run. See our Privacy Policy andSubprocessors page for the current draft details.

Security, residency, and transfer requirements differ between UAE Mainland, DIFC, ADGM, and other jurisdictions. Customers are responsible for validating that their configuration, providers, and use are suitable for the data they plan to process.

5. Customer security responsibilities

Customers and authorised users should:

• use individual accounts, protect sign-in methods, and promptly remove access that is no longer needed;
• apply least-privilege roles and connected-service permissions;
• review colleague configurations, schedules, approvals, results, and memory;
• configure budgets, classification labels, DLP policies, and sensitive-action approvals;
• avoid placing passwords, API keys, or other secrets directly in prompts and files;
• choose model providers appropriate for their data and contractual requirements; and
• promptly report suspected account compromise, misuse, or vulnerabilities.

6. Responsible disclosure

If you believe you have found a security vulnerability in ColleagueOne or an Avapti-owned service, please report it privately tosecurity@avapti.com (placeholder security contact). Include, where safe and available:

• a clear description of the issue and its potential impact;
• the affected URL, feature, API operation, or environment;
• minimal, reproducible steps and proof-of-concept material;
• the date and time of testing and any relevant request identifiers; and
• how we can contact you and whether you want to be acknowledged.

Do not include unnecessary personal data, customer content, secrets, or data belonging to another person. Encrypt sensitive details using a method agreed with our security contact before sending them.

We intend to acknowledge valid reports, investigate them, and share progress when practical. Specific response and remediation time commitments will be added after the security contact and process are operationally confirmed.

7. Good-faith research boundaries

Unless we give prior written permission, do not:

• access, modify, copy, retain, or destroy another user’s or customer’s data;
• perform denial-of-service, load, stress, social-engineering, phishing, or physical-security tests;
• use automated scanning that degrades the Service or generates disruptive traffic;
• test third-party providers, connected services, or customer-controlled systems;
• plant malware, establish persistence, pivot to other systems, or exfiltrate data;
• publicly disclose an unresolved vulnerability or demand payment as a condition of confidentiality; or
• violate law, privacy, or the Acceptable Use Policy.

Stop testing once you have enough evidence to demonstrate the issue. If you inadvertently access data, stop, do not retain or share it, and tell us immediately. This draft does not create a bug bounty, promise payment, or grant permission to test systems.

8. Safe-harbour statement

Subject to legal review, Avapti intends not to pursue legal action against researchers who make a good-faith effort to comply with the final published policy, avoid harm and privacy violations, and allow a reasonable period for remediation before disclosure. This draft is not an authorisation and must not be relied on as a safe-harbour commitment until formally published.