Entitlements

    Access to a system is granted through an entitlement. It may be a directory role, a group, a license, or an API permission. It may also be something an agent is given to work with, such as a model, a knowledge base, or an MCP server.

    The entitlement inventory brings all of these into a single list. You can review grants—the raw access records from each source system—across all your directories and applications in one place instead of checking each source system separately. Each entitlement needs an owner to approve or reject requests for it. An entitlement with no owner leaves those requests with no one to approve them. You can use the entitlement inventory to find entitlements with no owner and assign owners to them. The entitlement itself is still granted, amended, and revoked at its source (the directory or application it came from), not in SecureAI.

    How entitlements are discovered and what SecureAI stores against them

    Entitlements are discovered, not defined, in SecureAI. Every grant reported by a connected directory or application instance is stored as an entitlement record. Each entitlement record holds the name and description the source carries, the instance that reported it, and its type, such as a role, API permission, or knowledge base.

    The owner exists only in SecureAI, since no source system holds the concept. An owner you record does not reach the source. Access requests and certification campaigns read the owner to determine who approves a request for the entitlement. The inventory itself only displays the owner. A technician's delegated role determines what they can read, and whether they can change the description or the owner.

    Prerequisites

    • To view the inventory, log in as Super Admin, or as a technician whose role includes the Entitlement task under Access Configuration. Changing a description or owner also requires the Edit Entitlement Properties permission under that same task. The built-in Governance Manager role carries both.
    • Add at least one directory or application instance under Application Settings, associate the relevant services with it, and confirm the sync has completed.
    • Owners can only be chosen from the users reported by synced instances, so a user missing from that list cannot be selected.

    Note: Entitlements cannot be created, renamed, or deleted. Only their descriptions and owners can be changed.

    What you can do

    The entitlement inventory lists every entitlement discovered in the connected directories and applications, with its name, description, type, and owners. The type is one of Group, Role, License, API Permission, MCP Server, Model, or Knowledge Base. The Directories column names the instance the entitlement came from and the application that instance belongs to.

    To narrow what is listed, or to change how it is displayed:

    • Use the Select Instances field to limit the inventory to chosen applications and instances. The applications are listed with their instances beneath them, and selecting an application selects all of its instances. All Selected means nothing is excluded.
    • Use the search icon to search by name or description, or to filter by a single type.
    • Use the Add/Remove Columns icon to show or hide the columns.

    To record an owner against a single entitlement:

    1. Click the edit icon beside the entitlement.
    2. Use the Select Entitlement Owner field to choose one or more owners. An owner can approve or reject access requests and review entitlements assigned to them under the certifier assigning rules.
    3. Click Save to record the description and the owners or Close to discard them.

    To record the same owners against several entitlements, select those entitlements and then click Update Owner.

    Tips

    • Work through the entitlements that have no owner by type, starting with the grants that carry administrative rights—an unreviewed request there does the most damage.
    • Where an entitlement you expect is missing, confirm that it's instance is included and no search is applied. If it is still absent, select Fetch against that instance under Application Settings and check again.
    • A sharp rise in the record count almost always follows a newly onboarded instance rather than a change in your directories. Review what that instance added before you schedule the next certification campaign.
    • Name owners who can judge whether someone should hold the entitlement, not the administrators of the platform it came from. Record more than one owner on the grants that carry real risk, so that requests are not held up when a single owner is unavailable.
    • Where the entitlement itself has to change, make the change in the directory or application that defines it. Only the description and the owner are yours to set in SecureAI.
    • If you regularly grant the same set of entitlements together, bundle them into an access template instead of selecting them one at a time. The owner determines who a request is routed to for approval—confirm that routing in Access Review Request or the certification campaign, not in the inventory. See Access Template, Access Review Request, and Access Certification Campaign.
    • Give read-only reviewers a role that includes Entitlement without Edit Entitlement Properties, and reserve editing rights for the team accountable for ownership data. See Help Desk Roles.