37c75867e53dbcb92e1360cfa3a8bbb0fb9c67ae on 2026-10-22. None of the requested access, privacy, autonomy, afterTeammateReplies, channels, or aiTopics actions has a matching customer Studio route and OpenAPI operation. The action-by-action inactive inventory is docs/platform-api/proposals/ENG-5853-5859.json; ENG-5896 owns the missing behavior. This is not an API contract.
Existing controls and their boundaries
learning_controls and learning_app_controls manage learning-signal settings under the learning feature gate. learning/consent changes region-scoped forward-only learning consent, and its route is gated by LEARNING_CONSENT_API_ENABLED. Learning output terms add/remove bounded terms used by the learning output guard. These are distinct partial controls, not a unified Studio privacy or training setting.
human_ownership_policy exposes show/history/create for specific handoff and return behavior. Account members can read it; administrators can write it. Its wait/alert fields are partial references for timing. Alert recipients are not named Studio approvers. The handoff/settings route requires the default-off HANDOFF_TENANT_SETTINGS_API_ENABLED deployment switch and administrator policy, and persists configuration. The stored dispatch_min_role is read by HandoffTenantSetting.dispatch_roles_for and applied to user actors by EngineeringHandoff#authorise_dispatch! when a transition enters dispatched, subject to ENGINEERING_HANDOFF_LIFECYCLE_ENABLED and AgentAudit::Append.enabled?. This is internal transition authorization: architecture guards show no wired lifecycle dispatch controller or job caller today. No customer dispatch route is established, and no other stored handoff setting is claimed to have a current consumer. These controls do not provide a general autonomy, after-teammate-replies, or approver API.
The published Agent configuration versions page documents exactly four current operations: list versions, compare versions, show the current route, and restore an existing version. Rollback changes the stable pointer and writes one account-scoped activity. It does not publish a version or activate an autonomy rule. No future publish or approval guarantee follows.
Account user and custom-role APIs manage membership/role definitions, not Studio access grants or named external approvers. Super-admin staff approvals and internal switch transitions are separate. P4 owns one shared role/scope model; do not create a second. ENG-5891 owns account defaults versus agent overrides.
Action availability
Every requested action below is missing as a Studio route/operation today. The inactive inventory records each action’s precise reuse boundary, future effect/safety proof, null route and operation ID, pending scopes/events, hidden MCP, and excluded SDK.Future authorization and behavior proof
Until P4 decisions, future governance writes use an administrator and the account resolved throughCurrent.account. P4 owns the shared role/scope model; P9 owns governance and kill-switch decisions; I-30 owns backend implementation. No caller may widen its own scope or approver status. An agent/bot cannot approve its own request.
Future tests exercise each safety-loosening write: role grant, scope widening, autonomy increase, rule removal, and approver addition. Accepted changes record actor and prior value; refused writes preserve permissions and limits. Revocation closes intended sessions. Restore activates only the selected account-owned version. Pending cancel/reassign tests prove chosen bounds, per-item results, conflicts, retries, and no duplicate execution/audit. These are future requirements; this docs slice adds no tests and claims no current runtime enforcement.
External event families access, privacy, autonomy, and after_teammate_replies remain unapproved names without delivery promises. Scopes/events and MCP remain pending P4/P9 review. This inventory is not an operational register, baseline, exemption, or harness-debt entry. The existing three moves_money operations remain unchanged.