AI Guardrails: Set Rules, Permissions, and Review Points
AI guardrails combine instructions, enforced limits, and human review. Set them around a real workflow so a convincing answer cannot quietly become an unauthorized action.
Updated 5 min read
AI guardrails are the instructions, technical limits, and review points that keep AI-assisted work within an agreed scope. To set them, define the allowed task, restrict what the assistant can access or change, and put a person before actions that need approval. Written rules alone cannot enforce those boundaries.
fenbs keeps agreed rules and decision history available to connected assistants, while permissions in the system performing an action must enforce access. This distinction matters when an assistant can do more than write an answer. A mistaken draft can be corrected; a sent message or deleted record may already have affected someone.
How do you set guardrails around one workflow?
Begin with a small workflow you can describe from input to final action. For example, let an assistant prepare a reply to a routine customer question using approved help material. Treat drafting the reply and sending it as separate actions, with separate permissions and checks.
- Define the useful output: a draft reply with links to the approved source material, ready for a person to check.
- List excluded work: no account changes, compensation offers, or answers about topics outside the supplied material.
- Choose permitted inputs: only the information needed for this question and the relevant approved references.
- Limit available actions: grant access to prepare the draft without granting the ability to send or change customer records.
- Set the review and stop points: a person checks the response, and unanswered or sensitive questions go to the appropriate colleague.
Name who will check that these limits work. Our guide to using AI at work helps you choose a suitable task before adding more connections or authority.
Which limits actually stop an action?
Different safeguards do different jobs. An instruction can guide an answer. A permission can deny a request regardless of what the assistant says. A review point can let a person judge a proposed action, provided the system waits for that judgment before proceeding.
| Safeguard | Example | What to verify |
|---|---|---|
| Written instruction | Draft replies without promising refunds. | Does the assistant understand the task and recognize exceptions? |
| Access permission | The connection cannot issue a refund. | Does the service refuse the action when directly requested? |
| Output check | A form requires a valid order reference. | Does validation reject invalid input before a change occurs? |
| Human approval | A person approves the exact outgoing reply. | Can the assistant send or alter the reply without another approval? |
| Activity record | Record who changed the task and what was approved. | Can a later reviewer identify the action and its scope? |
An activity record helps explain what happened afterward; it is not a substitute for blocking an unauthorized action. Keep the approved rules in fenbs, and enforce external tool permissions where those tools perform the work.
Why are prompts alone an incomplete boundary?
An assistant can misunderstand a rule, miss relevant context, or encounter conflicting instructions inside material it reads. Prompt injection means content tries to redirect the assistant’s behavior, such as a web page telling it to reveal private information. A convincing instruction is still text the model must interpret.
The OWASP guidance on prompt injection (opens in a new tab) recommends measures including limited privileges, validation, separating untrusted content, and human approval for high-risk actions. These measures reduce the consequences of a model following the wrong instruction; a prompt by itself does not provide the same protection.
Keep secrets out of prompts and give connections only the access required for the task. When an outside page contains apparent commands, treat them as material to examine rather than authority to follow. A shared AI brain can preserve your instructions, but it cannot guarantee that a model obeys them.
How do you test whether the boundary holds?
Test the ordinary task and the prohibited action. Use a test account or harmless sample data where possible. Ask for an action outside the agreed scope, then inspect whether the underlying system refused it. An assistant saying “I cannot do that” is weaker evidence than a service rejecting a request it received.
- Try a missing or invalid reference and check that it cannot change the wrong record.
- Include a harmless instruction inside source material asking the assistant to ignore its task, then inspect the result.
- Request an action beyond the connection’s role and verify the actual denial.
- Check that the reviewer sees the final destination, proposed change, and relevant source before approving.
- Change a permitted input after approval and check whether the action requires review again.
The NIST Generative AI Profile (opens in a new tab) addresses testing and risk management across the use of generative AI. For your workflow, save the conditions and results of each check so later changes can be evaluated against the same boundary.
What happens when the task needs an exception?
An exception should return the decision to a person with authority, rather than invite the assistant to improvise. The assistant can explain what it needs and why the current rule blocks progress. The person can approve a narrower alternative, change the rule, or decline the request.
For example, a draft may need a refund explanation that the approved material does not contain. The next step is to ask the right colleague for an answer, not to grant broad account access. If additional access is appropriate, specify the task and remove it when that work ends.
Record whether the choice applies once or changes future work. Without that distinction, a later assistant may treat a single exception as permission for every similar case.
Keep a one-time exception from becoming the rule
Record the person’s decision and its scope in fenbs, and keep ongoing instructions in Decisions and rules. History shows who changed the work record. Assistants can record what a person decided, but cannot decide or sign off themselves.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
When should you revisit the safeguards?
Recheck the boundaries when the model, connected tools, account permissions, input sources, or intended audience changes. A workflow that only produced private drafts has changed materially if it can now publish them. A previously useful test may not cover the new consequence.
Also review near misses: a reviewer catching an unsupported promise is evidence about where the process needs work. Save the lesson and the approved replacement rule in fenbs, then retest the relevant control. Avoid adding rules that nobody can interpret or verify.
How to keep the guardrail record with fenbs
- Create a free account, then add the project and the task whose boundaries you want to make clear.
- Record the human-approved scope, forbidden actions, and required review points in Decisions and rules.
- Add tasks for checking actual tool permissions. Record the observed results and any limits of the tests.
- Connect an assistant using the integration guides, have it read the AI context before work, and save progress when the session ends.
fenbs is free for one person, with no credit card. It is useful for keeping agreed boundaries available across assistants. It is not the right fit if you need software to inspect every model response or block actions in external systems; it does not perform those jobs.
Use the AI governance guides to connect these workflow controls to your team’s wider rules. Start with the action that carries the clearest consequence, and make its boundary testable.