Ansvar | Threat Intelligence
CONFIDENTIAL
Prepared For

FinAI

STRIDE Threat Model

Date Placeholder
Version 1.0
Framework STRIDE
Report ID 202cbb1c
Prepared By Ansvar
Validated By John Doe, Senior Cyber Security Expert

01 Executive Dashboard

The following metrics summarize risk concentration by severity tier. Severity reflects potential impact assuming successful exploitation, prior to control effectiveness adjustments.

5
Critical
10
High
3
Medium
0
Low
18
Total
Risk Heatmap ISO 31000
Negligible
Minor
Moderate
Major
Severe
Almost Certain
0
0
0
0
0
Likely
0
0
0
8
Likely / Major
• RISK-003: Internal/Hyrbid Traffic Sniffing Captures Tokens and Enables Replay
• RISK-006: Pinecone API Key Abuse Enables Unauthorized Vector Queries and Cost/Privacy Impact
• RISK-007: RAG/Vector Index Tampering Poisons Retrieval Integrity
• RISK-009: Partner API Key Replay Enables Aggregator Impersonation and Consent Abuse
• RISK-010: SMS Gateway API Key Compromise Enables OTP Spoofing and ATO
... and 3 more
2
Likely / Severe
• RISK-002: DMZ-to-Internal Service Impersonation Due to Missing S2S Identity
• RISK-005: Azure OpenAI API Key Theft Enables Unauthorized LLM Usage and Data Exposure
Possible
0
0
3
Possible / Moderate
• RISK-011: Datadog Ingestion Key Abuse Enables Telemetry Spoofing and Monitoring Blindness
• RISK-012: mTLS Certificate Theft/Forgery Enables Service Identity Takeover (CRM/Fraud)
• RISK-018: Conversation/Inference Logging Gaps Enable Repudiation and Evidence Tampering
5
Possible / Major
• RISK-001: Edge Identity Header Spoofing/Tampering Enables User Impersonation
• RISK-004: Session Store Hijack/Fixation via Weak Binding and Replay
• RISK-008: Genesys OAuth Token Replay Enables Unauthorized Case/Transcript Actions
• RISK-015: Indirect Prompt Injection via RAG Documents Spoofs Bank Policy Guidance
• RISK-016: Prompt/Jailbreak-Induced AuthZ Bypass for Tool Use (Confused Deputy)
0
Unlikely
0
0
0
0
0
Rare
0
0
0
0
0
Low Impact → High Impact

02 Executive Summary

Bottom Line
FinAssist AI's threat profile presents potentially significant risk to NordicBank and its customers. Five critical threat categories require executive attention before go-live: API key and certificate compromise affecting Azure OpenAI and partner integrations, missing service-to-service authentication between DMZ and internal zones, indirect prompt injection via RAG document poisoning, edge-to-gateway identity gaps enabling session hijacking, and credential replay vulnerabilities at the hybrid ExpressRoute boundary. These threats span identity verification gaps, secrets management weaknesses, and LLM supply chain integrity concerns. Validation and remediation of these findings is essential to meet DORA ICT risk requirements and protect customer trust.
Top 3 Priorities
1
RISK-005 • Spoofing, Tampering, Repudiation
2
RISK-002 • Spoofing, Tampering, Repudiation
3
RISK-009 • Spoofing, Tampering, Repudiation
This STRIDE-based threat assessment of NordicBank's FinAssist AI platform identified 18 prioritized threats, with 5 rated critical. The platform—serving 2.3 million retail customers via web, mobile, and third-party widgets—handles sensitive customer data including account balances, transaction histories, and personal information through its Azure OpenAI and fallback Llama 3.1 inference paths. If the critical threats identified above are validated and exploited, business impacts could include regulatory exposure under GDPR and DORA, financial fraud through manipulated AI responses, and operational disruption to the bank's digital customer experience. DORA Chapter II compliance is assessed as partial, with identified gaps in ICT risk management controls requiring validation and closure before the planned launch. Spoofing threats represent 28% of findings—indicating that investment in zero-trust identity controls across trust boundaries offers the highest remediation leverage.
Key Findings
  • 5 critical risks involve Spoofing, suggesting focused remediation opportunity
  • Analysis identified 18 risks requiring executive attention

03 System Architecture

Data Flow Diagram showing system components organized by trust zones. Click on components to highlight connected data flows.

34
Components
6
Trust Zones
41
Data Flows
27
Cross-Boundary
12
External Entities
STRIDE Threat Model - Data Flow Diagram INTERNET ZONE DMZ ZONE INTERNAL ZONE DATA ZONE THIRD-PARTY ZONE ON-PREMISE ZONE HTTPS-TLS1_3 HTTPS-TLS1_3 Internal RPC - inferred Internal RPC - inferred REST-HTTPS - assumed REST-HTTPS - assumed HTTPS-TLS1_3 HTTPS - assumed Internal RPC - inferred Internal RPC - inferred Internal RPC - inferred REST-HTTPS - assumed REST-HTTPS - assumed mTLS + JWT - documented mTLS + JWT - documented mTLS - documented mTLS - documented REST-HTTPS - assumed REST-HTTPS - assumed REST-HTTPS - assumed REST-HTTPS - assumed REST-HTTPS - assumed REST-HTTPS - assumed HTTPS - assumed HTTPS - assumed Internal RPC - inferred Internal RPC - inferred Internal RPC - inferred REST-HTTPS - assumed REST-HTTPS - assumed SaaS UI - HTTPS - assumed REST-HTTPS - assumed HTTPS - assumed HTTPS - assumed Portal-API - unspecified Portal-API - unspecified Internal RPC over ExpressRoute - inferred Private link - inferred Private link - inferred Internal RPC over ExpressRoute - inferred CI-CD pipelines - HTTPS assumed RetailBanking Customers UnauthUsers Third-partyApp Users PSD2 licensedThird-party… HumanSupport Agents SOCSecurity Operations FrontDoor with WAF APIGateway (FinAssist… PartnerWidget Integrations FinAssistAI APILayer OrchLayer ContextBuilder ResponseFiltering BankIdentity Provider CustomerData API InternalCRM FraudDetect API K8sNetwork Policies ExpressRouteAzure SessionStore RAGSource Documents… ConvLogs Anonymized…Model Improvement… PartnerIntegr Logging Store OpenAISvc OpenAIEmbeddings Model PineconeVector DB Svc GenesysCloud SMSGateway MonitorAzure DatadogAPM DevOpsCI-CD On-premiseGPU Cluster… LEGEND External Service Process (System Component) Data Store External Actor (Entity) Data Flow Return Flow TRUST BOUNDARIES Internet Zone DMZ Zone Internal Zone Data Zone Third-Party Zone On-Premise Zone

Trust Boundary Analysis

Data flows crossing trust boundaries require additional security scrutiny.

Boundary Crossing Flows Data Types Risk
Internet Zone → DMZ Zone 3 HTTPS-TLS1_3, HTTPS-TLS1_3, HTTPS - assumed PII
DMZ Zone → Internal Zone 1 Internal RPC - inferred PII
DMZ Zone → Data Zone 1 Internal RPC - inferred Auth
Internal Zone → Data Zone 3 Internal RPC - inferred, HTTPS - assumed, Internal RPC - inferred PII
Data Zone → Internal Zone 2 Internal RPC - inferred, HTTPS - assumed Auth
Internal Zone → Third-Party Zone 7 REST-HTTPS - assumed, REST-HTTPS - assumed, REST-HTTPS - assumed (+4 more) PII
Third-Party Zone → Internal Zone 5 REST-HTTPS - assumed, REST-HTTPS - assumed, REST-HTTPS - assumed (+2 more) PII
Third-Party Zone → Internet Zone 1 SaaS UI - HTTPS - assumed PII
Internet Zone → Third-Party Zone 2 Portal-API - unspecified, Portal-API - unspecified
Internal Zone → On-Premise Zone 1 Private link - inferred
On-Premise Zone → Internal Zone 1 Private link - inferred

04 Prioritized Threats

Risks are prioritized by severity tier (Critical → Low) and CVSS score within each tier. Ratings represent base technical severity prior to control effectiveness adjustments.

Assessment Methodology
  • Severity reflects potential impact assuming successful exploitation, not observed incidents.
  • Likelihood ratings are derived from observed exposure patterns and common threat behaviors, not from incident frequency data.
  • Scores represent base technical severity and do not reflect environmental or compensating controls.
RISK-002
STRIDE
CRITICAL

DMZ-to-Internal Service Impersonation Due to Missing S2S Identity

An external attacker who gains a foothold in the DMZ can impersonate the API Gateway when calling the API Layer because the gateway→API service identity (mTLS/JWT) is not documented. The attacker forges internal requests that appear “from gateway” to reach Orchestration and session-dependent APIs.

Api Gateway (Finassist Ingress)Api LayerOrchestration Layer
Business Impactcritical
Impersonated internal traffic can bypass edge controls (WAF/rate limits), enabling unauthorized access to PII/financial workflows and fraud actions. Incident may trigger GDPR breach assessment and DORA-critical service disruption reporting obligations.
LikelihoodHigh
Base HIGH because service-to-service auth is explicitly “not documented”; only edge controls are mentioned, and no strong preventive identity binding is evidenced for TB2.
CVSS Score
9.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 14
Recommended Controls
  • Enforce mTLS with SPIFFE/SPIRE or cloud workload identity between API Gateway and API Layer; reject non-mTLS traffic at service mesh/ingress.
  • Authorize gateway identity explicitly (audience/issuer/service ID) at API Layer; do not rely on forwarded user tokens alone.
  • Implement per-hop request signing (detached JWS) with short TTL and nonce to prevent internal replay/forgery.
Remediation Steps
  1. Enforce mTLS per hop with verified workload identity (SPIFFE/SAN allowlist).
  2. Require signed requests with nonce/expiry; reject unsigned or stale messages.
  3. Authorize gateway service ID at API Layer; ignore client-asserted identity.
RISK-005
STRIDE
CRITICAL

Azure OpenAI API Key Theft Enables Unauthorized LLM Usage and Data Exposure

An external attacker or malicious insider steals the Azure OpenAI API key (key lifecycle/scoping not documented) from configs, CI/CD, or logs. The attacker then impersonates the Orchestration Layer to send prompts containing stolen PII or to exfiltrate model outputs, consuming quota and bypassing business logic controls.

Orchestration LayerAzure Openai Service
Business Impactcritical
Impersonated LLM usage can leak sensitive prompts/outputs and drive unbounded cost spikes; it also creates regulatory exposure if PII is sent to third-party processing without controls. DORA incident handling may apply due to critical third-party dependence misuse.
LikelihoodHigh
Base HIGH because API keys are explicitly used and key management is flagged as undocumented; TLS helps against sniffing in transit but keys often leak via CI/CD, logs, or environment variables without strong controls.
CVSS Score
9.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 14
Recommended Controls
  • Replace static API keys with managed identity/OAuth where supported; otherwise store keys in a secrets manager with strict RBAC and just-in-time retrieval.
  • Scope keys per environment and per function; apply egress allowlisting so only Orchestration nodes can reach Azure OpenAI endpoints.
  • Implement key rotation with automated revocation, and alert on anomalous prompt volume, source IP, or usage outside normal patterns.
Remediation Steps
  1. Replace API keys with managed identity/OAuth; otherwise store keys in secrets manager.
  2. Scope keys per environment; restrict egress so only Orchestration reaches OpenAI endpoints.
  3. Rotate/revoke keys; alert on anomalous usage volume, region, and source identity.
RISK-009
STRIDE
CRITICAL

Partner API Key Replay Enables Aggregator Impersonation and Consent Abuse

An attacker who steals or guesses a partner API key can replay it against Partner Widget Integrations because API keys are weaker than OAuth and are not bound to mTLS/JWT. They can impersonate a licensed aggregator and access partner-only functions or data beyond the user’s consent scope.

Third-Party Financial Aggregators (Psd2 Licensed)Partner Widget IntegrationsPartner Integration Logging Store
Business Impactcritical
Unauthorized partner access can expose customer-linked data, break PSD2 consent assumptions, and create regulatory exposure. Incident response requires partner key rotation and possible suspension of integrations; reputational and contractual penalties are likely.
LikelihoodHigh
Base HIGH because TB1 explicitly warns that partner API keys are weaker and replayable if not bound to stronger mechanisms; no compensating controls beyond IP allowlisting are described.
CVSS Score
9.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 9Art. 14
Recommended Controls
  • Replace partner API keys with OAuth2 client credentials + mTLS (RFC 8705) so partner identity is cryptographically bound to a certificate.
  • If API keys remain, implement request signing (HMAC with nonce/timestamp), strict replay detection, and per-partner scoped permissions.
  • Add automated partner key rotation and anomaly detection on partner traffic (unexpected IPs, spikes, endpoint misuse), with rapid disablement workflows.
Remediation Steps
  1. Replace partner keys with OAuth2 client credentials and mTLS-bound client authentication.
  2. If keys remain, require signed requests with nonce/timestamp and replay detection.
  3. Scope partner permissions per client; rotate keys and disable on anomalous traffic.
RISK-013
STRIDE
CRITICAL

Hybrid Fallback LLM Impersonation Over ExpressRoute Breaks Trust Boundary

An attacker in the on-prem environment or along misconfigured hybrid routing impersonates the fallback LLM endpoint because the ExpressRoute flow lacks documented encryption/auth. Orchestration may accept responses as “trusted on-prem model output,” enabling identity misrepresentation and malicious completions under a trusted path.

Orchestration LayerAzure ExpressrouteOn-Premise Gpu Cluster (Fallback Llm)
Business Impactcritical
Spoofed fallback LLM can produce harmful or fraudulent guidance to customers and can leak PII/financial data through manipulated outputs. This undermines customer trust and can prompt reportable incidents due to critical service integrity failures (DORA) and GDPR impact.
LikelihoodHigh
Base HIGH because the boundary explicitly states auth/encryption are “not documented” and ExpressRoute does not guarantee encryption; no strong preventive controls are evidenced for TB8.
CVSS Score
9.0CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 5Art. 8Art. 9
Recommended Controls
  • Implement mTLS end-to-end over the ExpressRoute path with strict certificate pinning/allowlisting of fallback LLM service identity.
  • Add request/response signing (JWS) with nonce and expiry to prevent spoofed responses and replay across the hybrid boundary.
  • Apply consistent policy enforcement on fallback path (same response filtering, logging, and DLP) with explicit deny-by-default routing.
Remediation Steps
  1. Deploy end-to-end mTLS on hybrid link; pin fallback LLM certificates and identities.
  2. Sign requests and responses with nonce/expiry; reject unsigned or replayed messages.
  3. Enforce identical response policies and logging on fallback; deny-by-default routing.
RISK-015
STRIDE
CRITICAL

Indirect Prompt Injection via RAG Documents Spoofs Bank Policy Guidance

A malicious insider or compromised pipeline injects a RAG document that imitates official bank procedures (“reset MFA by collecting OTP in chat”). When retrieved, the LLM treats it as authoritative source and outputs spoofed guidance under the bank’s identity, bypassing normal policy controls.

Rag Source Documents StorageOrchestration LayerAzure Openai ServiceRetail Banking Customers
Business Impactcritical
Customers could be induced to share OTPs and PII, enabling fraud and high-impact complaints. The bank may face GDPR exposure due to resulting unauthorized access and must remediate content supply chain issues impacting a regulated customer channel.
LikelihoodMedium
Base HIGH because RAG poisoning is plausible when document ingestion controls are weak; reduced to MEDIUM since the architecture at least separates RAG storage and uses response filtering, though no source verification is described.
CVSS Score
9.0CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
MITRE ATLAS (AI/ML)
DORA Compliance
Art. 5Art. 8Art. 9
Recommended Controls
  • Implement signed/attested RAG ingestion: only accept documents from approved pipelines; verify signatures and provenance before indexing.
  • Use retrieval allowlists and rank/threshold controls; require multiple corroborating sources for policy-like answers.
  • Add content scanning to detect instruction-like prompt injection patterns in documents and quarantine suspicious content.
Remediation Steps
  1. Require signed/provenanced ingestion; verify document origin before indexing into RAG.
  2. Scan documents for instruction-like injections; quarantine and review suspicious content.
  3. Apply retrieval allowlists and multi-source corroboration for policy and authentication guidance.
RISK-007
STRIDE
HIGH

RAG/Vector Index Tampering Poisons Retrieval Integrity

An attacker steals the Pinecone API key (rotation/scoping not described) and inserts or modifies vectors/metadata in the US-East index. Queries then retrieve attacker-chosen documents, enabling deceptive answers and identity misuse (e.g., fake support instructions) despite correct user auth.

Orchestration LayerPinecone Vector Db ServiceResponse Filtering
Business Impacthigh
Corrupted retrieval can systematically mislead customers, causing financial harm and regulatory complaints. If poisoned content drives unauthorized actions, incident handling may require DORA operational disruption reporting and GDPR assessment if PII-linked embeddings are affected.
LikelihoodHigh
Base HIGH because API-key access to a critical knowledge component enables direct tampering; no strong preventive controls are documented for key scoping, rotation, tenant isolation assurances, or private connectivity at TB4.
CVSS Score
8.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
MITRE ATLAS (AI/ML)
DORA Compliance
Art. 8Art. 14
Recommended Controls
  • Use separate Pinecone projects/indices per environment and per tenant where applicable; enforce least-privilege API keys (read-only for query paths, write-only for ingestion).
  • Add integrity controls to RAG: signed document manifests and retrieval allowlists; alert on sudden shifts in top-k results or spikes in upserts/deletes.
  • Restrict network egress so only the ingestion/Orchestration identities can access Pinecone endpoints, and require private connectivity options where available.
Remediation Steps
  1. Scope Pinecone keys (read vs write) and rotate regularly.
  2. Require signed ingestion manifests; verify before upserts/deletes.
  3. Egress-allowlist Pinecone endpoints; alert on anomalous upsert/delete spikes.
RISK-010
STRIDE
HIGH

SMS Gateway API Key Compromise Enables OTP Spoofing and ATO

A criminal attacker obtains the SMS Gateway API key (controls not documented) and impersonates the bank’s OTP sender to trigger or reroute OTP delivery. Combined with SIM-swap/social engineering, the attacker can complete MFA flows or fraud recovery steps, appearing as legitimate authentication activity.

Orchestration LayerSms GatewayRetail Banking Customers
Business Impacthigh
OTP spoofing can directly enable account takeover and monetary fraud, increasing reimbursement/chargeback costs and call-center load. It also creates audit and compliance exposure for weak MFA delivery controls and could trigger major incident processes under DORA.
LikelihoodHigh
Base HIGH because SMS OTP has systemic interception risks and API key protections are explicitly not described; no request signing/mTLS/allowlisting is evidenced on TB6.
CVSS Score
8.4CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 10Art. 14
Recommended Controls
  • Add sender-constrained authentication to the SMS provider API (mTLS + signed requests with nonce/timestamp) and enforce strict IP allowlisting.
  • Implement risk-based OTP policies: velocity limits, device binding, and step-up verification for high-risk actions beyond SMS.
  • Continuously rotate and scope SMS API keys per environment and per function; alert on anomalous OTP volume and destination changes.
Remediation Steps
  1. Use mTLS and signed requests with nonce/timestamp for SMS API authentication.
  2. Rotate and scope SMS API keys; restrict caller IPs and egress identities.
  3. Add risk-based OTP controls and step-up authentication for high-risk actions.
RISK-006
STRIDE
HIGH

Pinecone API Key Abuse Enables Unauthorized Vector Queries and Cost/Privacy Impact

An attacker steals the Pinecone API key (rotation/scoping not described) and impersonates the Orchestration Layer to run similarity searches and enumerate embeddings/metadata. The attacker uses this to infer user topics or link embeddings to individuals, while consuming service quotas and bypassing in-app access gates.

Orchestration LayerPinecone Vector Db Service
Business Impacthigh
Unauthorized vector queries can reveal sensitive inferred attributes and facilitate reconstruction/linkage attacks on “anonymized” datasets; GDPR exposure is high due to cross-border processing and personal data inference. Cost and availability impact from abusive query volume is likely.
LikelihoodHigh
Base HIGH because API key auth is explicitly stated and key controls are flagged as missing; no private connectivity or tenant isolation assurances are mentioned in the boundary risks.
CVSS Score
8.2CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 9Art. 14
Recommended Controls
  • Use private connectivity (where available) and strict egress controls so only Orchestration can reach Pinecone; deny public internet access paths.
  • Implement least-privilege API keys per index/namespace with tight rate limits and quotas; rotate keys automatically.
  • Add query auditing with entity attribution (service identity, request ID) and anomaly detection for bulk enumeration patterns.
Remediation Steps
  1. Restrict access via private connectivity and strict egress allowlists to Pinecone endpoints.
  2. Use least-privilege keys per namespace/index; enforce quotas, rate limits, and rotation.
  3. Audit all queries with service identity; alert on bulk enumeration and abnormal patterns.
RISK-001
STRIDE
HIGH

Edge Identity Header Spoofing/Tampering Enables User Impersonation

An external attacker crafts requests that spoof forwarded identity headers because the design relies on “pre-authenticated token forwarded (encrypted headers)” but header protection/validation is underspecified. If the gateway trusts these headers, the attacker can impersonate users or escalate roles without valid OIDC context.

Retail Banking CustomersAzure Front Door With WafApi Gateway (Finassist Ingress)
Business Impacthigh
Account takeover-style impersonation enables unauthorized access to customer PII and financial context used by the assistant. This can drive fraudulent actions, GDPR Article 33 notification risk, and reputational loss due to “AI assistant accessing accounts.”
LikelihoodMedium
Base HIGH for common header-spoofing patterns, reduced to MEDIUM because the edge uses TLS 1.3 and WAF, which may block some injection but does not guarantee header origin binding.
CVSS Score
7.5CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 14
Recommended Controls
  • Use standard OIDC token transmission (Authorization: Bearer) end-to-end; avoid custom identity headers unless cryptographically signed.
  • If headers must be used, sign and encrypt them (JWE/JWS) with strict issuer validation at gateway; drop inbound client-supplied versions.
  • Add explicit allowlist of trusted proxy IPs and enforce 'forwarded header' sanitation at Front Door and gateway.
Remediation Steps
  1. Reject client-supplied identity headers; only accept headers added by trusted proxy.
  2. Use OIDC Bearer tokens end-to-end; validate iss/aud/exp and signatures.
  3. Sanitize forwarded headers and enforce trusted proxy allowlist at ingress.
RISK-003
STRIDE
HIGH

Internal/Hyrbid Traffic Sniffing Captures Tokens and Enables Replay

An attacker with on-prem foothold forges service identity across the ExpressRoute fallback path because authentication/encryption are “not documented.” They impersonate the on-prem LLM service to inject malicious responses or steal prompt context, bypassing cloud-side policy and monitoring expectations.

Orchestration LayerAzure ExpressrouteOn-Premise Gpu Cluster (Fallback Llm)
Business Impacthigh
Compromise of the fallback path can lead to unauthorized access to prompts containing PII/financial data and corrupted responses delivered to customers. Hybrid breach can expand blast radius across cloud and on-prem, raising DORA resilience concerns.
LikelihoodHigh
Base HIGH because the boundary explicitly states ExpressRoute does not guarantee encryption and auth is not documented; no strong controls are evidenced on this path to reduce likelihood.
CVSS Score
7.5CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 5Art. 8Art. 9
Recommended Controls
  • Enforce mTLS with mutual certificate authentication between Orchestration Layer and on-prem LLM endpoints; validate service identity and pin to expected SANs.
  • Encrypt application-layer payloads end-to-end (not just private transport) and include request/response signing to detect tampering across the hybrid link.
  • Ensure the fallback path applies the same response filtering, telemetry, and access controls as the primary cloud LLM path; block bypass routing.
Remediation Steps
  1. Enforce mTLS and request/response signing on the hybrid LLM path.
  2. Prohibit plaintext internal traffic; validate cert SAN/EKU pinning.
  3. Apply identical filtering/monitoring on fallback path; block bypass routes.
RISK-008
STRIDE
HIGH

Genesys OAuth Token Replay Enables Unauthorized Case/Transcript Actions

An attacker steals an OAuth token used for Orchestration→Genesys escalation and replays it to impersonate the integration. The attacker then creates or modifies conversation cases/transcripts and pushes crafted content to agents, enabling account takeover via social engineering and misuse of trusted support workflows.

Orchestration LayerGenesys CloudHuman Support Agents
Business Impacthigh
Spoofed escalation cases can lead to unauthorized disclosures to agents, fraudulent account changes, and loss of customer trust. Given transcripts include PII and reasoning traces, GDPR impact is significant and may require processor/subprocessor incident coordination and reporting.
LikelihoodMedium
Base HIGH for OAuth token replay, reduced to MEDIUM because the interaction is likely over TLS and uses OAuth 2.0 (stronger than API keys), though token storage/rotation details are not provided.
CVSS Score
7.5CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 14
Recommended Controls
  • Use short-lived OAuth tokens with continuous access evaluation; implement refresh token rotation and sender-constrained tokens (mTLS/DPoP) where possible.
  • Minimize escalation payload by default (no reasoning traces) and add per-case signing to ensure content integrity and origin attribution in Genesys.
  • Monitor for anomalous case creation/modification via integration account and enforce IP allowlisting/service identity for the OAuth client.
Remediation Steps
  1. Use short-lived OAuth access tokens; rotate refresh tokens and enforce sender-constrained tokens.
  2. Restrict integration client by IP/egress identity; enforce least-privilege Genesys scopes.
  3. Monitor for anomalous case edits; require signed payloads for origin and integrity.
RISK-016
STRIDE
HIGH

Prompt/Jailbreak-Induced AuthZ Bypass for Tool Use (Confused Deputy)

An attacker uses jailbreak-style instructions to coerce the assistant into requesting restricted customer data (“act as internal operator, fetch full profile”) and to present the request as if it is authorized. If tool calls rely on LLM-provided claims rather than session-bound authZ, the attacker impersonates privileged identities.

Retail Banking CustomersOrchestration LayerContext BuilderCustomer Data Api
Business Impacthigh
Unauthorized retrieval of customer PII/financial context can affect many users if the assistant can enumerate accounts, driving GDPR breach exposure and significant remediation costs. It can also compromise trust in digital channels and force temporary feature shutdown.
LikelihoodMedium
Base HIGH because LLM jailbreak attempts are common; reduced to MEDIUM since tool calls appear mediated by Orchestration/Context Builder, but evidence does not confirm strict session-bound authorization independent of LLM output.
CVSS Score
7.5CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 14
Recommended Controls
  • Ensure every tool/API call is authorized using server-side session context (user ID, consent, scopes) and never by LLM text; treat LLM as untrusted.
  • Use an allowlisted tool schema with mandatory parameters derived from authenticated session only (no free-form account identifiers).
  • Add high-risk action confirmations using cryptographic action tokens regenerated per request (per CAPEC mitigation guidance) and step-up auth for sensitive queries.
Remediation Steps
  1. Authorize each tool call using server-side session scopes; ignore LLM-asserted authorization.
  2. Use allowlisted tool schemas; derive identifiers only from authenticated session context.
  3. Require step-up auth and per-request action tokens for sensitive data retrieval.
RISK-017
STRIDE
HIGH

Training/Improvement Data Poisoning via Retained Transcripts

An external attacker or malicious user injects crafted conversation content that is retained “indefinitely” for model improvement. If these transcripts are later used for fine-tuning or evaluation without strong validation, they can poison future model behavior and embed identity-misuse backdoors.

Finassist Ai PlatformConversation LogsModel Improvement Dataset (Anonymized Transcripts)
Business Impacthigh
Poisoned model updates can degrade advice quality across the customer base, creating financial harm and large operational remediation costs. GDPR risk increases if “anonymized” data is later found re-identifiable or used beyond purpose limitation.
LikelihoodHigh
Base HIGH because the evidence explicitly notes indefinite retention for model improvement and weak anonymization assurances; no mitigations (data validation pipelines, provenance checks) are documented to reduce likelihood.
CVSS Score
7.5CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
MITRE ATLAS (AI/ML)
DORA Compliance
Art. 11Art. 12Art. 14
Recommended Controls
  • Gate any training/fine-tuning data with provenance checks, automated toxicity/backdoor scans, and human review for high-impact examples before inclusion.
  • Separate user-generated transcripts from training corpora by default; require explicit allowlisting and sampling to limit attacker influence.
  • Implement retention limits and DSAR/erasure support for transcripts; document the legal basis and purpose limitation for any model-improvement usage.
Remediation Steps
  1. Implement provenance and validation gates for any training/eval dataset inclusion.
  2. Separate user transcripts from training by default; require explicit allowlisting.
  3. Apply retention limits and deletion workflows for model-improvement data.
RISK-014
STRIDE
HIGH

LLM Direct Prompt Injection Drives Identity/Role Impersonation and Phishing

A malicious user crafts prompts that cause the LLM to claim it is a bank employee/system agent and to request credentials or OTPs, bypassing intended identity boundaries. Without strong role separation and policy checks independent of model output, the assistant can be manipulated into “acting as trusted support.”

Retail Banking CustomersApi Gateway (Finassist Ingress)Orchestration LayerAzure Openai Service
Business Impacthigh
Customers may disclose passwords/OTP/PII to the assistant, causing account takeover and fraud. This creates reputational damage (“bank chatbot phished me”) and increases regulatory scrutiny for inadequate customer authentication and secure communications controls.
LikelihoodHigh
Base HIGH because prompt-based social engineering is easy to attempt; response filtering is present but its ability to prevent role-impersonation prompts is not evidenced and can be bypassed without deterministic policy gating.
CVSS Score
7.4CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 5Art. 6Art. 8
Recommended Controls
  • Enforce deterministic policy: never request secrets/OTPs in any channel; block and template safe responses regardless of model output.
  • Add jailbreak/prompt-injection detection with allowlisted intents and structured outputs; separate system instructions from user content with strict tooling.
  • Display strong user-facing identity assurances and out-of-band verification for sensitive actions (confirm in authenticated app, not chat).
Remediation Steps
  1. Enforce hard rule: never request credentials/OTPs; override model output with templates.
  2. Detect prompt-injection/jailbreak patterns; use allowlisted intents and structured outputs.
  3. Require out-of-band verification in authenticated app for sensitive actions and disclosures.
RISK-004
STRIDE
HIGH

Session Store Hijack/Fixation via Weak Binding and Replay

A compromised internal workload impersonates Orchestration when calling the Session Store because internal auth is “inferred” and not documented. The attacker reads or overwrites session identifiers to hijack active user conversations, then uses those sessions to interact with downstream customer-data and support flows as the victim.

Orchestration LayerSession Store
Business Impacthigh
Hijacked sessions can expose customer PII and sensitive conversation history and can enable fraudulent actions initiated through the assistant channel. This increases GDPR breach risk and can drive call-center fraud costs and customer remediation overhead.
LikelihoodMedium
Base HIGH due to undocumented internal auth on a critical session component, reduced to MEDIUM because Kubernetes Network Policies are present (segmentation) but do not prove identity/auth at the datastore API.
CVSS Score
7.1CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 9
Recommended Controls
  • Require mTLS + workload identity (service account/managed identity) for Session Store access; enforce ACLs per service identity.
  • Encrypt and MAC-protect session blobs; use rotating session secrets and bind sessions to device/client attributes (risk-based checks).
  • Add session anomaly detection (IP/device/UA drift) and forced re-authentication before sensitive actions.
Remediation Steps
  1. Require mTLS and per-service identity to access Session Store; deny unauthenticated calls.
  2. MAC-protect session records; rotate signing keys and invalidate on suspicious changes.
  3. Detect session anomalies; force re-authentication before privileged or risky actions.
RISK-012
STRIDE
MEDIUM

mTLS Certificate Theft/Forgery Enables Service Identity Takeover (CRM/Fraud)

An attacker who compromises a workload node steals the mTLS client certificate/private key used for “mTLS + JWT (documented)” calls to Internal CRM. They then authenticate as the Orchestration service to CRM APIs, bypassing normal checks and acting under a trusted service identity.

Orchestration LayerInternal Crm
Business Impactmedium
Impersonation of the Orchestration Layer can expose or alter CRM records and escalations, impacting many customers and creating regulatory exposure. If CRM contains PII, unauthorized access may necessitate GDPR reporting and costly remediation.
LikelihoodMedium
Base MEDIUM because certificate theft requires host/pod compromise; evidence confirms mTLS is used (valuable target) but does not describe HSM-backed keys, rotation, or key protections that would strongly reduce feasibility.
CVSS Score
6.8CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 6Art. 8Art. 14
Recommended Controls
  • Store private keys in managed HSM/Key Vault-backed identities where possible; avoid exportable keys in containers and disable filesystem persistence of cert material.
  • Rotate client certificates frequently and bind them to workload identity (SPIFFE) with short-lived SVIDs; revoke on compromise signals.
  • Add service authorization on CRM: verify both mTLS identity and JWT claims (aud/scopes) and enforce least-privilege service roles for Orchestration.
Remediation Steps
  1. Use non-exportable keys (HSM/managed identity) instead of container-stored certs.
  2. Rotate/revoke certificates frequently; prefer short-lived workload SVIDs.
  3. Require JWT scopes in addition to mTLS; enforce least-privilege CRM roles.
RISK-018
STRIDE
MEDIUM

Conversation/Inference Logging Gaps Enable Repudiation and Evidence Tampering

An attacker uses jailbreak-style instructions to coerce the assistant into requesting restricted customer data (“act as internal operator, fetch full profile”) and to present the request as if it is authorized. If tool calls rely on LLM-provided claims rather than session-bound authZ, the attacker impersonates privileged identities.

Retail Banking CustomersOrchestration LayerContext BuilderCustomer Data Api
Business Impactmedium
Unauthorized retrieval of customer PII/financial context can affect many users if the assistant can enumerate accounts, driving GDPR breach exposure and significant remediation costs. It can also compromise trust in digital channels and force temporary feature shutdown.
LikelihoodMedium
Base HIGH because LLM jailbreak attempts are common; reduced to MEDIUM since tool calls appear mediated by Orchestration/Context Builder, but evidence does not confirm strict session-bound authorization independent of LLM output.
CVSS Score
6.8CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
MITRE ATT&CK Techniques
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 9Art. 14
Recommended Controls
  • Ensure every tool/API call is authorized using server-side session context (user ID, consent, scopes) and never by LLM text; treat LLM as untrusted.
  • Use an allowlisted tool schema with mandatory parameters derived from authenticated session only (no free-form account identifiers).
  • Add high-risk action confirmations using cryptographic action tokens regenerated per request (per CAPEC mitigation guidance) and step-up auth for sensitive queries.
Remediation Steps
  1. Use append-only/WORM storage and hash chaining for conversation/audit logs.
  2. Audit all log reads/exports/deletes; restrict access with least privilege.
  3. Perform near-real-time redaction and enforce GDPR-aligned retention workflows.
RISK-011
STRIDE
MEDIUM

Datadog Ingestion Key Abuse Enables Telemetry Spoofing and Monitoring Blindness

An attacker obtains Datadog ingestion credentials (auth method “not documented”) and submits fabricated traces/logs to conceal session hijacking or token replay activity. By tampering with telemetry, they reduce detection probability while maintaining unauthorized access paths.

Finassist Ai PlatformDatadog ApmSecurity Operations (Soc)
Business Impactmedium
Reduced detection can extend attacker dwell time, increasing the scope of account compromise and compliance impact. False telemetry can mislead incident response and delay containment, raising operational risk and potential DORA reporting exposure for prolonged incidents.
LikelihoodMedium
Base MEDIUM because it requires access to ingestion credentials; evidence explicitly notes “telemetry controls not documented,” so there is no strong preventive control described to reduce likelihood.
CVSS Score
6.5CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
MITRE ATT&CK Techniques
CWE Weaknesses
CAPEC Attack Patterns
DORA Compliance
Art. 8Art. 9Art. 14
Recommended Controls
  • Use separate, least-privilege ingestion keys per environment/service and rotate regularly; store only in a secrets manager and block use from non-allowlisted egress IPs.
  • Enable integrity validation for telemetry pipelines: signed logs or authenticated forwarding (agent-based) rather than direct public ingestion from arbitrary sources.
  • Add SOC detections for gaps: alert on missing expected telemetry, anomalous spikes, and inconsistency between Azure Monitor and Datadog signals.
Remediation Steps
  1. Use per-service ingestion keys; rotate and restrict usage to allowlisted egress.
  2. Ingest via authenticated agents; block direct public ingestion endpoints.
  3. Alert on telemetry gaps and inconsistencies across monitoring sources.

06 Component Inventory

System components organized by trust zone with associated risk exposure. Click column headers to sort.

Component Type Trust Zone Attack Surface Related Risks
⚙️ Human Support Agents Component Internet Zone CRITICAL
⚙️ Security Operations - SOC Component Internet Zone CRITICAL
⚙️ Azure Front Door with WAF Component DMZ Zone CRITICAL
⚙️ API Gateway (FinAssist Ingress) Component DMZ Zone CRITICAL
⚙️ API Layer Component Internal Zone CRITICAL
⚙️ Orchestration Layer Component Internal Zone CRITICAL
⚙️ Bank Identity Provider Component Internal Zone CRITICAL
⚙️ Customer Data API Component Internal Zone CRITICAL
⚙️ Internal CRM Component Internal Zone CRITICAL
⚙️ Fraud Detection API Component Internal Zone CRITICAL
⚙️ Azure ExpressRoute Component Internal Zone CRITICAL
🗄️ Session Store Datastore Data Zone CRITICAL
🗄️ Conversation Logs Datastore Data Zone CRITICAL
🗄️ Model Improvement Dataset - Anonymized Transcripts Datastore Data Zone CRITICAL
🗄️ Partner Integration Logging Store Datastore Data Zone CRITICAL
⚙️ Azure OpenAI Service Component Third Party Zone CRITICAL
⚙️ Azure OpenAI Embeddings Model Component Third Party Zone CRITICAL
⚙️ Pinecone Vector DB Service Component Third Party Zone CRITICAL
⚙️ SMS Gateway Component Third Party Zone CRITICAL
⚙️ Azure Monitor Component Third Party Zone CRITICAL
⚙️ Retail Banking Customers Component Internet Zone HIGH
⚙️ Unauthenticated Users Component Internet Zone HIGH
⚙️ Third-party Application Users Component Internet Zone HIGH
⚙️ Third-party Financial Aggregators - PSD2 licensed Component Internet Zone HIGH
⚙️ Partner Widget Integrations Component DMZ Zone HIGH
⚙️ Context Builder Component Internal Zone HIGH
⚙️ Response Filtering Component Internal Zone HIGH
🗄️ RAG Source Documents Storage Datastore Data Zone HIGH
⚙️ Genesys Cloud Component Third Party Zone HIGH
⚙️ Datadog APM Component Third Party Zone MEDIUM
⚙️ Azure DevOps CI-CD Component Third Party Zone MEDIUM

08 Remediation Roadmap

Prioritized remediation plan for critical and high severity findings with recommended controls.

Risk Finding & Recommended Control Severity Timeline
RISK-002
DMZ-to-Internal Service Impersonation Due to Missing S2S Identity
Enforce mTLS with SPIFFE/SPIRE or cloud workload identity between API Gateway and API Layer; reject non-mTLS traffic at service mesh/ingress.
CRITICAL Immediate (0-30 days)
RISK-005
Azure OpenAI API Key Theft Enables Unauthorized LLM Usage and Data Exposure
Replace static API keys with managed identity/OAuth where supported; otherwise store keys in a secrets manager with strict RBAC and just-in-time retrieval.
CRITICAL Immediate (0-30 days)
RISK-009
Partner API Key Replay Enables Aggregator Impersonation and Consent Abuse
Replace partner API keys with OAuth2 client credentials + mTLS (RFC 8705) so partner identity is cryptographically bound to a certificate.
CRITICAL Immediate (0-30 days)
RISK-013
Hybrid Fallback LLM Impersonation Over ExpressRoute Breaks Trust Boundary
Implement mTLS end-to-end over the ExpressRoute path with strict certificate pinning/allowlisting of fallback LLM service identity.
CRITICAL Immediate (0-30 days)
RISK-015
Indirect Prompt Injection via RAG Documents Spoofs Bank Policy Guidance
Implement signed/attested RAG ingestion: only accept documents from approved pipelines; verify signatures and provenance before indexing.
CRITICAL Immediate (0-30 days)
RISK-001
Edge Identity Header Spoofing/Tampering Enables User Impersonation
Use standard OIDC token transmission (Authorization: Bearer) end-to-end; avoid custom identity headers unless cryptographically signed.
HIGH Near-term (30-90 days)
RISK-003
Internal/Hyrbid Traffic Sniffing Captures Tokens and Enables Replay
Enforce mTLS with mutual certificate authentication between Orchestration Layer and on-prem LLM endpoints; validate service identity and pin to expected SANs.
HIGH Near-term (30-90 days)
RISK-004
Session Store Hijack/Fixation via Weak Binding and Replay
Require mTLS + workload identity (service account/managed identity) for Session Store access; enforce ACLs per service identity.
HIGH Near-term (30-90 days)
RISK-006
Pinecone API Key Abuse Enables Unauthorized Vector Queries and Cost/Privacy Impact
Use private connectivity (where available) and strict egress controls so only Orchestration can reach Pinecone; deny public internet access paths.
HIGH Near-term (30-90 days)
RISK-007
RAG/Vector Index Tampering Poisons Retrieval Integrity
Use separate Pinecone projects/indices per environment and per tenant where applicable; enforce least-privilege API keys (read-only for query paths, write-only for ingestion).
HIGH Near-term (30-90 days)

Timeline: Immediate (0-30 days) | Near-term (30-90 days) | Strategic (>90 days)

This section documents the scope, basis, methodology, and limitations of this threat assessment to ensure clarity for audit, compliance, and governance purposes.

A.1 Scope of Assessment

Consolidated STRIDE threat modeling outputs focused on identity, secrets, session/token handling, hybrid connectivity, and LLM/RAG integrity across a multi-provider banking assistant platform.

Components in Scope

20 components were analyzed as part of this assessment. See Component Inventory for the complete list with trust zone assignments.

Trust Zones Analyzed
DMZ ZoneData ZoneInternal ZoneInternet ZoneOn-Premise ZoneThird-Party Zone

A.2 Basis of Analysis

This assessment is based on the following input artifacts and data sources:

Input Artifact Status / Description
Data Flow Diagram (DFD) System architecture with trust boundaries
Architecture Documentation System description and component overview
Threat Analysis 18 risks identified via STRIDE analysis
MITRE ATT&CK Mapping Threat-to-technique correlation

No additional documentation or stakeholder interviews were provided beyond the artifacts listed above.

A.3 Methodology Statement

This assessment applies the STRIDE threat modeling framework as defined by Microsoft. STRIDE is a widely adopted industry framework for architectural threat modeling, particularly for distributed and cloud-native systems. Threats are systematically analyzed across six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Severity Rating: Risk severity is determined using CVSS v3.1 base scores aligned to standard severity bands (Critical ≥9.0, High 7.0-8.9, Medium 4.0-6.9, Low <4.0). See Appendix C: Severity Rating Methodology for details.

Risk Prioritization: Beyond CVSS scoring, risks are prioritized based on business context, threat consolidation (merged related threats), and attack surface exposure. Risks with CVSS ≥8.5 may be elevated to Critical when composite factors indicate systemic risk.

Threat Intelligence: Identified threats are mapped to MITRE ATT&CK techniques, MITRE ATLAS (AI/ML threats), CAPEC attack patterns, and CWE weakness categories where applicable, providing industry-standard reference points.

Compliance Alignment: Risks are mapped to applicable regulatory frameworks including DORA, NIS2, GDPR, NIST CSF, ISO 27001, PCI-DSS, and SWIFT CSCF where control requirements align with identified threats.

A.4 Assumptions

The following assumptions were made during this assessment:

  • Threat lists provided represent the authoritative set of modeled threats for the assessed architecture version.
  • Affected assets listed in the consolidated risk analysis reflect the primary components in scope for remediation prioritization.
  • External services (Azure OpenAI, Pinecone, Genesys, SMS gateway, Datadog, partners) are reachable from orchestration_layer in some capacity.
  • Customer PII and/or payment data is processed or accessible through the described workflows.
  • CVSS scores and vectors in this assessment are valid and used for prioritization.

A.5 Limitations & Disclaimers

  • Detailed threat narratives, control validation evidence, and compliance mappings were not provided as part of this assessment run.
  • No confirmed likelihood ratings, exploitability evidence, or incident history was provided.
  • No control inventory or current-state implementation evidence for identity, secrets, and logging controls was provided.
  • DORA risk-to-gap mapping was empty and must be validated before audit use.
  • No source code review, configuration review, or pen test results were provided alongside the consolidated risks.
  • This assessment evaluates design-time and architectural risks and does not replace operational testing or live incident response validation
Important: This assessment evaluates design-time and architectural risks based on available information at the time of analysis. It does not replace operational testing, penetration testing, or live incident response validation. Recommendations should be validated against current system state before implementation. This assessment does not guarantee the absence of vulnerabilities not identified herein.
Interactive explanations, expandable sections, and linked references are available in the digital version of this report.

09 Appendices

Supporting documentation, methodology details, and technical references.

Mermaid diagram source code for reference and customization. Copy and modify in any Mermaid-compatible editor (VS Code, Notion, GitHub, Mermaid Live Editor).

mermaid
flowchart TB

    subgraph Internet_Zone[INTERNET ZONE]
        A_Retail_Banking_Customers(["Retail<br/>Banking Customers"])
        A_Unauthenticated_Users(["Unauth<br/>Users"])
        A_Third_party_Application_Users(["Third-party<br/>App Users"])
        C_Third_party_Financial_Aggregators_PSD2_licensed(("PSD2 licensed<br/>Third-party…"))
        C_Human_Support_Agents(("Human<br/>Support Agents"))
        C_Security_Operations_SOC(("SOC<br/>Security Operations"))
    end

    subgraph DMZ_Zone[DMZ ZONE]
        C_Azure_Front_Door_with_WAF(("Front<br/>Door with WAF"))
        C_API_Gateway_FinAssist_Ingress(("API<br/>Gateway (FinAssist…"))
        ES_Partner_Widget_Integrations{{"Partner<br/>Widget Integrations"}}
    end

    subgraph Internal_Zone[INTERNAL ZONE]
        C_FinAssist_AI_Platform(("FinAssist<br/>AI"))
        C_API_Layer(("API<br/>Layer"))
        C_Orchestration_Layer(("Orch<br/>Layer"))
        C_Context_Builder(("Context<br/>Builder"))
        C_Response_Filtering(("Response<br/>Filtering"))
        ES_Bank_Identity_Provider{{"Bank<br/>Identity Provider"}}
        A_Customer_Data_API(["Customer<br/>Data API"])
        C_Internal_CRM(("Internal<br/>CRM"))
        C_Fraud_Detection_API(("Fraud<br/>Detect API"))
        C_Kubernetes_Network_Policies(("K8s<br/>Network Policies"))
        C_Azure_ExpressRoute(("ExpressRoute<br/>Azure"))
    end

    subgraph Data_Zone[DATA ZONE]
        DS_Session_Store[("Session<br/>Store")]
        DS_RAG_Source_Documents_Storage[("RAG<br/>Source Documents…")]
        DS_Conversation_Logs[("Conv<br/>Logs")]
        DS_Model_Improvement_Dataset_Anonymized_Transcripts[("Anonymized…<br/>Model Improvement…")]
        DS_Partner_Integration_Logging_Store[("Partner<br/>Integr Logging Store")]
    end

    subgraph Third_Party_Zone[THIRD-PARTY ZONE]
        ES_Azure_OpenAI_Service{{"OpenAI<br/>Svc"}}
        ES_Azure_OpenAI_Embeddings_Model{{"OpenAI<br/>Embeddings Model"}}
        ES_Pinecone_Vector_DB_Service{{"Pinecone<br/>Vector DB Svc"}}
        ES_Genesys_Cloud{{"Genesys<br/>Cloud"}}
        ES_SMS_Gateway{{"SMS<br/>Gateway"}}
        C_Azure_Monitor(("Monitor<br/>Azure"))
        C_Datadog_APM(("Datadog<br/>APM"))
        C_Azure_DevOps_CI_CD(("DevOps<br/>CI-CD"))
    end

    subgraph On_Premise_Zone[ON-PREMISE ZONE]
        ES_On_premise_GPU_Cluster_Fallback_LLM{{"On-premise<br/>GPU Cluster…"}}
    end

    %% Data Flows
    A_Retail_Banking_Customers -->|HTTPS-TLS1_3| C_Azure_Front_Door_with_WAF
    C_Azure_Front_Door_with_WAF -->|HTTPS-TLS1_3| C_API_Gateway_FinAssist_Ingress
    C_API_Gateway_FinAssist_Ingress -->|Internal RPC - inferred| C_API_Layer
    C_API_Layer -->|Internal RPC - inferred| C_Orchestration_Layer
    C_Orchestration_Layer -->|REST-HTTPS - assumed| ES_Bank_Identity_Provider
    ES_Bank_Identity_Provider -->|REST-HTTPS - assumed| C_Orchestration_Layer
    A_Unauthenticated_Users -->|HTTPS-TLS1_3| C_Azure_Front_Door_with_WAF
    C_Third_party_Financial_Aggregators_PSD2_licensed -->|HTTPS - assumed| ES_Partner_Widget_Integrations
    ES_Partner_Widget_Integrations -->|Internal RPC - inferred| DS_Partner_Integration_Logging_Store
    C_Orchestration_Layer -->|Internal RPC - inferred| DS_Session_Store
    DS_Session_Store -->|Internal RPC - inferred| C_Orchestration_Layer
    C_Context_Builder -->|REST-HTTPS - assumed| A_Customer_Data_API
    A_Customer_Data_API -->|REST-HTTPS - assumed| C_Context_Builder
    C_Orchestration_Layer -->|mTLS + JWT - documented| C_Internal_CRM
    C_Internal_CRM -->|mTLS + JWT - documented| C_Orchestration_Layer
    C_Orchestration_Layer -->|mTLS - documented| C_Fraud_Detection_API
    C_Fraud_Detection_API -->|mTLS - documented| C_Orchestration_Layer
    C_Orchestration_Layer -->|REST-HTTPS - assumed| ES_Azure_OpenAI_Service
    ES_Azure_OpenAI_Service -->|REST-HTTPS - assumed| C_Orchestration_Layer
    C_Orchestration_Layer -->|REST-HTTPS - assumed| ES_Azure_OpenAI_Embeddings_Model
    ES_Azure_OpenAI_Embeddings_Model -->|REST-HTTPS - assumed| C_Orchestration_Layer
    C_Orchestration_Layer -->|REST-HTTPS - assumed| ES_Pinecone_Vector_DB_Service
    ES_Pinecone_Vector_DB_Service -->|REST-HTTPS - assumed| C_Orchestration_Layer
    C_Orchestration_Layer -->|HTTPS - assumed| DS_RAG_Source_Documents_Storage
    DS_RAG_Source_Documents_Storage -->|HTTPS - assumed| C_Orchestration_Layer
    C_Orchestration_Layer -->|Internal RPC - inferred| C_Response_Filtering
    C_Response_Filtering -->|Internal RPC - inferred| C_Orchestration_Layer
    C_FinAssist_AI_Platform -->|Internal RPC - inferred| DS_Conversation_Logs
    C_Orchestration_Layer -->|REST-HTTPS - assumed| ES_Genesys_Cloud
    ES_Genesys_Cloud -->|REST-HTTPS - assumed| C_Orchestration_Layer
    ES_Genesys_Cloud -->|SaaS UI - HTTPS - assumed| C_Human_Support_Agents
    C_Orchestration_Layer -->|REST-HTTPS - assumed| ES_SMS_Gateway
    C_FinAssist_AI_Platform -->|HTTPS - assumed| C_Azure_Monitor
    C_FinAssist_AI_Platform -->|HTTPS - assumed| C_Datadog_APM
    C_Security_Operations_SOC -->|Portal-API - unspecified| C_Azure_Monitor
    C_Security_Operations_SOC -->|Portal-API - unspecified| C_Datadog_APM
    C_Orchestration_Layer -->|Internal RPC over ExpressRoute - inferred| C_Azure_ExpressRoute
    C_Azure_ExpressRoute -->|Private link - inferred| ES_On_premise_GPU_Cluster_Fallback_LLM
    ES_On_premise_GPU_Cluster_Fallback_LLM -->|Private link - inferred| C_Azure_ExpressRoute
    C_Azure_ExpressRoute -->|Internal RPC over ExpressRoute - inferred| C_Orchestration_Layer
    C_Azure_DevOps_CI_CD -->|CI-CD pipelines - HTTPS assumed| C_FinAssist_AI_Platform

    %% Styling
    style Internet_Zone fill:rgba(220, 38, 38, 0.15),stroke:#dc2626,stroke-width:2px
    style DMZ_Zone fill:rgba(249, 115, 22, 0.15),stroke:#f97316,stroke-width:2px
    style Internal_Zone fill:rgba(59, 130, 246, 0.15),stroke:#3b82f6,stroke-width:2px
    style Data_Zone fill:rgba(34, 197, 94, 0.15),stroke:#22c55e,stroke-width:2px
    style Third_Party_Zone fill:rgba(168, 85, 247, 0.15),stroke:#a855f7,stroke-width:2px
    style On_Premise_Zone fill:rgba(59, 130, 246, 0.15),stroke:#3b82f6,stroke-width:2px
    classDef actor fill:#134e4a,stroke:#14b8a6,stroke-width:2px,color:#5eead4
    classDef process fill:#2e1065,stroke:#8b5cf6,stroke-width:2px,color:#c4b5fd
    classDef datastore fill:#14532d,stroke:#22c55e,stroke-width:2px,color:#86efac
    classDef external fill:#3b0764,stroke:#a855f7,stroke-width:2px,color:#d8b4fe
    classDef core fill:#1e1b4b,stroke:#8b5cf6,stroke-width:4px,color:#c4b5fd
    class A_Retail_Banking_Customers,A_Unauthenticated_Users,A_Third_party_Application_Users,A_Customer_Data_API actor
    class C_Third_party_Financial_Aggregators_PSD2_licensed,C_Human_Support_Agents,C_Security_Operations_SOC,C_Azure_Front_Door_with_WAF,C_API_Gateway_FinAssist_Ingress,C_FinAssist_AI_Platform,C_API_Layer,C_Orchestration_Layer,C_Context_Builder,C_Response_Filtering,C_Internal_CRM,C_Fraud_Detection_API,C_Kubernetes_Network_Policies,C_Azure_ExpressRoute,C_Azure_Monitor,C_Datadog_APM,C_Azure_DevOps_CI_CD process
    class DS_Session_Store,DS_RAG_Source_Documents_Storage,DS_Conversation_Logs,DS_Model_Improvement_Dataset_Anonymized_Transcripts,DS_Partner_Integration_Logging_Store datastore
    class ES_Partner_Widget_Integrations,ES_Bank_Identity_Provider,ES_Azure_OpenAI_Service,ES_Azure_OpenAI_Embeddings_Model,ES_Pinecone_Vector_DB_Service,ES_Genesys_Cloud,ES_SMS_Gateway,ES_On_premise_GPU_Cluster_Fallback_LLM external

This assessment uses a hybrid severity rating methodology that combines industry-standard CVSS v3.1 scoring with composite risk analysis.

Base Severity (CVSS v3.1)

Severity ratings are primarily determined by CVSS v3.1 Base Scores:

Rating CVSS Range Description Remediation Timeline
CRITICAL 9.0 – 10.0 Easily exploitable with severe impact. Requires immediate action. Immediate (0-30 days)
HIGH 7.0 – 8.9 Significant risk requiring priority remediation. Near-term (30-90 days)
MEDIUM 4.0 – 6.9 Moderate risk with exploitability or impact limitations. Planned (90-180 days)
LOW 0.1 – 3.9 Minor risk. Risk acceptance may be appropriate. Discretionary (180+ days)

Severity Elevation

In limited cases, a risk with a High CVSS score (7.0-8.9) may be elevated to Critical when composite factors indicate systemic risk. Elevated risks are marked with .

Elevation Criteria (all must apply):
  • CVSS ≥ 8.5 – Near-critical base score
  • AND one of:
    • Priority score > 90 (high composite business risk)
    • 5+ merged threats (indicates systemic vulnerability pattern)

Note: This methodology ensures severity ratings remain aligned with CVSS standards while accounting for real-world risk amplification factors such as threat consolidation and business impact assessment.