Part 1

Quickstart

Five steps, about thirty minutes. At the end, your agent will ask a human before doing anything risky — and you'll have approved your first action in Slack.

# In the Render dashboard: New → Blueprint → select
sentryops-dev/sentryops → Apply
# Fill in the secrets below when prompted, then deploy.

cd policy-engine
python3 app.py
# listening on http://localhost:8000

cd policy-engine
docker compose up --build
# listening on http://localhost:8000, ledger persists in ./data/

curl -s http://localhost:8000/health
# {"status": "ok", "policy_version": "0.1.0"}

2 Connect Slack

Approval requests arrive as Slack cards with Approve, Deny, and Snooze 1 hour buttons. Three values connect the engine to your workspace:

1. Create a Slack app at api.slack.com/apps (or use an existing one).
2. Under Basic Information → App Credentials, copy the Signing Secret → set it as the SLACK_SIGNING_SECRET environment variable on your engine. Tip: paste it through a plain-text editor first — invisible trailing whitespace breaks signature verification.
3. Under OAuth & Permissions, copy the Bot User OAuth Token (starts with xoxb-) → SLACK_BOT_TOKEN.
4. Under Interactivity & Shortcuts, turn it on and set the Request URL to https://<your-engine>/slack/actions. Slack will verify the URL — the engine must be reachable.

Invite the bot to the channel where approvals should land (we use #agent-approvals).

slack.com — #agent-approvals

A real approval card. The approver sees what the agent wants to do, why it was held, and three buttons — nothing else to learn.

4 Wire up the Agentforce agent

Add the governed actions to your agent's topic (we use an "Orders and refunds" topic). Each action is an @InvocableMethod — the agent discovers them like any other action. Nothing about the agent's instructions changes; the check lives inside the action, not in the prompt.

Agentforce Builder — agent preview

The agent preview. The agent does its normal routing — the hold happens inside the action, invisible to the agent's reasoning.

Part 2

Make it yours

The rules are plain English, not code. A non-technical person can change them — and the change takes effect immediately, no redeploy.

The policy editor

Set the COATCHECK_ADMIN_TOKEN environment variable on your engine, then open https://<your-engine>/admin?token=<your-token>. This is the actual interface — shown here exactly as it renders:

The real policy editor UI (static preview — the live page saves for real). Four lists control everything.

The four lists, in plain terms:

Adding a custom action

Every governed action follows the same pattern: ask the engine before doing anything, then enforce the answer. Here's the skeleton, adapted from the purchase-order action:

// 1. Ask the policy engine FIRST — before any business logic.
SentryOpsEvaluateAction.EvalRequest req = new SentryOpsEvaluateAction.EvalRequest();
req.agentName  = 'My Agent';
req.actionName = 'invoice.create';  // dot-namespaced, e.g. billing.adjust
req.paramsJson = JSON.serialize(new Map<String, Object>{
    'amount' => amount,
    'vendor' => vendor
});
SentryOpsEvaluateAction.EvalResult eval =
    SentryOpsEvaluateAction.evaluate(new List<SentryOpsEvaluateAction.EvalRequest>{req})[0];

// 2. Enforce the answer. There is no path around this.
if (eval.decision == 'allow') {
    // Do the thing.
    createInvoice(vendor, amount);
} else if (eval.decision == 'require_approval') {
    // Park it. The evaluation ID lets you resume after the human decides.
    holdForApproval(eval.evaluationId);
} else {
    // 'deny' — blocked outright. Nothing happens.
    blockRequest(eval.reason);
}

Then add the action name to policies.yaml (or the policy editor) — a spending limit, the always-hold list, or the allowlist. The check is in the doorway of the action, not in the agent's instructions — so no prompt trick can bypass it.

Customizing Slack messages

The card text lives in the engine's Slack payload builder. Every message is plain, friendly language written for a non-technical approver — no jargon, no scare tactics. Edit the templates to match your team's voice; the Approve / Deny / Snooze buttons and signature verification stay the same.

Safety floors: the rules policy can't override

Some rules shouldn't be editable at all. The Apex layer carries hardcoded guardrails that only ever make decisions stricter — never looser. Example: refund.issue is hardcoded to always hold, even if someone loosens the policy to auto-allow refunds under $250.

That's deliberate. The policy editor is for the business; the guardrails are for the worst day — a misconfigured policy, or an agent that talked someone into loosening it. We demoed exactly this: the policy said yes, the safety net said no.

Part 3

Any agent, not just Agentforce

The policy engine is a plain REST API. If your agent can make an HTTP call, it can use Coatcheck — no Salesforce required.

Before your agent does anything consequential, it asks one question:

POST https://<your-engine>/v1/evaluate
{
  "agent":   "procurement-copilot",
  "action":  "order.create",
  "params":  { "vendor": "Acme Metals", "amount": 42000 },
  "context": { "user": "rich" }
}

→ 200 OK
{
  "decision":      "require_approval",   // allow | deny | require_approval
  "reason":        "This is $42,000, which is over the $500 approval limit…",
  "evaluation_id": "a3f9c1d2e4b5"          // track it in your audit log
}

Three possible answers, three behaviors:

• allow — proceed. The action is routine and within policy.
• deny — stop. The action is never permitted (or looks like an instruction-override attack). Nothing happened.
• require_approval — pause and wait. The engine notifies a human (Slack, email, your channel of choice); your agent resumes when the human decides, referencing the evaluation_id.

The whole integration, in Python

import requests

ENGINE = "https://your-engine.onrender.com"

def coatcheck(agent, action, **params):
    """Ask Coatcheck before doing anything consequential."""
    r = requests.post(f"{ENGINE}/v1/evaluate", json={
        "agent": agent, "action": action,
        "params": params, "context": {},
    }, timeout=30)
    r.raise_for_status()
    return r.json()  # {decision, reason, evaluation_id}

# In your agent, at the moment of consequence:
verdict = coatcheck("procurement-copilot", "order.create",
                    vendor="Acme Metals", amount=42000)

if verdict["decision"] == "allow":
    create_purchase_order(vendor="Acme Metals", amount=42000)
elif verdict["decision"] == "require_approval":
    wait_for_human(verdict["evaluation_id"])  # poll GET /v1/decisions/{id}
else:
    log_blocked(verdict["reason"])             # denied — do nothing

Works with whatever you're building on

Catalog

Use cases

Twenty-plus governed actions drawn from real production-agent deployments and incidents. Each one is a moment where an agent's judgment alone isn't enough.

Live in demos today

Money movement

Procurement & manufacturing

Insurance, HR & data

Attack resistance

"Planned" items have working policy definitions and Apex templates ready; they light up as actions are connected. If your use case isn't listed, the pattern in Part 2 covers it.

Reference

API reference

Every endpoint on one page. The engine speaks JSON over HTTPS; there's nothing else to learn.

Environment variables