# 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.

Fails

Employee request

### Gate 1 · Intent screening
Is this a legitimate IT request?

### Gate 2 · Plan validation
Only the skill's allowed tools, in a justified order

### Gate 3 · Policy evaluation
Does the plan comply with central policy?

### Gate 4 · Execution gates
Preview, user consent, and audit on every risky step

Fix verified · ticket with full audit trail

Blocked and explained

# 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 -** preview 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.