One guarded way in and no route out by default. Only the edge is exposed, and all outbound traffic crosses a default-deny proxy.
Chakali / Trust CenterEnterprise AI with
Enterprise AI with
control in the path.
A concise view of how Chakali approaches security, governance, deployment and evidence — so leaders and technical teams can evaluate the platform with clarity.
CONTROL POSTURE ACTIVE
Security and governance operate with the workflow.POLICYACCESSHUMANEVIDENCE
AI OS
Logical architecture summary · Configuration varies by deploymentAI OSThe enclave, defined
Five properties make it
an enclave.
An enclave is protected territory that runs under its own control inside a larger, less-trusted world. These five properties are what earn Chakali the word, and each is a mechanism rather than a promise.
It runs on infrastructure you own, on the models you approve, and your data never has to leave to be useful.
Workspaces and provider code are sealed from one another, so a permission granted in one place never widens another.
The model holds no standing authority. Anything consequential stops at a human approval, so even a hijacked agent cannot act.
Every run leaves a tamper-evident record of identity, models, tools, policy decisions and outcome.
00Operating principles
Trust is designed
into the operating model.
Three principles shape how Chakali approaches control, evidence, and deployment from the beginning.
Permissions, policy, model and tool boundaries are evaluated before consequential work proceeds.
Runtime records stay connected to the models, knowledge, decisions and approvals behind an outcome.
Choose air-gapped, on-premises, private cloud or SaaS based on organizational risk and operating requirements.
01Deployment architecture
One platform.
Three operating patterns.
The control model remains consistent while infrastructure ownership and integration boundaries adapt to the organization.
YOUR ORGANIZATION
Identity providerEnterprise knowledgeBusiness systemsSecurity controls
CONTROLLED CONNECTION
SaaS
Managed application operation with organizational identity, data and integration boundaries.
RabitaNoor operatedPrivate cloud
Dedicated deployment pattern aligned to private networking and organizational cloud controls.
Shared operating modelOn-premises / air-gapped
Application and connected models operated inside infrastructure controlled by the organization, with or without internet.
Customer operated IDENTITY ENCRYPTION POLICY LOGGING RECOVERY
02Controlled data flow
Every request passes through
an accountable execution path.
This logical view intentionally communicates the control model without exposing sensitive implementation detail.
REQUEST PLANE
01User or system
02Identity + workspace
03Orchestrator
RUNTIME CONTROL GATEPurpose · Access · Policy · Risk
INTELLIGENCE PLANE
04Permission-aware RAG
05Approved tools
06Approved model
DECISION GATEGuardrail · Exception · Human approval
OUTCOME PLANE
07Action or answer
08Report
09Audit evidence
03Governance evidence
From policy statement
to reviewable proof.
Governance becomes useful when requirements can be connected to runtime decisions and retained evidence.
CONTROL INPUTS
PoliciesRolesModel approvalsKnowledge scopesGuardrails
GOVERNEDEXECUTIONPolicy applied at runtime
EVIDENCE RECORD
Identity + purpose Model + knowledge Tools + actions Guardrail results Human decisions Outcome + timing
04Foundation controls
Protect the operating
foundation.
Evaluate the deployment, identity, access, and security boundaries around the platform.
Security architecture
Logical control layers, execution boundaries and runtime policy enforcement.
AvailableDeployment
Air-gapped, on-premises, private cloud and managed SaaS patterns aligned to organizational requirements.
ConfigurableIdentity + access
Workspace roles, scoped assets, least privilege and deployment-dependent identity integration.
Configurable05AI execution control
Govern intelligence
while it is in use.
Review how data, models, organizational knowledge, and runtime decisions remain controlled.
Data protection
Data boundaries, encryption expectations and deployment-specific key-management choices.
Deployment-dependentModel governance
Approved-provider routing, agent-level model selection and observable model usage.
AvailablePermission-aware RAG
Authorized retrieval scopes, evidence linkage and governed knowledge lifecycle.
Available06Evidence + assurance
Keep every outcome
reviewable.
Understand the evidence, resilience, and responsible-AI practices that support ongoing oversight.
Audit evidence
Run inputs, outputs, tools, models, policy checks, approvals, timings and outcomes.
AvailableResilience + recovery
Backup, recovery and continuity controls defined for the selected operating model.
Deployment-dependentResponsible AI
Human accountability, purpose boundaries, review paths and evidence-oriented governance.
AvailableStandards alignment
Named standards,
named mechanisms.
The frameworks security and procurement teams ask about, and the specific mechanism in Chakali that satisfies each. Alignment describes the controls Chakali is engineered to meet and the evidence it produces; it is not a substitute for a formal certification.
| Framework | What it asks for | How Chakali meets it |
|---|---|---|
| NIST AI RMF 1.0 | Govern, map, measure and manage AI risk across the lifecycle. | Approvals, scope and guardrails bound every run; the evidence trail and attested releases provide accountability. |
| OWASP Top 10 for LLM Apps | Prompt injection, excessive agency, data disclosure, supply chain. | Excessive agency removed, injection contained, data kept in-boundary, and every solution signed. |
| MITRE ATLAS | The adversarial threat landscape for AI systems. | The platform is hardened against these techniques and uses ATT&CK and ATLAS in its analyst skills. |
| ISO/IEC 42001 | An AI management system with policy and accountability. | Documented autonomy policy, human oversight and a tamper-evident record of decisions and changes. |
| ISO/IEC 27001 | An information-security management system. | Network isolation, least privilege, default-deny egress and self-hosting. |
| EU AI Act | Human oversight, logging, robustness and cybersecurity. | Approvals meet oversight, the evidence trail meets record-keeping, and isolation meets the security duty. |
| SOC 2 | Security, availability, processing integrity, confidentiality. | An attested release pipeline, zero-outage cutovers and an exportable audit trail. |
| SLSA / NIST SSDF / SBOM | A secure software supply chain with provenance. | Signed solutions, digest-pinned images, predecessor-hashed releases and an SBOM. |
ASSURANCE & EVIDENCEClaims grounded
Claims grounded
in evidence.
Chakali is designed to support security, privacy and responsible AI governance controls. Certifications and attestations are stated only when supported by current, independently verifiable evidence.
Security boundaries are stated openly: signing establishes package origin and integrity, not that code is safe; prompt-injection risk is reduced, not eliminated; container isolation is not equivalent to a hardened virtual machine. Chakali is an architectural and network enclave today, not a silicon trusted-execution environment, and can be deployed onto confidential-compute hardware where that is required. Host hardening, identity lifecycle, key custody, monitoring, backup and compliance remain the operator's responsibility.
During an appropriate evaluation, qualified organizations may request available control mappings, architecture documentation, recovery commitments, penetration-testing summaries and security questionnaire responses.
SECURITY + ARCHITECTUREEvaluate Chakali
Evaluate Chakali
around your requirements.
Bring your deployment boundary, data classes, identity model, critical integrations and governance requirements.
Request an architecture review [email protected]Trust information is reviewed as the platform and operating model evolve. See also the guided tour and resources.