Deployment and security
A clear home for your AI, tooling, and data.
Start with your approved AI client and AJAEX-operated tooling. Compare who runs each component, where data travels, and the current availability of managed and private alternatives.
Common architecture
The bridge stays with TRIRIGA. The intelligence layer can move.
Layer 1
Intelligence and control
Semantic routing, evidence composition, governed MCP and REST tools, tenant and environment policy, confirmation, and audit.
AJAEX-operated in Models 1 and 2. Customer-operated in Model 3.
Layer 2
Customer-side AJAEX bridge
Supported in-JVM access to the TRIRIGA platform surfaces that require local execution, licensed and signed for the named scope.
Installed and operated with the customer in every model.
System of record
Customer TRIRIGA
Platform, database, configuration, records, documents, runtime, and the approved integration identity remain customer-hosted.
Commercial models
Compare responsibility, data flow, and current availability.
Bring your AI
Customer AI / AJAEX Tooling
Organisations that already have an approved AI client or model account.
AJAEX: Hosted TRIRIGA intelligence, MCP tooling, policy, and administration.
Customer: AI client or model account, TRIRIGA, and the installed signed AJAEX bridge.
Managed workspace
AJAEX Managed
Teams that want one managed workspace and a single service boundary.
AJAEX: AI workspace, model integration, hosted intelligence, MCP tooling, and administration.
Customer: TRIRIGA and the installed signed AJAEX bridge.
Private edition
Customer Private
Regulated, sovereign, isolated, or customer-operated environments.
AJAEX: Deployment components and templates, implementation guidance, and an agreed support scope for the design-partner engagement.
Customer: UI, AI, intelligence runtime, secrets, logs, network, TRIRIGA, and operating controls.
Responsibility matrix
Who operates each component.
Scroll horizontally to compare all models.
| Component | AJAEX Managed | Customer AI | Customer Private |
|---|---|---|---|
| UI and user experience | AJAEX | Customer | Customer |
| AI model or model account | AJAEX and selected provider | Customer | Customer |
| Intelligence, MCP, and admin layer | AJAEX | AJAEX | Customer |
| AJAEX bridge inside TRIRIGA | Customer | Customer | Customer |
| TRIRIGA and system of record | Customer | Customer | Customer |
Data flow
Bring Your AI keeps the AI client with you; selected tooling data still reaches AJAEX.
Each service design documents regions, provider terms, retention, backup, support access, deletion, and subprocessors.
Scroll horizontally to compare all models.
| Data category | AJAEX Managed | Customer AI | Customer Private |
|---|---|---|---|
| Prompts and conversations | Can traverse AJAEX and the selected AI provider | Customer AI; AJAEX only if the chosen adapter sends them | Customer systems and selected provider |
| Tool arguments and results | AJAEX-hosted tooling | AJAEX-hosted tooling | Customer-hosted tooling |
| Service credentials | AJAEX-hosted secret path for the named environment | AJAEX-hosted secret path for the named environment | Customer secret store |
| Identity and audit metadata | AJAEX UI, admin, and gateway | Customer AI plus AJAEX tenant-level gateway audit | Customer-hosted audit |
| TRIRIGA system of record | Customer | Customer | Customer |
| Licence, update, and support traffic | Documented for the selected managed service | Documented for the selected tooling service | Online, offline, or proxied route agreed during solution design |
The current hosted architecture uses AWS eu-west-2. Any contractual commitments for residency, retention, backup, support access, or recovery are set out in the selected service agreement.
Control questions
Review the controls behind each deployment model.
Service identity and least privilege
The customer supplies a dedicated TRIRIGA integration identity. Its permissions and the enabled tool list together define the maximum reachable scope.
Signed bridge requests
Hosted and private models use different signing arrangements. The named solution design records the active signer, tenant binding, rotation, and failure behaviour.
Tool policy and confirmation
Read, write, administrative, and deployment capabilities are separated. Tools that change state require server-side confirmation and an agreed change boundary.
Explicit data flow
Prompts, arguments, results, credentials, identity metadata, logs, diagnostics, and provider processing are mapped for the selected model.
Customer-operated bridge
The supported bridge is installed inside the customer TRIRIGA environment in the appropriate javax or Jakarta-compatible build.
Assurance follows the model
Review the available evidence for retention, backup, monitoring, support access, recovery, provider terms, and artifact handling before agreeing the service scope.
The current hosted MCP authenticates at tenant level. Per-user TRIRIGA identity and user-level OAuth attribution are not provided as standard controls. Any production engagement that requires them must address those requirements before use.
Make the deployment boundary the first architecture decision.
The architecture review maps the AI, tooling, bridge, identity, network, data flow, enabled tools, and assurance evidence before a pilot is defined.