Enterprise

OpenSentinel is built for teams and organizations. SOC 2-ready security controls, multi-user, SSO, audit logging, GDPR compliance, production-hardened Docker, and Kubernetes deployment.

Overview

OpenSentinel includes a comprehensive set of enterprise features that make it production-ready for organizations of any size. Unlike consumer AI assistants, OpenSentinel runs on your infrastructure, giving you complete control over data, access, and compliance.

Multi-User Support

Unlike single-user AI assistants, OpenSentinel is designed for teams from the ground up. Every user gets their own session, memory space, and permissions — while sharing a common organizational knowledge base.

Key Features

• Role-Based Access Control (RBAC) — define roles (admin, user, viewer) with granular permissions for tools, integrations, and workflows
• Per-user sessions — each user has isolated conversation history and memory
• Team knowledge base — shared documents and context accessible to all team members
• User management — create, disable, and manage users via the admin dashboard or API

Configuration

MULTI_USER_ENABLED=true
DEFAULT_USER_ROLE=user
MAX_USERS=100

// Create a new user via the API
$ curl -X POST http://localhost:8030/api/admin/users \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer ADMIN_TOKEN" \
    -d '{"email": "alice@company.com", "role": "user"}'

SSO Integration

Integrate OpenSentinel with your organization's identity provider. Users authenticate through your existing SSO system — no separate passwords to manage.

Supported Protocols

• SAML 2.0 — Okta, OneLogin, Azure AD, ADFS
• OAuth 2.0 — Google Workspace, GitHub, custom providers
• OpenID Connect — Auth0, Keycloak, AWS Cognito

Configuration

# SAML 2.0
SSO_PROVIDER=saml
SAML_ENTRY_POINT=https://idp.company.com/sso/saml
SAML_ISSUER=opensentinel
SAML_CERT=./certs/idp-cert.pem

# Or OAuth 2.0 / OIDC
SSO_PROVIDER=oidc
OIDC_CLIENT_ID=your-client-id
OIDC_CLIENT_SECRET=your-client-secret
OIDC_DISCOVERY_URL=https://auth.company.com/.well-known/openid-configuration

Security

OpenSentinel includes multiple layers of security to protect your data and infrastructure. Every security feature can be enabled independently.

Gateway Token Authentication

Optional shared-secret authentication for the web UI and API. Disabled by default for self-hosted/localhost use. Set GATEWAY_TOKEN in your environment to require authentication. When enabled, the web UI prompts for the token on first visit and stores it in localStorage for subsequent requests. Uses constant-time comparison to prevent timing attacks.

AES-256-GCM Field Encryption

Sensitive data is encrypted at rest using AES-256-GCM. Memory content, 2FA secrets, and other sensitive fields are encrypted before database insertion and decrypted transparently on read. Set FIELD_ENCRYPTION_KEY to enable.

Tamper-Proof Audit Logs

Audit log entries are chained using HMAC-SHA256 hashes with sequence numbers. Each entry references the previous entry's hash, forming an immutable chain. Any tampering with historical records is detectable via chain integrity verification.

Incident Response System

Automated security incident detection, classification, and escalation. Incidents are categorized by severity (low/medium/high/critical) with configurable notification channels and response playbooks.

Two-Factor Authentication (2FA)

TOTP-based 2FA compatible with Google Authenticator, Authy, and other authenticator apps. Secrets are encrypted at rest and persisted in the database. Required for admin accounts by default.

Biometric Verification

Optional biometric verification for sensitive operations using WebAuthn/FIDO2. Supports fingerprint readers, Face ID, and hardware security keys.

Encrypted Memory Vault

Sensitive data (API keys, passwords, personal notes) stored in an encrypted vault. AES-256-GCM encryption at rest with per-user encryption keys.

Command Sandboxing

Control which shell commands and tools the AI can execute:

# Allowlist mode - only these commands are permitted
COMMAND_ALLOWLIST=ls,cat,grep,curl,git

# Or blocklist mode - block specific dangerous commands
COMMAND_BLOCKLIST=rm,sudo,chmod,chown,dd

Plugin Isolation

Third-party plugins run in sandboxed environments with limited filesystem, network, and memory access. Plugins cannot access other plugins' data or the host system.

Rate Limiting

Configurable rate limits per user, per API endpoint, and per tool. Prevents abuse and controls cost.

RATE_LIMIT_REQUESTS_PER_MINUTE=30
RATE_LIMIT_TOKENS_PER_DAY=1000000

Audit Logging

Every action in OpenSentinel is logged with full context: who did it, what they did, when, and the result. Essential for compliance and incident investigation.

What Gets Logged

• User authentication events (login, logout, failed attempts)
• Tool executions (command, parameters, result)
• Configuration changes (env vars, user roles, integrations)
• Data access (memory queries, document reads, API calls)
• Workflow triggers and completions

Configuration

AUDIT_LOG_ENABLED=true
AUDIT_LOG_RETENTION_DAYS=365
AUDIT_LOG_EXPORT_FORMAT=json  # json, csv, or syslog

Exporting Logs

# Export audit logs for a date range
$ curl http://localhost:8030/api/admin/audit-logs \
    -H "Authorization: Bearer ADMIN_TOKEN" \
    -d '{"from": "2025-01-01", "to": "2025-12-31", "format": "csv"}' \
    -o audit-logs.csv

GDPR Compliance

OpenSentinel includes built-in tools for GDPR and privacy regulation compliance. Since all data stays on your infrastructure, you maintain full control.

Compliance Features

• Data export — export all data associated with a user in machine-readable format (JSON)
• Right to deletion — permanently delete all user data, memory, and conversation history
• Retention policies — automatically purge data older than a configurable threshold
• Consent management — track and enforce user consent for data processing activities

Configuration

GDPR_ENABLED=true
DATA_RETENTION_DAYS=730         # 2 years
MEMORY_RETENTION_DAYS=365       # 1 year for AI memory
CONSENT_REQUIRED=true

Usage Quotas

Control costs and resource usage with per-user quotas. Set limits on API calls, storage, and tool usage to prevent runaway costs.

Configurable Limits

Configuration

QUOTA_ENABLED=true
QUOTA_API_CALLS_PER_DAY=100
QUOTA_TOKENS_PER_DAY=500000
QUOTA_STORAGE_MB=500
QUOTA_TOOL_CALLS_PER_DAY=200
COST_ALERT_THRESHOLD_USD=50  # Alert when daily cost exceeds this

Observability

Full visibility into how OpenSentinel is being used, what it's doing, and how it's performing. Essential for debugging, optimization, and cost management.

Features

• Metrics dashboard — real-time charts for request volume, latency, token usage, error rates, and cost
• Conversation replay — replay any conversation step-by-step, including tool calls and AI reasoning
• Tool dry-run mode — test tool executions without side effects (no actual file writes, no real API calls)
• Prompt inspector — view the exact prompts sent to Claude, including system messages and tool definitions
• Cost alerting — receive notifications when spending exceeds configurable thresholds
• Error tracking — automatic error capture with stack traces, context, and frequency analysis
• Anomaly detection — AI-powered detection of unusual patterns in usage, errors, or cost

Configuration

OBSERVABILITY_ENABLED=true
METRICS_RETENTION_DAYS=90
CONVERSATION_REPLAY=true
TOOL_DRY_RUN=false           # Enable for testing environments
PROMPT_INSPECTOR=true
COST_ALERT_EMAIL=admin@company.com

Kubernetes Deployment

Deploy OpenSentinel to Kubernetes for horizontal scaling, high availability, and seamless rolling updates. Helm charts are included for quick deployment.

Features

• Helm charts — production-ready charts with sensible defaults
• Horizontal scaling — scale worker pods based on queue depth or CPU
• Health checks — liveness and readiness probes for reliable orchestration
• Resource limits — configurable CPU and memory limits per pod
• Secrets management — Kubernetes secrets for API keys and credentials

Quick Start with Helm

# Add the OpenSentinel Helm repository
$ helm repo add opensentinel https://charts.opensentinel.dev
$ helm repo update

# Install with default configuration
$ helm install opensentinel opensentinel/opensentinel \
    --set env.CLAUDE_API_KEY=sk-ant-... \
    --set env.DATABASE_URL=postgresql://user:pass@db:5432/opensentinel \
    --set env.REDIS_URL=redis://redis:6379 \
    --namespace opensentinel \
    --create-namespace

# Or use a values file for full configuration
$ helm install opensentinel opensentinel/opensentinel \
    -f values.yaml \
    --namespace opensentinel \
    --create-namespace

Scaling

# Scale the worker pods
$ kubectl scale deployment opensentinel-worker --replicas=5 -n opensentinel

# Or use Horizontal Pod Autoscaler
$ kubectl autoscale deployment opensentinel-worker \
    --min=2 --max=10 --cpu-percent=70 -n opensentinel

Docker Deployment

The simplest way to deploy OpenSentinel in production. Two Docker Compose files are included: docker-compose.yml for development and docker-compose.prod.yml for hardened production deployment.

Production Setup

# Clone and configure
$ git clone https://github.com/dsiemon2/OpenSentinel.git
$ cd OpenSentinel
$ cp .env.example .env
$ nano .env  # Add your API keys

# Start all services
$ docker compose up -d

# Check status
$ docker compose ps
$ docker compose logs -f opensentinel

Services

Production Hardening (docker-compose.prod.yml)

The production Docker Compose file includes enterprise-grade security hardening:

• Non-root execution — all containers run as user: "1000:1000"
• Read-only filesystem — application container uses read_only: true with tmpfs for /tmp
• Capability dropping — cap_drop: ALL with only NET_BIND_SERVICE added back
• No privilege escalation — no-new-privileges:true on all containers
• Resource limits — CPU and memory limits on every service
• Log rotation — json-file driver with max-size and max-file limits
• Redis authentication — requirepass enforced
• TLS via Nginx — Let's Encrypt SSL with automated renewal
• Health checks — liveness probes on all services

# Production deployment
$ cp .env.example .env && nano .env
$ mkdir -p docker/ssl  # Add fullchain.pem + privkey.pem
$ docker compose -f docker-compose.prod.yml up -d

SOC 2 Readiness

OpenSentinel's security controls map directly to the SOC 2 Trust Service Criteria. The following table shows coverage across all control categories.

Competitive Comparison

OpenSentinel is the only self-hosted AI assistant with enterprise-grade security controls. Here's how it compares:

Support & Pricing

OpenSentinel is 100% open source under the MIT license. All features are included in the free community edition.

Enterprise contact: enterprise@opensentinel.ai

Managed Hosting (Coming Soon)

• Fully managed PostgreSQL, Redis, and application hosting
• Automatic updates and security patches
• Daily backups with point-in-time recovery
• Custom domain with TLS
• Uptime monitoring and alerting