Straight answers, including
the uncomfortable ones.

Chakali is a secure enclave for autonomous AI. It is the AI operating system your organization runs AI on: identity, policy, approvals, isolation and evidence applied the same way to every Agent, workflow and Solution.

The comparison that usually lands: you already know how an operating system works. Solutions are the applications, the Chakali Hub is the app store, Skills and Tools are the drivers and libraries, Guardrails are the security kernel, and Runs are the receipts.

No. Chakali is the operating system around models, not a model itself. You choose which models run — open-weight models on your own hardware, models in your own cloud tenant, or approved external providers — and Chakali governs what any of them is allowed to see, use and do.

This is deliberate. Chakali can become more intelligent without automatically becoming more authoritative.

Public AI tools send your prompts, documents and context to an external provider, and the model itself decides what to do next. Neither is acceptable in an environment where the data cannot leave and the action has consequences.

Chakali runs inside your boundary, on models you approved. Deterministic policy — not the model — decides what may execute. Sensitive actions stop and wait for a named person. Every run leaves a reviewable record connecting the identity, the knowledge, the tools, the policy decisions and the outcome.

Yours. Solutions installed from the Hub bring the providers, skills, tools, certificates and runtime a capability needs. Your teams then compose those into Agents, workflows and Agent Teams for the work they actually do.

Chakali's job is to decide what each one may see, use and do — every door still checks the badge.

In an air-gapped or on-premises deployment, no. The application and the models it uses run on infrastructure you control, with or without an internet connection. No prompt, no retrieved document, no metadata and no telemetry crosses the boundary.

If you choose private cloud or managed SaaS instead, the boundary moves and we will tell you exactly where it sits before you commit.

That approach masks identifiers before sending the prompt to an external provider. It is a genuine control, and for many workloads it is the right trade because it keeps frontier capability available. Its limitation is that it is the only mode on offer: even with values replaced, the prompt's structure, intent and business context still leave the boundary, and there is no setting that stops them.

Chakali treats that as a choice rather than an architecture. A workload that cannot tolerate any outbound flow runs closed, on models inside your boundary. A workload where frontier capability matters more can route to an approved external model under policy. Both are governed the same way, and the evidence record shows which path each run took.

Yes, where your risk position allows it. Approved external providers are one of three postures, alongside models in your own cloud tenant and open-weight models on your own hardware.

The difference is that the model is not a user preference. Policy binds which models a given Agent may use, against which data classes, in which workspace — and the run record shows which model saw which data. That is model governance rather than model access: the point is not that you can reach a frontier model, it is that you can prove exactly when you did and what it was given.

Yes. The posture is set per deployment, per workspace and per use case. A research team working on open material can be permitted to reach an approved external model while a supervisory or classified workspace in the same organization stays fully closed.

Workspaces are sealed from one another, so a permission granted in one does not widen what another can do.

Three mechanisms, in the execution path rather than beside it. Every Agent has a role, a scope and a ceiling it cannot step outside. Tools are typed and bounded, so an Agent performs exactly the approved action and nothing adjacent to it. Consequential actions stop for a named human approval that is bound to that exact action.

Policy is enforced in code, not written into a prompt and hoped for.

Prompt-injection risk is reduced, not eliminated. We state that plainly because a vendor who claims otherwise is not being straight with you.

What Chakali does is limit the blast radius: an injected instruction still cannot exceed the Agent's permissions, still cannot call a tool the Agent was not granted, still cannot clear a human approval gate, and still appears in the run record. Defence sits in the architecture rather than in the model's willingness to refuse.

Today Chakali is an architectural and network enclave, not a hardware trusted-execution environment. The protection comes from the perimeter, the isolation between workspaces and providers, the approval gates and the evidence trail, not from CPU-level memory encryption.

Where a silicon TEE is required, Chakali can be deployed onto confidential-compute hardware. We will tell you which guarantees are architectural and which are hardware-backed for your specific deployment, rather than blurring the two.

Yes — that is the point of the evidence model. Each Run retains the identity and purpose behind the request, the model and knowledge used, the tools and actions invoked, the guardrail results, the human decisions, and the outcome with timings. It is exportable for audit.

We state certifications and attestations only when they are supported by current, independently verifiable evidence. Rather than publishing a badge wall, we will tell you during an evaluation exactly what exists today, what is in progress, and what remains the operator's responsibility.

Host hardening, identity lifecycle, key custody, monitoring, backup and compliance sit with the operator in any deployment. We would rather you learn that from us early than from an auditor late.

Three patterns, with one consistent control model. On-premises or air-gapped, operated entirely by you. Dedicated private cloud, aligned to your networking and cloud controls. Or managed SaaS, operated by Rabita Noor within your identity and integration boundaries.

Deployment is a strategy decision, not a technical detail — it follows your risk position, not our convenience.

No. Chakali runs fully cut off from the internet on your own machines, and can switch between connected and disconnected operation as your requirements change.

Updates travel as a signed release bundle you carry across the boundary on your own media. The platform verifies the bundle against its predecessor, deploys it behind a health check, and rolls back automatically if the new release does not come up clean.

Base images and models are staged once when the environment is built, so a routine update is a small, verifiable package rather than a fresh download. No update requires the air-gapped system to reach the internet.

Yes, with the specifics depending on the deployment pattern you choose. Workspace roles, scoped assets and least-privilege access are part of the platform; retrieval is permission-aware, so an Agent can only read what the person behind the request is entitled to read.

The enterprise foundation is typically a 12–16 week engagement covering implementation, integration, air-gapped engineering where required, training and support. After that, each department adding its own Solutions follows a repeatable pattern rather than starting over.

It depends entirely on which models you intend to run and how many people will use them concurrently. This is sized during evaluation against your actual workloads — any vendor quoting you a hardware figure before seeing those numbers is guessing.

The platform is licensed, and Solutions come in three kinds. Built-in Solutions are included with the licence. Paid Solutions built by Rabita Noor are available by subscription, licence or one-time purchase. Custom Solutions are scoped builds on your own APIs, systems and business logic.

Services — implementation, integration, air-gapped engineering, training, support and custom development — are quoted against the deployment you choose.

That is the recommended path. Begin with one high-value use case, validate the data, models, controls and business result, then reuse the platform across the organization. Autonomy expands on run evidence, not on optimism.

A use case you actually care about, a sense of the data and systems behind it, and your hard constraints — regulatory, residency, connectivity, and who has to approve what. That is enough to map models, knowledge, Solutions, agents, workflows, controls and a deployment approach.

Request it from the Trust Center or the contact page. During an appropriate evaluation, qualified organizations can review the available security, governance and architecture documentation under the terms that fit your procurement process.