AI Safety Guardrails

Pathrule3 Rules • 1 Memory • 1 Skill

AI safety guardrails are layered runtime controls around a probabilistic model, not a single system prompt or blocked-word list. This bundle classifies use-case risk, separates instructions from untrusted content, authorizes every tool action, validates output, and defines human escalation and incident evidence. Unlike LLM Evals, it enforces live boundaries while evals measure behavior offline.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

red-team-ai-feature

src/

ai/

safety/

Keep untrusted content outside the instruction channel

Validate output for its destination

Guardrail strength follows use-case risk

api/

Authorize every tool call outside the model

Rules

Keep untrusted content outside the instruction channel/src/ai/safetyhighstrictUser, retrieved, uploaded, web, tool, and memory content is labeled as data and cannot rewrite system policy.

1	User, retrieved, uploaded, web, tool, and memory content is labeled as data and cannot rewrite system policy. Attackers can place instruction-like text inside any content source the model reads, including documents that appear internal or previously summarized. Enforce this boundary in /src/ai/safety so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Build prompts from typed sections that preserve source, trust level, and intended use instead of concatenating strings.
4	- Never interpolate untrusted text into system or developer instructions, tool definitions, or policy templates.
5	- Tell the model the data boundary, but enforce it again with deterministic tool and output controls.
6	- Treat remembered and retrieved content as untrusted unless a separate verified source grants authority.
7
8	Verification: Seed conflicting instructions in every content source and confirm they cannot change allowed tools, data scope, output policy, or approval requirements.

Authorize every tool call outside the model/src/apihighstrictA model proposal becomes an action only after schema, principal, tenant, resource, risk, and current-state checks pass.

1	A model proposal becomes an action only after schema, principal, tenant, resource, risk, and current-state checks pass. Valid JSON and a permitted tool name do not prove that the current user may act on the requested resource or amount. Enforce this boundary in /src/api so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Expose the smallest tool surface and use server-derived identity and tenant values rather than model-supplied authority.
4	- Validate arguments with a strict schema and resolve resource identifiers against authorized current state.
5	- Require confirmation or human approval for irreversible, financial, privileged, or externally communicative actions.
6	- Give mutations idempotency keys and record proposal, policy decision, approval, effect, and result without leaking sensitive content.
7
8	Verification: Attempt cross-tenant IDs, stale state, excessive amounts, hidden side effects, duplicate calls, and approval bypass; verify every rejection occurs before effect.

Validate output for its destination/src/ai/safetyhighstrictOutput policy depends on whether content is displayed, stored, executed, indexed, sent externally, or used in a decision.

1	Output policy depends on whether content is displayed, stored, executed, indexed, sent externally, or used in a decision. A response safe to show as quoted text may be dangerous when rendered as HTML, executed as code, used as a URL, or treated as verified fact. Enforce this boundary in /src/ai/safety so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Apply structural and semantic validators for downstream machine consumers before handing them the result.
4	- Escape or sanitize for the actual renderer and keep model text out of raw HTML, shell, query, and template contexts.
5	- Require citations or source checks for factual claims where the product promises grounded answers.
6	- Block, transform, or escalate according to the use-case risk policy and preserve an auditable reason code.
7
8	Verification: Send adversarial markup, links, code, unsupported claims, secret-like data, and policy-sensitive content through every destination; confirm controls differ by destination.

Memories

Guardrail strength follows use-case risk/src/ai/safetyA writing suggestion, internal search result, code change, support reply, payout decision, and medical summary have different impact, reversibility, and oversight needs.

1	A writing suggestion, internal search result, code change, support reply, payout decision, and medical summary have different impact, reversibility, and oversight needs. Classify each AI feature by affected people, data sensitivity, autonomy, scale, detectability, reversibility, and legal or product obligations.
2
3	Bind the tier to allowed data, models, tools, output destinations, evaluation depth, monitoring, approval, and fallback behavior. Reassess the tier when a feature gains tools, new users, broader data, or automated action. Do not lower a control merely because model quality improved; quality and consequence are separate axes. Keep the decision explicit at /src/ai/safety; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /src/api for action authorization and /tests/ai for tier-specific adversarial evidence. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

red-team-ai-feature/rootRed-team an AI feature across prompt injection, data access, tools, output destinations, failure, and human escalation.

1	---
2	name: red-team-ai-feature
3	description: Red-team an AI feature across prompt injection, data access, tools, output destinations, failure, and human escalation.
4	---
5
6	# Red Team Ai Feature
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Map actors, trusted instructions, untrusted data sources, tools, destinations, protected assets, risk tier, and the exact boundaries expected to enforce policy.
11	2. Create attacks for instruction override, indirect injection, data exfiltration, cross-tenant access, tool argument abuse, unsafe rendering, and approval fatigue.
12	3. Run cases through production-equivalent retrieval, memory, provider, tool, and UI paths while capturing policy decisions and side effects.
13	4. Turn successful attacks into deterministic controls and regression fixtures, assign owners, and retest after model, prompt, tool, or data-source changes.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Why this pattern

Agents rely on prompt wording to resist hostile content, expose broad tools to model choice, and render or execute output before deterministic policy checks.

Built for Teams deploying AI features that read untrusted content, call tools, or influence consequential decisions.

Keeps your assistant from:

Prompt injection turning retrieved content into instructions
A model invoking a valid tool with unauthorized arguments
Unsafe or unsupported output reaching users or downstream systems

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25