Approve queue
Agents propose changes; they do not apply them until a human approves (and ops enables execution on the API).
Console
Owners and admins see Approve queue on the AI Teammates page when proposals are pending, and Recent approve decisions for executed, failed, or rejected items.
API: GET /v1/ai/approve-actions?status=pending and GET /v1/ai/approve-actions/history?limit=20.
Execution flag
Mutators (disable alert rule, update finding status) run only when the operator sets OWLPANE_AI_APPROVE_EXECUTE=true on the API. Without it, approvals are recorded only.
Restart and scale with payload.cluster (linked cluster name) queue kubernetes_ops when the operator sets OWLPANE_AI_APPROVE_K8S_EXECUTE=1 and the cluster has ops enabled. Without cluster or the flag, approval is audit-only (suggested kubectl in the audit trail).
Alert group and composite proposals remain audit-only (console / Alerts UI follow-up).
Slack (optional)
When OWLPANE_AI_SLACK_APPROVE=1 and a Slack app channel is connected, new proposals post Approve / Reject buttons. Owners/admins link their Slack member ID under Settings → AI → Slack approve. With OWLPANE_AI_SLACK_APPROVE_RBAC=1, only linked members can approve from Slack (console admins always can). Configure interactivity URL:
{public-api}/v1/integrations/slack/interactions
Proposal sources
- Runbook / Triage on warn or critical briefings with a service name → restart proposal (
deployment= service,namespacefrom env, optionalclusterfrom your linked Kubernetes cluster). - SLO coach on SLO burn (warn/critical) → scale proposal (default replica target from operator config).
- Noise coach after alert runs → mute proposal for the firing rule.
- Security analyst (low-severity briefing) → suppress finding proposal.
- Comms after alert runs → comms draft proposal (review-only post until autopost GA).
Last updated