Operate / Day two

Approvals queue

Give it an owner, measure the response time, and understand why an expired approval is worse than a denied one.

#Work it

/approvals in the console, with a pending-count badge.

Each card carries the full decision context, which is deliberate:

• The agent, its delegation chain, and what it is acting for
• The tool, the capability, the parameters, the amount
• The policy and rule that required approval, with the conditions that matched
• The risk level, score and every signal that fired, each with its explanation
• The agent's recent action history
• The purpose the agent supplied
• The blast radius, for a destructive tool

#Deny with a real reason

bashCopy
curl -X POST $CP/v1/approvals/apr_01ABC/deny \
  -H "Authorization: Bearer $KEY" \
  -H 'content-type: application/json' \
  -d '{ "reason": "Order ord_8812 was already refunded on 1 Oct" }'

The reason reaches the agent as the message on APPROVAL_DENIED, so it can report something meaningful upstream instead of "the request failed". "Denied" on its own wastes the one chance to explain.

#Measure it

promqlCopy
histogram_quantile(0.95,
  rate(veefore_approval_decision_duration_seconds_bucket[1h]))

Your approval SLA, measured rather than asserted.

Alert on it:

yamlCopy
- alert: VeeforeApprovalsNotBeingWorked
  expr: |
    histogram_quantile(0.95,
      rate(veefore_approval_decision_duration_seconds_bucket[1h])) > 900
  for: 30m
  labels: { severity: warning }

#Route it somewhere people are

Subscribe a webhook to approval.requested and push it into chat.

bashCopy
curl -X POST $CP/v1/webhooks \
  -H "Authorization: Bearer $KEY" -H 'content-type: application/json' \
  -d '{
    "name": "approvals-to-chat",
    "url": "https://hooks.internal.example.com/veefore-approvals",
    "event_types": ["approval.requested"]
  }'

#Set the TTL per rule

jsonCopy
{
  "then": {
    "decision": "REQUIRE_APPROVAL",
    "reason": "Refunds above ₹1,000 require a human approver.",
    "approval": {
      "routingMode": "SINGLE",
      "requiredApprovals": 1,
      "approverRoleKeys": ["APPROVER"],
      "ttlSeconds": 900
    }
  }
}

Match the TTL to how fast a human can realistically respond to that particular thing, not to a round number.

An approval that always expires is a rule that always blocks, dressed up as a rule that asks.

#Routing

requireStepUp: true forces the approver to re-authenticate at the moment of approving. Use it for anything irreversible — it means an unattended, still-valid browser session is not enough.

When several rules both require approval, the effects merge conservatively: the maximum requiredApprovals, the minimum ttlSeconds, the union of approver roles, and requireStepUp true if any rule asked for it.

#Separation of duties

By default SECURITY_ADMIN does not hold approval:approve, and neither does DEVELOPER. Only APPROVER, ADMIN and OWNER do.

That is deliberate: the person who wrote the rule requiring approval should not be the person satisfying it. Grant the overlap explicitly if your organization genuinely wants it, having decided to.

#Tuning the rules themselves

Review monthly. For each approval rule ask:

Is it firing too often? A rule that fires on most actions is not a control, it is a tax, and approvers will start rubber-stamping. Narrow the condition or raise the threshold.

Is it never firing? Either the threshold is wrong or the rule is describing something that does not happen. Both are worth knowing.

Is it being worked around? If a human is regularly doing the thing manually after an approval is denied, the rule is wrong, not the control. Find out what it should have said.

Is the right person deciding? An approver who always defers to someone else is not the approver; the person they ask is. Change the routing.

#Related