AGT — prompt-injection detector
The built-in, in-process prompt-injection detector
AGT — prompt-injection detector
The AGT provider wraps the platform's baseline prompt-injection detector (Microsoft agent-governance-toolkit). It runs in process — no services to deploy, no network hop, sub-millisecond evaluation — and is the only provider that works out of the box on every instance.
The migration seeds one row, prompt-guard-agt, serving pre_call in enforce
mode. Deleting it re-enables the built-in fallback screen; setting Default
On = Off on an existing row disables the detector entirely — absence of a row
is not an admin decision, but a disabled row is.
| Hook | Notes |
|---|---|
pre_call | Screens inbound chat text. |
Configuration
| Field | Meaning | Example |
|---|---|---|
allowed_categories | Only findings whose policy categories intersect this list are block-capable; everything else is still recorded as an observation. Empty = all categories allowed. Categories: direct_override, delimiter, role_play, context_manipulation, multi_turn, encoding, blocklist. | ["direct_override", "encoding"] |
timeout_ms | Framework knob — the detector itself is in-process and fast. | 1500 |
on_error | fail_open (default) or fail_closed. | fail_open |
{
"allowed_categories": ["direct_override", "encoding"]
}Blocks vs observations
The detector's strength on a turn decides the verdict: a single self-sufficient
signal (an unambiguous override, a blocklist hit) is block-capable, while softer
multi-signal findings are recorded as observations. On top of that, the legacy
Admin → System → Security mode still applies: in audit mode the AGT row
logs findings but cannot block regardless of its Enforce switch; only in
enforce mode can an enforcing row actually refuse a turn.
Findings from this provider appear in the guardrail events log like any other
provider, and enforcement also keeps the legacy prompt_guard.* audit trail —
so historical dashboards stay comparable after the framework rollout.