Task-Scoped Authority Grant and Test Protocol

Status: proposed reusable protocol; not independently validated
Purpose: bind one agent task to explicit, expiring and revocable authority while keeping capability, credentials and permission separate.

1. Grant worksheet

Complete every field before enabling a consequential side effect.

2. Proposed grant object

{
  "grant_id": "grant-example-017",
  "version": 3,
  "task_id": "task-example-1042-date",
  "principal": "operations-owner",
  "actor": "delivery-date-agent",
  "parent_grant": null,
  "actions": ["read", "update_delivery_date"],
  "resources": [{"tenant": "test", "type": "order", "id": "TEST-1042"}],
  "data_classes": {"allow": ["order_schedule"], "deny": ["payment", "price", "credentials"]},
  "side_effect_classes": ["read", "external_write_reversible"],
  "conditions": {"required_readback": true, "approval_id": null},
  "budgets": {"writes": 1, "tool_calls": 6},
  "not_before": "2030-01-15T14:00:00Z",
  "expires_at": "2030-01-15T14:30:00Z",
  "one_time": false,
  "revocation_epoch": 12,
  "evidence_required": ["decision_receipt", "returned_record_id", "field_readback"],
  "on_uncertainty": "deny",
  "delegation": "prohibited",
  "issuer": "operations-owner",
  "acceptance_owner": "operations-owner"
}

All identifiers, dates and records are synthetic. The object illustrates structure; it is not a credential or executed grant.

3. Lifecycle

proposed -> active -> closed
                \-> suspended -> active
                \-> revoked
                \-> expired
                \-> consumed

Rules:

1. Only active authorizes execution.
2. Expiry is evaluated against a trusted clock immediately before action.
3. A material correction creates a new version and supersedes the old one.
4. Revocation advances authoritative state; cached grants with an older epoch deny.
5. One-time grants become consumed atomically with the admitted operation where feasible.
6. closed preserves evidence but carries no continuing permission.
7. A live session or valid credential never changes these rules.

4. Admission procedure

For each proposed tool call:

1. Authenticate the actor and resolve the represented principal.
2. Load the current grant by immutable task and grant identity.
3. Canonicalise the tool, verb, target, tenant/account, parameters, data classes and side-effect class.
4. Reject an inactive, expired, revoked, consumed, superseded or unverifiable grant.
5. Evaluate:

requested action ⊆ actor baseline
requested action ⊆ principal's delegable rights
requested action ⊆ task grant
requested action ⊆ resource policy
all live conditions = satisfied

1. For high-impact operations, verify a short-lived approval bound to actor, tool, target and material parameters; consume it once.
2. Execute through the narrowest available adapter or credential.
3. Read back the exact target state.
4. Persist the decision, execution result, readback and updated budgets.
5. Do not call the business outcome complete unless its separate acceptance evidence exists.

5. Decision receipt

{
  "decision_id": "decision-uuid",
  "grant_id": "grant-example-017",
  "grant_version": 3,
  "task_id": "task-example-1042-date",
  "principal": "operations-owner",
  "actor": "delivery-date-agent",
  "request": {
    "action": "update_delivery_date",
    "resource": {"tenant": "test", "type": "order", "id": "TEST-1042"},
    "material_parameters_sha256": "hex"
  },
  "grant_state": "active",
  "revocation_epoch_checked": 12,
  "checks": ["actor", "principal", "action", "resource", "data", "budget", "time", "conditions"],
  "decision": "allow|deny|abstain|error",
  "reason_codes": ["string"],
  "policy_version": "string",
  "evaluated_at": "timestamp",
  "side_effects_before_decision": [],
  "execution_result": "not_started|succeeded|failed|unknown",
  "readback": {"status": "not_run|verified|mismatch|unavailable", "evidence_id": "string|null"},
  "proposition_established": "string",
  "properties_not_established": ["wisdom", "source truth", "business outcome", "universal security"]
}

6. Minimum positive and negative suite

Test fixtures must contain no live credentials or private customer data.

7. Delegation checklist

Before creating a child grant:

• [ ] Parent grant permits delegation.
• [ ] Child actions are a strict subset of parent actions.
• [ ] Child resources and data are no broader.
• [ ] Child expiry is no later than parent expiry.
• [ ] Child budgets do not exceed remaining parent budgets.
• [ ] Principal and immediate actor are both retained.
• [ ] Child cannot alter issuer, revocation reference or acceptance owner.
• [ ] Fallback does not route around the gate.
• [ ] Output target and evidence contract are explicit.
• [ ] Parent verifies the child's receipt before acceptance.

8. Pilot scorecard

Compare broad standing access, prompt-only restriction and task-scoped grants on matched cases. Record:

• intended-task completion rate;
• unauthorised-action rate;
• false denials and abstentions;
• median and tail approval latency;
• revocation propagation time;
• bypass attempts and alternate-path coverage;
• policy-authoring and maintenance effort;
• operator interventions;
• actions with missing or mismatched readback;
• consequential failures, reported separately from aggregate accuracy.

Do not claim success from denial tests alone. A secure but unusable gate is not a completed operating design; positive cases must also work under the same controls.

9. Release checklist

• [ ] Identity, capability, credential and authority are represented separately.
• [ ] Grant is bound to one task, actor, principal and version.
• [ ] Actions, resources, data and side-effect classes are explicit.
• [ ] Expiry, correction, revocation and one-time consumption are exercised.
• [ ] Policy is enforced outside ordinary model context.
• [ ] Approval is exact-action, expiring and replay-resistant where required.
• [ ] Positive cases complete without widening permission.
• [ ] Every negative case fails before the governed side effect.
• [ ] Delegation attenuates authority and preserves actor attribution.
• [ ] Policy or revocation uncertainty does not become implicit allow.
• [ ] External results are read back against the exact target.
• [ ] Receipts state what they do not establish.
• [ ] Independent review and accountable acceptance remain separate.