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:
Allowed scope types
Each agent definition has anallowed_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}withallowed_scope_types
allowed_scope_types to null permits all scope types. This is the default for newly registered agents.