
Persona Guardrail: A Production-Grade Defense Framework for Agentic Systems
Persona Guardrail is a production-grade runtime defense framework for customer-facing LLM agents that enforces explicit functional boundaries via synchronous input/output validation against semantic allowlist and blocklist specifications. The authors also introduce PAGE (Persona-Aware Guardrail Evaluation), a benchmark covering benign, adversarial, and out-of-domain user and agent turns; deployed in production, it raises overall accuracy from 85.7% to 95.9% versus a generic LLM-based guardrail, boosts out-of-domain detection from 57.3% to 93.5%, and cuts the false-approved rate from 25.0% to 4.7%, all within latency budget.
What it is
Persona Guardrail is Uber's production runtime defense for customer-facing LLM agents, built around a single formal abstraction: the agent's functional boundary. The paper (Pal et al., Uber, arXiv:2610.03434v1) defines this as a partition of the query space Q into Qallow and Qblock — the guardrail's job is to approximate that partition with minimal false positives (blocking legit queries) and false negatives (allowing malicious/out-of-domain ones).
How it works
The system sits synchronously on both ends of the agent: an input guardrail validates user requests before they reach the agent, and an output guardrail validates generated responses before they're returned to the user. Neither can run asynchronously, since both make blocking decisions on the critical path.
The functional boundary itself is represented via a hybrid allowlist-blocklist, chosen after evaluating three alternatives:
- Allowlist-only: secure but overly conservative — incomplete enumeration of legitimate requests drives false positives and hurts UX.
- Blocklist-only: covers both security-driven entries (prompt injection, jailbreak patterns) and functionality-driven entries (out-of-domain requests that are benign but outside the agent's intended purpose).
- Hybrid: combines both, and is the design Persona Guardrail adopts.
A key operational detail: whether out-of-domain queries are blocked at all is configurable per deployment — some agents are built as narrow specialists and reject OOD queries, others may permit them. The boundary itself is not static; it's continuously refined using production telemetry, attack simulations, and deployment feedback, rather than fixed at design time.
Preconditions / Affected
Applies to customer-facing agentic systems where an external user has black-box query access (no access to system prompts, internal tools, memory, or orchestration logic). The threat model explicitly excludes indirect prompt injection, tool poisoning, and memory poisoning — those attack the agent's internals, not its public interface, so this guardrail does not inspect intermediate reasoning or tool calls, only the input/output boundary.
flowchart LR
U[User query] --> IG[Input Guardrail]
IG -->|Qblock: malicious/OOD| R1[Reject]
IG -->|Qallow| A[Agent: LLM + tools/APIs]
A --> OG[Output Guardrail]
OG -->|violates boundary| R2[Reject]
OG -->|within boundary| OUT[Return to user]Caveats
The paper itself scopes out indirect prompt injection, tool poisoning, RAG poisoning, and memory poisoning as outside the evaluated threat model — Persona Guardrail may incidentally catch a policy-violating final response caused by such attacks, but it doesn't inspect intermediate agent actions. The fetched text cuts off mid-description of the input/output enforcement mechanics (section 3.2+), so implementation specifics (e.g., what model/classifier performs the semantic match, how the closed-loop feedback updates the lists) aren't captured here beyond what the existing summary's numbers already convey.
Technologies named here
- Persona Guardrail
- LLM-based agentic AI systems
- PAGE
- Generic LLM-based guardrail
- LLM
Techniques named here
- Prompt Injection
- Out-of-domain querying
Related in AI Security
