IAM and Access
Identity and access management (IAM) controls who and what can use your organisation's Infuse resources.
Most organisation access management starts in the Infuse Portal under Access:
- Members manages active members and invitations. Open a member to manage their baseline membership level, additional roles, direct grants, effective access, and personal API-key metadata.
- Service accounts manages non-human identities for shared integrations and unattended workloads. This section is shown only to administrators with principal-management access.
- Groups manages reusable collections of users and service accounts. Group members inherit every compatible role assigned to the group.
- Roles shows permissions, resource limits, assignments, and conditions. Administrators can create organisation roles or clone an Infuse-provided template.
Personal API keys are self-service credentials under Account > API keys. Service-account API keys are managed from the relevant service account under Access > Service accounts.
How Access Fits Together
| Concept | What it represents | Where to manage it |
|---|---|---|
| Member | A person who belongs to the active organisation. | Access > Members |
| Service account | A non-human identity for an application, integration, agent, or unattended workload. | Access > Service accounts |
| Principal | An identity that can receive access. In an organisation, a principal is a user or service account. | The relevant member or service-account page |
| Group | A reusable collection of users and service accounts. Members inherit every compatible role assigned to the group. | Access > Groups |
| Role | A named bundle of permissions, optional resource limits, conditions, and supported principal types. | Access > Roles |
| Permission | A single allowed action, such as viewing devices or managing IAM groups. | Select a role under Access > Roles |
| API key | A credential that authenticates its owning user or service account. It does not receive access separately. | Account > API keys, or a service account's API keys tab |
Recommended Model
Use roles as the normal unit of access and grant the narrowest role that allows the work to succeed.
Use groups when several users or service accounts need the same access. Assign the role once to the group, then update membership as the team or integrations change.
Open a member or service account and use its Access view when you need to confirm what the identity can do now and why. The effective-access view separates additional direct roles, group-inherited roles, direct grants, and current effective permissions.
Use a personal API key for your own CLI or script when its actions should follow your current organisation access. Use a service account for a shared, production, or unattended workload whose identity and lifecycle must not depend on one person. Keep every key in server-side secret storage and rotate or revoke it when necessary.