Security evidence for enterprise review
Deployment models, data boundaries, identity controls, auditability and procurement materials — in one place for security, privacy and architecture teams.
- Customer-controlled deployment
- Human-gated actions
- Explicit limits
- Reviewed 28 July 2026
Choose the boundary before choosing the model
The exact control set is agreed per engagement. This public matrix describes the supported architectural profiles, not a blanket certification.
| Control point | Your cloud | Your infrastructure | On-premises | Air-gapped |
|---|---|---|---|---|
| Data location | Your cloud tenancy | Servers and networks you control | Your data centre | Isolated environment |
| Inference | Approved endpoint in your tenancy | Approved endpoint inside your perimeter | Local or approved private endpoint | Local endpoint only |
| Inbound access | By customer policy | Not required for operation | Not required for operation | None |
| Release path | Controlled deployment pipeline | Customer-controlled pull | Signed offline-capable package | Pull-only/offline package |
| Typical fit | Enterprise cloud estates | Sovereign customer environments | Regulated operations | Highly restricted environments |
Capabilities and responsibilities are confirmed in the solution design and security review before production.
Egress under control
In sovereign deployments the control plane holds no customer data; the only egress is a data-free licence heartbeat.
A runtime egress latch refuses to boot unless inference is pinned to an approved endpoint, and hard-blocks any call outside the perimeter.
The AI never outruns the person
SSO & corporate directory
Sign-in through your identity provider; accounts and roles follow your directory.
On-behalf-of execution
AI can never exceed the rights of the person who launched it; authorization is re-checked per request.
Role-based permissions
Access is scoped by role and area; administrative actions are separated from everyday use.
Every step accountable
Append-only trace
Every reasoning step and action lands in an append-only, replayable trace.
Per-read access logging
Document access is logged per read, not per session.
Human-gated write-back
Changes to systems of record require explicit human confirmation.
Your models, your keys
Bring your own model: OpenAI-family and Anthropic Claude lanes proven inside a customer's own cloud — keys never leave your perimeter.
Encryption extends to the derived AI plane: abstracts, digests and claims are encrypted, not just the source data.
What we do not claim
- We do not currently claim ISO or SOC certification; our security posture is demonstrated architecturally and per engagement
- Specific capabilities depend on the deployment mode — cloud, on-prem and air-gap profiles differ
- A security review with your team is part of every engagement before production
Materials for vendor, security and privacy review
Public documents can be used immediately. Engagement-specific materials are issued after scope and deployment boundaries are known.
Security overview
PublicVersioned English summary of the controls and honest limits published in this Trust Center.
Download MarkdownPrivacy policy
PublicWebsite data handling, legal bases, retention principles, recipients and data-subject rights.
Open policyData Processing Agreement
On requestPrepared for the applicable services, roles, data categories and deployment model.
Request DPASecurity questionnaire
On requestCompleted against the actual solution scope rather than a generic product profile.
Start reviewArchitecture & data-flow pack
Under NDADetailed boundaries, integrations, ports, identities and operational responsibilities.
Request architecture packProcessor schedule
Engagement-specificThe applicable provider list and processing roles depend on channel and deployment choices.
Review public categoriesPublic categories of providers and processing
This is the public baseline for the website and demo surfaces. A named, engagement-specific schedule is provided where ARBA acts as processor.
| Surface | When used | Data involved | Primary control |
|---|---|---|---|
| Website delivery & security | Public-site access | IP address and request metadata | Limited operational retention and access |
| CRM & operational notifications | Inquiry submission | Business contact details and inquiry content | Need-to-know access and purpose limitation |
| Messaging channels | Only when that channel is selected | Channel identifiers and message content | Channel-specific terms and user choice |
| Aptus demo infrastructure | Aptus demo only | Demo interaction and functional continuity token | Functional purpose and documented retention |
See the Privacy Policy for legal bases, retention principles and international-transfer safeguards.
Report a potential security issue
Send a reproducible report to [email protected] with the subject “Security disclosure”. Include the affected surface, impact, steps to reproduce and a safe contact method. We aim to acknowledge a credible report within five business days.
Do not access, change or retain data that is not yours; do not disrupt services; and allow a reasonable remediation window before public disclosure. ARBA does not currently operate a public bug-bounty programme.
- test only against accounts, tenants and data you are authorized to use
- use the minimum proof needed to demonstrate the issue
- coordinate disclosure timing while remediation is in progress
Trust Center FAQ
Bring your security, privacy and architecture teams
We will review the actual deployment boundary, controls and open questions with them.