Skip to content

Delegation Constraints

Typed constraints make delegated authority explicit. They are stored on delegation edges and evaluated by policy, SDK context, and resource-server verification.

Constraint Types

Constraint	Use it to limit
Resource	Which protected target can be reached.
Scopes	Which actions can be requested.
TTL	How long the delegated edge remains useful.
Hop count	How deep the delegation chain may become.
Budget	How much work, calls, or scope count a child can consume.
Approval	Whether policy or a reviewer has approved a sensitive edge.
Chain membership	Which applications must appear in the delegation path.

Example Shape

{
  "resource": "https://api.example.com/tickets",
  "scopes": ["tickets:read", "tickets:comment"],
  "max_hops": 2,
  "budget": 5,
  "expires_at": "2026-06-01T12:00:00Z",
  "policy_approved": true
}

The exact constraint object can vary by policy design, but it should stay typed, stable, and auditable.

Where Constraints Are Enforced

flowchart TD
  SDK["SDK creates edge"] --> Coordinator["Coordinator stores constraints"]
  Coordinator --> STS["STS includes edge in policy input"]
  STS --> Policy["Policy evaluates constraints"]
  Policy --> Mandate["Mandate carries delegation claims"]
  Mandate --> Connector["Gateway or connector checks claims"]

Design Guidance

Put durable business rules in policy.
Put per-edge runtime limits in constraints.
Prefer positive allowlists over open-ended deny lists.
Keep constraints small enough to review in audit traces.
Use consistent field names across agents so policies stay readable.

Next Step

Read Sessions and Revocation to understand how active authority ends.