Skip to content
Trustle Docs

Core concepts

Trustle controls who can access what in the systems your organization uses. This page explains the terms you need before you set up connections and approval policies. The glossary defines each term in short form.

Connections and systems

Section titled “Connections and systems”

A connection is a link between Trustle and an external system, such as AWS, GitHub, Okta, or Google Workspace. Trustle uses a connection to find the users and the access in that system. It also uses the connection to grant and remove access.

Each connection has a type:

  • A standard connection is a system that Trustle grants access to, such as AWS or Snowflake.
  • An identity provider (IdP) connection, such as Okta or Entra ID, is the system of record for who your users are.
  • An HRIS connection, such as Workday, is the system of record for employment and reporting-line data.

Trustle uses IdP and HRIS connections to keep user records correct. It uses standard connections to manage the access.

The vendor behind a connection is its provider. The provider sets which kinds of access the connection can show, and how Trustle grants access there.

Connect your IdP and HRIS first. Trustle uses them to know who your users are and when their status changes. Then connect the systems that hold the access you want to manage.

Principals and identities

Section titled “Principals and identities”

A principal is an identity inside a connected system, such as a user account or a service account. Trustle finds principals when it reads a connection.

A linked principal is a principal that belongs to a Trustle user. A link lets that person request and receive access through Trustle. An orphaned principal is a principal that no Trustle user owns. It is often an account of a former employee, or an account made outside Trustle. Trustle flags orphaned principals so you can review them.

A service account is a principal that is not a person, such as a bot or an automation. Bulk actions for people, such as expiring all standing access, skip service accounts.

One Trustle user can own many principals, one for each connection where they have an identity. These links show every system a person can reach and every entitlement they hold. When a person leaves, Trustle shows each of their principals, so you know what to remove.

Entitlements and eligibility

Section titled “Entitlements and eligibility”

An entitlement is a unit of access that users can request in a connection, such as a group, a role, a team, or a permission set.

A permission binding is a user’s current access to an entitlement. It is what the connected system shows the user has now.

An eligibility is not access. It is the right to turn access on without an approver, for a set window. A user with a live eligibility can activate the entitlement at any time. This is self-provisioning. Each activation expires on its own.

How an eligibility differs from access:

  • Standing access: the user holds the access until someone removes it.
  • Just-in-time access: the user holds the access for a set time. Then Trustle removes it.
  • Eligibility: the user holds no access. When they need it, they turn on just-in-time access without an approver.

Access requests and approval routing

Section titled “Access requests and approval routing”

An access request is how a user asks for access, such as “give me this entitlement for this reason.” The requester submits it. The request then goes through an approval workflow before Trustle acts on it.

The approval workflow is a set of rules that decides who must approve a request for an entitlement. In the UI, the Approval Routing options are Manager, Single Approval, Quorum Approval, and Two-Level Approval. Each option names who approves. An approver is a user whose decision moves the request forward.

A user can submit up to 20 requests on one connection as a basket. An approver reviews the basket as one item. An admin can also build a privilege pack, a set of entitlements that users request in one step. A pack request creates one access request for each entitlement in the pack.

When every required approval is in place, Trustle approves the request and grants the access. If an approver denies the request, or the requester withdraws it, the request closes and grants nothing.

Provisioning, expiration, and revocation

Section titled “Provisioning, expiration, and revocation”

Provisioning grants access in the connected system, for example by adding a principal to a group. Trustle provisions access after it approves a request, or after a user activates an eligibility. Deprovisioning removes that access from the connected system.

Access can have an expiration: a date and time after which Trustle removes it. An admin can set, extend, or clear an expiration. Access can also end early through revocation, by the user, by an admin, or by a process such as offboarding. Trustle records each grant, extension, and revocation as an access event. Nobody can edit or delete an access event.

Break-glass access gets an on-call user access without an approver. The entitlement’s policy must allow it, and the access ends when the on-call shift ends.

Standing access and just-in-time access

Section titled “Standing access and just-in-time access”

Standing access has no expiration. It stays until someone removes it. Just-in-time access has an expiration from the start, so Trustle removes it when the time ends.

You choose per entitlement:

  • Use just-in-time access for risky access, such as production database access or billing administration. The access ends even if nobody remembers to remove it.
  • Use standing access for tools that people use every day, where a new request each day costs more than it protects.
  • Use self-provisioning between the two. A user gets an eligibility once, then turns on short access when they need it.

Next steps

Section titled “Next steps”