Allow Routine Work But Block Dangerous Operations

Use an explicit action allowlist when an agent needs selected writes but should never delete resources, administer credentials, or use newly introduced unknown operations. This is broader than read-only access and safer than a denylist with an allow fallback.

Web Console

1. Create a Structured Policy scoped to the adapter.
2. Select the complete known-safe action set. For a GitHub issue agent, that might include repository, issue, branch, and pull-request reads plus github:issue:write.
3. Do not include delete, Actions secret, collaborator, repository-admin, or generic unknown endpoint writes.
4. Set THEN to allow and OTHERWISE to deny with reason operation_not_approved.
5. Test each allowed write, explicit destructive actions, unknown endpoints, malformed resources, and another repository.
6. Publish, test, enable, and attach the Policy as mandatory.

CLI Definition Example

{
  "type": "structured",
  "adapter_scope": "github",
  "when": {
    "actions": [
      "github:repo:read",
      "github:issue:read",
      "github:issue:write",
      "github:pull_request:read",
      "github:branch:read"
    ]
  },
  "then": {"decision": "allow", "reason": "routine_work_allowed"},
  "otherwise": {"decision": "deny", "reason": "operation_not_approved"}
}

Publish through the normal Structured Policy lifecycle and attach with apiz client binding policy add only after the full fixture suite passes.

Verify And Maintain

An issue update should reach GitHub; delete, secret, collaborator, and unknown write requests should stop before Secret Broker release. Access Logs must show the normalized action and stable reason.

Adapter action catalogs evolve. Review apiz adapter explain <id> during every APIZ upgrade and deliberately add newly required actions. Default deny keeps an unknown future action blocked until that review. Provider-side least privilege remains a second boundary; APIZ Policy does not broaden the upstream token.