Manage Members, Teams, Roles, and Policies

Keeptrusts now exposes an AWS-style IAM model across the main identity settings surfaces in the console.

• Policies hold reusable allow or deny statements.
• Roles are attachment containers for those policies.
• Teams share roles across many members.
• Members carry lifecycle state and can receive direct exception-based role grants.

Access is no longer described as a hidden team or route scope. Permissions are evaluated against the target resource using the policies attached through a role.

Use this page when

• You need to invite members, build teams, create roles, or author custom policies.
• You want to inspect the effective permission surface before granting access broadly.
• You need to review member MFA posture while changing identity and access settings.

Primary audience

• Primary: Technical Leaders and IT Admins managing organizational structure
• Secondary: Technical Engineers and Security Engineers reviewing access grants

What You'll Accomplish

• Invite members and review their current MFA posture
• Group members into teams that share job-function roles
• Create reusable policies and attach them to roles
• Inspect effective permissions and current assignments before rollout

Core IAM Model

Surface	Responsibility
Settings → Policies	Author custom allow or deny statements over actions, resources, and conditions
Settings → Roles	Create reusable roles and attach policies to them
Settings → Teams	Maintain shared membership and team role attachments
Settings → Members	Manage user lifecycle, direct exception grants, and MFA posture

Policies

Open Settings → Policies when you need to define reusable access documents.

• System policies are read-only.
• Custom policies can be created and edited by policy managers.
• Statements define allow or deny access over specific actions and KRN-targeted resources.
• The current editor also exposes common conditions such as MFA-required enforcement.
• When you change a policy's statements, Keeptrusts publishes a new default policy version behind the scenes.

Roles

Open Settings → Roles when you want to package policies into a reusable job function.

• Roles do not carry inline permissions.
• The role detail page shows attached policies, current holders, effective permissions, and audit history.
• Use Effective permissions to inspect the resolved allow, deny, and implicit deny surface before you assign the role widely.
• Use the assignments view to see which users, teams, and tokens already hold the role.

Members

Open Settings → Members when you need to work on user lifecycle and posture.

• Invite new members.
• Change display name or organization role.
• Suspend or remove members quickly when access must be revoked.
• Review the built-in security posture summary, including MFA coverage and any active admins without MFA.

Direct user role grants are still available, but they should be treated as exception paths rather than the default shared-access mechanism.

Teams

Open Settings → Teams when you need to share the same role set across many people.

• Teams group members and inherit shared role attachments.
• Membership changes automatically pick up or drop those shared grants.
• Operational team overrides may exist on the team record, but those do not replace IAM policy evaluation.
• Team membership is useful for governance and delegation, but the attached policies still determine what resource access is allowed.

Permission Inspection

When you are deciding whether an assignment is safe, inspect the permission evidence first.

• Review the role's Effective permissions section.
• Check attached policies on the role detail page.
• Open the audit log from the role or policy detail page to see who changed the grant path.
• Use the member and team pages to verify whether access comes from a direct role grant or a shared team attachment.

Best Practices

• Keep policies narrow and resource-specific.
• Use teams for shared job functions such as reviewers, operators, or support queues.
• Reserve direct user grants for true exceptions or short-lived elevation.
• After a policy change, re-check effective permissions before assigning the updated role to more members.

Business Outcomes

Outcome	How the IAM Surfaces Deliver It
Least-privilege access	Policies and effective-permission inspection make grants explicit and reviewable
Scalable onboarding	Team role attachments let new members inherit the right access quickly
Faster reviews	Member posture, role assignments, and audit history expose the full grant path
Safer change management	Versioned policy changes and role-level inspection reduce accidental over-granting

Next steps

• Security Settings — strengthen sign-in and network protections
• Compliance Reporting — connect identity governance to formal evidence
• Members, Teams, and Roles — overview of the same IAM model across console and CLI

For AI systems

• Canonical terms: IAM policy, role attachment, effective permissions, member lifecycle, team role inheritance.
• Console navigation: Settings → Policies, Settings → Roles, Settings → Teams, Settings → Members.
• Current model: policies hold statements, roles hold policies, teams share roles, members carry lifecycle state and exception grants.
• Avoid describing access as hidden team scope or route-based inheritance on these pages.

For engineers

• Start with policies, then roles, then team or user assignment.
• Use team attachments for repeatable job functions and direct user grants for exceptions.
• Review the MFA posture summary on the Members page before expanding privileged access.
• Re-check effective permissions after every policy edit because the attached role may now resolve differently.

For leaders

• Policies, roles, teams, and members now form a more auditable and maintainable grant path than the older scope-shaped model.
• Team-based inheritance keeps onboarding and offboarding predictable at scale.
• Effective-permission inspection helps approval and security reviewers sign off on access with concrete evidence.
• Member MFA posture lets you pair privilege decisions with authentication strength.