Architecture and Security Overview

1. Purpose

This document describes the technical architecture of the CompleteFlow platform and the security controls that apply at each layer. It is intended for customer security and procurement teams, and is the reference document underpinning CompleteFlow's information security policies.

The document is deliberately specific. It names services, protocols, regions, and version numbers, and it identifies the boundaries of CompleteFlow's responsibility versus that of the customer and of upstream providers (notably Microsoft Azure). Where a control is dependent on a customer choice (for example, region selection or optional integrations), that is stated explicitly.

2. Platform overview

CompleteFlow is an enterprise agentic AI workflow automation platform. It comprises three integrated capabilities:

• A conversational AI agent for end users
• A visual workflow automation canvas for building multi-step automated processes
• Document automation and processing, including retrieval-augmented generation (RAG) and structured data extraction

The platform is targeted at regulated mid-market enterprises in legal, insurance, and financial services. Its design is shaped by the operational, regulatory, and data sovereignty requirements of those sectors.

3. Deployment model

3.1 Dedicated tenancy per customer

CompleteFlow is deployed into a dedicated Microsoft Azure subscription per customer. There is no shared compute, shared database, or shared storage layer between customers. The deployment model is single-tenant in the strictest sense: each customer's environment is a logically and physically separated Azure subscription, billed directly by Microsoft to the customer and operated by CompleteFlow under a managed services arrangement.

This design has three direct consequences for security and compliance:

1. Data segregation is structural, not policy-based. It is not possible for one customer's data to mingle with another's because the data is held in entirely separate Azure subscriptions with separate identity boundaries.
2. Customers retain ownership of their infrastructure. The Azure subscription belongs to the customer. CompleteFlow operates within it with delegated, time-bound, and audited access.
3. Cost transparency. Customers receive Azure invoices directly from Microsoft and can verify infrastructure spend independently of CompleteFlow's licensing fees.

3.2 Region selection

Customers select their primary Azure region at provisioning. For UK customers, the default is Azure UK South (London datacentres). Customers may optionally enable cross-region disaster recovery to Azure UK West (Cardiff datacentres). Both regions are within the United Kingdom and within the EEA-equivalent jurisdiction recognised under UK GDPR.

CompleteFlow does not deploy to regions outside the UK for UK customers without explicit customer instruction and a documented data transfer impact assessment.

3.3 Customer-configurable architecture choices

The following are customer choices, agreed during deployment scoping and subject to change with notice:

4. Component architecture

4.1 Core services

4.2 Network architecture

• The platform is deployed into a CompleteFlow-managed Azure Virtual Network within the customer's subscription. All inter-service communication occurs over Azure private networking.
• Public ingress is restricted to the application frontend, via Azure Container Apps' managed HTTPS ingress with TLS 1.2+ enforced and Azure-managed TLS certificates. Adding a managed web application firewall (via Azure WAF on Front Door, Azure Application Gateway v2 with WAF v2, or equivalent) is available as a customer-configurable enhancement where a specific ruleset or filtering posture is required.
• The PostgreSQL database, Redis cache, Blob Storage, Key Vault, and Azure OpenAI Service are not exposed to the public internet. They are reachable only from within the customer's Azure VNet via private endpoints.
• Network Security Groups restrict inter-subnet traffic to documented flows, and outbound traffic from the platform is restricted to documented destinations (upstream Microsoft services and optional customer-approved integrations).
• Data services additionally enforce identity-based access control (Azure Managed Identity + AAD RBAC), with shared access keys disabled on Storage and RBAC authorisation on Key Vault. This provides defence in depth alongside the network isolation.

4.3 Data flow summary

A typical end-user interaction follows this path:

1. User authenticates via the customer's Entra ID tenant (OIDC flow). Authentication tokens contain the user's identity and role assertions; CompleteFlow does not store user passwords.
2. The authenticated session reaches the application frontend over TLS 1.2+ via Azure Container Apps' managed HTTPS ingress.
3. The frontend communicates with the application backend over the private VNet.
4. The backend retrieves and stores data in PostgreSQL, Blob Storage, and Redis as needed, all via private endpoints.
5. AI inference requests are sent to Azure OpenAI Service over private endpoints. Inference inputs and outputs are not retained by Microsoft beyond the configured abuse monitoring window (see Section 8).
6. Workflow steps execute in the self-hosted workflow orchestrator, which runs within the same VNet and has the same data access constraints as the backend.
7. All steps are logged to Azure Log Analytics within the customer's subscription.

5. Identity, authentication, and access control

5.1 End-user authentication

End users authenticate via the customer's Microsoft Entra ID tenant using OpenID Connect. SAML 2.0 is supported on request. CompleteFlow does not store, transmit, or have visibility of user passwords or other authentication factors.

Multi-factor authentication is enforced for all end users via the customer's own Entra ID conditional access policies. CompleteFlow does not bypass or weaken customer-defined MFA enforcement.

5.2 CompleteFlow staff access to customer environments

CompleteFlow customer deployments are actively co-developed with the customer, and the access model is sized accordingly. In the current stage of the business, a single named individual (the Director and Information Security Officer) holds administrative access to each customer's Azure subscription. This is framed so that the customer retains strong audit and revocation controls even where standing access exists. Governing controls:

• Named accounts only. Each staff member uses a named account federated to the customer's Entra ID tenant via B2B guest identity; shared accounts are prohibited.
• MFA enforced. Hardware-backed FIDO2 or authenticator-app MFA is required.
• Device compliance. Conditional access restricts sign-in to CompleteFlow-managed devices meeting the configuration standard in CF-POL-004.
• All actions logged. Azure Activity Log captures every privileged action; logs are retained in the customer's Log Analytics workspace and are not editable by CompleteFlow.
• Customer control. The customer may review activity, revoke access, and configure Azure PIM on their own subscription to require just-in-time elevation or per-activity approval for specific roles.
• Change notice. Adding, changing, or removing individuals with administrative access requires written notice to the customer.

As the CompleteFlow operations team scales, this arrangement transitions to PIM-based just-in-time elevation with time-boxed activations and, where required, customer-side approval. The transition is communicated to customers in advance and documented in each customer's deployment specification.

5.3 Service-to-service authentication

Internal service-to-service authentication uses Azure Managed Identities. No long-lived credentials are stored in application code or configuration files. Where service principals are required, credentials are rotated automatically and stored exclusively in Azure Key Vault.

5.4 Role-based access control

CompleteFlow implements role-based access control (RBAC) at three layers:

• Azure RBAC for infrastructure-level access (CompleteFlow staff to Azure resources)
• Application RBAC for end-user permissions within the platform. Authorisation decisions are enforced by an in-process policy engine evaluating declarative policies; authorisation decisions are logged as part of the audit trail.
• Per-user credential broker for downstream tool access. When the platform calls third-party APIs on behalf of a user (for example, a document management system), the call is authenticated as that user via per-user credentials stored in the customer's Key Vault. There are no shared service accounts for downstream integrations.

6. Cryptography

6.1 Approved protocols and algorithms

Cryptographic controls follow NCSC, Microsoft, and NIST current guidance.

Approved:

• TLS 1.2 and TLS 1.3 for network transport
• AES-256 for symmetric encryption at rest
• RSA 2048-bit minimum, or elliptic curve (P-256, P-384) for asymmetric keys
• SHA-256 and SHA-384 for hashing
• Argon2id or PBKDF2 (SHA-256, minimum 600,000 iterations) for password derivation, where applicable
• HMAC-SHA-256 for message authentication

Prohibited:

• SSL (all versions), TLS 1.0, TLS 1.1
• MD5 and SHA-1 for any security-sensitive use (including certificate signing and password storage)
• DES, 3DES, RC4
• RSA keys below 2048 bits
• Hard-coded cryptographic keys or secrets in source code or configuration files

6.2 Data in transit

All network traffic is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are explicitly disabled. Cipher suites are configured to align with NCSC and Microsoft current guidance, prioritising forward-secret cipher suites.

Internal communication between services within the Azure VNet is also TLS-encrypted; CompleteFlow does not rely on network-layer trust for service authentication.

6.3 Data at rest

• Azure Blob Storage: AES-256 encryption at rest, enabled by default. Customer-managed keys (CMK) supported via Azure Key Vault.
• Azure Database for PostgreSQL Flexible Server: AES-256 encryption at rest, with optional CMK.
• Azure Cache for Redis: TLS for all connections; data not persisted to disk by default.
• Azure Key Vault: FIPS 140-2 Level 2 validated HSMs for key material.

6.4 Key management

Encryption keys are managed via Azure Key Vault within the customer's Azure subscription. Customers may opt to provide their own key material (Bring Your Own Key) for blob storage and database encryption. Key rotation follows NCSC guidance: rotation at least annually for symmetric keys, immediate rotation in the event of suspected compromise or personnel departure involving key access. Key access is logged to Azure Monitor Log Analytics within the customer's subscription.

Secrets (API keys, connection strings, signing keys) are stored exclusively in Azure Key Vault. No long-lived credentials are stored in application code, configuration files, or environment variables outside Key Vault.

6.5 Certificate management

Public-facing TLS certificates are managed by Azure Container Apps' managed certificate service, with automatic renewal before expiry. Internal TLS and any customer-specific signing certificates are held in Azure Key Vault with certificate lifecycle and expiry monitoring via Azure Monitor.

7. Logging, monitoring, and audit

CompleteFlow provides two complementary logging and audit layers: a technical observability layer based on Azure Monitor, and an application audit log surfaced in the CompleteFlow UI.

7.1 Technical logs (Azure Monitor and Application Insights)

All platform components emit structured logs to Azure Monitor Log Analytics and Application Insights within the customer's Azure subscription. The logs captured include:

• Application logs: workflow execution, agent interactions, errors, performance traces
• Infrastructure logs: Azure Activity Log, network flow logs, Container Apps ingress and system events
• Authentication logs: sign-in events, role changes, PIM elevations, conditional access events
• AI interaction metadata: model endpoint, request timing, token counts, workflow context (request and response content is logged only where the customer explicitly enables it)

Default retention is 90 days hot and 12 months archived. Customers may extend retention or configure export to their own SIEM (for example, Microsoft Sentinel, Splunk, Elastic) via standard Azure diagnostic settings and Event Hub patterns.

7.2 Alerting

Alerting is provided via two mechanisms:

• Microsoft Defender for Cloud: built-in security alerts covering common misconfigurations, suspicious authentication patterns, and known attack signatures across the Azure environment
• Custom Azure Monitor alert rules: KQL-based alert rules for CompleteFlow-specific signals (for example, unusual privileged access patterns, unexpected outbound network destinations, AI interaction patterns outside configured norms)

Alerts are routed to CompleteFlow's on-call engineer and may additionally be routed to the customer's security operations contact by agreement.

7.3 Application audit log

The CompleteFlow application provides an in-UI audit log, searchable by customer administrators. The audit log captures user-facing material actions and is configurable by the customer. Default coverage includes:

• Chat events: conversational AI interactions with the agent
• Workflow runs: execution of configured workflows, including input and output context
• Document imports: documents uploaded or ingested into the platform
• Agent actions: each action taken by an agent, with the identified end user, the model used, tool calls, token usage, policy evaluations, and duration

Customers may extend coverage to additional event types via the application's audit configuration. The audit log is distinct from the Azure Monitor technical logs: it is curated for compliance and administrative use, whereas Azure Monitor serves engineering and SOC use.

8. AI-specific architecture

The AI components of CompleteFlow merit specific description because they introduce data-handling considerations distinct from conventional SaaS.

8.1 Default model and data flow

The default LLM endpoint is Azure OpenAI Service deployed within the customer's Azure subscription. This means inference requests do not leave the customer's Azure tenancy. Microsoft's contractual terms for Azure OpenAI Service apply, including:

• Customer data submitted to Azure OpenAI Service is not used to train or improve any Microsoft or OpenAI models.
• Inputs and outputs are subject to abuse monitoring with a default 30-day retention. Customers eligible under Microsoft's Limited Access Program may opt out of abuse monitoring entirely (zero retention).
• Data is processed only in the Azure region(s) selected by the customer.

8.2 Optional model endpoints

CompleteFlow can be configured to use other models, subject to explicit customer approval and documented in the customer's deployment specification:

• Microsoft Azure AI Foundry models (for example, alternative Azure-hosted LLMs). Same data handling characteristics as Azure OpenAI Service.
• External OpenAI-compatible endpoints (for example, customer-hosted or third-party providers). Where these are enabled, the data handling characteristics depend on the provider and are documented case-by-case. CompleteFlow recommends against the use of providers that train on customer inputs.

The CompleteFlow AI Governance and Acceptable Use Policy (CF-POL-008) sets out the controls that apply to any non-default model endpoint.

8.3 Retrieval-augmented generation (RAG)

When the platform performs RAG over customer documents, the document corpus is embedded using an Azure OpenAI Service embedding model and stored in the customer's PostgreSQL database with vector indexing. The corpus does not leave the customer's Azure subscription. Retrieval combines semantic and keyword search.

Embedding inference uses Azure OpenAI Service in the customer tenancy and is subject to the same data-handling characteristics described in Section 8.1.

8.4 Prevention of data leakage to public LLMs

CompleteFlow's architecture prevents inadvertent data flow to public LLM endpoints by design:

• The platform does not contain integrations with consumer-grade or public LLM endpoints (e.g. ChatGPT consumer, public Claude, public Gemini). Where similar capabilities are needed, they are accessed via enterprise endpoints under contract.
• Outbound network traffic from the customer's VNet is restricted to documented destinations only.
• Per-user MCP credentials prevent platform users from invoking external tools or LLMs without explicit, audited credential provisioning.

9. Sub-processors

CompleteFlow uses the following sub-processor as standard:

In addition, the following sub-processors are available on an opt-in basis with explicit customer consent:

9.1 Notification of sub-processor changes

CompleteFlow notifies customers in advance of any addition or change to the sub-processor list, with a minimum 30 days' notice. The customer retains the right to terminate the agreement on reasonable terms if it objects to a change.

10. Business continuity and disaster recovery

10.1 Recovery objectives

Recovery time and recovery point objectives are agreed with each customer in the applicable Service Level Agreement, in light of the customer's availability needs, Azure service capabilities in the deployment region, and any enabled DR options. The underlying architecture supports a range of objectives, drawing on:

• Azure Database for PostgreSQL Flexible Server point-in-time restore (up to 35 days)
• Zone-redundant and (optionally) geo-redundant storage for Azure Blob Storage
• Zone-redundant configurations for supporting services where Azure supports them in the deployment region
• Infrastructure-as-code re-deployment from source to a paired UK region where cross-region DR is enabled

Cross-region DR (UK South to UK West) is available as a customer-configurable option. Support hours and response expectations are defined in the SLA.

10.2 Backup posture

• PostgreSQL backups are taken automatically by Azure with point-in-time restore for up to 35 days.
• Blob Storage uses zone-redundant storage (ZRS) by default within the primary region; geo-redundant storage (GRS) within the UK is available where DR is enabled.
• Backup data is encrypted with the same standards as production data and held within the customer's Azure subscription.

10.3 Testing

The CompleteFlow Business Continuity and Disaster Recovery Plan (CF-PLAN-002) sets out the testing schedule. The first DR test will be conducted on CompleteFlow's reference deployment prior to customer go-live and at least annually thereafter.

11. Vulnerability and security testing

CompleteFlow operates a shared responsibility model for security testing. Continuous automated testing is performed by CompleteFlow on every release. Independent penetration testing is performed by the customer against a dedicated test environment that CompleteFlow provisions. The two activities are complementary: automated testing catches known vulnerability patterns at the speed of the development cycle, while customer-conducted penetration testing applies adversarial human judgement appropriate to the customer's threat model.

11.1 Continuous automated testing

The following automated checks run on every release as part of CompleteFlow's CI/CD pipeline. A release cannot ship if any check produces an ERROR-severity finding without explicit override and recorded justification.

11.2 Customer-conducted penetration testing

CompleteFlow facilitates customer penetration testing as follows:

• Dedicated test environment. On request, CompleteFlow provisions a production-equivalent test environment within the customer's Azure subscription, deployed from the same infrastructure-as-code definitions as production. The environment mirrors production architecture, configuration, and security controls.
• Customer-conducted testing. The customer engages their own penetration testing provider and conducts testing against the test environment. CompleteFlow does not constrain the customer's choice of provider, methodology, or scope (within the technical boundaries of the test environment).
• Joint triage. All findings are jointly triaged between CompleteFlow and the customer to agree validity, severity classification, and scope. Findings that are false positives, out of scope, or accepted risks are recorded and excluded from remediation tracking. Only agreed findings are in scope for the remediation SLA.
• Remediation SLA. For findings agreed in joint triage, CompleteFlow commits to the following:

A "compensating control" is a measure that materially reduces the risk associated with the finding to a level acceptable to the customer, applied while a permanent fix is engineered. Examples include feature flags, access restrictions, additional monitoring, and configuration changes. The customer must agree the compensating control as adequate before it is recorded as remediation.

11.3 OS and platform patching

• Azure-managed services receive patches from Microsoft on Microsoft's published cadence; CompleteFlow has no direct patching responsibility for these services.
• Self-managed components (application code, workflow orchestrator, container base images) are patched on the following schedule:
  • Critical security patches: within 7 days of release
  • High-severity patches: within 14 days
  • Medium-severity patches: within the next scheduled release cycle
  • Low-severity patches: within normal release cycles

11.4 Continuous monitoring

CompleteFlow uses Microsoft Defender for Cloud for continuous security posture assessment across the customer's Azure subscription. Findings are reviewed weekly by the engineering team and surfaced to the customer's security operations contact for any items requiring customer-side action (for example, identity-related findings within the customer's Entra tenant).

12. Compliance and certifications

12.1 CompleteFlow Ltd

CompleteFlow Ltd is a UK-incorporated company registered as a data controller and processor with the UK Information Commissioner's Office.

The following certifications are in active preparation:

• Cyber Essentials Plus: Engagement scoped with an IASME-accredited certification body; certification targeted post customer contract signature.
• ISO/IEC 27001: Phased implementation. The Information Security Management System (ISMS) policy framework is operational and aligned with ISO 27001 Annex A controls.

12.2 Inherited from Microsoft Azure

CompleteFlow's platform inherits the certifications held by Microsoft Azure for the underlying infrastructure. Relevant certifications include:

• ISO/IEC 27001, 27017 (cloud-specific controls), 27018 (cloud privacy)
• SOC 1, SOC 2 Type II, SOC 3
• CSA STAR Level 2
• UK Cyber Essentials Plus
• UK G-Cloud (Crown Commercial Service framework)

Current Microsoft attestations are published at the Microsoft Trust Center.

13. Document control

This document is reviewed annually or upon any material change to the platform architecture, sub-processor list, or compliance posture. Material changes are communicated to customers with a minimum of 30 days' notice unless a shorter notice period is required to address an active security concern.