Permissions decide what an agent is able to do. Guardrails inspect what it is trying to do and can block or flag it. You need both, but permissions come first, because they hold even when the model is fooled and a filter misses.
Two different jobs
A permission is enforced by the system that owns the resource. A read only database role cannot write, whatever the agent says. OWASP's excessive agency guidance puts it this way: enforce authorization in downstream systems instead of relying on the model to decide what is allowed.
A guardrail sits between the model and the world and examines content or actions. OWASP's prompt injection page lists input and output screening with rules, semantic checks and relevance checks, and deterministic validation of output formats.
Where each is strong
- Can the agent delete the table?: Permissions: Decide it, Guardrails: Can warn
- Did the output contain a card number?: Permissions: Weak, Guardrails: Good fit
- Is this URL on the allowlist?: Permissions: Network layer, Guardrails: Good fit
- Is this tool call unusual for this task?: Permissions: Weak, Guardrails: Good fit
- What if the model is fully fooled?: Permissions: Still holds, Guardrails: May miss
Permissions are blunt but reliable. Guardrails are flexible and contextual, but they are pattern matching against an attacker who can try many phrasings.
A build order
- Start with permissions: narrow tools, narrow scopes, per user identity.
- Add approval for irreversible actions.
- Add deterministic checks on structured output and tool arguments.
- Add content screening for sensitive data and obvious injection patterns.
- Add monitoring and anomaly alerts. OWASP says monitoring will not prevent excessive agency, but it limits damage.
Skipping to step four, which is the one that feels most like AI security, leaves the damage ceiling unchanged.
A useful test for any control
Ask what happens if the control fails open. If the answer is the agent can still only read a small data set, you have good permissions underneath. If the answer is it can send mail to anyone, the guardrail is carrying a load it cannot carry.
Common misunderstandings
Some teams treat a guardrail as a replacement for access control because it is easier to install. It is easier, but it protects against a different failure. A guardrail catches the obvious bad request. A permission limits the damage from the one it misses.
Others assume permissions alone are enough, then discover that a permitted action can still be harmful in context, such as a legitimate send to the wrong recipient. Guardrails and approval steps cover that gap, since they can look at the content and the destination.
How to explain it to a manager
Permissions are the locks on the doors. Guardrails are the guard who looks at who is walking up to the door and what they carry. A building with only a guard depends on one person being right every time. A building with only locks cannot notice that someone is behaving strangely. Most programs need both, with the locks installed first.
Where Safeguard fits
Safeguard includes policies, gates and guardrails, an MCP Guardrail and agent identity, covering both sides: who the agent is and what it is allowed to call.
Quick check
If I have a strong guardrail, can I loosen permissions?
No. A guardrail can be bypassed by new phrasing. Keep permissions narrow so a miss has a small effect.
Sources
Last reviewed: 19 October 2026.
