> For the complete documentation index, see [llms.txt](https://doc.threatreaper.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.threatreaper.ai/getting-started/platform-architecture.md).

# 🏗️ Platform Architecture

This page explains how LockThreat is put together **conceptually** — enough to design a sound integration, reason about data flow, and answer basic security-review questions. It intentionally stays at the architecture level; it does not describe internal source code, infrastructure, or implementation details.

### Layered view

```mermaid
flowchart TB
    subgraph Clients["Client Layer"]
        A1[Console UI]
        A2[Your Application via REST API]
        A3[IDE / Browser Plugins]
        A4[Chat Wrapper End Users]
    end

    subgraph Access["Access & Identity Layer"]
        B1[Sign-in / SSO]
        B2[JWT Session Tokens]
        B3[API Keys]
        B4[Roles & Permissions]
    end

    subgraph Engine["Security Engine"]
        C1[Policy Engine]
        C2[Guardrail Detectors]
        C3[Autonomous Decision Engine]
        C4[Explainability Engine]
    end

    subgraph Integration["Integration Layer"]
        D1[Cloud Connectors — AWS / Azure / GCP]
        D2[Source Connectors — GitHub]
        D3[Model Connectors — OpenAI / Azure OpenAI / Anthropic / etc.]
        D4[Network & Endpoint Agents]
        D5[Notification Channels — Email / Slack / Teams / Webhook]
    end

    subgraph Data["Data Layer"]
        E1[Policies, Projects, Scans]
        E2[Logs & Audit Trail]
        E3[Credits & Billing Records]
    end

    Clients --> Access --> Engine
    Engine --> Integration
    Engine --> Data
    Integration --> Data
```

| Layer                       | Responsibility                                                                 | What you see in the console                                                          |
| --------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
| **Client Layer**            | How you and your applications interact with LockThreat                         | The Console UI, the REST API, IDE/browser plugins, and your chat wrapper's end users |
| **Access & Identity Layer** | Authenticates every request and enforces what it's allowed to do               | Sign-in, organisation/project selection, API keys, Roles                             |
| **Security Engine**         | Evaluates prompts/responses/code/models against policy and produces a decision | AI-Firewall, AI-Agents, AI-Probe, AI-Explain                                         |
| **Integration Layer**       | Connects the engine to the outside world                                       | Connectors, Agents, Notification channels                                            |
| **Data Layer**              | Stores everything durably and auditable                                        | Policies, scan history, audit logs, credit/billing records                           |

### Request flow example: a protected prompt

```mermaid
sequenceDiagram
    participant App as Your Application
    participant FW as AI-Firewall API
    participant PE as Policy Engine
    participant GR as Guardrails
    participant LLM as Your AI Model
    participant Log as Live Logs / AI-Explain

    App->>FW: POST /v2/raksha/tr_firewall_analyze (prompt, projectId)
    FW->>PE: Look up policy for projectId
    PE->>GR: Run enabled guardrails (Prompt Injection, PII, Toxicity, ...)
    GR-->>PE: Per-guardrail results + confidence
    PE-->>FW: overall_decision, allow_prompt, risk_level
    FW-->>App: JSON response
    FW->>Log: Record decision for Live Logs & AI-Explain
    App->>LLM: Send prompt only if allow_prompt = true
    LLM-->>App: Model response
    App->>FW: POST /v2/raksha/tr_firewall_validate (response, projectId)
    FW-->>App: Validated / masked response to show the user
```

This same pattern — **analyze before the model, validate after the model** — applies whether the caller is your own backend, an AI-Guard chat wrapper, or an endpoint agent protecting a desktop AI tool.

### How discovery and testing fit in

```mermaid
flowchart LR
    Cloud[Cloud Accounts<br/>AWS / Azure / GCP] -->|Connector| Discover[AI-Discover]
    Network[Internal Network] -->|Network Agent| Discover
    Endpoint[Employee Devices] -->|Endpoint Agent| Discover
    Discover -->|Found assets & endpoints| Probe[AI-Probe]
    Code[Source Repositories] -->|GitHub Connector| Probe
    Probe -->|Findings & risk scores| Explain[AI-Explain]
    Discover -->|Risk scores| Explain
    Firewall[AI-Firewall decisions] -->|Decisions| Explain
```

AI-Discover and AI-Probe don't protect traffic in real time — they find and test things. AI-Firewall, AI-Agents, AI-Guard and AI-MCP protect traffic in real time. AI-Explain sits across all of them so you always have a single place to ask "why."

### Deployment models

| Model                 | Description                                                       | Typical fit                                                   |
| --------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------- |
| **Multi-tenant SaaS** | Hosted by LockThreat, organised by region (for example UAE North) | Fastest to start, no infrastructure to manage                 |
| **On-Premises**       | Deployed inside your own infrastructure                           | Strict data-residency, air-gapped, or regulatory requirements |

Both expose the same console and API surface. A policy, connector, or integration you build against the SaaS API works the same way against an On-Premises deployment — only the base URL changes.

### Multi-tenancy and isolation

* Every object you create (projects, policies, scans, logs, credits) belongs to an **organisation** and, within it, a **project**. Data is scoped by project ID on every read and write.
* Roles and permissions are evaluated per project — a user can hold different permissions in different projects within the same organisation.
* Credentials you provide to connectors are stored per organisation and are only used to perform the actions you configure (for example, read-only cloud inventory, or sending a prompt to your chosen model provider). They are never shared across organisations.

### Where compliance mapping fits

AI-Align doesn't change how the Security Engine behaves — it **maps** the guardrails and policies you already have onto external frameworks (NIST AI RMF, OWASP LLM Top 10, ISO/IEC 42001, EU AI Act, GDPR, HIPAA, SOC 2, and others) so you can see coverage and gaps, and export evidence. Think of it as a reporting and gap-analysis layer on top of the same policy data everything else uses.

### Summary

* **One policy, many enforcement points** — the same policy can protect a direct API integration, an AI-Guard chat wrapper, and traffic observed by an endpoint agent.
* **Analyze-then-validate** is the core request pattern for anything that talks to an LLM.
* **Discover and Probe feed Explain** — every asset risk score and scan finding is explainable, not just firewall decisions.
* **Connectors and Agents are the only things that touch your external systems** — everything else operates on data already inside LockThreat.

Continue to the full **LockThreat User Guide** for day-to-day operation of each module.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://doc.threatreaper.ai/getting-started/platform-architecture.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.