Skip to Content
ConceptsPolicies

Policies

A policy is a versioned set of rules that Relynt evaluates for every agent request. Policies determine whether an action is allowed, denied, or requires human approval.

How policies work

When an agent calls the gateway, the policy engine:

  1. Looks up the active policy version for the organization
  2. Matches the request’s action and resource against policy rules
  3. Evaluates any conditions on the matching rule
  4. Returns a decision: allow, deny, or pending_approval

Every evaluation produces a structured result:

{
  "decision": "allow",
  "risk_level": "low",
  "requires_approval": false,
  "reason": "Action matches allow rule for update_deal",
  "policy_version": "v3"
}

Policy structure

Each policy version contains an ordered list of rules. Rules are evaluated top-to-bottom, and the first matching rule wins.

Rule fields

FieldDescription
actionThe action to match (e.g., update_deal, close_ticket)
resource_patternResource pattern with wildcard support (e.g., crm:deal:*)
decisionWhat to do when matched: allow, deny, or require_approval
risk_levelRisk classification: low, medium, or high
conditionsOptional conditions for more granular control

Resource patterns

Patterns support * wildcards:

  • crm:deal:* — matches any CRM deal
  • ticket:* — matches any ticket
  • * — matches everything (use with caution)

Conditions

Conditions provide fine-grained control within a rule. Supported conditions in v0:

max_amount_change

Deny or require approval if a numeric field exceeds a threshold:

{
  "action": "update_deal",
  "resource_pattern": "crm:deal:*",
  "decision": "allow",
  "conditions": {
    "max_amount_change": 10000
  }
}

If payload.amount exceeds 10,000, the request requires approval regardless of the base decision.

require_approval_if_stage

Require approval when a deal moves to certain stages:

{
  "conditions": {
    "require_approval_if_stage": ["closed_won", "closed_lost"]
  }
}

deny_fields

Block requests that attempt to modify specific fields:

{
  "conditions": {
    "deny_fields": ["owner_id", "created_at"]
  }
}

Conditions are AND-ed. If a rule has multiple conditions, all must pass for the base decision to apply. If any condition triggers, the action is escalated to deny or require_approval.

Versioning

Policies are versioned. Each time you modify a policy, a new version is created. Only one version can be active at a time.

  • Every receipt records which policy_version was evaluated
  • You can roll back by activating a previous version
  • Old versions are retained for auditability

Best practices

  • Start permissive — begin with broad allow rules and add restrictions as you identify risky actions
  • Use risk levels — classify rules by risk so approvers can prioritize
  • Version intentionally — treat policy versions like code releases, with clear reasons for each change
  • Test with the simulator — use the policy simulator to validate policy behavior before applying to production agents
Last updated on
AgentsReceipts