Agent Guardrails: Real-Time Safety for AI Agents

AI agents are powerful. They can draft emails, summarize documents, call APIs, and make decisions. But they also inherit every risk that comes with running a language model in production: prompt injection, PII leakage, off-topic responses, system prompt exposure, and outputs that violate defined content policies.

Shipping an agent to production and hoping it behaves is not a safety strategy. Runtime checks must sit between users and the agent, inspecting every input and output before either can cause harm. Connic Guardrails provides those checks.

The threat model has also moved beyond model output. The OWASP Top 10 for Agentic Applications 2026 now covers goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, and cascading failures. Connic pairs real-time input and output inspection with scoped tools, approvals, iteration limits, and traces so teams can address those risks across the full agent run.

Why Agents Need Guardrails

Traditional software is deterministic. If a developer writes a function that adds two numbers, it adds two numbers. Language models are different. The same prompt can produce wildly different outputs depending on context, temperature, and how creatively a user phrases their request.

This unpredictability creates real risks in production:

Connic Guardrails address all of these. They run as a configurable layer around the agent, inspecting content in real time and taking action before damage is done.

Further reading: OWASP Top 10 for Agentic Applications 2026.

How Guardrails Work

Guardrails sit in the execution pipeline of every agent run. They check content at two points: before the agent processes the input, and after the agent produces a response.

Input guardrails evaluate the raw user message before the agent sees it. If a guardrail detects a prompt injection attempt, the message is blocked and the agent never executes. If PII is detected, it can be redacted in place so the agent receives a sanitized version.

Output guardrails evaluate the agent's response before it reaches the user. If the response contains system prompt fragments, toxic content, or data exfiltration patterns, the guardrail intercepts it. The user gets a safe rejection message instead.

Three Modes of Action

Every guardrail rule operates in one of three modes. This provides fine-grained control over how aggressively each check should respond:

10 Built-In Guardrail Types

Connic ships a set of guardrail types that cover the most common safety needs for production agents. Each can run on input, output, or both.

Configuration in YAML

Guardrails are defined in the agent's YAML configuration. Each rule specifies its type, mode, and optional parameters. Input and output guardrails are configured separately so each stage can use different checks.

guardrails:
  input:
    - type: prompt_injection
      mode: block
    - type: pii
      mode: redact
      config:
        entities: [email, phone, ssn]
    - type: topic_restriction
      mode: block
      config:
        allowed_topics: [support, billing]
        off_topic_message: "I can only help with support and billing questions."
  output:
    - type: moderation
      mode: block
    - type: system_prompt_leakage
      mode: block
    - type: pii_leakage
      mode: redact
    - type: relevance
      mode: warn

This configuration blocks prompt injection on input, redacts PII from user messages, restricts the agent to support and billing topics, and then checks the output for moderation violations, system prompt leakage, PII in the response, and relevance drift.

Writing Custom Guardrails

When the built-in types are not enough, custom guardrails can be written in Python. Create a module in the agent's guardrails/ directory that exports a check() function. It receives the content being checked and a context dictionary with metadata about the current run.

from connic import GuardrailResult

COMPETITORS = ["acme corp", "rival inc", "other platform"]

def check(content: str, context: dict) -> GuardrailResult:
    content_lower = content.lower()
    for name in COMPETITORS:
        if name in content_lower:
            return GuardrailResult(
                passed=False,
                message="I'm not able to discuss other platforms.",
                details={"matched": name},
            )
    return GuardrailResult(passed=True)

Then reference it in the YAML configuration:

guardrails:
  output:
    - type: custom
      name: competitor_mentions
      mode: block

Full Observability with Traces

Every guardrail evaluation is captured as an OpenTelemetry trace span. The trace shows what was checked, what passed, and what was blocked or redacted.

That data answers questions such as: How often is prompt injection being attempted? Which agents trigger the most PII redactions? Are topic restrictions too aggressive? The data is there for every run.

External Providers

Several built-in guardrail types support external providers for more accurate detection. Teams can swap the default detection engine for a specialized service without changing the guardrail configuration:

Real-World Examples

A few guardrail configurations teams run in production:

Getting Started

Adding guardrails to an existing agent takes minutes:

1. 1

   Open the agent's YAML configuration and add a guardrails section with the required rules

2. 2

   Deploy the agent. Guardrails activate automatically on the next run

3. 3

   Check the Traces tab in the Connic dashboard to see guardrail spans for each run

4. 4

   Open individual runs to inspect which guardrails fired and drill into blocked requests

Start with prompt injection and PII detection. Those two cover the most common attack vectors. Then layer on topic restriction, moderation, and custom checks as traffic patterns become clear.

For the full configuration reference and all available options, check the Guardrails documentation. Teams new to our platform can start with the quickstart guide to deploy a first agent, then add safety layers around it.