Security

1. Our Approach

This page describes the security practices actually implemented across the Burdenoff platform today. We keep it accurate rather than aspirational: where a control is on our roadmap but not yet shipped, we say so explicitly rather than imply it exists.

2. Encryption

• All traffic to the Service is encrypted in transit. Public endpoints accept TLS 1.2 or TLS 1.3 only, both at our edge network and at the origin load balancers behind it, and the origin load balancers accept connections only from that edge network.
• Services connect to their databases over TLS with full certificate verification.
• Databases and object storage are encrypted at rest using our cloud provider's managed encryption keys.
• Sensitive credential fields — including MFA (TOTP) secrets, API/HMAC signing keys, OAuth access and refresh tokens, and tenant OIDC client secrets — are field-level encrypted at rest with AES-256, in addition to storage-level encryption.

3. Access Control & Tenant Isolation

• Every workspace, organization, and tenant is isolated at the data layer; API access is scoped to the authenticated actor's own tenant.
• Every GraphQL query and mutation across our services carries an explicit role-based-access-control (RBAC) authorization check, enforced centrally at the API gateway from a versioned permission catalog — services never re-implement authorization on their own.
• Administrative and internal service-to-service calls are authenticated and scoped; there is no direct, unauthenticated machine-to-machine path into the platform.
• Production infrastructure access is restricted to authenticated operators through a managed bastion and Zero Trust access broker — there is no open SSH or direct public database access.
• Changes to production data require an operator's individual single-sign-on identity and a recorded reason; shared credentials are refused for write access.
• Application secrets are held in a managed secrets store and delivered to workloads at runtime; they are never committed to source control.

4. Audit Logging

Administrative and security-relevant actions are recorded in an activity/audit log. Audit records are retained for a mandatory 7-year window and cannot be deleted early through any admin-facing control, including by Burdenoff staff, once written — purge only occurs automatically once a record is more than 7 years old.

5. Vulnerability Management

• Every service image is scanned for known CVEs, infrastructure-as-code misconfiguration, and software-bill-of-materials issues in CI before it can deploy.
• Secret scanning runs against every commit to prevent committed credentials.
• We run a documented internal security review before every production deployment.

6. Hosting, Change Management & Backups

• The Service runs on Amazon Web Services in the ap-south-1 (Mumbai, India) region, behind Cloudflare's edge network. We do not currently operate a second hosting region.
• Every production change is made through version-controlled source and an automated build-and-deploy pipeline; there is no manual deployment path to production.
• Production relational databases are backed up automatically with point-in-time recovery and are protected against accidental deletion.

7. Data Retention & Deletion

See our Privacy Policy for retention periods by data category, and burdenoff.com/subprocessors for the current list of parties who process data on our behalf.

8. Certifications and Attestations

Burdenoff has not yet completed a third-party accredited security certification or attestation (for example, SOC 2 Type II, ISO/IEC 27001, or ISO/IEC 42001). Achieving these is on our compliance roadmap, and engaging an accredited auditor requires a dedicated engagement over weeks to months once scheduled. This page will be updated with the specific certification, scope, and issuing auditor only once an attestation has actually been completed and a report is available — we do not claim a certification is in place before that happens. If your organization requires a signed customer security questionnaire or a specific control attestation ahead of a certification, contact security@burdenoff.com.

To prepare for an independent audit, we maintain an internal map of our controls and the evidence for each against the SOC 2 Trust Services Criteria, ISO/IEC 27001 Annex A and, for AI agents, ISO/IEC 42001 Annex A. This is internal readiness work, not an attestation, and no independent audit has started yet.

Burdenoff is not currently able to sign a HIPAA Business Associate Agreement, and the Service is not designed for protected health information. Please do not submit protected health information unless it has been expressly agreed in a signed enterprise order form. Payments are handled by our payment processors; Burdenoff does not store full payment card numbers.

9. AI Agent Governance

Workspace administrators govern the AI agents in their workspace with policies. Only policies an administrator has activated are enforced, and they are enforced by the Service at the moment an agent runs, not only stored as settings:

• Model usage. An administrator can limit which AI models and model providers agents may use. A request that would use any other model is refused before the model is called, including requests delegated from one agent to another and messages arriving from connected chat channels.
• Content. Blocked keywords and patterns, and optional detection of common personal-data shapes, are checked on the message sent to an agent and on the agent's answer. A blocked answer is replaced with a refusal and is never shown.
• Rate and budget limits. Per-minute and per-hour request limits, a per-minute token limit and a daily token budget stop an agent once they are reached, and a per-call cap limits how many tokens a single model answer may use.
• Tools and other agents. Tools can be restricted by name with allow and deny lists and capped by risk level, the number of tool calls in one agent run and the time a tool call may take can be limited, and connections and messages to external agents are refused below the trust level the workspace requires.

Policy refusals on chat channels are recorded in the workspace audit log. We do not yet offer an approval step before an agent goes live, and no part of this is an ISO/IEC 42001 certification; see section 8 for our certification status.

10. Reporting a Vulnerability

If you believe you have found a security vulnerability in the Service, please report it responsibly to security@burdenoff.com. Include enough detail to reproduce the issue. Please do not access, modify, or delete data that is not your own, and give us a reasonable opportunity to investigate and remediate before any public disclosure. We do not offer monetary rewards for vulnerability reports.

Last updated: October 25, 2026