Skip to main content
A policy is one statement, a grant: a subject (the whole organization, a team, or a role) is allowed or denied a service or a single tool. Together, an organization’s grants decide what each member’s agents can call.

​
Enforcement

Enforcement is on by default. A call the policy refuses answers 403 with Your organization does not have access to this tool and writes a tool.denied row to the audit log with the reason. The check runs on every path a tool can be executed from: single and batch tool calls over the API, the MCP server (which calls the same API) and hosted workflows. It also runs at discovery, so a member’s search results and service tool lists leave out what they could not call. Self-hosted deployments can change the mode with ORG_TOOL_AUTHZ_MODE:

​
How evaluation works

The subjects that match a member are the organization (org / default), their role, and every team they belong to. The grants for those subjects are composed like this:
  • No grants means ungoverned. Every member keeps full access to the organization’s tools.
  • The first grant switches the organization to deny-by-default. From then on, a member can only use what a grant allows.
  • Explicit deny wins. A deny on the tool, or on its service, for any subject that includes the member refuses the call, whatever else allows it.
  • Owners and admins skip the allow-lists. They are not subject to deny-by-default, so a mistaken allow cannot lock the people who can fix it out. An explicit deny whose subject includes them (the organization, their role, one of their teams) still applies to their calls, but never to their ability to edit the policies, which depends on their role alone.
  • Scope. A service-level grant covers every tool in that service. A tool-level grant covers one tool.
  • The public catalog can be denied, never allow-listed. Allow grants govern the organization’s own internal, local-only and private tools; they never restrict the catalog, so the first allow grant does not hide the marketplace from members. A deny on a public catalog service or tool applies to every call made in the organization’s context (a danube-org-id header naming it, or one of its keys) and is refused with org_policy:explicit_deny; the same call made outside the organization’s context is not affected. To limit what one key may call in the catalog, restrict the key itself with allowed_services / allowed_tools.
A member sees the effect before calling anything: a tool the policy would refuse is missing from their search results and from the service’s tool list, a denied catalog tool included when they search in the organization’s context. The owners and admins who edit policies still see everything, apart from an explicit deny whose subject includes them.

​
Subjects

​
Team grants

A team grant needs a team of this organization (400 otherwise) with people in it: add them under Teams on the Organization page or with POST /v1/organizations/{org_id}/teams/{team_id}/members ({"email": "..."} or {"user_id": "..."}, plus "role": "lead" if you want). A membership change takes effect on the next call. Deleting a team removes every grant that targeted it, so the policies page never lists a grant for a team that no longer exists.

​
Create a policy

1

Open Access

Go to Dashboard > Access. Admins and owners only.
2

Pick the subject and the effect

Choose the organization, a team, or a role, and whether the grant allows or denies. A public catalog service or tool can only be denied.
3

Pick the scope

Choose a service (all of its tools) or one tool. The tool picker lists the organization’s own services first and the rest of the catalog after them; once a service is chosen it searches that service’s tools by name and description and shows the first eight matches.
4

Check the audit log

After the first grant exists, denied calls appear in the audit log with status denied and a denial_reason. Use it to confirm the policy does what you intended before relying on it.

​
Example

The finance team may use every tool of the organization’s internal Billing service, but nobody outside the admins may void an invoice:
Admins keep the void tool because the deny targets the member role, not the whole organization. An org / default deny would reach the admins too. Members outside the finance team see none of the Billing tools, since the organization is now governed and nothing allows them.

​
Denial reasons

Every refused call is audited as tool.denied with one of these denial_reason values.

​
Organization caps

Two caps under Organization > Settings > Limits (owner or admin; rate_limit_per_minute and daily_spend_cap_cents on PATCH /v1/organizations/{org_id}/settings) apply to every call made in the organization’s context, whichever key made it, on top of the per-key caps. A call runs in the organization’s context when it carries a danube-org-id header naming it or uses one of its keys; a personal organization is never capped here. The per-minute window is a sliding 60 seconds; allowed calls count toward it, refused ones do not, so a client that keeps retrying does not push its own window out. The daily figure is the sum of paid-call costs since midnight UTC over every key that has belonged to the organization, revoked ones included, plus the price of the call being gated. Free tools count against the rate cap only.

​
Endpoints

Admin or owner. Validation rules: a grant needs a service_id or a tool_id; organization-wide grants must use subject_id: "default"; role grants must name one of the four roles; team grants must name a team of this organization. An identical grant answers 409. The list stamps service_name and tool_name on each row so a grant reads as what it targets, not a uuid.