Skip to main content

Trust policies

Availability

Cloud & Enterprise · Enterprise plan

Trust policies decide whether one agent is allowed to act in relation to another — for example, whether a caller agent may delegate to, or be trusted by, a target agent. They build on the agent registry: rules reference agents by their registered identity.

Allow and deny rules​

A trust policy is an allow or deny rule whose subject is either:

  • a specific agent id, or
  • a group wildcard, written group:*, matching a set of agents.

This lets you write both broad and precise rules — trust an entire group, then carve out a single agent with a deny.

Evaluation: deny-wins over default deny​

Two principles govern every decision:

  • Default deny — if no rule allows the relationship, it is denied. Trust is never implicit.
  • Deny wins — if any matching rule denies, the result is deny, even when another rule would allow. A deny cannot be overridden by an allow.

Together these make trust explicit and safe: you grant trust deliberately, and a single deny rule is always sufficient to block a relationship.

Endpoints​

  • GET /v1/identity/trust — list trust policies.
  • POST /v1/identity/trust — create an allow or deny rule.
  • DELETE /v1/identity/trust/{policyID} — remove a rule.
  • POST /v1/identity/authorize — evaluate whether a cross-agent action is permitted under the current trust policies, returning the trust decision.

Every authorization outcome is recorded in the activity ledger.

  • Agent identity — the registry and scoped credentials that trust rules reference.
  • Federation — bring in agents authenticated by an external OIDC issuer.
  • Policy engine — the broader RBAC/ABAC/ReBAC policy engine for actions on resources, which shares the deny-wins principle.