diff --git a/docs/writing-an-api.md b/docs/writing-an-api.md
index e381b1c9..f967af23 100644
--- a/docs/writing-an-api.md
+++ b/docs/writing-an-api.md
@@ -403,6 +403,8 @@ async init () {
 
 Other modules extend `_access` with their own keys (e.g. `_access.users`, `_access.groups`) and tap both hooks with additional grants, all OR-combined with the base `public` grant. Use `addAccessClause` (exported from `adapt-authoring-api`) for the query-level grant so observers compose safely with each other and with any user-driven `$or`.
 
+`_access` carries an `_adapt.inputType: 'Access'` editor annotation so the authoring UI renders it as a single access widget rather than a raw object. A module adding a grant key should annotate its own sub-property too (e.g. an identity grant uses `_adapt.inputType: 'Principal'` with `options.apiRoot`/`labelField`/`kind`) so the widget can render it without any UI change.
+
 `_access.public` defaults to `true` — resources are public unless a grant or the creating UI sets it otherwise. This preserves open access for resource types without a sharing UI; clients that scope access (e.g. the course wizard) set the value explicitly.
 
 Enforcement is request-scoped: both hooks read `req.auth`/`req.apiData.query`, so `_access` is only applied to REST API requests. Internal/programmatic data access (e.g. server-side `find()`, preview, publish, export) bypasses it by design — there is no request identity to check against outside a REST request.
diff --git a/schema/access.schema.json b/schema/access.schema.json
index dde67788..5bf2d6fd 100644
--- a/schema/access.schema.json
+++ b/schema/access.schema.json
@@ -8,6 +8,7 @@
         "_access": {
           "type": "object",
           "default": {},
+          "_adapt": { "inputType": "Access" },
           "properties": {
             "public": {
               "description": "Whether the resource is accessible to all users",