Application runtime
Record where Cayra runs, who administers it, how it is updated, and how support access is approved.
SECURITY, PRIVACY & DEPLOYMENT
Know where your data goes—and who can access it.
Cayra gives teams natural-language access to ERP and operational data while making deployment, database permissions, AI processing, retained records, and operating responsibility reviewable. Start in a Cayra-managed Cloud VM dedicated to your organization, deploy on customer-controlled infrastructure, or define an eligible Air-Gapped scope with Cayra Nova.
Cloud is self-service. On-Premises and Air-Gapped deployments require a written technical scope.
Security review map
Cayra control boundary
Application runtime
Database boundary
AI processing
Records and operations
Deployment, processors, permissions, retained records, and ownership are reviewed together.
Reviewable boundaries
- Customer-dedicated managed VM
- Database-enforced least privilege
- Documented primary and auxiliary AI flows
- Customer-managed and scoped offline options
01 — YOUR SECURITY BOUNDARY
Your architecture defines your security boundary.
Security depends on more than where the application is hosted. Review the application runtime, database permissions, primary model, auxiliary processors, retained records, network controls, support access, and operating ownership together.
Database boundary
Use a separate database principal, restrict it to approved reporting objects, and verify that write and DDL operations fail.
AI processing
Identify the primary model and every enabled auxiliary processor, including provider, region, network path, retention, and training-use terms.
Records and operations
Document application history, query records, files, logs, backups, deletion, monitoring, and incident-response ownership separately.
02 — DATA FLOW
See the full path from question to answer.
A useful security review follows each data object through the system instead of treating the interaction as a single AI request.
Cayra analysis data flow
- 01
Authorized user
A permitted user asks a business question.
- 02
Cayra application and approved context
Cayra assembles the permitted conversation, business, schema, and feature context.
- 03
Configured model
The configured processor generates analysis code, a plan, or SQL.
- 04
Scoped database execution
The Cayra runtime executes through the customer-approved database account.
- 05
Answer generation
Query-derived results may return to the configured processor to produce the answer.
- 06
Application records
Answer, execution details, history, and optional exports may be stored.
Data objects to map
- User question
- Conversation and business context
- Schema metadata
- Generated analysis code and SQL
- Query-derived results
- Final answer
- Question and query history
- File excerpts when file features are used
- Logs and operational metadata
Cayra’s standard analysis loop is not schema-only. Depending on the deployment and enabled features, user questions, schema metadata, generated SQL or analysis code, query-derived results, conversation context, and file excerpts may be processed by the configured model or an auxiliary service.
Record every enabled processor, provider, region, retention term, training-use restriction, and subprocessor for the selected environment.
Application history and model-provider retention are separate records. Confirm both.
An approved Air-Gapped scope must keep the supported Cayra and Cayra Nova workflow inside the customer network and demonstrate that supported reporting questions are not sent to external LLM services. The scope must identify the offline runtime, licensing behavior, local dependencies, compute requirements, update path, and egress-denied acceptance test.
03 — DEPLOYMENT OPTIONS
Choose the control model that fits your environment.
Deployment location is one part of the security boundary. Each option still needs an explicit data-flow, operating, support, and retention scope.
MANAGED CLOUD
Start quickly with managed Cloud
Each self-service Cloud deployment is provisioned on a Cayra-managed virtual machine for that customer deployment. Record the applicable region, primary and auxiliary model processors, retention, support access, backups, monitoring, and deletion terms for the selected plan.
- Customer-dedicated virtual-machine boundary
- Cayra-managed application runtime
- Self-service account and subscription flow
- Written model and data-flow terms
- Plan-specific operating and retention scope
A customer-dedicated VM does not automatically mean a dedicated physical host, customer-owned cloud account, private cloud, certification, customer-managed keys, or zero retention.
View plansON-PREMISES
Run Cayra on customer-controlled infrastructure
Deploy Cayra’s Docker-based application stack on customer-controlled Linux infrastructure or a reviewed private-cloud environment. The customer controls the host, network, identity, database account, backups, and monitoring. Model processing may still use external services unless every required processor is approved as local.
- Customer-controlled infrastructure
- Customer network and identity policies
- Database-native least-privilege account
- Written primary and auxiliary model flow
- Defined application-update procedure
- Defined support-access and incident process
Running the application on-premises does not by itself make every AI processor local or remove all outbound connectivity requirements.
Request a written technical scopeAIR-GAPPED + CAYRA NOVA
Define a closed-network deployment with Cayra Nova
For eligible environments, Cayra can be delivered under a written Air-Gapped technical scope with Cayra Nova running inside the customer’s closed network for the supported workflow.
- Approved offline model and runtime artifacts
- Customer-provided compute capacity
- All required processors local or disabled
- Licensing behavior validated without external connectivity
- Controlled software and model updates
- Customer-aligned logs, backups and monitoring
- Egress-denied acceptance testing
Availability depends on approved offline components and versions, customer-provided compute capacity, controlled updates, licensing behavior without external connectivity, and an egress-denied acceptance test.
Request a written technical scope04 — DATABASE ACCESS
Make database permissions the final control.
Connect Cayra through a separate database principal whose permissions are enforced by the database and limited to the approved reporting tables and views.
Generated-SQL instructions and application validators do not replace database permissions. The database account is the final write-prevention boundary.
Deployment acceptance checklist
- Create a separate database service account
- Grant only the required read or SELECT permissions
- Limit access to approved tables and views
- Block write, update, delete, execute and DDL operations where applicable
- Restrict the network path to approved application hosts
- Validate company, table, column and row visibility
- Test scope with real business questions
- Document credential storage, rotation and revocation
- Document question, SQL, result-preview and history retention
- Repeat acceptance tests after permission or schema changes
05 — AI DATA HANDLING
Make every AI processing step explicit.
Review each configured processor against the exact data it receives, where it runs, how long it retains records, and what its contract permits.
What is processed?
Identify whether user questions, conversation context, business rules, schema metadata, generated analysis code, SQL, query-derived results, files, or prior history reach each processor.
Where is it processed?
Record the primary model, every enabled auxiliary processor, provider, hosting location, data region, network path, and applicable subprocessors.
How long is it retained?
Document application history, query records, result previews, files, logs, backups, model-provider retention, and deletion procedures separately.
How may it be used?
Record contractual restrictions on model training, service improvement, human review, abuse monitoring, and secondary use for every provider.
Do not infer these answers from the words “Cloud,” “On-Premises,” “Local,” or “Air-Gapped.” Confirm them for the selected deployment, enabled features, providers, and contract.
Selecting a primary model does not by itself prove that every AI-assisted feature uses only that endpoint.
07 — OUTPUT VALIDATION
Keep business-critical answers verifiable.
Cayra accelerates analysis, but financial, regulatory, and operational decisions still require an approved validation process.
Supported technical interfaces can expose generated SQL, selected tables, execution metadata, result previews, and exports. Availability varies by interface and deployment.
AI-generated analysis should support accountable decisions—not bypass the people responsible for them.
Validation process
- Compare the answer with an approved reference report
- Use the same reporting period, filters and organizational scope
- Confirm the underlying database account and object scope
- Review generated SQL and execution details where the selected interface supports them
- Check result truncation, row-count and scope indicators where available
- Explain material differences
- Require acceptance from the authorized report owner
- Record known limitations and validation results
08 — POLICIES & EVIDENCE
Use current documents and deployment records—not security slogans.
These links are current public documents or anchors on this page. Their presence is not a certification or security attestation.
Privacy Policy
Review the currently published privacy terms.
Terms of Service
Review the currently published service terms.
Cookie Policy
Review the currently published cookie terms.
Deployment options
Compare the bounded Cloud, On-Premises, and Air-Gapped models.
Data-flow overview
Follow the data objects and processors from question to answer.
Privacy, Terms, and Cookie documents must still be reviewed for the selected deployment and contract. Do not treat them as certificates.
09 — BEFORE YOU DEPLOY
Four questions to answer before production access.
- 01
Which data reaches which processor?
Map the user question, schema context, generated SQL, query-derived results, files, answer, history, primary model, and auxiliary processors separately.
- 02
How narrowly is database access enforced?
Use a separate database-native read account, list approved objects, block write and DDL operations, and test company and user scope.
- 03
Who owns deployment and operations?
Assign infrastructure, backups, monitoring, updates, support access, deletion, and incident-response responsibilities.
- 04
How is a critical answer approved?
Compare the result with an authorized reference using the same period, filters, and organizational scope, then require acceptance from the responsible report owner.
TRUST FAQ
Questions to resolve before production use.
Use these answers as a review framework, then document the selected deployment, processors, permissions, and contract.
Cayra should be connected through a separate database account that the database itself restricts to SELECT or equivalent read access on approved tables and views. Application prompts and SQL validators are not substitutes for database permissions. During deployment acceptance, confirm that write, update, delete, execute, and DDL operations fail.
Depending on the deployment and enabled features, user questions, conversation context, business rules, schema metadata, generated analysis code, SQL, query-derived results, and file excerpts may be processed. Document the primary model and every enabled auxiliary processor separately.
Do not assume one answer applies to every provider. Record the contractual training-use, service-improvement, human-review, abuse-monitoring, retention, and deletion terms for each enabled processor in the selected deployment.
Each self-service Cloud deployment is provisioned on a Cayra-managed virtual machine for that customer deployment. This describes a virtual-machine boundary; it does not automatically mean a dedicated physical host, customer-owned cloud account, private cloud, certification, customer-managed keys, or zero retention.
The applicable cloud region, primary model, auxiliary processors, network path, subprocessors, retention terms, and support-access boundaries must be recorded for the selected plan. Do not infer a US or EU region without current deployment evidence.
Yes. Cayra supports a Docker-based On-Premises deployment on customer-controlled Linux infrastructure. The customer controls the host, network, database permissions, backups, and monitoring. Model processing may still use external services unless every required processor is approved as local.
For eligible environments, Cayra can be delivered under a written Air-Gapped technical scope with Cayra Nova running inside the customer’s closed network for the supported workflow. The scope must validate offline components, licensing behavior, compute capacity, updates, local dependencies, and an egress-denied acceptance test. Standard Cloud or On-Premises deployment is not automatically air-gapped.
There is no single retention period for every data category. Application history, query records, result previews, files, caches, logs, backups, deleted-account artifacts, and model-provider records must each be documented for the selected deployment.
Compare the answer with an approved reference report using the same reporting period, filters, and organizational scope. Review generated SQL or execution details where available, explain material differences, and require acceptance from the authorized report owner.
View the current plans on cayra.io and choose Starter or another available Cloud plan. Starter includes a 7-day free trial with no credit card required; account and database setup follow the central plan flow. No demo is required.
CHOOSE YOUR CONTROL MODEL
Choose the deployment that matches your risk model.
View Cayra Cloud plans, including the 7-day no-card Starter trial, or define a written technical scope for an On-Premises or eligible Air-Gapped deployment.
Need On-Premises or Air-Gapped deployment? Request a written technical scope.