by AgentGuard (LX AI)
Agent guardrails are the input filters, tool permissions and output checks that constrain what an autonomous agent can do before, during and after a tool call. The NIST AI Risk Management Framework gives them a vocabulary: Govern, Map, Measure, Manage.
I started AgentGuard after watching a team ship an LLM‑powered agent that could read a database, call a payment API and send email, all with a single prompt. The agent worked in the demo, but a simple typo in the user query caused it to transfer money to the wrong account. No one had checked what the agent was allowed to do before the call, and there was no way to stop it once the mistake happened.
I realized that the problem was not the model itself but the missing boundaries around its actions. I wanted a repeatable way to list every tool an agent can reach, decide who can enable each tool, test the agent against the permissions we think it has, and react when something goes wrong. The NIST AI Risk Management Framework gave me the four functions that line up exactly with those steps.
In the sections below I show how each function maps to concrete guardrail practices, how we rate the risk of a tool call, and what you can actually do today with the AgentGuard product.
These are checks that run on the user prompt or the agent’s internal reasoning before a tool is invoked. Examples include:
We implement input filters as lightweight regex engines combined with a small allow‑list of safe patterns. They add less than two milliseconds of latency per call.
Tool permissions define what data a tool can read, write or delete, and which external services it may contact. We store each permission as a tuple:
customers table, write access to audit_log)api.paymentprovider.com on port 443)When the agent asks to use a tool, the permission service checks the tuple against the current context and either allows the call, modifies the parameters, or blocks it.
After a tool returns a result, output checks verify that the response stays within the expected bounds. Examples:
If a check fails, the system can truncate the result, redact sensitive bits, or trigger an alert.
The framework’s four functions give a clear structure for organizing guardrail work. Below is a table that shows which guardrail belongs to each function, the concrete artifact we produce, and a short example.
| NIST function | Guardrail type | Artifact | Example |
|---|---|---|---|
| Govern | Approval workflow | Tool enablement record | A signed document that lists who approved the send_email tool, the date, and the required MFA for the approver. |
| Map | Tool inventory | Permission matrix | A spreadsheet that enumerates every tool, the tables it can read/write, and the external endpoints it may call. |
| Measure | Test suite | Adversarial prompt set | A collection of prompts designed to trigger privilege escalation, data exfiltration, or unauthorized external calls. |
| Manage | Runtime response | Kill‑switch log | A timestamped entry that records when the agent tried to delete a production record, the action that was blocked, and the operator who was notified. |
Each function builds on the previous one. Govern decides who may add a new tool to the inventory. Map creates the inventory that Measure will test against. Measure produces evidence that Manage can act on. The loop repeats whenever the tool list or the agent’s prompt changes.
We start by looking up the tool in the permission matrix. The matrix assigns a base risk level:
If the tool requires an approval token, we add one level to the base risk.
We run the user prompt through the input filter engine. If the engine detects a pattern from the OWASP prompt injection cheat sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) we increase the risk by one level.
We examine the data sources the tool can touch. If any source contains personally identifiable information (PII) or financial data, we add another level.
The final rating is the sum of the base level, prompt‑level, and data‑level adjustments. Based on the rating we recommend:
This rating is recomputed each time the tool list changes, ensuring the guardrails stay aligned with the agent’s capabilities.
I want to be clear about the limits of guardrails so you do not mistake them for a silver bullet.
Export the exact text that the agent receives at startup and the JSON or YAML file that declares every tool it can call.
For each tool, record:
Apply the four‑step rating process described earlier. Record the initial risk level for each tool.
Based on the risk level, produce concrete filter rules (regex patterns, row‑count limits, redaction rules). Store them alongside the tool definition.
Run the agent against the prompt set from the Measure column of the table. Verify that the filters block or mitigate the expected failure modes.
Create a short report that lists:
Configure the agent’s runtime environment to log every tool call, the applied filters, and the output check results. Route anomalies to your incident‑response channel.
Mark the workflow to repeat when any of the following occurs:
Teams sometimes think that adding a keyword blocker is enough. We counter this by requiring both input and output checks for any medium or high‑risk tool, and we log when either check fires.
When a tool gains a new capability (e.g., a payment API now supports refunds), the matrix must be edited before the agent can use it. We enforce this by making the matrix a version‑controlled file that the CI pipeline validates on every push.
A read‑only lookup that returns a user’s email address can become dangerous if the agent later uses that address in a password‑reset flow. We treat data sensitivity as a separate rating factor, so a low‑level tool that touches PII is automatically upgraded.
For tools that can move money or delete records, we mandate an explicit approval step that cannot be bypassed by automation. The approval is recorded in an immutable log.
We embed the review workflow into the team’s definition of done for any feature that changes the agent’s behavior. This makes the process repeatable rather than a forgotten checklist item.
No. They constrain the blast radius of a mistake. A determined attacker, a mis-scoped tool or a bad prompt can still cause harm inside the boundary you allowed.
The agent's system prompt and its tool list. That is enough to rate calls and suggest filters.
No. It is a mapping to help you find the right obligations. Classifying your system and meeting the obligations still needs a qualified reviewer.
Whenever the tool list, the system prompt or the data a tool can reach changes.
It reviews the prompt and tool configuration. Runtime monitoring is a separate layer you still need.
Require an approval step, narrow its parameters, and log every invocation. High-risk tools usually need a human in the loop rather than a filter.
Try the product: AgentGuard
AgentGuard reviews an agent's prompt and tool list and rates the risk of each tool call, then suggests input and output filters. A read-only lookup is a different risk class from a tool that sends email, moves money or deletes records — rating them the same way is how teams end up with a guardrail that looks thorough and stops nothing.
AgentGuard reviews an agent's prompt and tool list and rates the risk of each tool call, then suggests input and output filters. A read-only lookup is a different risk class from a tool that sends email, moves money or deletes records — rating them the same way is how teams end up with a guardrail that looks thorough and stops nothing.
A per-tool risk rating, suggested input/output filters, and an EU AI Act mapping you can hand to whoever owns governance. The point is that the review is repeatable: re-run it when the tool list changes, not only at launch.
No. They constrain the blast radius of a mistake. A determined attacker, a mis-scoped tool or a bad prompt can still cause harm inside the boundary you allowed.