---
title: "Principals"
description: "Who can be granted access: users, teams and product tokens, and how Governance identifies them."
canonical: "https://docs.cm.com/governance/guides/core-concepts/principals"
---

# Principals

> Who can be granted access: users, teams and product tokens, and how Governance identifies them.

Source: https://docs.cm.com/governance/guides/core-concepts/principals

A **principal** is anyone or anything that can be given access. When Governance decides whether to allow an action, the first question is always: _who is asking?_

## Types of principal

| Type | What it is | How it is identified |
| - | - | - |
| **User** | A person with a CM.com account. | Their CM.com user GUID. |
| **Team** | A group of users that share the same access. | An ID Governance creates when the team is made in the Governance portal. |
| **Product token** | A machine identity for a system or integration, not a person. | The ID of an existing CM.com API key. Governance registers the key; it does not create one. |

## Good to know

- **CM.com Platform is the source of truth for users.** Governance copies user details from Platform, so you do not create users in Governance.
- **Access can be given to a user directly, or through a team.** A user gets everything their teams are given. See [Teams](https://docs.cm.com/governance/guides/core-concepts/teams).
- **A principal has no access on its own.** It gets access only through a [role assignment](https://docs.cm.com/governance/guides/core-concepts/role-assignments).

## Related

- [Roles](https://docs.cm.com/governance/guides/core-concepts/roles)
- [Accounts and organizations](https://docs.cm.com/governance/guides/core-concepts/accounts-and-organizations)
- [How access decisions work](https://docs.cm.com/governance/guides/how-access-decisions-work)