---
title: "Configure content security"
source: "https://docs.vertesiahq.com/security/content-security"
markdown: "https://docs.vertesiahq.com/llms/security/content-security.md"
---

# Configure content security

Content security supplies the resource-side data used by both direct grants and dynamic access rules. Administrators
can classify documents and collections, restrict a collection to named principals, and propagate collection policy to
member documents.

## Classification fields

Vertesia provides two first-class fields for Bell-LaPadula-style policies:

| Field | Principal side | Resource side | Combination behavior |
| --- | --- | --- | --- |
| Security level | `clearance` | `sensitivity` | A typical rule permits `sensitivity <= clearance`. |
| Security domains | `compartments` | `compartments` | A typical rule requires an overlapping compartment. |

The default level labels are:

| Value | Label |
| --- | --- |
| 0 | Public |
| 1 | Internal |
| 2 | Confidential |
| 3 | Restricted |
| 4 | Secret |

These labels make policies easier to discuss, while the stored values remain numeric.

## Classify a document

1. Open the content object.
2. Select **Metadata**.
3. Find **Security Classification**.
4. Select **Edit**.
5. Set the sensitivity and compartments.
6. Save the object.

Documents can also carry custom properties used by Resource Set rules, such as `properties.department` or
`properties.customer_id`.

## Classify a collection

1. Open the collection.
2. Select **Metadata**.
3. Set the sensitivity and compartments.
4. Save the collection.

Collection classification is propagated to member documents:

- document sensitivity becomes the highest sensitivity contributed by its collections;
- document compartments become the union of compartments contributed by its collections.

When a document belongs to multiple collections, the most restrictive contributed sensitivity and the full set of
contributed compartments apply.

## Manage direct collection grants

Use direct grants when a collection should be accessible to named users or groups independently of its attributes.

1. Open a non-dynamic collection.
2. Select **Security**.
3. Select **New**.
4. Choose a user or group.
5. Choose **Read**, **Write**, or **Delete**. Permission levels are cumulative.
6. Save the grant.

You can also add `project:*` from the collection actions. `project:*` means any project member whose system role grants
the corresponding content permission.

Direct grants are stored on the collection and propagated to member documents and their revisions. For an object in
multiple secured collections, grants are additive: access granted by any parent collection remains effective.

Removing one collection's grant does not remove access supplied by another collection or by a matching ABAC rule.
Review all applicable sources when investigating unexpected visibility.

## Unclassified resources

Resources without sensitivity or compartments are treated as unclassified. The current dynamic content policy keeps
unclassified resources visible when a rule uses the corresponding classification field. Classify sensitive content
before relying on a clearance rule to hide it.

For a default-deny rollout, inventory and classify existing content first, then test the restrict-mode policy with
representative users and API keys.

## Administrative bypass capabilities

- The `content:read_all` permission bypasses content security for read operations only.
- The `content_superadmin` role carries `content:superadmin`, which bypasses content security for read, write, and
  delete operations.

These capabilities are intentionally broad. Use them for trusted audit, migration, or content-processing identities,
not as a substitute for a normal access policy.

## Read and mutation behavior

When read access is denied, Vertesia generally returns **404 Not Found** so the response does not reveal whether the
resource exists. A denied write or delete generally returns **403 Forbidden** after the resource has been identified.

List, search, facet, and count operations apply the same visibility policy and omit inaccessible resources.

## Operational checklist

- Use stable classification and compartment vocabularies.
- Prefer group grants over many individual grants.
- Verify propagation after changing a large collection.
- Test every applicable scope with a newly issued token.
- Include direct grants, dynamic rules, and bypass roles in access reviews.
- Keep at least one controlled administrative recovery path before enabling broad restrict mode.

Continue with [Dynamic access rules](/security/dynamic-rules) or the [Developer
guide](/security/developer-guide).