Threat Model¶

Status: Initial threat-model baseline
Scope: AI orchestration, authentication, authorization, integrations, data handling, and deployment security
Verification: Required controls must be verified against source code, automated tests, and deployed configuration before they can be considered implemented.

1. Purpose¶

This document identifies security threats affecting WhiteLotusAI and defines the mitigations, verification activities, and evidence required to manage them.

WhiteLotusAI combines AI orchestration with external integrations that may expose confidential email, calendar events, collaboration messages, documents, and issue-tracking data. This creates trust boundaries between users, application services, language models, integration clients, external providers, and persistent storage.

The initial integration phase is strictly read-only. WhiteLotusAI must not create, send, modify, delete, share, or otherwise mutate data in connected services.

This threat model establishes the security requirements for that operating model. It does not certify that the controls described here have been implemented or independently validated.

Objectives¶

• Protect user identities, credentials, provider data, and application state.
• Prevent unauthorized access and cross-user data disclosure.
• Resist prompt injection and manipulation of model-generated instructions.
• Enforce read-only restrictions across every reachable execution path.
• Prevent credential leakage and unsafe fallback behavior.
• Establish traceable security findings, remediation ownership, and verification evidence.

2. Scope and security assumptions¶

In-scope integrations¶

• Google Gmail
• Google Calendar
• Microsoft Teams
• Jira
• Google Drive
• Slack

The exact provider operations, OAuth scopes, endpoints, and execution paths must be verified against the current source code and provider configuration.

Out of scope: This document does not authorize write-capable integration features, establish a formal compliance certification, or assert that production controls have passed security testing.

3. Assets requiring protection¶

4. Trust boundaries and architecture¶

The following conceptual diagram identifies the principal trust boundaries relevant to WhiteLotusAI's security review. It is a threat-model view, not a claim that every connection or enforcement point has been verified in the deployed system.

flowchart TB
    User["Authenticated User"]
    Frontend["Web Frontend"]
    Gateway["API Gateway<br/>Authentication and request validation"]
    Orchestrator["AI Orchestrator<br/>Intent and context processing"]
    Model["Language Model<br/>Untrusted output"]
    Policy["Server-Side Policy Enforcement<br/>Identity, authorization, read-only allowlist"]
    Registry["Approved Read-Only Tool Registry"]
    Integration["Integration Services<br/>User-bound credentials"]
    Providers["External Providers<br/>Gmail, Calendar, Teams,<br/>Jira, Drive, Slack"]
    Storage[("Application Database<br/>Sessions, connections, records")]
    Logs[("Security Logs<br/>Redacted audit evidence")]

    User --> Frontend
    Frontend --> Gateway
    Gateway --> Logs
    Policy --> Logs
    Integration --> Logs
    Gateway --> Orchestrator
    Orchestrator --> Policy
    Orchestrator <--> Model
    Policy --> Registry
    Registry --> Integration
    Integration --> Providers
    Gateway --> Storage
    Integration --> Storage

    classDef identity fill:#DCEBFA,stroke:#2864A5,color:#17365D,stroke-width:1.5px
    classDef application fill:#E8E2FA,stroke:#7251A3,color:#39265F,stroke-width:1.5px
    classDef security fill:#D9F2E6,stroke:#16805D,color:#104D3A,stroke-width:2px
    classDef external fill:#FCE8D5,stroke:#B86B24,color:#663A13,stroke-width:1.5px
    classDef storage fill:#E8EDF2,stroke:#65758B,color:#263445,stroke-width:1.5px
    classDef untrusted fill:#FBE0E0,stroke:#B42318,color:#7A1711,stroke-width:2px

    class User,Frontend identity
    class Gateway,Orchestrator,Integration application
    class Policy,Registry security
    class Providers external
    class Storage,Logs storage
    class Model untrusted

    linkStyle default stroke:#8795A5,stroke-width:1.5px

Boundary analysis¶

For each boundary, the implementation review should identify the actual source modules, routes, handlers, credential flows, and enforcement points.

5. Threat register¶

The following register defines the baseline threats and the minimum expected mitigations. Severity must be assessed using the project's approved risk methodology rather than inferred solely from the order of the entries.

Threat prioritization¶

Prioritize findings using the team's approved likelihood and impact scale. Until a formal risk assessment is completed, do not assign numerical scores or label individual threats as resolved based solely on this baseline.

Give particular attention to:

• Read-only enforcement: Any reachable path that can mutate provider data.
• Authorization boundaries: Cross-user access, identity confusion, or privilege escalation.
• Credential security: Token exposure, excessive OAuth scopes, or unsafe fallback behavior.
• AI trust boundaries: Prompt injection or model-generated data influencing privileged decisions.

6. Mandatory policy: read-only enforcement¶

Read-only access is an application security requirement, not a user-interface preference.

The application must define the permitted operations explicitly and reject every operation that is not approved. This policy must remain effective even if a user manipulates a request, the model produces malicious output, or a legacy execution path is invoked directly.

Required enforcement controls¶

1. Maintain an explicit allowlist of approved read operations.
2. Deny operations by default when they are unknown, unsupported, or not explicitly approved.
3. Reject prohibited mutations before they reach provider clients.
4. Apply the policy across AI tool dispatch, HTTP endpoints, RPC handlers, workers, and reachable legacy paths.
5. Enforce authorization independently of frontend visibility and confirmation prompts.
6. Prevent model-supplied fields from overriding server-side authorization.
7. Fail closed when identity, permissions, connection ownership, or token resolution cannot be established.
8. Never silently substitute shared credentials or a less restrictive credential path.
9. Test both the denial response and the absence of provider-side execution.
10. Review provider scopes as an additional safeguard, not as a substitute for application enforcement.

Illustrative enforcement sequence¶

The following pseudocode describes the required decision flow. It is a specification example, not production implementation code.

async def authorize_tool_execution(
    principal,
    connection,
    operation,
    parameters,
):
    # 1. Reject unauthenticated or untrusted identities.
    if principal is None:
        raise AuthorizationError("Authentication required")

    # 2. Reject operations outside the approved read-only registry.
    if operation not in APPROVED_READ_OPERATIONS:
        raise AuthorizationError("Operation not permitted")

    # 3. Verify ownership and operation-level permissions.
    if not await owns_connection(principal, connection):
        raise AuthorizationError("Connection access denied")

    if not await is_authorized(principal, operation, parameters):
        raise AuthorizationError("Operation not authorized")

    # 4. Validate parameters before any provider request.
    validated = validate_operation_parameters(operation, parameters)

    # 5. Resolve credentials for this principal and connection.
    credentials = await resolve_user_bound_credentials(
        principal,
        connection,
    )

    if credentials is None:
        raise AuthorizationError("Authorized credentials unavailable")

    # Dispatch only after all applicable checks have passed.
    return await execute_approved_read(
        operation,
        validated,
        credentials,
    )

Read-only acceptance criteria¶

See Read-Only Integration Security Policy for the detailed requirements and acceptance criteria.

7. Confirmation and authorization boundaries¶

A previously identified project risk involved trusting entities["__confirmed"] from planner or language-model output.

If that value is derived from untrusted model output, it cannot establish user consent or grant permission to execute an operation.

For any future operation that legitimately requires confirmation, approval must be represented by trusted application state associated with:

• The authenticated user.
• The exact proposed operation.
• The validated operation parameters.
• A limited validity period.
• A single-use or otherwise replay-resistant approval mechanism, where appropriate.

The dispatcher must independently verify authorization and applicable policy before execution.

A confirmation flag must never override the read-only restriction. Prohibited mutation operations must be rejected regardless of the presence, value, or apparent validity of any confirmation field.

8. Additional security requirements¶

8.1 Authentication and session integrity¶

• Validate authentication tokens using the configured verification policy.
• Enforce expiration and appropriate token-validation requirements.
• Prevent untrusted request fields from replacing the authenticated principal.
• Check authorization at the relevant resource and operation boundaries.
• Avoid exposing tokens or sensitive authentication details in responses and logs.

8.2 OAuth and credential lifecycle¶

• Request only the scopes necessary for approved read operations.
• Validate OAuth redirect URIs against registered, trusted destinations.
• Protect access tokens, refresh tokens, client secrets, and provider credentials.
• Associate credentials with the correct user and integration connection.
• Handle refresh failures without falling back to unrelated credentials.
• Review revocation, disconnection, expiration, and credential rotation behavior.

8.3 Prompt injection and untrusted content¶

Email bodies, documents, calendar descriptions, messages, issue descriptions, and tool outputs must be treated as untrusted content.

• Do not interpret retrieved instructions as changes to system policy.
• Do not allow retrieved content to grant permissions or change the authenticated identity.
• Validate tool names, arguments, and operation types independently of model output.
• Enforce data-access restrictions outside the model.
• Test malicious instructions embedded in otherwise legitimate provider content.

8.4 Data protection and logging¶

• Minimize the amount of provider data processed and retained.
• Redact credentials and sensitive content from logs, traces, and errors.
• Restrict access to security logs and operational records.
• Define retention and deletion requirements for application data and backups.
• Record security-relevant decisions without unnecessarily recording complete message or document contents.

8.5 Availability and dependency security¶

• Bound request sizes, query complexity, pagination, concurrency, and retries.
• Configure timeouts for external provider requests.
• Prevent retry loops and uncontrolled parallel execution.
• Scan dependencies and container images using the project's approved tooling.
• Protect CI/CD secrets and restrict access to release artifacts.
• Review production configuration for debugging features, permissive CORS settings, exposed services, and unnecessary privileges.

These requirements describe the expected security posture. Their implementation status must be assessed separately.

9. Risk assessment and findings management¶

Each identified finding must have a traceable record containing the information needed to reproduce, remediate, and verify the issue.

Do not mark a finding as mitigated merely because a prompt, comment, configuration example, or documentation statement instructs the application to avoid the behavior.

Recommended finding lifecycle¶

flowchart TD
    Identified["Threat Identified"]
    Assessed["Risk Assessed"]
    Assigned["Owner Assigned"]
    Remediated["Fix Implemented"]
    Tested["Security Tests Passed"]
    Reviewed["Evidence Reviewed"]
    Closed["Finding Closed"]

    Identified --> Assessed
    Assessed --> Assigned
    Assigned --> Remediated
    Remediated --> Tested
    Tested --> Reviewed
    Reviewed --> Closed
    Tested -. "Failure" .-> Remediated
    Reviewed -. "Insufficient evidence" .-> Remediated

    classDef pending fill:#FCE8D5,stroke:#B86B24,color:#663A13,stroke-width:1.5px
    classDef validation fill:#DCEBFA,stroke:#2864A5,color:#17365D,stroke-width:1.5px
    classDef complete fill:#D9F2E6,stroke:#16805D,color:#104D3A,stroke-width:1.5px

    class Identified,Assessed,Assigned,Remediated pending
    class Tested,Reviewed validation
    class Closed complete

    linkStyle default stroke:#8795A5,stroke-width:1.5px

10. Security verification plan¶

The security review must combine source inspection, automated tests, and deployment verification.

Evidence standards¶

A security control should be considered verified only when the available evidence supports the specific claim being made.

1. Source inspection: Identify the actual enforcement point and determine whether bypass paths exist.
2. Automated testing: Demonstrate both expected behavior and rejection of prohibited behavior.
3. Integration testing: Confirm that security decisions remain effective across service and provider boundaries.
4. Deployment review: Confirm that the running configuration preserves the intended controls.
5. Evidence recording: Link the finding to test results, review records, and remediation changes.

11. Review and maintenance¶

Review this threat model whenever:

• A provider integration or capability is added.
• A tool, endpoint, worker, handler, or execution path changes.
• OAuth scopes or credential-handling logic change.
• Authentication, authorization, or orchestration architecture changes.
• A new dependency introduces material security risk.
• A security incident or relevant vulnerability is identified.
• Verification results change the assessed risk or the implementation status of a control.

The project owner or designated security reviewer must review outstanding high-risk findings before release. Any accepted residual risk must be documented, assigned to an authorized decision-maker, and revisited when the relevant conditions change.

12. Related documentation¶

• Security Overview — security objectives, trust boundaries, and verification expectations.
• Read-Only Integration Security Policy — mandatory restrictions and acceptance criteria for connected services.

Document status: Initial threat-model baseline. Update this document as the architecture, security controls, and verification evidence evolve.