Mapping policies to high-risk actions

Before you write a single policy, write down the actions you are afraid of. Not features, not endpoints — the specific operations that move money, change commitments, or touch a customer in a way you cannot quietly undo. Refunds. Credits. Plan and price changes. Contract sends. External messages. That list is your real attack surface, and it is usually short.

Start from the action catalog

Each entry on that list becomes an action type — a canonical name like issue_refund or change_plan_or_price. Action types are the vocabulary every other part of the system shares: your SDK calls them, your policies decide on them, your audit records them. Naming them deliberately is the single most valuable thing you do, because everything downstream keys off that name.

One policy per action, per environment

A policy attaches decision logic to an action type inside an environment. Sandbox and production are separate on purpose: the same issue_refund action can be wide open while you evaluate and strict once real customers are involved. A policy answers a single question — given this payload and context, is the action allowed, denied, or does it need a human?

Thresholds and approver routes

Most real policies are a few honest rules rather than a sprawling rulebook. The canonical example:

• A refund of 100 or less is allowed directly and returns a permit immediately.
• A refund over 100 requires approval and routes to a named approver group.
• Anything that does not match a rule is denied.

That last line is the important one. Default-deny means a policy gap fails safe: an action you forgot to consider does not slip through, it stops. You add permission deliberately, never by omission.

Approvals resolve to the same artifact

When a policy requires a human, Veritrellis creates a pending request, surfaces it in the approvals inbox, and emails the assigned approver group a link to review it. On a decision, the requester is emailed the outcome. Once approved, the request produces the same signed permit a directly-allowed request would. Your execution code does not branch on "was this auto-allowed or human-approved" — it verifies a permit, full stop.

Audit is not an afterthought

Every request, every approval decision, every permit issued, and every policy change is written to an append-only product audit stream. That trail lives independently of your model logs and your application logs, which means a security or compliance reviewer can answer "who allowed this action, under which policy, and when" without reconstructing it from inference traces. The audit is a record of authorization decisions, not a transcript of what a model said.