Agent governance#
Most of Anemoi is configured per workspace: its agents, their policies, approvals, budgets and evaluations. Two controls belong to the whole organisation and are set by its owners and admins: organisation guardrails, rules every agent of every workspace follows, and the marketplace, where workspaces share agent and flow templates. This page covers both. For agents themselves, see Anemoi.
Organisation guardrails#
A guardrail is a set of Cedar policies that only forbid. It is added to
every agent run's tool policy when the run starts, so no agent's own policy
can undo it: a permit never overrides a forbid. Workspace admins write
their workspace's guardrails; an organisation's guardrails apply to every
workspace of the organisation, on every cluster, and workspace admins cannot
change or remove them.
In each workspace's Guardrails page, the organisation's guardrails are
listed with the tag organisation, read-only, named org-<name>. Each
run's receipt names the guardrails it ran under.
Write an organisation guardrail#
The console has no editor for organisation guardrails; use the API. You must be an owner or admin.
For example, no agent of the organisation sends an HTTP DELETE or calls a
tool whose name says it deletes:
@id("no-http-delete")
@reason("deleting is for people")
forbid (principal, action == Action::"http", resource)
when { resource.method == "DELETE" };
@id("no-delete-tools")
@reason("deleting is for people")
forbid (principal, action == Action::"tools/call", resource)
when { resource.name like "*delete*" || resource.name like "*remove*" || resource.name like "*destroy*" };
$ jq -n --rawfile text no-deletes.cedar '{description: "No deleting", text: $text}' \
| curl -sS -X PUT "$ASTRA_URL/api/v1/orgs/acme/guardrails/no-deletes" \
-H "Authorization: Bearer $ASTRA_TOKEN" -H "Content-Type: application/json" -d @-
{"name":"no-deletes","cluster_name":"org-no-deletes","description":"No deleting","text":"…",
"sync":[{"workspace":"research","namespace":"ws-3f9a1c07b2e4","cluster":"…","ok":true}]}
A workspace's Guardrails page offers this and other ready-made examples (no merging pull requests, read-only HTTP, writes in office hours only) to start from.
| Field | Rules |
|---|---|
| Name (in the path) | Lower-case letters, digits and -, at most 50, not starting or ending with -. Appears in workspaces as org-<name>. |
text |
Cedar policies, forbid only: at least one forbid, no permit. At most 16 KiB. Each workspace's cluster checks it in full. |
description |
What it is for; optional. |
The same PUT replaces an existing guardrail. The policy language and the
context an agent's tool call carries are described in
Anemoi.
The answer's sync lists, for each workspace and cluster, whether the
guardrail was written there (ok) or why not (error). A cluster that could
not be reached is caught up by the next change or by a sync:
$ curl -sS -X POST "$ASTRA_URL/api/v1/orgs/acme/guardrails/sync" -H "Authorization: Bearer $ASTRA_TOKEN"
{"sync":[…]}
A sync writes every organisation guardrail into every workspace, and removes from them organisation guardrails that no longer exist. A workspace given access to a new cluster receives the organisation's guardrails there at once.
| Request | Who | Does |
|---|---|---|
GET /orgs/{org}/guardrails |
Every member | Lists the guardrails, with their text, who changed them and when. |
PUT /orgs/{org}/guardrails/{name} |
Owners, admins | Creates or replaces one, then writes it everywhere. |
DELETE /orgs/{org}/guardrails/{name} |
Owners, admins | Removes it everywhere. |
POST /orgs/{org}/guardrails/sync |
Owners, admins | Writes them all again everywhere. |
Changes are recorded in the audit log as org.guardrail.put and
org.guardrail.delete.
The marketplace#
The marketplace is where an organisation's workspaces publish agent and flow templates for each other: a snapshot of one version of an agent or a flow, with what it needs (credentials, deployments, drives…) listed by name, never their values. Workspace editors publish from an agent's or a flow's page and install from their workspace's Marketplace.
Organisation → Marketplace shows every template. As an owner or admin you can:
- Require approval: tick A version published by someone other than an admin waits for an admin's approval. Every member sees the setting; only owners and admins change it.
- Approve or Reject a version waiting for approval. A notice at the top of the page lists the templates waiting. A rejection asks why; the reason is shown to the publisher.
- Withdraw a version: it is no longer offered; what was installed stays.
- Change or delete any template.
Templates are visible to the whole organisation, or only to the workspaces the publisher names. Installing one in a workspace makes the agent or flow there through the same checks as making it by hand.
The marketplace's actions are recorded in the audit log
(org.marketplace.*, workspace.marketplace.install).