How Sasha is secure

For organisations evaluating Sasha

Architecture

Sasha runs each organisation in its own instance. Your data, processing, and systems are separate from those of every other organisation that uses the service.

Data isolation

Database: each organisation has its own database instance.
File storage: documents, uploads, and generated files are stored in storage allocated to your organisation. File paths, storage containers, and backup locations are unique to you.
Processing: your requests run in isolation. There are no shared processing queues, temporary files, or memory spaces.
Data flow: no analytics, reporting, or optimisation system aggregates or compares data across organisations.

Infrastructure isolation

Container: each organisation runs in its own software container with its own operating system processes, memory allocation, and file system.
Network: network traffic for your organisation is isolated from other organisations.
Dedicated servers: available for organisations that require no hardware sharing.
On-premise: Sasha can run in your own data centre, including air-gapped configurations with no internet connectivity. This requires custom integration work.
Hybrid: core systems on-premise, with specific features using cloud services. This requires custom integration planning.

In the standard cloud deployment, physical servers may host several isolated containers and basic internet connectivity is shared. Both can be dedicated if your security requirements demand it.

AI processing

Standard: AI requests from your organisation are processed without access to other organisations' prompts, responses, or learned patterns.
Amazon Bedrock option: Sasha can integrate with Amazon Bedrock so that AI processing runs in your own AWS account. AWS bills you. You control the AI service configuration and access. This requires custom integration setup.
On-premise AI option: local AI deployment with no external AI service calls. This requires custom integration work.
No cross-training: the AI does not learn or train from data across organisations.

Authentication and access control

Each organisation has its own user directory and authentication system. User accounts, passwords, and permissions exist only within your instance. There is no central user management system that spans organisations. You set your own security policies and password requirements.

Staff access to your data

Context is Everything staff can access your data only with written authorisation from your organisation. Routine operations such as monitoring, health checks, software updates, security patches, and infrastructure maintenance do not involve data access. Most support is handled through system logs, configuration review, and guided troubleshooting.

When data access is needed:

Before access: a written request with business justification, approval from your authorised signatories, an NDA specific to the engagement, and an agreed scope and duration.
During access: audit logging of all activity, access limited to the minimum necessary data, time-bounded access with automatic expiration, and your right to observe.
After access: deletion of temporary copies, a final access report, and an archived access log for your compliance records.

Cloud storage connections

Connections to Google Drive, SharePoint, and AWS S3 run from your Sasha instance to your cloud service. Credentials are stored within your container. Files are read from your storage without an intermediate storage system.

Compliance and data ownership

Data residency: you choose the geographic location where your data is processed and stored.
HIPAA: each container can maintain HIPAA compliance independently.
GDPR: data processing occurs only in your specified regions.
SOC 2: inherited from your chosen infrastructure.
Audits: you can review the architecture documentation, run security audits and penetration tests on your instance, and examine system configurations.
Data ownership: you own your data. Retention, deletion, and export follow your requirements. If you leave, you can export all data, configurations, and settings, and deletion from Context is Everything infrastructure is verifiable.

Encryption, backup, and monitoring

Data in transit: TLS 1.3.
Data at rest: AES-256.
Keys and certificates: encryption keys and SSL certificates are managed per organisation.
Backup: automated backups stored in your designated location, with point-in-time recovery.
Monitoring: security monitoring, intrusion detection, and audit logs per container. Alerts go to your team only.

Frequently asked questions

How is this different from typical SaaS security?

Traditional SaaS uses shared databases with access controls. Sasha gives each organisation separate systems, so a flaw in access control software cannot expose one customer's data to another.

Can Context is Everything employees access our data?

Only with your written authorisation, under the process described in Staff Access to Your Data.

What happens when we need technical support?

Most support is provided without data access. When access is needed, the authorisation process in Staff Access to Your Data applies.

How can we verify the isolation is real?

Review the architecture documentation, run your own security audit and penetration test, and examine the system configuration.

What if Context is Everything experiences a security incident?

Your instance does not share databases, systems, or network paths with Context is Everything's corporate systems or with other customers, so an incident there has no path to your data.

Can we perform our own security audit?

Yes. You can run security audits and penetration tests on your instance without coordination with other customers.

Contact: security@sasha-studio.com
Documentation: architecture documentation is available on request