Permission statements

Managed registries provide top-level statements for namespace authorization. They compile to policy features under FM.POLICY; embedded and local registries do not enforce this policy surface.

Users

CREATE USER [IF NOT EXISTS] 'principal'
    [WITH property = value [, ...]]

ALTER USER 'principal'
    SET property = value [, ...]

DROP USER [IF EXISTS] 'principal'

A user principal is always a string literal, normally an email address or service-account alias. CREATE USER materializes a link to an existing project principal; it does not grant privileges.

User and namespace groups

CREATE USER_GROUP [IF NOT EXISTS] group_name
    AS 'principal' [, 'principal' ...]
ALTER USER_GROUP group_name
    ADD | REMOVE | SET 'principal' [, 'principal' ...]
DROP USER_GROUP [IF EXISTS] group_name

CREATE NAMESPACE_GROUP [IF NOT EXISTS] group_name
    AS namespace [, namespace ...]
ALTER NAMESPACE_GROUP group_name
    ADD | REMOVE | SET namespace [, namespace ...]
DROP NAMESPACE_GROUP [IF EXISTS] group_name

DROP NAMESPACE [IF EXISTS] namespace

ADD and REMOVE change group membership incrementally. SET replaces the complete membership. Group cycles and removals that would leave referenced policy objects dangling are rejected.

There is no CREATE NAMESPACE statement. Namespace paths exist through feature names; a policy anchor is materialized when a rule or namespace group needs one.

Allow, deny, and revoke

ALLOW [ROLE] privilege_or_role
    ON NAMESPACE namespace | NAMESPACE_GROUP group_name
    TO USER 'principal' | GROUP group_name | PUBLIC

DENY [ROLE] privilege_or_role
    ON NAMESPACE namespace | NAMESPACE_GROUP group_name
    TO USER 'principal' | GROUP group_name | PUBLIC

REVOKE ALLOW | DENY [ROLE] privilege_or_role
    ON NAMESPACE namespace | NAMESPACE_GROUP group_name
    FROM USER 'principal' | GROUP group_name | PUBLIC

ROLE marks the following identifier as a role bundle instead of one privilege. Revocation always names the effect being removed: REVOKE ALLOW or REVOKE DENY.

Inspect permissions

SHOW PERMISSIONS
    [AT namespace]
    [FOR 'principal']
    [WHERE boolean_expression]

SHOW RAW PERMISSIONS
    [WHERE boolean_expression]
    [ORDER BY expression [ASC | DESC] [, ...]]
    [LIMIT count [OFFSET offset]]

SHOW PERMISSIONS AT namespace resolves effective policy at one path. FOR asks about another principal when the caller has authority. SHOW RAW PERMISSIONS returns authored policy rules rather than the resolved decision.

Conditional form and playgrounds

IF EXISTS suppresses missing-target errors for drops.

These statements intentionally have no public playground: a permission mutation in the shared browser session could affect other visitors. See Permissions for privileges, specificity, delegation, and managed-registry examples.