Breadcrumbs

AgileSec Security Model

AgileSec incorporates multiple layers of protection for data in transit, at rest, and during processing. The platform enforces strict isolation, encryption, and authentication across all components and deployment models.

Secrets Management and Encryption

The Secrets Management service is the central component for key management and secure credential handling.

Key responsibilities include:

  • Integration with key management systems — Interfaces with deployment-specific backends:

    • AWS deployments using AWS KMS

    • Azure Kubernetes Service (AKS) deployments using Azure Key Vault

    • On-premises deployments using local Java Keystores

    • HashiCorp Vault integration is planned for a future release

  • Customer Master Key (CMK) management — Generates Customer Master Keys in the configured key store, providing customers full control over root encryption keys.

  • Data Encryption Key (DEK) generation — Generates unique DEKs for each sensitive data object or configuration payload.

  • Envelope encryption — Encrypts DEKs using the CMK. Encrypted DEKs are stored alongside the data in MongoDB, while plaintext DEKs are never persisted.

  • Secure runtime decryption — Provides plaintext DEKs to authorized services (e.g., scan execution environments) on-demand for decryption of configuration data. The service ensures just-in-time access and wipes plaintext keys from memory after use.

  • JWT issuance for service access — Generates short-lived JWT tokens for authenticated access to OpenSearch (including Advanced Dashboards) and the Ingestion Service.

All configuration data transmitted through the pipeline (e.g., sensor credentials, scan parameters) is encrypted using a fresh DEK before being sent. Scan execution environments have limited privileges to request decryption of required configuration via the Secrets Management service.

Data in Transit

  • Mutual TLS (mTLS) — All service-to-service communication, including access to Kafka, MongoDB, OpenSearch, and all micro-services is protected using mTLS for on-premise deployments.

  • Kubernetes deployments — Service-to-service traffic is optionally secured by a service mesh such as Istio for advanced policy enforcement, traffic visibility, and certificate management.

Authentication and Authorization

  • Single Sign-On (SSO / SAML) — Enterprise authentication integration with customer Identity Providers enables secure access to the Web UI, Advanced Dashboards, and API.

  • Role-Based Access Control (RBAC) — Fine-grained permissions are enforced across UI, API, and data access based on user roles and tenant context.

  • API and Ingestion authentication — All API calls and ingestion submissions require valid tokens (JWT or API keys) with strict validation.

Data at Rest

  • All persistent sensor configuration data in MongoDB is encrypted using envelope encryption with customer-controlled master keys.

  • Raw and enriched findings can be protected using encrypted file systems (EFS).

Multi-Tenant Isolation

In SaaS mode, strict tenant isolation is enforced across all layers:

  • Separate encryption keys per tenant

  • Tenant-scoped access control

  • Physical partitioning using tenant-specific Kafka topics

  • Physical partitioning of tenant-specific indexes in OpenSearch

  • Physical partitioning of tenant-specific databases in MongoDB

In dedicated (on-premises or private K8s) deployments, the instance is single-tenant by design.

This comprehensive security model ensures that sensitive scan data, credentials, and findings remain protected throughout the entire lifecycle, meeting enterprise compliance and security requirements across all supported deployment models.