> ## Documentation Index
> Fetch the complete documentation index at: https://helpcenter.magure.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security overview
> MagOneAI's enterprise security architecture and defense-in-depth approach to protecting your data and infrastructure
Security is not an afterthought — it's woven into every layer of MagOneAI's architecture. From network isolation to secrets management to comprehensive audit trails, the platform is designed to meet the security requirements of the most demanding enterprises.
## Defense-in-depth architecture
MagOneAI employs a defense-in-depth approach with multiple overlapping security layers. Each layer provides independent protection, ensuring that a compromise at one level doesn't expose your entire system.
Deploy MagOneAI on your own infrastructure, within your network perimeter. Private model support ensures data never leaves your environment. Control all ingress and egress traffic.
Enterprise SSO via OpenID Connect (Microsoft Entra ID, Google Workspace, Oracle IDCS) with just-in-time provisioning. Multi-factor authentication (TOTP). API key access for automation. Signed-cookie sessions with rotating refresh tokens.
HashiCorp Vault integration for all credentials, API keys, and tokens. Secrets are never stored in configuration files or environment variables. Runtime injection with audit trails.
Encryption at rest and in transit using industry-standard algorithms. Organization-level data isolation. No cross-tenant data access. Data residency controls.
Role-based access control (RBAC) at organization, project, and resource levels. Principle of least privilege. Fine-grained permissions for every action.
Per-step execution activity logs with status, timing, and errors. LLM token and cost tracking. Structured operational logging and record provenance.
## Platform hardening
Recent releases added defensive controls that bound and isolate every execution, regardless of which model or trigger is used.
### Hard input limits
Every execution is capped before any file reaches an agent's context, independent of the LLM:
* **File count** — At most **10 files** per execution, counting START-node inputs plus active chat attachments.
* **Combined size** — At most about **1,000,000 estimated tokens** across all file inputs (estimated cheaply from the persisted word count, no tokenizer required).
* **Upload size** — START-node uploads and chat attachments are capped at **50 MB** (larger files belong in a knowledge base); general file-tool uploads are capped at **100 MB**.
These gates are enforced at two points — the chat attachment endpoint and the START activity — so no trigger path can bypass them.
### Tenant isolation
Multi-tenant boundaries are enforced in the repository and authorization layers, not just the UI:
* **Scoped queries** — Data access is scoped by organization and project, so an ID from another tenant simply does not resolve and surfaces as **404 Not Found**.
* **Non-revealing denials** — When you lack access to a resource in an org or project you can see, the platform returns a generic **"Access denied"** response rather than confirming what exists, which limits object enumeration (IDOR) probing.
### Decompression-bomb protection
ZIP-based Office formats (DOCX, PPTX, XLSX) are inspected before they are handed to a parser. A file is rejected if its uncompressed payload, any single entry, or its entry count exceeds the platform caps (500 MB total, 200 MB per entry, 10,000 entries), stopping a small hostile file from expanding to many gigabytes and exhausting memory.
### Rate limiting on the real client IP
Sensitive authentication and sign-up endpoints are rate-limited to resist brute force. The rate-limit key is the genuine client IP, derived from `X-Forwarded-For` by counting the trusted proxy hops your own infrastructure adds (from the right, which is spoof-resistant). If the header is missing or the deployment is misconfigured, it fails closed to the socket peer rather than trusting an attacker-supplied value.
## Compliance considerations
MagOneAI's architecture supports compliance with major regulatory frameworks. The platform provides the technical controls you need to meet your compliance obligations.
### GDPR compliance
* **Data residency** — Deploy MagOneAI in any geographic region to meet data residency requirements. Self-hosted deployments keep all data within your infrastructure.
* **Data isolation** — Organization-level data boundaries ensure complete isolation between tenants. No cross-organization data access at any level.
* **Right to be forgotten** — Deletion of user data and execution history. Execution logs and record provenance track processing activity.
* **Data minimization** — Automated TTL-based cleanup of transient data such as per-file dynamic indexes and generated artifacts. Because you self-host, you control retention of logs and execution history in your own environment.
### HIPAA compliance
* **Private model support** — Process PHI using models deployed within your infrastructure. Data never leaves your network or reaches third-party providers.
* **Encryption** — All data encrypted at rest using AES-256 and in transit using TLS 1.3. Encryption key management with support for customer-managed keys.
* **Access controls** — RBAC ensures only authorized users can access PHI. Execution activity logs record agent and workflow runs against your data.
* **Business Associate Agreement** — Magure can execute BAAs for managed hosting deployments.
### SOC 2 Type II
* **Execution logging** — Per-step execution activity logs and LLM token/cost tracking record what ran, when, and at what cost. Structured operational logs support platform monitoring.
* **Access controls** — RBAC with principle of least privilege. Regular access reviews.
* **Secrets management** — HashiCorp Vault for credential storage and rotation.
* **Change tracking** — Resources record who created and last updated them, with timestamps (provenance columns).
### Data residency
* **Deploy anywhere** — Self-hosted deployments run entirely within your infrastructure. Choose any cloud provider, region, or on-premises data center.
* **Data sovereignty** — All processing, storage, and logging occur within your chosen environment. No data transmission to Magure or third parties.
* **Private models** — Use locally-deployed LLMs like Ollama or private model endpoints. Your data never leaves your network.
## Security by deployment model
Your security posture varies based on how you deploy MagOneAI. Choose the model that best fits your security requirements.
### Self-hosted deployment
Self-hosted deployments provide maximum security and control:
* **Network isolation** — Deploy behind your corporate firewall. Control all network access with your existing security policies.
* **Infrastructure control** — Choose your cloud provider, region, and network architecture. Use your existing security tooling and monitoring.
* **Identity integration** — Connect to your enterprise identity provider via [OpenID Connect SSO](/security/sso) (Microsoft Entra ID, Google Workspace, Oracle IDCS). Use your existing authentication policies, and enforce MFA.
* **Private models** — Run LLMs within your infrastructure using Ollama or private model endpoints. Data never reaches third-party AI providers.
* **Data ownership** — All data, logs, and execution history remain within your environment. Complete control over retention and deletion.
### Managed hosting
Magure-managed deployments balance convenience with security:
* **Dedicated infrastructure** — Your organization runs on dedicated infrastructure, isolated from other tenants.
* **Enterprise security controls** — Magure applies SOC 2 security controls, including encryption, RBAC, and audit logging.
* **Compliance support** — BAA execution for HIPAA, DPA for GDPR, and compliance documentation for audits.
* **Shared responsibility** — Magure manages infrastructure security, you manage user access and data governance.
MagOneAI's architecture means your security posture is as strong as your infrastructure. Deploy behind your corporate firewall, use your existing identity provider, and run private models — the platform adds enterprise security controls on top.
## Security best practices
Follow these practices to maintain a strong security posture:
Never store credentials in configuration files or environment variables. Always use `vault:` references to HashiCorp Vault.
Assign users the minimum role they need. Most users should be project Operators or Viewers, not Owners or Admins.
Use Studio's execution history to review runs and errors, and watch the org and project usage summaries for unusual cost or activity. Because you self-host, ship the platform's structured logs and metrics into your own monitoring stack.
For sensitive workloads, use locally-deployed models like Ollama. This ensures data never leaves your infrastructure.
Periodically review user roles and permissions. Remove access for users who no longer need it.
Place MagOneAI in an appropriate network segment. Restrict outbound access to only required services.
## Security incident response
MagOneAI provides the tools you need to respond to security incidents:
* **Execution history analysis** — Review execution activity logs to identify unexpected runs or suspicious activity.
* **Immediate revocation** — Instantly revoke user access, API keys, or OAuth tokens when compromised.
* **Workflow isolation** — Disable or quarantine workflows without affecting the rest of the platform.
* **Data export** — Export execution data for incident analysis.
If you suspect a security incident, immediately revoke potentially compromised credentials in HashiCorp Vault and review execution logs in Studio. Contact your security team and, for managed hosting deployments, notify Magure support.
## Next steps
Understand the RBAC system and permission hierarchy
Learn how HashiCorp Vault protects your credentials
Review execution activity logs, cost tracking, and monitoring
Deploy MagOneAI securely in your environment