AI Guardrails

What are AI guardrails?

AI guardrails are environment-wide content safety policies that administrators configure in the Admin Console. They evaluate content before it reaches an AI model (input guardrails) and after the model generates a response (output guardrails), protecting against risks like prompt injection, personally identifiable information (PII) exposure, toxic content, and policy violations.

AI guardrails apply automatically to every generative AI execution, excluding Enterprise Copilot, the a!documentsChat() function, and spreadsheet extraction AI skills. Developers don't need to implement safety logic in individual objects. Administrators define policies once, and Appian applies them across the board.

Why use AI guardrails?

AI guardrails move content safety enforcement from individual objects to the platform level. Instead of relying on each developer to add safety checks in every AI object, administrators configure guardrails once and Appian applies them everywhere.

AI guardrails provide the following advantages:

• Centralized enforcement: Define content safety policies in one place. Appian applies them to every generative AI execution without requiring changes to individual objects.
• Consistent protection: Every AI execution gets the same safety evaluation, so there are no gaps from inconsistent implementations.
• Reduced developer burden: Developers focus on business logic instead of building redundant safety checks. AI guardrails protect their applications automatically.
• Audit visibility: Guardrail violation logging gives security and compliance analysts a clear audit trail for all guardrail events, supporting internal audits and regulatory requirements.

How AI guardrails fit into Appian's security architecture

AI guardrails are one layer in Appian's defense-in-depth approach to AI security. They evaluate the text content of AI interactions for policy violations, independent of who initiated the request or what data is accessed. This content-layer protection works alongside the structural controls already built into the platform:

• Object Security: AI features always operate with the initiator's permissions and cannot exceed user-level access.
• Record-Level Security: Record-level and field-level security apply to all AI interactions with data.
• Process model security: AI executions respect process model security and cannot bypass object-level permissions.

AI guardrails don't replace access controls or data security. The two work together: structural controls determine what data and objects a user can reach, while guardrails evaluate the content of AI interactions for policy violations. For a full overview of Appian's AI security architecture, see Security and Compliance.

How AI guardrails work at runtime

AI guardrails evaluate content at two points during an AI execution:

• Input guardrails: Evaluate content before it reaches the AI model. If a guardrail triggers a Block action on input, no LLM call is made.
• Output guardrails: Evaluate the AI model's response before it reaches the user. If a guardrail triggers a Block action on output, no response is returned to the caller.

Evaluation order and action hierarchy

When multiple guardrails evaluate the same content, Appian applies the following hierarchy:

• Block supersedes Mask. If any guardrail triggers a Block action, no masks are applied. For input guardrails, no LLM call is made. For output guardrails, no response is returned to the caller.
• Multiple masks are additive. If no Block is triggered and multiple guardrails trigger Mask actions, all matched content is redacted.

What happens when a guardrail triggers

The behavior depends on the configured action:

• Block: Execution stops. Appian returns a guardrail response containing the administrator-configured block message. The consuming feature determines the end-user experience:
  • AI agents: The agent receives the block message, then proceeds with different content.
  • AI skills (via the Execute Generative AI Skill smart service): The smart service returns an error. The Success output is false and the Error Message output contains "The content was blocked by an AI guardrail." Handle this error in your process logic to determine the next step.
• Mask: Matched content is redacted using the administrator-configured replacement text. The remaining content continues through the pipeline. Masking applies only to the matched string.

Streaming behavior

When an output guardrail is active, streaming is disabled. The AI model's full response is evaluated against the guardrail before any content is returned to the user. Users may notice a delay before a response appears while the guardrail completes its evaluation.

AI guardrail configuration options

Administrators configure AI guardrails in the Admin Console under AI Guardrails. Any user with access to the Admin Console can configure guardrails. Each environment supports a maximum of 10 guardrails.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Creation options

Appian provides two paths to create a guardrail:

• Start with a template: Explore pre-built guardrail templates for common use cases.
• Start from scratch: Create your own custom guardrail.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Guardrail templates

Appian provides the following template categories and templates for common guardrail use cases:

• PII Detection: Identifies personally identifiable information such as names, addresses, and identification numbers.
  • SSN Detection
  • Credit Card Number Detection
  • Email Address Detection
• Toxic Content Detection: Flags inappropriate, offensive, or harmful language.
  • Self-Harm & Violence
  • Hate Speech & Harassment
  • Sexual Content
  • Profanity
• Malicious Code Detection: Identifies potentially harmful code in AI interactions.
  • Malicious Code Generation
• Compliance and Regulatory Checks: Enforces organization-specific compliance policies.
  • Medical Diagnosis
  • Financial Advice
  • Legal Advice
  • Performance Guarantees
• Custom Content Detection: Verifies brand alignment and enforces internal policies.
  • Prohibited Topics
  • Internal Project Names

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Scope

The scope setting controls where the guardrail applies during the AI call:

• User input: Checks text submitted by users before it is processed.
• AI response: Checks AI responses before they display to the user.
• User input and AI response: Checks all text in the user input and AI response.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Detection methods

The detection method determines how the guardrail identifies content:

• Keywords: Match exact words or phrases. For example, "Project Falcon", "4.2 Release". You can add multiple keywords per guardrail, and at least one keyword must be defined.
• Regex: Use regular expressions to find complex text strings. For example, \d{3}-\d{2}-\d{4} for SSN patterns. The Admin Console validates that the regex pattern compiles before saving. For the full list of supported syntax, see Regular expression reference.
• Semantic: Uses AI to detect content with similar meaning or context. For example, "Block requests asking about competitor products."

Actions

The action determines what happens when the guardrail identifies a violation:

• Block: Prevents the content from being processed or displayed. Administrators configure a block message that is shown to users when the guardrail identifies a violation.
• Mask: Obscures sensitive text while displaying the rest of the message. Administrators configure a mask replacement value (for example, [REDACTED]) that replaces the detected content. Masking is only available for keyword and regex guardrails.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Testing

The Admin Console includes an inline testing tool that lets administrators test a guardrail configuration against sample content before it takes effect. Enter sample text and click TEST GUARDRAIL to see the result:

• Guardrail Triggered: The sample content matched. The test displays the configured block message or masked output.
• Guardrail Not Triggered: The sample content did not match the guardrail's detection criteria.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Create an AI guardrail

You can create up to 10 guardrails per environment.

To create a guardrail:

1. In the Admin Console, go to AI Guardrails.
2. Click CREATE GUARDRAIL.
3. Choose how to start:
   • Start with a template: Select a template category, then select a template. Click CONTINUE. The Create Guardrail screen displays with some fields pre-populated.
   • Start from scratch: The Create Guardrail screen displays immediately.
4. Enter a name and description for the guardrail. Names must be unique within the environment and cannot exceed 200 characters.
5. Click CONTINUE. The options for configuring your new guardrail display.
6. Under Scope, select where the guardrail applies:
   • User input to evaluate content before it reaches the AI model.
   • AI response to evaluate the model's response before it reaches the user.
   • User input and AI response to evaluate both.
7. Under Detection Method, select how the guardrail identifies content:
   • Keywords to match exact words or phrases.
   • Regex to match a regular expression pattern.
   • Semantic to use AI-based meaning detection.
8. Enter the detection criteria based on the method you selected.
9. Under Action, select what happens when the guardrail triggers:
   • Block to stop the content from being processed or displayed. Enter a block message (up to 500 characters) that is returned when the guardrail triggers.
   • Mask to redact matched content. Enter a replacement value (up to 100 characters) that replaces the detected content. Masking is only available for keyword and regex detection methods. If you selected Semantic as the detection method, only Block is available.
10. Click TEST GUARDRAIL to validate the configuration against sample content. For more information, see Testing.
11. Click SAVE.

The guardrail is enabled by default after saving. To disable it, return to the Guardrail screen and toggle it off. For more information, see Enable and disable guardrails.

Enable and disable guardrails

Each guardrail can be individually enabled or disabled in the Admin Console. Disabled guardrails do not evaluate content.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Deploy guardrails between environments

AI guardrails are deployed between environments through packages. Guardrails do not have import customization files (ICFs). When you import a package containing guardrails into a target environment, the guardrail configurations are applied as-is.

To deploy guardrails:

1. In the source environment, export a package that includes the AI guardrails configuration.
2. In the target environment, import the package.
3. Verify the guardrail configurations in the Admin Console after import.

AI guardrail violation logging

AI guardrails use a two-layer logging architecture that provides both operational visibility and forensic investigation capability.

Guardrail violation audit log

The guardrail violation audit log is always active when guardrails are enabled. This log captures structured metadata for every guardrail violation:

Field	Description
Timestamp	Date and time of the violation.
User UUID	Identifier of the user whose action triggered the violation.
Guardrail UUID	Identifier of the guardrail that triggered.
Guardrail Name	The name of the guardrail that triggered.
Action	The action taken: BLOCK or MASK.
Layer	Where the guardrail triggered: INPUT or OUTPUT.
Source Object UUID	Identifier of the AI object that was executing (AI skill, agent, expression rule).
Source Object Name	The name of the AI object that triggered the evaluation.

The guardrail violation audit log records identifiers and event metadata only—no content. Guardrail name, category, and detection method are resolved through UUID lookup against the guardrail configuration.

The log is located at audit/ai_guardrail_violations.csv and follows the same 7-day / 100 MB retention policy as other AI audit logs.

Regular expression reference

A regular expression (regex) is a pattern that matches text. When you select Regex as the detection method for a guardrail, you write a regex pattern to detect specific content in user inputs or AI responses.

A regex can contain ordinary characters and special characters. An ordinary character like T or test matches itself exactly. Special characters control how the pattern matches text.

Any character

Syntax	Description
.	Matches any single character except a newline. For example, c.t matches cat, cot, and c9t.

Anchors

Anchors match a position in the text rather than a character.

Syntax	Description
^	Matches the start of the text. For example, ^Hello matches Hello world but not Say Hello.
$	Matches the end of the text. For example, end$ matches the end but not endless.

Repetition

Repetition operators control how many times the preceding element must appear.

Syntax	Description
*	Matches 0 or more of the preceding element. For example, go*d matches gd, god, good, goood, and so on.
+	Matches 1 or more of the preceding element. For example, go+d matches god and good but not gd.
?	Matches 0 or 1 of the preceding element. For example, colou?r matches both color and colour.
{m}	Matches exactly m copies of the preceding element. For example, \d{3} matches any three-digit sequence like 123 or 456.
{m,n}	Matches between m and n copies of the preceding element. For example, \d{2,4} matches 12, 123, or 1234 but not 1 or 12345. Omitting m means zero. Omitting n means unlimited.

Non-greedy repetition

By default, repetition operators are greedy—they match as much text as possible. Adding ? after a repetition operator makes it non-greedy, matching as little text as possible.

Syntax	Description
*?	Matches 0 or more, preferring fewer.
+?	Matches 1 or more, preferring fewer.
??	Matches 0 or 1, preferring zero.
{m,n}?	Matches between m and n, preferring fewer.

For example, given the text [first][second], the pattern \[.*\] matches the entire string because it is greedy. The pattern \[.*?\] matches only [first] because it is non-greedy.

Possessive repetition

Possessive quantifiers work like greedy quantifiers—they match as much text as possible. However, they never give back characters once matched, even if that causes the rest of the pattern to fail. This can improve performance when you know backtracking won't help.

Syntax	Description
*+	Matches 0 or more, never backtracking.
++	Matches 1 or more, never backtracking.
?+	Matches 0 or 1, never backtracking.
{m,n}+	Matches between m and n, never backtracking.

For example, \d++X fails on 123. The \d++ claims all the digits and refuses to release any for X to match. A standard greedy \d+X also fails here because there is no X. In patterns where backtracking is possible, possessive quantifiers prevent it and can significantly improve performance on non-matching inputs.

Escape character

Syntax	Description
\	Removes the special meaning of the next character, letting you match it literally. For example, \. matches a period, \* matches an asterisk, and \\ matches a backslash.

Character sets

A character set matches any single character from the set. Define a set using square brackets ([]).

Syntax	Description
[aeiou]	Matches any single vowel.
[a-z]	Matches any lowercase letter. A hyphen between characters defines a range.
[0-9]	Matches any digit.
[^aeiou]	A ^ at the start of a set matches any character not in the set. This example matches any character that isn't a vowel.

Alternation

Syntax	Description
\|	Matches the expression on either side. For example, yes\|no matches either yes or no. You can chain multiple alternatives: red\|green\|blue.

Groups

Parentheses group parts of a pattern together. A group can be used with repetition operators or alternation.

Syntax	Description
(...)	Groups the enclosed pattern. For example, (ha)+ matches ha, haha, hahaha, and so on.
(?:...)	A non-capturing group. Works the same as (...) for grouping, but doesn't save the matched text for later use.

Backreferences

A backreference matches the same text that was previously matched by a group.

Syntax	Description
\1, \2, etc.	Matches the same text captured by the corresponding numbered group. For example, (\w+)\s+\1 detects repeated words like the the or is is.

Atomic groups

An atomic group matches its contents and then discards all backtracking positions within it. If the overall pattern fails later, the engine cannot retry alternatives inside the atomic group.

Syntax	Description
(?>...)	Matches the enclosed pattern without allowing backtracking into it. For example, (?>order\|ord)er fails on order because after matching order inside the group, the engine can't go back and try ord instead when the trailing er fails.

Named groups

Named groups let you assign a label to a captured group, making complex patterns easier to read and maintain.

Syntax	Description
(?P<name>...)	Captures the matched text under the given name. For example, (?P<year>\d{4})-(?P<month>\d{2}) captures the year and month from a date like 2026-07.
(?P=name)	Matches the same text captured earlier by the named group. For example, (?P<tag>\w+).*(?P=tag) matches an opening and closing tag that use the same word.

Lookahead and lookbehind

Lookahead and lookbehind let you match a position based on what comes before or after, without including that surrounding text in the match.

Syntax	Description
(?=...)	Positive lookahead. Matches the current position only if the pattern ahead matches. For example, \w+(?=ing) matches walk in walking. It matches word characters only when they are followed by ing.
(?!...)	Negative lookahead. Matches the current position only if the pattern ahead does not match. For example, \d+(?!\.) matches 42 in 42 apples but not the 42 in 42.0. It avoids digits followed by a period.
(?<=...)	Positive lookbehind. Matches the current position only if the pattern behind matches. For example, (?<=\$)\d+ matches 100 in $100 but not in €100. The pattern inside must be a fixed length.
(?<!...)	Negative lookbehind. Matches the current position only if the pattern behind does not match. For example, (?<!\$)\d+ matches 100 in €100 but not in $100. The pattern inside must be a fixed length.

Special sequences

Special sequences start with a backslash (\) followed by a specific character. They provide shortcuts for common character classes.

Syntax	Description
\b	Matches a word boundary—the position between a word character and a non-word character. For example, \brun\b matches run in I run daily but not in running or rerun.
\B	Matches a position that is not a word boundary. For example, \Brun matches run in rerun but not at the start of run.
\d	Matches any digit (0–9).
\D	Matches any character that is not a digit.
\s	Matches any whitespace character such as a space, tab, or newline.
\S	Matches any character that is not whitespace.
\w	Matches any word character: letters, digits, and underscore (a–z, A–Z, 0–9, _).
\W	Matches any character that is not a word character.
\A	Matches only at the very start of the text.
\Z	Matches only at the very end of the text.

AI guardrails limitations

Keep the following limitations in mind when configuring AI guardrails:

• Maximum guardrails per environment: 10.
• Maximum guardrail name length: 200 characters.
• Maximum block message length: 500 characters.

• Maximum mask replacement length: 100 characters.

• Scope: AI guardrails apply environment-wide only. Per-object or per-application guardrail configuration is not supported.
• Actions: Block and Mask are the available actions. A Warn action (allow execution but flag in logs) is not available in this release.
• Feature coverage: AI guardrails apply to all generative AI features, excluding Enterprise Copilot, the a!documentsChat() function, and spreadsheet extraction AI skills.
• Streaming: When an output guardrail is active, streaming is disabled. The full response is evaluated before any content is returned to the user.
• Guardrail names: Must be unique within an environment. The UI enforces uniqueness. Duplicate names can only occur through manual editing of export files.

Feedback