Security Overview¶

WhiteLotusAI combines AI orchestration with enterprise integrations that may access confidential emails, documents, calendar events, issues, and collaboration data. Security must therefore be enforced by trusted application components rather than delegated to the AI model or frontend.

1. Purpose¶

This document establishes the security objectives, trust boundaries, and verification expectations for WhiteLotusAI. It serves as the entry point for the detailed security policies and threat analysis maintained in this documentation.

The security baseline is intended to guide implementation, code review, testing, deployment, and release-readiness decisions.

Security principles¶

2. Security objectives¶

WhiteLotusAI security engineering must prioritize the following objectives.

3. Security boundaries and architecture¶

Security reviews must identify where trust changes, which component is responsible for enforcement, and what evidence demonstrates that enforcement works.

The following diagram presents the logical security boundaries that must be reviewed. It is a security model, not a claim that every control has already been implemented.

flowchart TB
    USER["User / Client"]
    FRONTEND["Frontend"]
    GATEWAY["API Gateway<br/>Authentication and request validation"]
    ORCHESTRATOR["AI Orchestration<br/>Untrusted model proposals"]
    POLICY["Trusted Policy Layer<br/>Authorization and operation allowlist"]
    INTEGRATIONS["Integration Services<br/>User-bound credentials"]
    PROVIDERS["External Provider APIs"]
    DATA[("Database and Conversation State")]
    LOGS["Audit Logs and Monitoring"]

    GATEWAY -.-> LOGS
    POLICY -.-> LOGS
    INTEGRATIONS -.-> LOGS

    USER --> FRONTEND
    FRONTEND --> GATEWAY
    GATEWAY --> ORCHESTRATOR
    ORCHESTRATOR -->|"Proposed operation"| POLICY
    POLICY -->|"Authorized operation only"| INTEGRATIONS
    INTEGRATIONS --> PROVIDERS

    GATEWAY --> DATA
    ORCHESTRATOR --> DATA
    INTEGRATIONS --> DATA

    classDef client fill:#E8F1FF,stroke:#3767A6,color:#17365D,stroke-width:1.5px
    classDef trusted fill:#DDF5E5,stroke:#24804A,color:#174D30,stroke-width:1.5px
    classDef ai fill:#F2E8FF,stroke:#8250B4,color:#4B2675,stroke-width:1.5px
    classDef external fill:#FFF0D9,stroke:#B87519,color:#70420C,stroke-width:1.5px
    classDef storage fill:#E2F4F4,stroke:#277F83,color:#155457,stroke-width:1.5px

    class USER,FRONTEND client
    class GATEWAY,POLICY,INTEGRATIONS trusted
    class ORCHESTRATOR ai
    class PROVIDERS external
    class DATA,LOGS storage

Figure 1. Logical security boundaries and enforcement responsibilities.

Boundary review checklist¶

4. Read-only integration security¶

The initial integration scope is read-only for the following providers:

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

Only explicitly approved read operations may execute. Operations that send, create, update, delete, share, move, or otherwise modify external resources must be blocked during this phase.

Mandatory safeguards¶

1. Maintain an explicit allowlist of approved operations.
2. Enforce authorization on the server before any provider operation executes.
3. Apply consistent restrictions across HTTP routes, tool dispatch, RPC handlers, workers, and reachable alternate paths.
4. Bind credentials and provider connections to the authenticated user.
5. Fail closed when identity, authorization, or connection ownership cannot be established.
6. Test that denied operations never reach provider clients.
7. Reassess the policy whenever an integration or execution path changes.

Related policy: Read-Only Integration Security Policy

5. Identity and access control¶

Every integration request must be associated with a verified user identity and an authorized provider connection.

The implementation must validate:

• The authenticated principal.
• The requested operation and its permitted scope.
• The user's authorization for the target resource.
• The association between the user and the provider connection.
• Internal service authentication, where applicable.

User identifiers supplied through request parameters, message content, or model-generated arguments must never independently establish identity or authorization.

Authorization decision flow¶

flowchart TD
    REQUEST["Incoming Request"]
    IDENTITY{"Identity verified?"}
    OPERATION{"Operation allowlisted?"}
    RESOURCE{"Resource access authorized?"}
    CONNECTION{"User owns or may access connection?"}
    EXECUTE["Execute approved operation"]
    DENY["Reject request"]

    REQUEST --> IDENTITY
    IDENTITY -->|No| DENY
    IDENTITY -->|Yes| OPERATION
    OPERATION -->|No| DENY
    OPERATION -->|Yes| RESOURCE
    RESOURCE -->|No| DENY
    RESOURCE -->|Yes| CONNECTION
    CONNECTION -->|No| DENY
    CONNECTION -->|Yes| EXECUTE

    classDef decision fill:#FFF0D9,stroke:#B87519,color:#70420C,stroke-width:1.5px
    classDef success fill:#DDF5E5,stroke:#24804A,color:#174D30,stroke-width:1.5px
    classDef denied fill:#FCE8E6,stroke:#B3261E,color:#7F1D1D,stroke-width:1.5px

    class IDENTITY,OPERATION,RESOURCE,CONNECTION decision
    class EXECUTE success
    class DENY denied

Figure 2. Required authorization sequence. A failed or indeterminate check must not proceed to execution.

Authentication or authorization failure must result in rejection, without falling back to a less restrictive execution path.

6. Credential and OAuth security¶

Credentials must be protected throughout their lifecycle, from initial authorization to storage, retrieval, refresh, revocation, and deletion.

Do not document a token-storage mechanism, encryption guarantee, or OAuth protection as implemented until the corresponding code and configuration have been reviewed.

7. AI orchestration and prompt-injection security¶

Emails, documents, chat messages, calendar events, issues, attachments, and other retrieved content must be treated as untrusted data.

Retrieved content may contain instructions designed to manipulate the model into disclosing confidential information or requesting unauthorized operations.

Required controls¶

• Separate retrieved content from trusted application instructions.
• Validate model-generated tool names and arguments against server-defined schemas.
• Apply authorization independently of model output.
• Never trust model-generated confirmation flags as proof of user approval.
• Prevent retrieved content from changing security policy or authenticated identity.
• Restrict execution to explicitly authorized operations.
• Test adversarial prompts and malicious retrieved content.
• Avoid exposing secrets or unrelated user data in model context and outputs.

Safe tool-execution pattern¶

Receive request
    ↓
Establish authenticated identity
    ↓
Classify intent and prepare a proposed operation
    ↓
Validate tool name and argument schema
    ↓
Apply server-side authorization and read-only policy
    ↓
Resolve the user's authorized provider connection
    ↓
Execute only if every required check succeeds
    ↓
Validate the result and return a safe response

This sequence describes the required security behavior. It must be verified against the actual orchestration and integration implementation.

8. Data protection and privacy¶

The application should process only the information necessary to fulfill the user's authorized request.

Security reviews must cover:

• Access restrictions for stored conversations and provider data.
• Database ownership checks and tenant isolation.
• Data minimization in logs, traces, and monitoring.
• Sensitive information included in model prompts and outputs.
• Retention, deletion, and backup requirements.
• Secure handling of attachments and downloaded content.
• Access to backups, deployment artifacts, and diagnostic exports.

Specific privacy or data-protection guarantees must not be asserted until implementation and deployment configuration have been examined.

9. API and operational security¶

Backend services should enforce security controls consistently across synchronous requests, asynchronous workers, internal communication, and external provider calls.

Recommended control areas include:

• Request validation and bounded payload sizes.
• Authentication and authorization at appropriate enforcement points.
• Bounded pagination, query limits, and execution time.
• Appropriate timeouts, retry budgets, and concurrency controls.
• Safe error responses that do not disclose secrets or internal details.
• Rate limiting where needed.
• Restricted internal service communication.
• Security-relevant logging and monitoring.
• Dependency, container, and secret scanning.
• Secure deployment configuration and access management.

Operational failure behavior¶

The precise behavior must be verified for each service and execution path. Retries must not cause duplicate side effects if an operation is ever permitted to modify external state in a future phase.

10. Security documentation and related policies¶

Use the following documents to review specific threats and enforcement requirements.

These documents define requirements and record security considerations. Their existence does not establish that the application satisfies those requirements.

11. Verification and release readiness¶

A security control should be marked verified only when appropriate evidence demonstrates that it works as intended.

Evidence required for verification¶

• Source-code review of the enforcement point.
• Automated unit and integration tests.
• Negative tests for unauthorized operations.
• Direct endpoint and alternate-path testing.
• Credential handling and OAuth configuration review.
• Dependency and secret scanning.
• Deployment configuration review.
• Documented findings, remediation, and retest results.

Verification status¶

Use the following labels consistently in security reviews and supporting documentation.

These labels describe different levels of evidence. Finding code that appears to implement a control does not, by itself, establish successful runtime behavior.

12. Continuous improvement¶

Review this security baseline whenever:

• A new integration, provider, or tool is introduced.
• An endpoint, worker, or execution path changes.
• OAuth scopes or credential-handling logic changes.
• Authentication or authorization logic changes.
• A security finding or incident is discovered.
• Deployment architecture, data retention, or data handling changes.

Update the security overview, threat model, integration policies, and regression tests together so that documented requirements remain aligned with verified implementation behavior.

Next steps

Read the Threat Model Review the Read-Only Integration Policy

Security baseline for WhiteLotusAI. Implementation and runtime verification remain subject to evidence-based review.