> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Standards & Guardrails
> The standards every new agent inherits, and the deterministic rules that block, hold, redact, or flag an action at the boundary — every decision recorded.
Permissions decide what an identity may do; standards and guardrails decide how it is built and what
it may do *right now*. Standards apply your organization's rules at the moment an agent is created,
and guardrails inspect each action as it crosses the boundary, refusing or rewriting it before it
lands. This page covers both, and where each one is the right tool.
## Standards — applied when an agent is created
**Create agent** on the Fleet screen opens a four-step flow — *What should it do*, *Definition*,
*Standards pack*, *Review & create* — and the third step applies your organization's **standards
pack** automatically. The point is that a new agent cannot quietly ship without an owner, a budget,
or grading, because those are not steps somebody has to remember.
| Standard | What it settles |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Guardrails** | The default posture for the agent's actions — read-only work proceeding on its own, privileged diagnostics asking first, and mutations always asking. |
| **Quality judges** | Which judges grade its runs, and at what sampling rate. |
| **Memory & knowledge** | The history and knowledge the agent can draw on. |
| **Cost budget** | A per-run and per-month ceiling. |
| **Ownership** | The team that owns this agent, and where they are reachable. |
| **Escalation route** | Where something goes when the agent cannot finish it. |
| **Docs** | An agent card generated from the above: what it does, what it may do, and who owns it. |
Each standard fills in as the step loads, and the pack is scored out of seven — **7/7** when
everything applies. The last step restates it as a **standards scorecard** next to the agent
summary, and that is what you confirm before creating.
Every standard except **Docs** carries a **Waive** switch. Waiving one drops the score — 7/7 becomes
6/7 — and the row shows **Waived** in place of its value rather than disappearing. The governance
value here is legibility, not enforcement: an agent with a waiver is fine, an agent whose waiver
nobody can see is not.
Once created, the agent carries a standards badge in the fleet, so the state of its governance is
visible from the list rather than only at creation time.
## Guardrails — enforced at the action boundary
A guardrail is a rule you configure that decides whether a specific action may proceed. It is
evaluated **outside the agent**: an agent cannot skip a guardrail, because the check does not run in
the agent's own process. It runs at the boundary the agent's traffic has to cross.
You author them under **Standards & Guardrails**, which lists your rules on a **Policies** tab with
**Add policy** to create one, and their decision trail on an **Activity** tab. Each rule is filtered
by the action it takes — Blocking, Hold for approval, Redacting, or Alert only.
A guardrail governs traffic that goes through the platform's gateways. An agent reaching an external
system by some other path is outside this control — which is the strongest argument for routing
everything through the built-in integrations or the
[MCP Gateway](/manage-your-agents/build/mcp-gateway).
### The five gates
A guardrail stands at one gate, and the gate is fixed for the life of the rule.
| Gate | What it inspects |
| ------------------ | ------------------------------------------------------------------------------ |
| **Agent start** | The run as it is created, before the agent does anything. |
| **Tool call** | A tool call on its way out, including its arguments. |
| **Tool response** | What a tool returned, on its way back to the agent. |
| **Model request** | What is being sent to a model, including the instructions the agent was given. |
| **Model response** | What the model sent back. |
### What a guardrail does on a match
| Outcome | Effect |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Block** | The action is refused. This is the default, because someone authoring a rule is asking for a control. |
| **Hold for approval** | The action pauses and waits for a human decision instead of being refused outright — the human-in-the-loop posture for mutating work. See [Approvals](/security-and-governance/controls/approvals) for what the decider sees. |
| **Redact** | The action proceeds with every matched value replaced. Useful for keeping a credential out of a third-party tool call or a model prompt. |
| **Alert only** | The action proceeds and the match is recorded — the detect-only posture, for a rule you want measured before you enforce it. |
Every outcome is recorded either way, so a guardrail always produces an activity trail whether it
intervened or not. The **Activity** tab is that trail: when, which agent, the outcome, the rule that
decided, and the action it was deciding about.
Redaction reads differently in each direction. On the way *in* — a tool result, a model answer — the
agent can see that something was removed and reason about it. On the way *out* the agent composed
the text and is not shown the rewrite, so it may go on to interpret a reply to a question it did not
actually ask. When the agent needs to act on what comes back, block is the honest choice.
### Who a rule covers
Target a guardrail at explicit agents, or at a label bag the calling agent's own labels must
contain. Labels are the durable option: a rule scoped to `env = production` keeps covering the right
agents as the fleet changes.
### Matching a call
The authoring form is a picker rather than a syntax. It lists the tools your workspace actually has,
grouped by server, so you are choosing from reality instead of guessing at tool names. A glob
pattern is available as an alternative — a selection covers the tools that exist now, a pattern
covers the ones that arrive later — and the form reports how many of your current tools a pattern
matches.
A pattern that matches nothing is the mistake to watch for: it produces a guardrail that looks
active and protects nothing. Check the match count the form shows you.
You can also condition on a tool's **arguments**, chosen from the real argument names of the tools
you picked, and on **named value classes** — a payment card number, a cloud access key — which match
a kind of value rather than a string you had to write yourself.
The empty state offers the three rules most workspaces want first, so a first guardrail is an edit
rather than a blank page: **no destructive Kubernetes actions**, **nothing that writes to
production**, and **no payment card numbers reaching a model**. The third one is a redaction rule at
a model gate using a named value class — a useful shape to read even if you do not keep it.
### Test a rule before it is live
A draft rule can be **backtested** against recorded traffic, so you see what it would have done
before it does it. That is what makes it reasonable to write a blocking rule against production:
backtesting shows how the rule would have affected the recorded traffic you tested it against,
rather than leaving you to discover it live.
## Which one to reach for
| Situation | Use |
| ----------------------------------------------- | -------------------------------------------------------- |
| Every new agent must have an owner and a budget | A standard |
| This class of tool call must never happen | A guardrail set to block |
| A secret must not reach a third-party tool | A guardrail set to redact |
| I want to measure before enforcing | A guardrail set to record, plus a backtest |
| A person should decide this case by case | [Approvals](/security-and-governance/controls/approvals) |
## Next steps
When the right answer is a human decision rather than a rule.
The permission layer a guardrail sits on top of.
Where guardrail decisions are recorded.
What is masked without any rule at all.
## Related topics
- [Production Readiness & Standards](/modules-and-workflows/ops-automation/production-readiness.md)
- [How it works](/security-and-governance/how-it-works.md)
- [Network & egress control](/security-and-governance/architecture-considerations/network-egress-control.md)
- [Integrations overview](/manage-your-agents/build/integrations-overview.md)
- [Attention](/manage-your-agents/run/attention.md)