Security and Compliance

​

Overview

The 4MINDS platform is built with security and privacy as core principles. Your data remains private, your models are deployed in single-tenant environments, and all transmissions are encrypted. We maintain compliance with major industry standards to meet enterprise requirements.

​

Authentication

​

JWT-based authentication

All API requests and platform access use JSON Web Tokens (JWT) for secure, stateless authentication. Tokens expire automatically and can be revoked instantly if needed.

​

OAuth support

Sign in seamlessly with your existing accounts:

• Google - Use your Google Workspace or personal Google account
• GitHub - Authenticate with your GitHub credentials

OAuth integration eliminates the need to manage separate passwords while maintaining security through trusted identity providers.

​

Enterprise Single Sign-On (SSO)

For enterprise customers, 4MINDS supports additional identity providers:

• AWS - Authenticate using your AWS IAM Identity Center credentials
• Ping Identity - Connect through your organization’s Ping Identity platform
• Okta - Use your company’s Okta identity management system
• LDAP - Integrate with your organization’s LDAP directory service

Enterprise SSO enables centralized access control, simplified user provisioning, and compliance with your organization’s security policies.

​

API key generation

Generate API keys for programmatic access to your models and data. You can:

• Create multiple keys for different applications or environments
• Set expiration dates for temporary access
• Revoke keys immediately if they’re compromised
• Monitor API key usage and activity

​

Data privacy

​

Single-tenant model deployment

Your models run in isolated, single-tenant environments. No shared infrastructure means your model weights, training data, and inference results remain completely private.

​

Private data storage

All datasets, models, and generated content are stored in dedicated storage that only you can access. Data is never shared across accounts or used to train other models.

​

Encrypted transmission

All data in transit uses TLS 1.3 encryption. Whether you’re uploading datasets, querying models, or receiving notifications, your data is protected from interception.

​

Compliance

The 4MINDS platform maintains compliance with major security and privacy regulations:

​

ISO 27001

Our information security management system follows ISO 27001 standards for protecting sensitive data and managing security risks.

​

SOC-2 Type II

We undergo regular SOC-2 audits to verify our security controls, availability, and confidentiality practices meet industry standards.

​

GDPR

For users in the European Union, we comply with GDPR requirements for data protection, user rights, and privacy by design.

​

CCPA

California users benefit from CCPA protections, including the right to know what data we collect and the right to deletion.

​

MCP Security Architecture

The Model Context Protocol (MCP) enables AI systems to connect with external tools and services - but introduces significant security risks when naively integrated. Most implementations collapse decision-making, execution, and trust into the language model itself, creating opaque behavior and limited auditability. 4MINDS treats MCP as a governed system call layer, not a tool interface. Security is achieved through three independent architectural boundaries:

​

Reasoning Boundary: Constellation

Constellation determines what should happen but cannot make anything happen. It doesn’t open network connections, call MCP servers, hold credentials, or mutate system state. Its outputs are declarative artifacts describing intent and confidence. This means prompt injection or model jailbreaks cannot directly trigger execution - decisions are observable and auditable before any action occurs.

​

Execution Boundary: MCP Runtime

The MCP Runtime receives declarative intent and performs controlled capability invocation. It validates schemas, enforces timeouts, isolates transports, normalizes responses, and records audit logs - but never infers missing inputs or decides whether actions should occur. This mirrors how secure operating systems handle system calls: the caller declares intent, the kernel validates and executes, and policy is enforced elsewhere.

​

Governance Boundary: BAAE

All state-changing operations pass through the Bounded Autonomous Assistance Engine (BAAE), which enforces approval logic, scope limits, rate limits, kill switches, and immutable audit trails - independent of the language model. Even a compromised MCP server cannot cause damage without crossing an explicit governance decision point.

​

Transport Security

​

Open Source MCP Servers

Open source MCP servers are treated as untrusted by default. Server output is normalized by the runtime, evaluated through governance, and only then reflected in user-visible outcomes. This layered trust boundary ensures unexpected server behavior cannot escalate privileges or evade audit.

​

4MINDS RBAC Capabilities Overview

​

Role Hierarchy

4MINDS implements a multi-layered role system operating at three levels:

​

Organization Roles

​

Team Roles

​

System Admin Roles (Internal)

​

Access Levels (Permission Tiers)

Users are assigned one of three access levels that control feature availability: Access levels map to subscription tiers:

• Pro / Teams / Teams Plus → Plus access
• Enterprise → Admin access

​

Custom Roles and Permissions

​

Granular Permission Model

Permissions follow a {resource}:{action} naming convention: Resources: datasets, models, teams, organizations, conversations, evaluations, inference, apikeys, logs, integrations Actions: create, read, write, update, delete, train, execute, share, admin Permission Categories:

• Data Management
• Model Training
• Evaluation
• Inference
• Integrations
• Organization Management
• Team Management
• Security
• Billing

​

Role-to-Permission Mapping

Permissions are mapped to roles via RolePermission records scoped at the organization, team, or resource level. Admins can:

• View all available permissions
• Grant or revoke individual permissions for any role
• Assign bulk access levels (basic/plus/admin) to users

​

Implicit Permission Rules

• Delete implies all: Having X:delete automatically grants X:read, X:create, X:update, X:share, X:train, X:execute
• Owner bypass: Organization and team owners automatically have all permissions in their scope
• Superadmin bypass: Superadmins bypass all permission checks platform-wide

​

Resource-Level Access Control

​

Per-Resource Permissions

Beyond role-based access, 4MINDS supports fine-grained resource-level permissions via UserResourcePermission records. These can be granted to:

• Individual users (user_id)
• Entire teams (team_id)
• Entire organizations (org_id)

Each grant includes:

• Specific resource type and ID
• Who granted it and why
• Optional expiration date
• Soft-delete via revocation timestamp

​

Model Access Control

Per-model access supports two levels:

• Full Access — Complete workspace, training, and inference access
• Inference Only — Chat/inference access only (no training, no workspace)

Per-model grants can include restrictions:

​

Dataset Access Control

Binary access model — users/teams either have access to a specific dataset or they don’t. Grants include the dataset ID, grantee (user or team), and reason.

​

Resource Sharing

Datasets and models can be shared with teams, enabling collaborative access across the organization.

​

Permission Resolution Order

When checking if a user can perform an action, 4MINDS evaluates in this order (first match wins):

1. Superadmin → Access granted to everything
2. Organization Owner → All permissions within their org
3. Team Owner → All permissions within their team
4. Delete-implies-others rule applied
5. Resource-level permission (highest specificity)
6. Team-level role permission
7. Organization-level role permission (lowest specificity)

​

Enforcement & Frontend Integration

​

Backend Enforcement

• FastAPI dependency-injection middleware (require_permission, require_organization_admin, require_team_member, etc.)
• Every protected endpoint declares its required permission
• RBAC enforcement can be toggled via RBAC_ENFORCEMENT_ENABLED setting

​

Frontend Enforcement

• JWT-embedded permissions — Model access, access levels, and org privilege flags are encoded in the JWT token
• Route guarding — App.tsx routes users to different workspace views based on access level
• Conditional rendering — UI components use hooks (useWorkspaceOnlyMode, useInferenceOnlyMode, useModelAccess, useFeatureGate) to show/hide features
• Admin portal — Separate login and context (AdminContext) for internal admins

​

Audit Trail

All RBAC actions (grants, revocations, team creation, member changes) are logged in RBACActionLog with actor, target, resource, IP address, user agent, and timestamp.

​

SSO Integration

4MINDS supports automatic role provisioning via SSO: SSO groups can be mapped to teams with a default access level (basic/plus/admin), enabling automatic user provisioning when they authenticate.

​

Feature Gates

Controlled feature releases use a FeatureGate system with:

• Release states: internal_testing → enterprise_beta → public
• Visibility flags per audience (superadmin, enterprise, public)
• API endpoint mapping for backend enforcement
• Frontend useFeatureGate() hook for conditional UI rendering

​

Summary

​

Security best practices

To maximize security when using 4MINDS:

• Rotate API keys regularly
• Use OAuth when possible instead of password authentication
• Monitor your notification alerts for unusual activity
• Review connected integrations periodically and disconnect unused sources
• Keep your authentication credentials private and never share API keys

Security is a shared responsibility. We provide the infrastructure and controls, and you maintain secure practices when accessing and using the platform.