List all namespaces in the tenant. Namespaces are optional containers that scope resources — useful when the same resource type name is used across multiple isolated environments (e.g., prod vs staging).

Create a new namespace. Resources created inside this namespace are isolated from resources in other namespaces. Use "default" namespace unless you specifically need isolation.

Get a namespace by ID.

Delete a namespace by ID. This does not delete the resources inside it.

List all resource types. A resource type defines a category of thing you protect (e.g. "document", "project", "invoice") and the actions available on it.

Create a resource type. Do this before creating resources or policies. The actions list defines what verbs are valid for this type (e.g. ["read", "write", "delete"]). Policies targeting this type use these action names.

Get a resource type by ID.

Delete a resource type by ID.

List resources in the tenant.

Create a resource — a specific instance of a resource type (e.g. a specific document, a specific project). Set external_id to your system's own identifier (database UUID, slug) so you can reference it at evaluation time without storing Vengtoo's internal ID.

Get a resource by ID.

Delete a resource by ID.

List subjects (users, services, AI agents, or any other principal) in the tenant.

Create a subject — any principal that can be authorized (user, service, AI agent, device). Set external_id to your system's own user/service identifier so evaluation calls can reference it without a Vengtoo UUID lookup.

Get a subject by ID.

Delete a subject by ID.

Give a subject a role. The subject inherits all policies assigned to the role. Use this to build RBAC: create a role, assign policies to it, then assign the role to subjects.

Remove a role from a subject. The subject immediately loses any access that came exclusively from this role.

List all roles. Roles are named collections of policies — assign a role to many subjects instead of assigning the same policies repeatedly.

Create a role. After creating it, assign policies to the role with assign_policy (entity_type: "role"), then assign subjects to the role with assign_role_to_subject.

Get a role by ID.

Delete a role by ID. Subjects who had this role lose any access that came exclusively from it.

List all policies in the tenant.

Create a policy. A policy grants or denies a set of actions on a resource type (type-level) or a specific resource (instance-level). After creating, assign it to a subject or role with assign_policy.

For type-level: set resource_type_id and actions — the policy applies to ALL resources of that type. For instance-level: set resource_id and actions — the policy applies to ONE specific resource.

Get a policy by ID, including its resource and action assignments.

Delete a policy by ID. Subjects or roles that had this policy assigned immediately lose the access it granted.

Assign a policy to a subject, role, or group. This is what actually grants access — creating a policy alone does nothing until it is assigned.

entity_type must be "subject", "role", or "group".

For time-boxed (JIT) access: set expires_at. For future-dated access: also set starts_at.

Remove a policy assignment from a subject, role, or group. Access granted by this policy is revoked immediately.

Ask Vengtoo whether a subject can perform an action on a resource. Returns decision: true (allowed) or false (denied), plus the reason and which policy/access path was responsible.

Identify the subject and resource using either their Vengtoo UUID (id) or your system's own identifier (external_id). external_id is preferred in production — it avoids the need to store Vengtoo UUIDs.

For type-level checks (does this user have ANY access to this type of resource?): set resource_type and omit resource_id and resource_external_id. For instance-level checks (does this user have access to THIS specific resource?): set resource_id or resource_external_id.