Synapse — security policy

Change history

Contents

1. Purpose and scope
2. Definitions
3. Roles and responsibilities
4. Access control and user provisioning
5. Authentication requirements
6. Data classification and handling
7. AI inferencing and data sovereignty
8. Code sandbox security
9. Secrets and credential management
10. Monitoring, logging, and audit
11. Incident response
12. Third-party and supply chain
13. Vulnerability and patch management
14. Policy compliance and review

1. Purpose and scope

1.1 Purpose

This policy defines the security requirements for the design, operation, maintenance, and use of Synapse — Conscia UK's internal AI assistant platform. It establishes the controls that must be in place to protect the confidentiality, integrity, and availability of Synapse and the data it processes.

This policy supports Conscia UK's commitment to information security best practice and is written to align with the principles of ISO/IEC 27001, in anticipation of future formal certification.

1.2 Scope

This policy applies to:

• All Conscia UK employees who use, develop, operate, or administer Synapse
• All AWS infrastructure, software components, and third-party integrations that form part of the Synapse platform
• All data processed by Synapse, regardless of the channel through which it is submitted

1.3 Out of scope

• Underlying AWS account-level security controls (governed by Conscia UK's cloud security policy)
• Security of the Microsoft 365 tenancy used for Azure AD authentication (governed by Conscia's Microsoft governance policies)
• Client-side device security — endpoint protection and OS hardening are the responsibility of device management policies

2. Definitions

3. Roles and responsibilities

3.1 Policy owner

The policy owner is the Head of Solution Development. The policy owner is responsible for:

• Maintaining and updating this policy
• Ensuring controls described herein are implemented and remain effective
• Approving exceptions to this policy
• Escalating material security concerns to the CTO

3.2 Platform administrators

Platform administrators are responsible for:

• Provisioning and deprovisioning user accounts
• Assigning and reviewing Cognito group membership (roles)
• Monitoring CloudWatch and CloudTrail for anomalous activity
• Responding to security incidents involving Synapse
• Maintaining the EC2 sandbox host and Docker image
• Rotating secrets in AWS Secrets Manager as required

3.3 All users

All users are responsible for:

• Complying with this policy and the Synapse Acceptable Use Policy
• Reporting suspected security incidents or policy violations to a platform administrator
• Not sharing their Synapse session or Microsoft credentials with others
• Using Synapse only for legitimate Conscia UK business purposes

4. Access control and user provisioning

4.1 Access principles

Access to Synapse follows the principle of least privilege. Users are granted the minimum role necessary for their function. Elevated roles (Engineer, Admin) are granted only where there is a documented business need.

4.2 Provisioning

New Synapse users must be provisioned by a platform administrator. Self-registration is disabled at the Cognito level. All new accounts must:

• Be created using the user's Conscia corporate email address
• Be assigned the appropriate Cognito group (no group = Default role)
• Be documented with a brief justification for any non-Default role assignment

4.3 Role definitions and entitlements

Role assignments must be reviewed whenever a user's job function changes.

4.4 Deprovisioning

When a Conscia employee leaves the organisation or no longer requires Synapse access:

1. Their Cognito account must be disabled or deleted within one working day of departure or role change
2. Active WebSocket connections expire naturally (10-hour TTL)
3. Session data in S3 is not automatically deleted — administrators should evaluate retention or deletion on a case-by-case basis

Deprovisioning should be triggered as part of the standard Conscia offboarding process.

4.5 Privileged access review

Platform administrators must review users with Engineer or Admin roles at least every six months and remove any assignments that are no longer justified.

5. Authentication requirements

5.1 Authentication method

All access to the Synapse web UI is authenticated via AWS Cognito with Azure AD as the sole federated identity provider. Users authenticate with their corporate Microsoft credentials and are subject to Conscia's Azure AD conditional access policies, including multi-factor authentication.

Local Cognito authentication (username and password) is disabled. There is no fallback authentication method.

5.2 Session management

• Cognito session tokens have a maximum lifetime of 600 minutes
• WebSocket connection records carry a 10-hour DynamoDB TTL and are invalidated on explicit disconnect
• Session tokens are stored in browser sessionStorage — they are cleared when the browser tab is closed

5.3 Server-side token verification

Every authenticated request is independently verified server-side, including:

• Structural validation (three-part JWT format)
• Expiry check against current time
• Issuer validation against the Cognito pool URL
• Full RS256 cryptographic signature verification via the Cognito JWKS endpoint

Tokens failing any check are rejected with 401. JWKS unavailability is treated as a verification failure — there is no weakened fallback mode.

5.4 Credential sharing

Users must not share their Microsoft credentials or active Synapse sessions. Each session carries the user's identity, determining their role, data access, and audit attribution.

6. Data classification and handling

6.1 Data processed by Synapse

Synapse processes a wide range of data types in the course of normal use, including commercial and financial data, client information, personal data relating to Conscia employees, technical designs, and publicly available information. All data submitted to Synapse should be treated as Conscia Internal unless explicitly designated otherwise.

6.2 Prohibited data categories

The following categories of data must not be submitted to Synapse under any circumstances:

Regulated or security-classified client data

Any data relating to clients or projects that require background checks, security clearance, or other regulatory approval processes. This includes:

• Classified or protectively marked information (OFFICIAL-SENSITIVE, SECRET, TOP SECRET, or equivalent UK government classifications)
• Data relating to defence, intelligence, or law enforcement engagements where data handling restrictions apply
• Information about individuals subject to vetting or clearance processes
• Commercially sensitive data provided under a non-disclosure agreement that explicitly restricts processing by AI services

Users must exercise particular caution on engagements that have — or are expected to have — vetting, clearance, or regulatory data handling requirements attached to them.

Sensitive personal data (special category data)

While general personal data (names, email addresses, professional roles) arises naturally in normal use, users should not submit:

• Health or medical information about identifiable individuals
• Biometric or genetic data
• Criminal conviction data
• Religious, political, or philosophical belief data about identifiable individuals

Where processing of such data is genuinely required for a business purpose, the policy owner must be consulted before using Synapse.

6.3 Data storage location

All data at rest within Synapse is stored exclusively in AWS eu-west-2 (London). No data is replicated to other AWS regions or non-AWS storage. Data is protected by:

• S3 server-side encryption (AES-256) at the bucket level
• HMAC-SHA256 integrity signing on all session files
• Fernet symmetric encryption on stored Azure access tokens

6.4 Data minimisation

Users should submit only the data necessary for the task. Where a document contains more information than required, users should consider extracting the relevant portion rather than submitting the full document.

6.5 User data isolation

Each user's data is isolated from all other users by:

• S3 key prefixing under {email}/
• Server-side REST API prefix enforcement derived from verified JWT claims
• STS session policies scoped to {email}/* for sandbox credentials

No user can access another user's data through normal platform operation.

6.6 Retention and deletion

Session data is not automatically deleted. Users may delete conversations and files via the web UI. Administrators may delete data via S3 operations where required. Retention of former-employee data should be evaluated against Conscia's data retention policy.

7. AI inferencing and data sovereignty

7.1 Inference provider

All AI inference is performed via Amazon Bedrock using Anthropic Claude models. AWS does not use customer prompt data to train foundation models and does not store prompts or completions after inference is complete. Anthropic has no access to customer prompts, completions, or any identifying information through the Bedrock architecture.

7.2 Inference routing

The primary conversational model uses a global cross-region inference profile. Persistent data remains in eu-west-2, but inference requests may be transiently routed to any AWS commercial region for processing. Prompt content travels over the AWS Global Network under encryption and is not stored in the destination region.

Conversation title generation uses an EU-only inference profile, which restricts processing to EU/EEA regions.

Implication: Prompt content may be processed outside the UK and EU during inference. This is accepted for Conscia Internal data under AWS's GDPR Data Processing Addendum. It is not accepted for the prohibited categories in section 6.2.

If EU-only inference is required in future, this is achievable by changing a single model ID constant in the platform configuration — no architectural work is required.

7.3 GDPR

AWS's GDPR Data Processing Addendum and UK GDPR Addendum apply automatically, governing AWS's role as data processor and Conscia's role as data controller.

8. Code sandbox security

8.1 Isolation model

Each conversation has a dedicated Docker container on the EC2 sandbox host. Container names are derived from a hash of the user's email and conversation ID. One user cannot interact with another user's container. All containers run with hard resource limits (2 GB RAM, 1 vCPU).

8.2 Credential isolation

Each sandbox invocation receives short-lived STS credentials scoped by an inline session policy to the executing user's S3 prefix only. Credentials expire after one hour.

8.3 Host access model

The EC2 sandbox host has no inbound security group rules. It is managed exclusively via AWS SSM Run Command — there is no SSH access. All command execution is logged in CloudTrail.

8.4 Instance metadata

The EC2 instance metadata service is reachable from containers. The EC2 instance role is scoped to scratch-bucket S3 operations and SSM permissions only. Future hardening — blocking IMDS at the Docker bridge network level — is a noted improvement item.

8.5 Container lifecycle

Containers are cleaned up after four hours of inactivity. Administrators or users may trigger an immediate reset via a sandbox reset=True call.

9. Secrets and credential management

9.1 No embedded credentials

No credentials or secrets are embedded in source code, Lambda environment variables, or repository commits. All secrets are stored in AWS Secrets Manager and retrieved at runtime.

9.2 Secret collections

9.3 Rotation schedule

Secrets must be rotated:

• Immediately on confirmed or suspected compromise
• When a team member with access to a secret departs or changes role
• Annually as a minimum for all long-lived credentials

9.4 Access scope

Lambda execution roles grant secretsmanager:GetSecretValue only to specific required secret ARNs. Sandbox containers do not have direct Secrets Manager access — secrets are fetched by the Lambda and injected selectively by role.

10. Monitoring, logging, and audit

10.1 Application logging

Synapse logs to Amazon CloudWatch Logs. Logs include, at minimum:

• User email and conversation ID on every interaction
• Tool invocations and outcomes
• Authentication events (connect, disconnect, rejection)
• Sandbox lifecycle events
• Bedrock inference metrics and error codes

10.2 Metrics and CloudTrail

Custom CloudWatch metrics are published per user under the Synapse namespace, enabling usage monitoring. All AWS API calls — including Bedrock inference — are logged via CloudTrail. The inferenceRegion field in Bedrock events records the processing region for each request.

10.3 Log retention

CloudWatch log groups must be configured to retain logs for a minimum of 90 days. Longer retention should be applied where required by contract or regulation.

10.4 Monitoring obligations

Administrators should implement alerting for anomalous patterns — repeated authentication failures, unusually high inference volumes, unusual S3 access. Proactive monitoring posture should improve as the platform matures.

11. Incident response

11.1 What constitutes an incident

A security incident is any event that has caused or may cause:

• Unauthorised access to Synapse or the data it holds
• Loss, corruption, or unauthorised disclosure of data
• Compromise of a credential or secret
• Misuse of Synapse in violation of this policy or the Acceptable Use Policy
• Deliberate disruption to availability

11.2 Initial response steps

1. Contain — disable accounts, revoke credentials, rotate secrets, or stop the sandbox host as appropriate to the incident
2. Notify — inform the policy owner (Head of Solution Development) and the CTO promptly
3. Preserve evidence — retain CloudWatch logs, CloudTrail events, and S3 objects until explicitly released

11.3 Assessment and remediation

The policy owner, CTO, and relevant technical resource will assess scope, implement remediation, and conduct a post-incident review.

11.4 GDPR notification

If personal data is involved and the breach meets the UK GDPR notifiable threshold, the ICO must be notified within 72 hours of becoming aware of the breach. The responsible data protection contact must be notified immediately when a personal data breach is suspected.

12. Third-party and supply chain

12.1 AWS

Synapse is deployed on AWS. AWS holds ISO 27001, SOC 2, and GDPR certifications applicable to the services in use and operates under the shared responsibility model.

12.2 Anthropic (via AWS Bedrock)

Anthropic models are accessed exclusively via Bedrock. Anthropic has no access to deployment accounts or customer data. AWS's contractual commitments as data processor cover this relationship.

12.3 Microsoft (Azure AD)

Azure AD is used as the federated identity provider. Microsoft processes authentication tokens in accordance with Conscia's Microsoft enterprise agreement and applicable data protection commitments.

12.4 Other third-party integrations

Tavily (web search) and Mapbox (geocoding) receive only the minimum data required for their function — a search query or a postal address. Neither receives conversation history or user identity. Frontend CDN libraries (Mermaid.js, Highlight.js) are constrained by the Content Security Policy.

12.5 Dependency review

Platform administrators should review third-party dependencies for security advisories when making significant platform changes, and monitor for vulnerabilities in active dependencies.

13. Vulnerability and patch management

13.1 Lambda dependencies

Lambda function dependencies should be updated promptly when security vulnerabilities are identified in packages listed in requirements.txt.

13.2 Docker image

The sandbox Docker image should be rebuilt when security updates are available for the base image (python:3.14-slim) or pre-installed packages. Rebuilds are triggered by updating and redeploying the CloudFormation stack.

13.3 Infrastructure review

CloudFormation-managed infrastructure should be reviewed when AWS announces security-relevant changes to services in use. IAM policies should be tightened as platform functionality evolves.

14. Policy compliance and review

14.1 Compliance

All personnel within scope are required to comply with this policy. Non-compliance should be reported to the policy owner. Where non-compliance results from a technical control gap, the policy owner is responsible for prioritising remediation.

14.2 Exceptions

Exceptions may be granted by the policy owner with a documented business justification and a review date. Exceptions must not conflict with Conscia's legal or regulatory obligations.

14.3 ISO 27001 readiness

This policy is structured to align with ISO/IEC 27001 Annex A control domains, in particular A.5 (Organisational controls), A.6 (People controls), and A.8 (Technological controls). When Conscia UK pursues formal ISO 27001 certification, this policy should be reviewed against the relevant controls and supplemented as required to achieve full alignment.

14.4 Policy review

This is a living document. All updates will be recorded in the change history table. The policy owner is responsible for ensuring the document accurately reflects the current platform configuration and risk environment at all times.