> ## Documentation Index
> Fetch the complete documentation index at: https://docs.idemeum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Guardrails

> How every run is secured with guardrail architecture.

# What are guardrails?

Guardrails in Endpoint Care are not instructions we hope the model follows. They are code between the model and the machine: four gates every request must pass, none of which the model can skip or bypass.

```mermaid theme={null}
%%{init: {
  "theme": "base",
  "themeVariables": {
    "fontFamily": "Inter, ui-sans-serif, system-ui, sans-serif",
    "fontSize": "14px",
    "primaryColor": "#ffffff",
    "primaryBorderColor": "#e4e4e7",
    "primaryTextColor": "#18181b",
    "lineColor": "#a1a1aa",
    "edgeLabelBackground": "#ffffff"
  },
  "flowchart": { "useMaxWidth": false, "nodeSpacing": 40, "rankSpacing": 42 }
}}%%
flowchart TD
    A("Employee request") --> G1("Gate 1 · Intent screening<br/>Is this a legitimate IT request?")
    G1 --> G2("Gate 2 · Plan validation<br/>Only the skill's allowed tools, in a justified order")
    G2 --> G3("Gate 3 · Policy evaluation<br/>Does the plan comply with central policy?")
    G3 --> G4("Gate 4 · Execution gates<br/>Preview, user consent, and audit on every risky step")
    G4 --> R("Fix verified · ticket with full audit trail")

    G1 -.->|fails| X("Blocked and explained")
    G2 -.-> X
    G3 -.-> X

    classDef card fill:#ffffff,stroke:#e4e4e7,stroke-width:1px,color:#18181b;
    classDef muted fill:#f4f4f5,stroke:#e4e4e7,stroke-width:1px,color:#3f3f46;
    classDef primary fill:#18181b,stroke:#18181b,color:#fafafa;
    classDef destructive fill:#fef2f2,stroke:#fecaca,stroke-width:1px,color:#b91c1c;

    class G1,G2,G3,G4 card;
    class A muted;
    class R primary;
    class X destructive;
```

# What each gate does

### **Gate 1 - Intent screening**

Gate 1 inspects the request before any planning happens. It rejects anything outside IT support and any attempt to manipulate the agent, including prompt injection.

**Blocks:** off-topic requests, jailbreak attempts, instructions smuggled inside a request.

### **Gate 2 - Plan validation**

Before anything runs, the agent must produce an ordered plan, and Gate 2 validates it against the matched skill: every step must use a tool from the skill's allowed list, and diagnostics must come before fixes. Failed plans are sent back for revision; they never execute partially.

**Blocks:** any tool outside the skill's allowlist, corrective actions before diagnosis, skipped prerequisites, risk outside boundary.

### **Gate 3 - Policy evaluation**

Gate 3 checks the approved plan against your central policy: which actions need admin approval, what's forbidden, for whom. IT defines the rules; the model can't change them.

**Blocks:** anything your organization has ruled out, regardless of what the plan says.

### **Gate 4 - Execution gates**

Every step passes its own checks before it runs:

* **Scope -** the step stays within the user's own account. Privileged operations go through a controlled helper, never silent elevation.
* **Preview -** risky steps first show exactly what would change, computed by the real tool, not a guess.
* **Consent -** the user approves or declines. A decline doesn't break the run; the ticket records what wasn't done.
* **Deterministic execution -** steps run only through code-reviewed tools. The AI never writes commands or scripts.
* **Audit -** every step's inputs, result, and decisions are recorded.

# Why this architecture is more secure

Five properties make the system more secure:

1. **The plan is a whitelist -** the model commits to a plan before anything runs, and execution is bound to it. Even a compromised model cannot call a tool that isn't in the approved plan.
2. **The AI never writes code that runs -** its entire vocabulary is a fixed set of code-reviewed tools. There is no path from model output to arbitrary execution.
3. **Consent is a mechanism, not a courtesy - p**eview and consent fire automatically from each tool's declared risk. Authors can't forget them; the model can't suppress them.
4. **Least privilege, real boundaries -** actions are scoped to the requesting user, privileged steps go through a controlled helper, and passwords never touch the agent or its logs.
5. **Central control, full audit -** IT can disable any skill fleet-wide, and every plan, approval, and result lands in a reviewable audit trail.