Action Authorization & delegation grants

Two independent questions guard every mutating path:

• Action Authorization: may this principal perform this action on this state now?
• Commercial Authorization: may Sweep incur, rate and charge this usage under the customer’s standing relationship?

Neither substitutes for the other.

Principals

user, sweep_automation, developer_application, external_agent, service, connector. Every application and agent has its own auditable identity with status, owner, expiry, revocation, risk state and last activity. An agent never inherits a user’s full authority.

Delegation grants

A user delegates to a principal through a versioned grant that can constrain: operation classes and action classes, sources, containers, asset kinds, max objects/bytes per plan, max plans per day, allowed destinations, external destinations, destructive actions, automatic actions, the requirement for a Shadow Sweep plan, the risk level above which a human must approve, minimum plan confidence, a commercial ceiling, a time window, and expiry. Sweep Connect creates the initial grant from the consented operation classes; users can see and revoke every grant at any time.

Risk classes

Risk	Actions
read	read_inventory, read_quota, read_vault, search_vault
low	create_plan, preserve, monitor
medium	copy, unsubscribe, trash, restore
high	move, migrate_external, automate, manage_grants
critical	delete_vault_object, delete_account (permanent_delete is never allowed for any principal)

Above the grant’s requireHumanApprovalAbove, the decision is step_up_required and the delegating user must approve in the browser (approval_url). Revoking a grant, connection, key, agent or application stops execution immediately, even for a stale model session.

Every evaluation produces a policy decision record with the matched grant, reasons and obligations (require reversible action, require receipt, notify user). GET /v1/graph/explain/{executionId} shows them.