Ethics concerns

An organisation can write ethics rules, under Admin → Ethics, about the kinds of request it wants a person to weigh before an agent goes ahead. They read every approval and every gate check made through the API or the MCP server, whichever key or connector made it. Only an approval a person raises in the Deliverd app itself is exempt. For how administrators write them, see Ethics in the guide.

Each rule names a principle — fairness, privacy, safety, honesty, autonomy, wellbeing and legality, or other — and a concern: the question the person deciding should ask. It matches on registered actions, agents, keywords or input values, and has one of 3 effects: flag, escalate, refuse.

The concerns field#

When rules match, the approval — and a gate result — carries them in concerns, recorded as the rules read when the request was made:

"concerns": [
  {
    "principle": "fairness",
    "rule": "Decisions about someone's job",
    "concern": "This may affect someone's employment. Is the decision based on relevant facts?"
  }
]

concerns is always present and is empty when nothing matched. In the SDKs it is on the approval and gate objects the handles carry; over MCP it is in what get_approval and get_gate return.

What a concern changes#

A request with any concern also:

• needs a written reason to be approved. The approver's reason is recorded as the approval's note. It cannot be approved with one tap in Slack or Teams.
• is never decided from the sign-in-free link in an approval email, and cannot be addressed to a guest.
• is slower, by design. An agent that reads concerns knows why.

The model screen#

An organisation on Business (1,000 a month) and Enterprise (10,000 a month) can switch on the model screen under Admin → Ethics. A model reads each agent request and may add up to 3 concerns, which arrive in concerns with "rule": "Model screen".

• It can only add a concern. It never approves, refuses, escalates or removes anything.
• If it cannot run, or the month's allowance is used, the request is read by the organisation's rules alone.
• A request it declines to assess gets one concern asking the approver to read it with care.
• It can add a few seconds to creating an approval or answering a gate call.
• Fields an action marks restricted are never sent to the model provider.

How your agent should respond#

1. 1

   Treat a refusal as an answer

   refused_by_rule and a gate's denied are the organisation saying no. Stop, and tell the person you work for which rule refused and why; the concern is written for them.

2. 2

   Do not reword to get round a rule

   Rephrasing a title or moving a word out of the description to avoid a keyword is exactly what the rules exist to catch, and it gains nothing: the rules only add oversight. If a rule is wrong, the fix is an administrator changing it.

3. 3

   Describe the request honestly

   Rules read the title, the description and the input's text values. A request that says plainly what it will do, and to whom, is the one an approver can decide quickly, concern or not.

4. 4

   Raise concerns yourself

   If your agent notices a possible harm the rules did not, say so in the request's description. The open-source ethics skill teaches an agent how.