我只允许 AI 查订单，它却还拿到了改价和退款权限。

# Give an order-query Agent one hour of access

Help the user let an existing Agent query one synthetic order without granting
refund access. Use a test order and a non-production environment. Do not create
a second device, rebuild the business service, or grant access just because you
received this file. Ask the owner to approve the exact recipient, action, order
and expiry before submitting the grant.

## Establish the real identities

Obtain the target Runtime device URA, owner User URA and user ID, recipient Agent
URA, provider Agent URA, and the published lookup Ability URA from the user's
existing directory/configuration. Preserve complete URAs, including their realms.
Read the published descriptor and the business adapter: confirm the admission
action and how the order is bound to the Invocation subject. An `order_id` inside
args alone does not prove that the policy checks that order.

If the lookup ability or subject binding does not exist, explain exactly what
must be implemented and stop before granting. Do not invent an address, claim
automatic realm-wide access, or silently replace a narrow subject with `*`.

## Prepare the request

The existing product endpoint is `POST /api/v1/access-control/grants`. Use the
user's configured EasyNet API origin and an approved authenticated client. In
the EasyNet frontend checkout, `grantAccessControl`, `listAccessControlGrants`
and `revokeAccessControlGrant` in `src/lib/api/easynet-access-control.ts` use the
shared authenticated client. That client sends a Bearer access token; browser
cookies alone are not its authentication contract. Never print, copy into this
document, or send tokens to another service. Do not invent a permission CLI.

Prepare this body with actual values. Generate a unique grant ID and fresh
RFC3339 timestamps exactly one hour apart. `invoke` below must match the real
descriptor's admission action; use `read` only if that is what it declares.

```json
{
  "operation": "grant",
  "target_ura": "<actual Runtime device URA>",
  "grant": {
    "grant_id": "<new unique ID>",
    "owner_user_id": "<owner user ID>",
    "owner_ura": "<owner User URA>",
    "principal_kind": "agent",
    "principal_id": "<recipient Agent URA>",
    "principal_ura": "<recipient Agent URA>",
    "callee_ura": "<provider Agent URA>",
    "subject_ura_pattern": "<exact test order subject URA>",
    "ability_ura_pattern": "<exact lookup Ability URA>",
    "actions": ["invoke"],
    "effect": "allow",
    "lifetime": "ttl",
    "state": "active",
    "created_by": "<authenticated operator User URA>",
    "created_at": "<current RFC3339 timestamp>",
    "expires_at": "<one hour later>",
    "reason": "One-hour test order lookup"
  }
}
```

The backend derives the actor from authentication. Do not send `actor_ura` or
construct delegation proofs, signatures or authority headers yourself. If the
recipient is a person, use `principal_kind: user`, their scalar user ID in
`principal_id`, and their full User URA in `principal_ura`. Realm is part of the
address, not a third principal kind.

## Verify what actually changed

First list the recipient's existing grants with operation `list`, the actual
`target_ura`, `owner_ura`, `principal_kind`, `principal_ura` and `state: active`.
Check for broader existing permissions without removing them automatically.
Submit the owner-approved grant, then list again and match the returned ID,
recipient, subject, ability, action and expiry. Save sanitized responses.

Use the recipient's real authenticated invocation path to test:

- The permitted order query returns the expected synthetic order data.
- A different order is denied before its data is returned.
- A different recipient does not gain access from this grant.
- Refund is denied in a dry-run/test adapter before any financial side effect.

Never send a real refund to prove denial. If there is no safe refund test path,
mark that check untested. Other grants may allow a call; do not attribute their
permission to this narrow grant. A stored record alone is not evidence of
end-to-end enforcement, cross-realm delegation, or receipt completeness.

## Revoke and check again

With the owner's approval, POST operation `revoke` using the same target and
owner, the actual returned `grant_id`, and a reason. The Access Control settings
page also supports revocation. List with `state: revoked`, then repeat the test
lookup and record whether admission rejects it. Revocation does not promise to
cancel work already running. Test expiry separately if claiming expiry works.

Report the exact successful and failed checks, sanitized response/receipt IDs,
and whether the test grant was revoked or remains active. Do not report success
when you only prepared JSON or encountered an authentication/authority error.