Trust Center
Draft — not legal advice. Every [Organization-specific information required] marker needs a fact only your organisation can supply. No certification is claimed. Have counsel review before publishing.
One page for the questions a security review asks, with links to the technical detail behind each answer.
This page states what is true today. Where a programme is not in place, it says so rather than describing an aspiration in the present tense.
Trust principles
- Local by default. The agent loop runs on the customer's hardware. We hold less because less is sent.
- Explicit authority. Every action that changes something passes a permission gate the user controls.
- Legible behaviour. Tool calls, approvals and background runs are logged where the customer can read them.
- Stated limits. Gaps are documented, in the threat model and here.
Infrastructure
| Item | Status |
|---|---|
| Hosting providers and regions | [Organization-specific information required] |
| Data residency options | [Organization-specific information required] |
| Network isolation and segmentation | [Organization-specific information required] |
| Self-hosted option | Available. Docker and Kubernetes — see Self-hosting |
Availability and reliability
| Item | Status |
|---|---|
| Uptime commitment | [Organization-specific information required] — no SLA is offered by default |
| Historical uptime | [Organization-specific information required] |
| Status page | [Organization-specific information required] |
| Maintenance windows | Announced in advance; rolling upgrades avoid downtime where migrations allow |
| Degradation behaviour | A node whose database is unreachable reports unready and drains rather than returning errors |
Privacy
What is collected, why, and how long it is kept is set out in Privacy. In summary: sessions, memory and credentials are local by default; analytics and crash reporting are opt-in; we do not sell personal data and do not train models on customer content.
Security
Architecture, encryption, the permission model, disclosure and incident response are documented in Security. That page includes what is not implemented, which is usually the part a review needs.
Data protection
| Control | Status |
|---|---|
| Encryption in transit | TLS on all network traffic |
| Encryption at rest | Memory encrypted with project-scoped keys |
| Credential storage | OS keystore; never in configuration files |
| Key management | [Organization-specific information required] |
| Data deletion | User-initiated in app; backup purge window [Organization-specific information required] |
| Data processing addendum | [Organization-specific information required] |
Responsible AI
- Arble routes to the model the customer chooses. We do not train on customer content.
- Actions are gated. An agent cannot act outside the permissions granted to it.
- Output is not treated as authoritative: the product surfaces sources where a tool provides them, and the documentation states plainly that models are confidently wrong sometimes.
- Model providers are third parties with their own retention and training policies. We link to them rather than summarising them, because summaries go stale.
Transparency
- Breaking changes and deprecations are published in the changelog with removal versions.
- Security-relevant fixes are described rather than folded silently into a patch.
- Known limitations are documented on the page where someone would look for the feature.
Compliance
| Framework | Status |
|---|---|
| SOC 2 | [Organization-specific information required] — not claimed |
| ISO 27001 | [Organization-specific information required] — not claimed |
| HIPAA | [Organization-specific information required] — not claimed |
| GDPR | Rights and legal bases documented in Privacy. Representative and DPO: [Organization-specific information required] |
| CCPA | Rights honoured; no sale or sharing of personal information |
| Penetration testing | [Organization-specific information required] |
| Security questionnaires | [Organization-specific information required] |
We will not list a certification we have not completed. If a framework is required for your procurement, ask — an honest answer about where we are is more useful than a badge.
Subprocessors
Third parties that process personal data on our behalf, their purpose and their location: [Organization-specific information required]. Notification of changes to this list: [Organization-specific information required].
Note that AI providers and MCP servers you connect are your processors, not ours — you choose them and you supply the credentials.
Incident response and continuity
| Item | Status |
|---|---|
| Incident response process | Detect, contain, eradicate, recover, review — see Security |
| Customer notification timeline | [Organization-specific information required] |
| Regulator notification timeline | [Organization-specific information required] |
| Backup frequency and retention | [Organization-specific information required] |
| Restore testing cadence | [Organization-specific information required] |
| RTO and RPO | [Organization-specific information required] |
| Business continuity plan | [Organization-specific information required] |
Access controls
| Control | Status |
|---|---|
| Employee access to customer data | Minimised by architecture: most customer data never reaches us |
| Access review cadence | [Organization-specific information required] |
| Multi-factor authentication internally | [Organization-specific information required] |
| Background checks | [Organization-specific information required] |
| Security training | [Organization-specific information required] |
| Offboarding process | [Organization-specific information required] |
Monitoring and vendor security
- Service telemetry covers latency and error rates for our own infrastructure.
- Dependency advisories are tracked and patched; see supply chain.
- Vendor security review process: [Organization-specific information required].
Security contact
Security enquiries, questionnaires and disclosure: [Organization-specific information required].
FAQ
Are you SOC 2 certified?
Status is [Organization-specific information required]. We do not claim certifications we do not hold, and we will not put a badge on this page before an audit exists.
Can we self-host to keep data in our own environment?
Yes. Docker and Kubernetes are documented in Self-hosting. A self-hosted deployment sends us nothing beyond update checks, which can be disabled.
Do you sign a DPA?
[Organization-specific information required].
Where is our data processed?
For self-hosting, wherever you run it. For hosted services, [Organization-specific information required].
Do you train on our data?
No. Your chosen AI provider's policy is separate and worth reading.
Who are your subprocessors?
[Organization-specific information required]. AI providers and MCP servers you connect are your processors, not ours.
What is your uptime commitment?
None by default. Any commitment lives in a separate agreement — [Organization-specific information required].
How quickly would you notify us of a breach?
[Organization-specific information required]. The response process itself is documented in Security.
Can we run a penetration test?
Ask first at [Organization-specific information required]. Testing against shared infrastructure without agreement affects other customers.
How much customer data do you actually hold?
For local-only use, effectively none beyond account records. That is the point of the architecture rather than a policy choice.
Related
Feedback
Something unclear, or wrong? Documentation defects are treated as defects. Tell us at [Organization-specific information required], or open an issue against the documentation. Include the page and the sentence — a page nobody can follow is a page that has failed, whatever it says legally.