Glossary
This page defines the terms you see in the Trustle UI and in this documentation.
Access event
Section titled “Access event”A record of something that happened to an eligibility or an active grant of access — for example a grant, extension, revocation, or provisioning action. Access events give you a history of every access decision. You cannot edit or delete them.
Access request
Section titled “Access request”A user’s request for a change in access, such as “give me this entitlement for this reason.” A request moves through an approval workflow. Once approved, Trustle provisions the access.
Activation
Section titled “Activation”The action a user takes to turn a live eligibility into active access. The user is already authorized; activation is the moment they use that authorization. Activation goes through the normal request flow, but Trustle approves it automatically.
Approval workflow
Section titled “Approval workflow”The rules that decide who must approve an access request before Trustle provisions it. You configure a workflow per entitlement. Common shapes include manager approval, a named group of approvers, quorum approval, department-based routing, and fully automatic approval.
Approver
Section titled “Approver”The user, or one of the users, whose decision moves an access request forward. The approval workflow attached to the entitlement determines who qualifies as an approver.
Basket
Section titled “Basket”A group of access requests that a requester submits together, so approvers see one grouped review instead of several separate items. All items in a basket share one connection and one duration. A basket differs from a privilege pack: a requester creates a basket on the spot, while an admin curates and titles a privilege pack in advance.
Break-glass access
Section titled “Break-glass access”Emergency access that a designated on-call user can grant themselves when the normal approval workflow would otherwise block them. Trustle always audits break-glass access and reports it separately from regular grants.
Connection
Section titled “Connection”A configured link between Trustle and an external system, such as AWS, GitHub, Okta, or Google Workspace. Trustle discovers principals and entitlements through a connection, and uses it to perform provisioning.
Connection type
Section titled “Connection type”The role a connection plays in your environment. There are three types:
- Standard — a system Trustle grants access to, such as AWS or GitHub.
- Identity provider (IdP) — the system of record for who your users are, such as Okta, Google Workspace, or Azure AD.
- HRIS — the system of record for employment and org-chart data, such as Workday or BambooHR.
Deprovisioning
Section titled “Deprovisioning”Removing a user’s access. Deprovisioning happens automatically when access expires or an eligibility is revoked, or manually when an admin removes access. Trustle performs deprovisioning in the connected system itself, not only in Trustle.
Eligibility
Section titled “Eligibility”A record that a user is authorized to self-provision an entitlement for a set duration. Eligibility is the authority to get access, not the access itself. A user with a live eligibility can activate it on demand, without asking again.
Entitlement
Section titled “Entitlement”A requestable unit of access in a connection — a group, role, team, or permission set. Users ask for entitlements in an access request, and Trustle grants them once approved.
Expiration
Section titled “Expiration”The date and time after which Trustle automatically removes a grant of access or an eligibility. Expiration is the opposite of standing access. An admin can set, extend, or clear an expiration.
Identity provider (IdP)
Section titled “Identity provider (IdP)”The external system that owns user identity for your organization, such as Okta, Google Workspace, or Azure AD. An identity provider is a connection of type identity provider. Some connections, such as Google Cloud, delegate identity to your IdP, so a linked principal on the IdP also satisfies the identity requirement for those connections.
Linked principal
Section titled “Linked principal”A principal that is associated with a Trustle user. Linking lets that user request and receive access on the connection. Compare with orphaned principal and service account.
Organization
Section titled “Organization”Your company’s tenant in Trustle. An organization holds your users, connections, approval workflows, eligibilities, active access grants, and audit history. Every resource in Trustle belongs to an organization.
Orphaned principal
Section titled “Orphaned principal”A principal found in a connection that isn’t linked to any Trustle user — typically a former employee’s leftover account, or an account created outside of Trustle. Trustle flags orphaned principals for review and cleanup.
Permission binding
Section titled “Permission binding”A user’s current, active access to an entitlement on a connection — what the connected system would show you the user has right now. A permission binding is distinct from an eligibility, which is the authority to get that access without asking again.
Principal
Section titled “Principal”An identity inside a connection — a user account, a service account, or a group member. One Trustle user can be associated with many principals, one per connection where they have an identity. See linked principal, orphaned principal, and service account.
Privilege pack
Section titled “Privilege pack”A curated bundle of entitlements that are commonly requested together, such as “new backend engineer onboarding.” Requesting a privilege pack creates one access request per entitlement in the pack, and each request goes through its own approval workflow.
Provider
Section titled “Provider”The external vendor or platform behind a connection, such as AWS, GitHub, Okta, PagerDuty, Microsoft, or Google. The provider determines which kinds of entitlements and principals the connection can show, and how provisioning happens.
Provisioning
Section titled “Provisioning”Granting access in a connected system — for example, adding a principal to a group, attaching a role, or sending an invite. Provisioning is triggered by an approved access request or an activation. The opposite of provisioning is deprovisioning.
Requester
Section titled “Requester”The user who submitted an access request. Distinct from the approver, who decides whether to grant it.
Revocation
Section titled “Revocation”Ending an eligibility or a permission binding before its expiration — by user action, admin action, or an automated process such as offboarding. Trustle records every revocation as an access event.
Self-provisioning (self-approval)
Section titled “Self-provisioning (self-approval)”The ability a user gains when they hold a live eligibility: they can activate the entitlement themselves, on demand, without going through the full approval workflow. Self-provisioning lasts only until the eligibility’s expiration.
Service account
Section titled “Service account”A non-human principal — a bot, an automation agent, or a system integration. Service accounts have their own access lifecycle. Trustle generally excludes them from automation that targets human users, such as bulk expiration of standing access.
Standing access
Section titled “Standing access”Access with no expiration — it stays in place until someone explicitly removes it. Standing access is the opposite of time-bound or expiring access. Many customers convert standing access to expiring access as part of a least-privilege initiative.