Snapshot 96872

Document
Security page
URL
https://helpcenter.magure.ai/security/overview
Fetched
HTTP status
200
Content type
text/html; charset=utf-8
Fetch mode
static
Size
306791 bytes
SHA-256 (raw)
82fa9ceb4446ca27059a2483260d5056df3c0a1f3ef9bb904372e124ed4b716e
SHA-256 (normalized text)
f994aa0890a4ca58f10fba09bd02a77306b7e1e391a7e2fcd7d5e45a43346a5b

Normalized text

Scripts and page chrome removed; this is what change detection compares.

DocsChangelogRoadmapDashboardSupport
Security overviewAuthentication & SSOData flow diagramRole tiersOAuth authorization serverSecrets and VaultSensitive data in promptsInput limitsExecution logs and monitoring
Security & Administration
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.
Network security
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.
Authentication
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.
Secrets management
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.
Data protection
Encryption at rest and in transit using industry-standard algorithms. Organization-level data isolation. No cross-tenant data access. Data residency controls.
Access control
Role-based access control at organization, project, and resource levels, refined with groups and per-user overrides. Principle of least privilege, with a named permission for every action.
Execution logs and monitoring
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.
Account creation controls
Two checks apply when an account is created, each closing a different gap.
A written reason for every unauthenticated route
Every route that answers a caller with no credentials at all has to carry a written reason for being open, and a test enforces it against the running application rather than against a list someone maintains.
The distinction matters. A separate check confirms that every route maps to an action, but a route can satisfy that and still be reachable without credentials, because an exemption is matched as a path prefix and a new route added underneath one inherits it silently.
This is why the two checks exist side by side. The route-mapping check asks "is this route governed", and the surface test asks "what is genuinely open". The second one turned a believed two-endpoint list into a 44-route inventory, and found a route serving a container listing to the internet.
A small number of routes are open by construction and are expected to be. An inbound webhook receive URL and the hooks API are the clearest examples: the caller proves itself with its own signature rather than with a session, so there is no user to authenticate.
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 (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:
Use Vault for all secrets
Never store credentials in configuration files or environment variables. Always use vault: references to HashiCorp Vault.
Apply least privilege
Assign users the minimum role they need. Most users should be project Operators or Viewers, not Owners or Admins.
Review execution logs
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.
Deploy private models when possible
For sensitive workloads, use locally-deployed models like Ollama. This ensures data never leaves your infrastructure.
Regular access reviews
Periodically review user roles and permissions. Remove access for users who no longer need it.
Network segmentation
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
Roles and permissions
Understand the RBAC system and permission hierarchy
Secrets and Vault
Learn how HashiCorp Vault protects your credentials
Execution logs and monitoring
Review execution activity logs, cost tracking, and monitoring
Deployment guide
Deploy MagOneAI securely in your environment
Action reference
Every action MagOneAI can authorize, what it allows, and the levels a grant for it can attach to
Authentication & SSO
Single sign-on with OpenID Connect, multi-factor authentication, and secure session handling for MagOneAI
On this page
Defense-in-depth architecturePlatform hardeningHard input limitsTenant isolationDecompression-bomb protectionRate limiting on the real client IPAccount creation controlsA written reason for every unauthenticated routeCompliance considerationsGDPR complianceHIPAA complianceSOC 2 Type IIData residencySecurity by deployment modelSelf-hosted deploymentManaged hostingSecurity best practicesSecurity incident responseNext steps