Centralised policies
proAuthoring a team policy in the dashboard, where it lands on each device, and which team-managed settings actually change a decision.
A team policy is a named JSON document authored in the grith.ai dashboard. Team admins and the
team owner can create and edit one; every member's device pulls the current version with
grith pro sync into ~/.config/grith/policies/<name>.json.
The whole surface is gated on the policy_editor feature, on the dashboard and on the daemon's
own routes.
What a policy document holds
A policy document carries a name, a description, a version, created and updated timestamps and a
rules object. You supply the name, the description and the rules; the daemon sets the version
to 1 on create and bumps it on every update. The rules object is the part that matters:
{
"proxy": {
"auto_allow_threshold": 3.0,
"auto_deny_threshold": 8.0
},
"filters": { "secret-scan": true },
"allowlists": {
"paths": [],
"commands": [],
"domains": []
}
}Validation is strict about three things: the name must be alphanumeric-plus-hyphen and 64
characters or fewer; both thresholds must sit inside 0.0-10.0 with allow strictly below deny;
and every key in filters must name a filter the running proxy actually registered. An unknown
filter id is rejected rather than silently ignored. A file in the directory that does not match
this shape is skipped by the list route rather than failing it.
The local routes
All five require Pro. They read and write files in ~/.config/grith/policies/.
| Route | Does |
|---|---|
GET /api/policies | List every policy on this machine. |
GET /api/policies/{name} | Read one. |
POST /api/policies | Create one. 409 if the name is taken. |
PUT /api/policies/{name} | Update one and bump its version. |
DELETE /api/policies/{name} | Remove one. |
What actually changes a decision
⚠️A policy document is distributed, not enforced
The daemon scores tool calls against its own configuration - config/default.toml, then
~/.config/grith/config.toml, then ./.grith/config.toml, then GRITH_* environment
variables. A pulled policy file is stored and served back over the API; it does not move a
threshold or switch off a filter on its own.
Two team-managed things do change what a session does, and both arrive without any extra step:
- Team learned rules. Rules an admin approves for a profile are merged into every new session's allowlist on that profile, refreshed at session start.
- Team provider keys. Pulled, decrypted locally and used for model calls.
To move a scoring threshold across a team today, ship it in each machine's config.toml - that
is the file the daemon reads. See Tuning scoring thresholds.
Shared configs and team-config.toml
Shared configs pulled by grith pro sync sit as JSON under ~/.config/grith/configs/. Applying
them from the dashboard merges them into ~/.config/grith/team-config.toml, which the
dashboard's configuration view treats as the shared baseline that local config overrides. The
same caveat applies: it is the view's baseline, not the daemon's.