Proposal: a Delegation Charter for agent approval policies

[Lucas-almma]

The v0.8.8 approval work and Danny's note about approval policies that consider tool inputs and outputs prompted this.

Approvals answer whether a tool call may run. In production, the harder questions are what the agent must never do, when it must stop, and who is accountable.

We've published an open specification, the Delegation Charter (CC BY 4.0): https://github.com/almma-ai/delegation-charter

Every agent gets eight fields:

1. Owner: the one person who answers for the agent
2. Escalation recipient: who receives work the agent must not finish
3. Approval authority: who approves the charter, its changes, and its sharing
4. Scope: what it will do, plus a never-do list that can't be empty
5. Systems and permissions: each tool marked read, write, or irreversible
6. Inputs and outputs: without required inputs, the agent stops rather than guesses
7. Escalation rules: deterministic actions for out-of-scope requests, never-do matches, missing inputs, and irreversible actions
8. Execution constraints: irreversible actions always need a person's approval

Why it matters for LibreChat: in an audit of 3,478 agents on a LibreChat-based deployment, 97% had no named human contact and 93% had no escalation path. The builder doesn't ask for these, so they rarely get written.

What we'd propose:

1. Charter fields in the agent builder, optional by default, with an admin setting to require them for shared agents or agents with write tools.
2. Enforcement through the approval and Agent Plugins hooks, outside the model.
3. A reference plugin under MIT, which we'd build and maintain.

Two questions for maintainers:

a) Will the approval policy and plugin hooks be stable enough for third parties to build on?

b) Could a plugin add a panel to the agent builder, or would that need core changes?

Design mocks will follow next week. Happy to discuss at the October 9 town hall.

[Lucas-almma]

For operators who want to measure this on their own deployment first, we've published a read-only check that runs against a LibreChat database with one mongosh command and returns aggregate counts only, no message content: https://github.com/almma-ai/agent-governance-check

It reports how many agents have no instructions, hold tools without stated scope, reach outside the tenant or execute code without stated prohibitions, or were revised after being shared. If you run it, sharing the aggregate numbers here would help show how widespread the gap is.

[Lucas-almma]

Update ahead of tomorrow’s town hall.

We answered our own two questions by reading v0.8.8-rc4:

1. A plugin cannot add a builder panel. Plugins contribute skills, MCP servers, and hooks only, so charter fields in the builder need a core change.
2. Plugin hooks are enough to enforce a charter outside the model. PreToolUse receives the agent ID, tool name, and inputs, and a hook can only tighten the approval policy, never loosen it.

We published a diagnostic that any operator can install as an Agent Plugin: https://github.com/almma-ai/librechat-charter-diagnostic. It tests every agent against the charter, and the deployment against three conformance levels. It is read-only, admin-only, and MIT-licensed. Its hooks only observe, and every file states what it touches so a coding agent can verify it before you run it.

Three things it surfaced in v0.8.8 that may be worth a look:

1. Command hooks fail open on the official image. The executor runs hooks with bash, and the Alpine image doesn’t ship it. The spawn error is logged as a warning, and the tool call proceeds. Reproduced with LibreChat’s own executor: the same deny-guard blocks with bash on PATH and lets the call through without it (test/librechat-harness/setup.sh in the repo). Adding bash to the image, or falling back to sh, would fix it. Happy to open an issue or a PR.
2. toolApproval rules and approval hook modules apply to chat runs only. Agents API and Responses API runs don’t get them (the hitlCapable gate in agents/run.ts). Plugin hooks do run there. Worth stating in the docs, so operators don’t assume their deny list covers API keys.
3. The audit log defines agent_run, tool_call, and approval categories but doesn’t write them yet, so agent activity isn’t in it.

A first mock, in LibreChat’s own builder style: a never-do list where each item is either Enforced (tied to a tool and a condition, blocked outside the model) or Instructed (guidance to the model only). This is the core change we’d propose: the plugin can already enforce, but only the builder can capture it. See you tomorrow.

[Lucas-almma]

Opened #16923 for the bash fail-open case mentioned above.