Skip to main content
Scope grants define what an agent is authorized to do under a credential. They follow the OAuth 2.1 Rich Authorization Requests (RFC 9396) shape: structured authorization objects with a type field and optional type-specific constraints. A credential may carry multiple scope grants. A tool invocation is authorized if it satisfies any scope grant. Each grant is satisfied only if all its constraints are met. The supported grant types are published in the discovery document as authorization_details_types_supported:

Scope type reference

hasp.data.read

Authorize the agent to read records from the HASP Data API.

hasp.data.write

Authorize the agent to create or update records in the HASP Data API.
hasp.data.read does not implicitly grant hasp.data.write. A separate grant is required for write access even on the same entities.

external.tool.invoke

Authorize the agent to call an external or registered tool.
Each external.tool.invoke grant applies to a single tool. To authorize multiple tools, add one grant per tool.

agent.delegate

Authorize the agent to issue a child credential to another registered agent.
The child credential’s scopes are bounded by the parent’s. An agent cannot delegate scopes it does not itself hold.

human.escalate

Authorize the agent to escalate to a human via a configured channel.
Supply exactly one of to_role or to_user_id. Sending neither, or both, is rejected at issuance.

tool.destructive

Authorize the agent to invoke a single named destructive capability — one whose effects cannot be undone by a subsequent call.
A wildcard tool_id of "*" is rejected: a destructive capability must be named explicitly. Grant one per capability.

agent.compose

Authorize the agent to compose with another registered agent.

workflow.invoke

Authorize the agent to invoke named workflows over A2A.
The A2A route requires the workflow.run capability, which this grant confers. A credential whose grant names specific workflows is rejected when it invokes any other workflow, even one that is agent-callable in the same org.

workflow.schedule

Authorize the agent to create scheduled runs of named workflows.
Tier ceilings apply on top of the grant; the effective bound is the tighter of the two.

Substitution syntax

Filters and constraints may use substitution syntax to bind values at credential issuance time: Substitution happens at credential issuance, not at invocation. The credential carries already-resolved values. This makes scope fully auditable — the agent cannot re-evaluate bindings at runtime. Example:
Issued as:

Allowed scope types

Each agent definition has an allowed_scope_types list. A credential cannot be issued with a scope type that is not in the agent’s allowed types. To configure which scope types an agent may receive:
  • Dashboard: Developers → Agents → [agent name] → Settings
  • API: PATCH /v1/agents/{agent_id} with allowed_scope_types
Setting allowed_scope_types to null permits all scope types. This is the default for newly registered agents.

Scope type restrictions

Scope types are an enumerated set — new types require a platform update. Customers cannot define custom scope types. This is intentional: a scope type the platform does not recognize cannot be enforced or audited, which breaks the regulated-industry trust model. The current scope type set is: