Policies
Policy sets hold the rules every proposed action is decided against. Each version is immutable; publishing a new one changes what the gate does next.
Three outcomes
When several rules match, the most severe outcome wins: refuse beats require approval, which beats allow.
Until a policy set is in force, the gate refuses by default. An action no policy permits is refused.
Always refused
Some checks come before any policy and cannot be waived. Whatever the policy says, an action is refused when:
- the caller is not authenticated,
- the agent did not declare the tool, or the tool version is not admitted,
- the tool has changed since it was admitted,
- the agent, tool or scope is suspended,
- a rate cap is reached,
- the arguments don't match the tool's schema,
- the delegated authority behind the call is invalid or doesn't cover the action,
- the audit trail can't be written.
Where a policy applies
A policy set applies at one level: the whole organisation, a workspace, a workflow, an agent, a tool or a resource. Decisions combine every set that applies.
What rules can check
| Rule | What it checks |
|---|---|
| Argument constraint | A value in the action's arguments — equal to, in a list, matching a pattern, within a minimum or maximum. |
| Value limit | Money: a maximum per action, run, day or 30 days, per agent, person or workspace. |
| Count limit | How many times something happens within a window. |
| Sequence | One action following another within a run or a time window. |
| Requires preceding | An action that is only allowed after a given earlier event. |
| Time window | Days and hours, in a time zone. |
| Data boundary | Where data is going: recipients, destination domains, regions. |
| Evidence required | Evidence the action must carry before it can run. |
| Reversibility gate | How hard the action is to undo. |
| Context match | Environment, data classification, purpose and risk class. |
A rule that requires approval also says who approves: roles, teams, named people or the requester's manager, how many of them, and in what order. See Approvals.
Rolling a policy out
Each version, and each rule in it, runs in a mode:
| Mode | What happens when a rule would hold or refuse |
|---|---|
| observe | The action is allowed; the decision records what would have happened. |
| warn | The action is allowed with a warning; the decision records what would have happened. |
| approve | The action requires approval. |
| enforce | The rule's outcome applies as written. |
Review and publishing
A policy version starts as a draft, is submitted for review, and is then published or sent back. The author cannot review their own version, and a version must be published by a person other than its author. Publishing a version retires the one it replaces.
Your platform team writes and publishes policy through the TaskGate API. The Policies page in the console shows every set, how many are in force, and each version.
Simulate before you publish
On a policy set, replay recent decisions against a new version to see which verdicts it would change before it goes live. Nothing is changed. The simulation lists the decisions that would change, with examples.