Security Model

The SigilAI platform is engineered with a security-first mindset. This document outlines the core principles, mechanisms, and best practices that constitute SigilAI's security model, ensuring the protection of data, the integrity of scanning processes, and the overall trustworthiness of the service.

Core Security Principles

SigilAI's security model is built upon the following foundational principles:

1. Defense in Depth: Implementing multiple layers of security controls, so if one layer is compromised, others remain to protect the system.

2. Least Privilege: Granting components and users only the minimum necessary permissions to perform their functions.

3. Secure by Design: Integrating security considerations into every phase of the system development lifecycle, from design to deployment and maintenance.

4. Zero Trust (Conceptual): Assuming no implicit trust between components; all interactions should be authenticated and authorized where appropriate.

5. Data Minimization: Collecting and retaining only the data essential for providing the service.

6. Transparency and Auditability: Ensuring that security-relevant actions are logged and auditable.

Security Architecture Layers

1. Network Security

• Secure Transport: All communication between clients and the SigilAI MCP Gateway, as well as between SigilAI components and external services, must use encrypted channels (e.g., HTTPS with TLS 1.2+).

• Firewalls & Web Application Firewalls (WAF): Network firewalls and WAFs are employed to protect against common web attacks and unauthorized network access.

• DDoS Protection: Mechanisms are in place to mitigate Distributed Denial of Service attacks, ensuring service availability.

• Network Segmentation: Internal networks are segmented to limit the blast radius in case of a breach.

2. Application Security

• Authentication & Authorization:

  • Client Authentication: AI clients connecting to the MCP Gateway should be authenticated (e.g., using API keys, OAuth tokens, or mutual TLS).

  • User Context: If user-specific actions are performed, user identity from the client session is used for authorization checks.

  • Internal Authorization: Access between internal components may also be subject to authorization controls.

• Input Validation:

  • All data received from clients via MCP (tool parameters) is rigorously validated against predefined schemas (e.g., using Zod). This prevents injection attacks, malformed requests, and other input-related vulnerabilities.

  • Data received from external scanning engines or threat feeds is also validated before processing.

• Rate Limiting & Throttling: To prevent abuse and ensure fair usage, rate limits are applied to API requests and tool invocations.

• Secure API Design: Tool interfaces exposed via MCP are designed to minimize attack surfaces and follow secure API development practices (e.g., avoiding overly permissive parameters).

• Error Handling: Error messages are designed to be informative for debugging but avoid leaking sensitive internal system details.

• Session Management: Secure session management practices are followed for MCP client sessions, including secure session identifiers and timeouts.

3. Data Security

• Data Encryption:

  • In Transit: All data, including URLs, file content, and scan results, is encrypted during transmission using strong cryptographic protocols.

  • At Rest: Sensitive data stored in the Data Persistence Layer (e.g., scan results, configuration, API keys) is encrypted using industry-standard encryption algorithms (e.g., AES-256).

• Data Sanitization:

  • Input data is sanitized before being used in queries or passed to external systems to prevent injection attacks.

  • Sensitive information is redacted or masked in logs to prevent accidental exposure.

• Access Controls: Granular access controls are applied to data stores, ensuring that components and users can only access data they are authorized for.

• Data Retention & Disposal: Clear policies define how long data is retained and how it is securely disposed of when no longer needed, in compliance with relevant regulations.

• File Handling Security:

  • When files are submitted for scanning, they are handled in a secure, isolated environment.

  • Temporary files are securely deleted after analysis.

  • Measures are in place to prevent path traversal or other file system attacks.

4. Infrastructure Security

• Secure Cloud Configuration: If deployed in a cloud environment (e.g., AWS, Azure, GCP), infrastructure is configured according to cloud security best practices and benchmarks (e.g., CIS Benchmarks).

• Vulnerability Management: Regular vulnerability scanning and timely patching of operating systems, libraries, and third-party dependencies are performed.

• Container Security: If using containers (e.g., Docker), images are scanned for vulnerabilities, and containers are run with minimal privileges in secure orchestrators (e.g., Kubernetes with appropriate security contexts).

• Secrets Management: Sensitive credentials (API keys, database passwords) are managed securely using dedicated secrets management solutions (e.g., HashiCorp Vault, AWS Secrets Manager) and are not hard-coded.

5. Operational Security

• Security Monitoring & Alerting: Continuous monitoring of system logs, network traffic, and application behavior to detect suspicious activities and potential security incidents. Real-time alerts are generated for critical security events.

• Incident Response Plan: A well-defined incident response plan is in place to handle security breaches efficiently, including steps for containment, eradication, recovery, and post-incident analysis.

• Regular Security Audits & Assessments: Periodic internal and third-party security audits, penetration tests, and code reviews are conducted to identify and remediate vulnerabilities.

• Secure Software Development Lifecycle (SSDLC):

  • Security is integrated into all stages of development, from requirements gathering and design to coding, testing, and deployment.

  • Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools are used.

  • Secure coding guidelines are followed by developers.

  • Peer code reviews include a security checklist.

Trust Model

• Client Trust: SigilAI does not implicitly trust client-provided data. All inputs are validated.

• Internal Component Trust: While internal components operate within a trusted environment, communication between them may still be secured, and interactions are based on well-defined interfaces.

• Third-Party Trust: Interactions with external scanning engines or threat feeds are treated with caution. Data from these sources is validated, and the impact of a compromised third-party service is considered in the risk model.