Skip to content

Security and Compliance Policy

This document defines a baseline security and compliance posture, including authentication/authorization, secrets handling, data classification, logging/auditing, and minimal expectations for Factory-generated services and platforms. It is written for security teams, compliance officers, architects, and customers evaluating ConnectSoft's security practices.

ConnectSoft maintains a security-first architecture across all products, with encryption, access control, audit logging, and compliance considerations built into every platform. This policy guides architecture decisions, partner enablement, and contract discussions.

Important

Policy & Design Intent: This document describes policy and design intent, not a legal guarantee. Actual security certifications and compliance status are defined in contracts and official certifications. ConnectSoft aims for "compliance-ready by design" but references certifications only when truly achieved.

This document provides high-level security policy and posture. For detailed technical security documentation, see the dedicated Security section:

  • Security Overview - Security vision, principles, and security artifacts overview
  • Threat Models - Platform-level threat modeling using STRIDE methodology with AI-specific threats
  • Security Patterns Cookbook - Implementation patterns for tenant isolation, secrets management, zero-trust, input validation, and secure-by-default templates
  • Compliance Blueprints - Compliance-by-design architecture supporting SOC2, GDPR, and HIPAA-style requirements

Note

Documentation Split: This governance document focuses on policy and posture. Technical implementation details, threat analysis, and compliance mapping are covered in the Security section documents above.

Security Objectives and Scope

Objectives

  • Protect Customer Data - Ensure customer data and tenant isolation
  • Auditable Systems - Provide auditable systems via Audit Platform
  • Enable Compliance - Enable future compliance certifications (SOC2, GDPR, HIPAA)
  • Security-First Design - Build security into architecture from the start

Scope

This policy applies to:

  • AI Factory and agent execution
  • SaaS Platforms (Identity, Audit, Config, Bot)
  • Factory-generated services
  • Partner-delivered solutions (baseline expectations)

See: Factory Overview for Factory architecture.

See: Product Portfolio - Platforms for platform details.

Identity, Access, and Authentication

High-Level Rules

  • Standardized Identity - Use standardized identity (Identity Platform, OpenID Connect, OAuth2)
  • Principle of Least Privilege - Grant minimum necessary permissions
  • Multi-Tenant Isolation - Enforce tenant isolation at authentication level
  • Service-to-Service Auth - Support service-to-service authentication (client credentials)

Authentication Standards

Customer-Facing Services:

  • OAuth2/OIDC via Identity Platform
  • Authorization code with PKCE for interactive browser and mobile clients
  • Token-based authentication
  • Multi-factor authentication (MFA) support, with MFA required for administrators and privileged operations

Service-to-Service:

  • Client credentials flow
  • Service principals
  • Managed identities (Azure)

Identity Platform Responsibility Baseline

  • Authorization Server owns OAuth/OIDC clients, scopes, consent, token issuance, signing keys, refresh, revocation, introspection, and discovery metadata.
  • Identity Backend owns users, credentials, profiles, MFA, recovery, roles, claims, tenant membership, and external account links.
  • API Gateway owns public route protection, coarse authorization, rate limiting, CORS, correlation, and trusted user/tenant context propagation.
  • Backend APIs own resource-level authorization, tenant isolation, business authorization rules, and audit events.
  • Shell and microfrontends own the user session experience and must use approved OIDC/PKCE or BFF-style flows; they must not store long-lived secrets.

Federation and Token Policy

  • External providers must be configured per tenant or per product with explicit ownership, metadata rotation, and audit visibility.
  • Google, Facebook, Entra ID / Active Directory, Keycloak, SAML/OIDC providers, and LDAP-backed directories must normalize claims into the ConnectSoft identity contract before resource APIs consume them.
  • Access tokens must be scoped to audiences and operations; backends must validate issuer, audience, expiry, tenant context, and required scopes or roles.
  • Gateway-propagated identity headers are trusted only from internal gateway paths and must not replace token validation in resource APIs where bearer protection is required.
  • Implicit flow and resource owner password flow are not approved defaults for new ConnectSoft systems.

See: Identity Platform API Overview for authentication details.

See: Security & Compliance for security requirements.

Secrets Management and Configuration

Baseline Expectations

  • No Secrets in Source Code - No secrets in source code or configuration files
  • Secure Secret Storage - Use secure secret storage (e.g., Azure Key Vault conceptually)
  • Runtime Loading - Secrets loaded from secure provider at runtime
  • Factory-Generated Services - Factory-generated services must use options/config with secret providers

Secrets Management Checklist

  • No plain-text secrets in repos
  • Secrets loaded from secure provider at runtime
  • Secret rotation supported
  • Access to secrets logged and audited
  • Secrets encrypted at rest and in transit

Warning

Common Pitfalls: 1. Hardcoding Secrets - Developers hardcoding secrets in code or config files 1. Logging Tokens - Accidentally logging tokens or credentials in logs 1. Commit Secrets - Committing secrets to version control 1. Shared Secrets - Sharing secrets via insecure channels (email, chat)

See: Cloud-Native Mindset for configuration principles.

Logging, Auditing, and Monitoring

Logging Requirements

Minimal Logging Requirements:

  • Errors and warnings
  • Key business events
  • Security-sensitive operations
  • Structured logging with correlation IDs

Log Format:

  • Structured logging (JSON)
  • Correlation IDs for request tracing
  • Timestamps and log levels
  • No sensitive data in logs

Auditing Requirements

Use of Audit Platform:

  • Key security-sensitive actions recorded
  • Access control changes
  • Configuration changes
  • Data access events

Audit Event Types:

  • Authentication events
  • Authorization events
  • Data access events
  • Configuration changes

See: Audit Platform API Overview for audit details.

See: Observability-Driven Design for observability principles.

Monitoring Requirements

Integration with Observability Stack:

  • OpenTelemetry for distributed tracing
  • Metrics collection and alerting
  • Health checks and status endpoints
  • Dashboard and alerting setup

See: Monitoring and Dashboards for monitoring details.

Baseline Expectations Table

Area Baseline Expectation
Logging Structured, with correlation IDs
Auditing Key security-sensitive actions recorded
Monitoring Health checks, metrics, alerting thresholds

Data Classification and Handling

Data Classification

Simple Classification:

Classification Description Handling Expectations
Public Publicly available information No special handling required
Internal Internal use only Access control, basic encryption
Confidential Sensitive business information Encryption at rest/in transit, access control, audit logging
Sensitive Highly sensitive (PII, financial) Strong encryption, strict access control, audit logging, masking/redaction

Handling Expectations

Encryption:

  • At Rest - Encrypt confidential and sensitive data
  • In Transit - Use TLS/HTTPS for all data in transit
  • Key Management - Use secure key management (Azure Key Vault)

Access Control:

  • Role-based access control (RBAC)
  • Principle of least privilege
  • Regular access reviews

Masking/Redaction:

  • Mask sensitive data in logs
  • Redact PII in audit logs where appropriate
  • Use data masking in test environments

Note

Detailed classification per-project may evolve later. This provides a baseline framework that can be customized per customer or project requirements.

Compliance Alignment and Roadmap

Design Intent

Compliance-Ready by Design:

  • Design influenced by practices compatible with frameworks like SOC2, GDPR, HIPAA
  • Architecture supports compliance requirements
  • Not claiming actual certification unless specifically stated elsewhere

Future Steps

Short-Term:

  • Security policies and procedures
  • Security training for team
  • Regular security assessments

Medium-Term:

  • SOC 2 Type II preparation
  • GDPR compliance documentation
  • HIPAA readiness assessment (if applicable)

Long-Term:

  • SOC 2 Type II certification
  • Industry-specific certifications (as needed)
  • Continuous compliance monitoring

Decision

Compliance Decision: ConnectSoft aims for "compliance-ready by design" but references certifications only when truly achieved. Design is influenced by practices compatible with frameworks like SOC2, GDPR, HIPAA, but we do not claim actual certification unless specifically stated elsewhere.

Security Requirements for Factory-Generated Services

Minimal Checklist

Any Factory-generated service MUST:

  • Use Central Identity/Auth Pattern - Integrate with Identity Platform or use standard OAuth2/OIDC
  • No Secrets in Code - Use secure config source (Azure Key Vault, environment variables)
  • Basic Role/Permission Checks - Implement role/permission checks for protected operations
  • Logging and Error Handling - Implement structured logging and proper error handling
  • Sensitive Data Redaction - Redact sensitive data in logs where applicable
  • Audit Integration - Emit audit events for critical operations
  • Observability Hooks - Include observability hooks (logging, tracing, metrics)

See: Microservice Template for template security features.

See: Agent Microservice Standard Blueprint for standard blueprint.

See: Observability-Driven Design for observability requirements.

See: Audit Platform API Overview for audit integration.