Core concepts

Trustle manages who can access what, across every system your organization uses. This page introduces the ideas you need before you configure connections, workflows, or policies.

Read this page once before you set up your first connection. The rest of the documentation, including the guides and the glossary, builds on the terms introduced here.

Connections and systems

A connection is a configured link between Trustle and an external system, such as AWS, GitHub, Okta, or Google Workspace. Trustle uses a connection to discover the users and access in that system, and to grant or remove access on your behalf.

Connections have a type. A standard connection is a system Trustle grants access to, such as AWS or Snowflake. An identity provider (IdP) connection, such as Okta or Azure AD, is the system of record for who your users are. An HRIS connection, such as Workday, is the system of record for employment and org-chart data. Trustle uses your IdP and HRIS connections to keep user records accurate, and your standard connections to manage the access itself.

The vendor behind a connection is its provider. The provider determines what kinds of access the connection can show and how Trustle performs provisioning there.

You typically connect your identity provider and HRIS systems first, since Trustle relies on them to know who your users are and when their status changes. You then connect the standard systems that hold the access you want to manage, such as your cloud platforms, SaaS applications, and internal tools.

Principals and identities

A principal is an identity inside a connected system — a user account, a service account, or a member of a group. Trustle discovers principals when it scans a connection.

A principal becomes a linked principal when you associate it with a Trustle user. Linking is what lets that person request and receive access through Trustle. A principal that Trustle finds but that isn’t linked to any user is an orphaned principal — often a leftover account from a former employee, or one created outside of Trustle. Trustle flags orphaned principals so you can review and clean them up.

Not every principal represents a person. A service account is a non-human principal, such as a bot or an automation agent. Service accounts follow their own access lifecycle and are usually excluded from processes that target human users, such as bulk expiration.

A single Trustle user can be associated with many principals — one for each connection where they have an identity. Trustle uses these links to show you, for any one person, every system they can reach and every entitlement they hold.

This picture becomes especially important during offboarding. When a user leaves, Trustle can show you every principal linked to them, across every connection, so you know exactly what needs to be removed.

Entitlements and eligibility

An entitlement is a requestable unit of access in a connection — a group, a role, a team, or a permission set. Entitlements are what users ask for and what Trustle grants.

A user’s actual, current access to an entitlement is a permission binding. This is what the connected system would show you the user has right now.

An eligibility is different from a permission binding. Eligibility is a record that a user is authorized to get an entitlement on demand, for a set duration, without asking again. It models the authority to get access, not the access itself. A user who holds a live eligibility can activate it at any time; this is called self-provisioning.

Eligibility and standing access serve different purposes. Standing access is already granted and stays in place until removed. Eligibility is not access at all — it is a standing authorization that a user converts into short-lived access only when they need it, through activation.

Access requests and approval workflows

An access request is how a user asks for a change in access — typically “give me this entitlement for this reason.” A request always starts with the requester, and moves through an approval workflow before Trustle acts on it.

An approval workflow is the set of rules you configure that decides who must approve a request for a given entitlement. Common shapes include manager approval, a named group of approvers, quorum approval among several approvers, department-based routing, and fully automatic approval with no human step. The approver is the user whose decision moves the request forward; the workflow attached to the entitlement determines who qualifies. The requester is the user who submitted the request in the first place.

When several requests belong together, a requester can submit them as a basket, so an approver reviews one grouped item instead of many. An admin can also pre-curate a bundle of related entitlements into a privilege pack, such as “new engineer onboarding.” Requesting a pack creates one access request per entitlement inside it, and each one still goes through its own approval workflow.

Once every required approval is in place, the request is approved and moves on to provisioning. If an approver denies the request, or the requester withdraws it, the request closes without granting any access.

Provisioning, expiration, and revocation

Provisioning is the act of granting access in the connected system itself — adding a principal to a group, attaching a role, or sending an invite. Trustle triggers provisioning automatically once a request is approved, or once a user activates an eligibility. The reverse action, deprovisioning, removes that access from the connected system.

Access can carry an expiration: a date and time after which Trustle removes it automatically. An admin can set, extend, or clear an expiration on a grant. Access can also end earlier through revocation — by the user, by an admin, or through an automated process such as offboarding. Every grant, extension, and revocation is recorded as an access event, giving you a permanent, append-only history of each access decision. You can review this history at any time to see what access existed, who approved it, and when it changed.

For urgent situations, a designated on-call user can use break-glass access to grant themselves emergency access when the normal approval workflow would otherwise block them. Trustle always audits break-glass access separately from regular grants.

Standing access versus just-in-time access

Standing access is access with no expiration. It stays in place until someone explicitly removes it. Just-in-time access, by contrast, is access that carries an expiration from the start, so it is removed automatically once it is no longer needed.

Standing access is easier to grant but carries more long-term risk, since it does not go away on its own. Many organizations run least-privilege initiatives that convert standing access to expiring access, or that pair a standing entitlement with an eligibility so users self-provision short-lived access instead of holding it permanently.

Choosing between standing and just-in-time access is a policy decision you make per entitlement, based on how sensitive the access is and how often people need it.

Just-in-time access works well for entitlements that carry real risk, such as production database access or billing administration, because it limits how long that access exists even if someone forgets to remove it. Standing access still has a place for tools people use every day, where the friction of frequent re-requesting outweighs the risk.

Every concept on this page connects to the next: a connection surfaces principals and entitlements, a linked principal can request an entitlement or self-provision one it is eligible for, an approved request results in provisioning, and access then stays standing or expires. Every change along the way is recorded as an access event.

Next steps

With these concepts in hand, you are ready to set up your own environment.

• Connect a system to start discovering principals and entitlements.
• Browse the guides to configure approval workflows, expiration, and other features.
• Look up any term in the glossary.