Access Control Targets and Policies

Rustici Generator offers tighter controls on what an auth token can and cannot do for tokens given to Large Language Models. These controls come in the form of Access Control Targets and Access Control Policies.

Access Control Targets

An Access Control Target is a grouping of content defined by the user. They can be created and deleted in the access_control API, but the actual group of content they represent is managed on the content resources themselves. For example, one could create an Access Control Target using a request like this:

POST /api/v1/access_control/targets

{
    "id": "Target 1"
}

Target 1 is now a target, but it has no content assosciated with it. To associate content with it, go to the content resource and make a PATCH request specifying the target’s id, like so:

PATCH /api/v1/content/how_to_play_chess

{
    "targets": ["Target 1"]
}

And now how_to_play_chess is associated with Target 1. Content can be associated with any number of targets, and vise versa, so long as the two share a tenant.

Access Control Policies

Access Control Policies apply rules and permissions to Access Control Targets. Specifically, a policy is made of a either a list of targets or a list of other policies, and a rule known as an operator. For example, a request to create a policy might look like:

POST /api/v1/access_control/policies

{
    "id": "Policy 1",
    "target_ids": ["Target 1", "Target 2"],
    "operator": "IN"
}

This would dictate an Access Control Policy which permits access to any content within the targets of Target 1 and Target 2. If a content resource is in neither, then the content would not be visible to the policy holder.

The properties on the policy request are as follows:

• id: The id of the policy.
• target_ids: The list of Access Control Targets this policy refers to. Mutually exclusive with child_policy_ids.
• child_policy_ids: The list of Access Control Policies this policy refers to. Mutually exclusive with target_ids.
• operator: The rule which will be applied to these resources.
  • If target_ids are provided, possible values are IN and NOT_IN.
  • If child_policy_ids are provided, possible values are OR and AND.

To explain the operators a little more in depth: IN means that any content referenced by any listed target is accessible to the policy. NOT_IN would be the opposite; any content referenced by any target would be inaccessible to the policy. The list of content in question is always a union of the target’s sets.

Policies with target_ids can be resolved. Likewise, policies with child_policy_ids can then be resolved from those. The OR operator dictates that any content visible to any listed policy is visible, while the AND operator states that only content visible to all policies in the list will be visible to the parent policy.

For most policies, a simple IN and a list of targets should be enough. However, the ability to reference child policies can allow for very complex permissions if they are needed.

Once a policy is made, it can then be attached to auth tokens for Generator’s MCP resource via the login endpoint .