# ARBA Security Overview

Version: 2026-09-24

Owner: ARBA International B.V.
Public contact: info@arba-international.com

## Scope

This document summarizes ARBA Agency's public security posture for enterprise AI work and the Nexus platform. It is not a certification, audit opinion or substitute for an engagement-specific security review.

## Supported deployment profiles

- Customer cloud: deployment in the customer's own cloud tenancy.
- Customer-controlled infrastructure: systems run on servers and networks controlled by the customer.
- On-premises: installation inside the customer's data centre without a requirement for inbound operational access.
- Air-gapped: pull-only or offline release path, no callbacks and offline-capable licensing for the applicable Nexus profile.

Platform hosting and model inference are separate choices. Public AI services process the content of requests sent to them. On-premises and air-gapped profiles require suitable local models and dependencies if model requests must stay inside the perimeter. Exact capabilities, responsibilities and update procedures are confirmed in solution design before production.

## Data boundaries and egress

Model providers, regions, endpoints and permitted outbound data flows are agreed with the customer. Public AI services receive the content sent in model requests. Egress controls restrict connections to the approved configuration. An isolated profile requires local models and dependencies suitable for the selected tasks.

## Identity and authorization

- SSO through the customer's identity provider where included in scope.
- Role-based permissions.
- On-behalf-of execution: an AI action cannot exceed the rights of the initiating user.
- Authorization is checked per request for protected operations.

## Auditability and human control

- Execution trace recording source references, tool calls, actions and decisions for review and audit.
- Document access logged per read where the applicable Nexus capability is used.
- People approve operating rules and permitted actions. Disputed cases and actions requiring separate approval return to a responsible person.
- Administrative and everyday operational permissions are separated.

## Model and key control

ARBA uses public AI services and can use on-premises models when their quality meets the task requirements. Provider selection, credential storage and endpoint access are agreed in system design. Derived AI data such as abstracts, digests and claims is included in the encryption design, not only source documents.

## Public processing baseline

The public website may use providers for website delivery and security, database storage, CRM and operational notifications, and selected messaging channels. The applicable named processor schedule depends on the service, channel and deployment and is provided when required.

See https://arba-international.com/privacy for legal bases, retention principles, recipient categories and international-transfer safeguards.

## Responsible disclosure

Send a reproducible report to info@arba-international.com with the subject `Security disclosure`. Include the affected surface, potential impact, reproduction steps and a safe contact method.

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 aims to acknowledge a credible report within five business days and does not currently operate a public bug-bounty programme.

## Honest limits

- ARBA does not currently claim ISO 27001, SOC 2 or another company-wide security certification.
- Capabilities differ by deployment profile.
- A security review with the customer's team is required before production.
- Engagement-specific DPA, questionnaire responses, architecture packs and processor schedules are issued only after the solution scope and data boundary are known.