A principal is the "who" in Tines 3B's access control: the identity that holds access and acts on it. Whenever Tines 3B decides whether something is allowed, it's asking about a principal. Understanding principals makes the rest of access control click into place, because they're one of the three parts every grant is built from.
Read about how access control works here.
The "who" in every grant
Access in Tines 3B is always expressed as a grant: a principal, in a role, on a scope. The principal is the first part, the actor the grant is about. A grant like "this principal has the editor role on this space" only means something once you know who the principal is. So principals are the subjects of access: the things access is given to, and the things whose permissions get checked when they try to do something.
Three kinds of principal
Tines 3B recognizes three kinds of principal, and access can be granted to any of them:
Members. The human users of your tenant, the people who sign in and work in Tines 3B.
Groups. Collections of members, used to grant access to many people at once.
Service accounts. Non-human identities, for scripts, jobs, and services that act on their own rather than as a person.
Because all three are principals, they slot into grants the same way. You can give a member editor access to a space, or a group, or a service account, using the exact same mechanism.
A principal's access is the sum of its grants
No principal's access is a single setting; it's everything granted to it, added together.
For a member, that includes grants made to them directly and grants made to any group they belong to.
Join a group and you pick up all of its access; the union of your own grants and your groups' grants is what you can actually do. This is what makes groups powerful: a group is a principal you grant once, and every member of it inherits that access.
Operations act as a principal
Access checks aren't only about what a principal has; they're about who's acting. Every operation in Tines 3B is carried out as some principal, and it's that principal's grants that decide what's allowed. This holds no matter how the action starts: from the interface, through the API, or by Tines 3B's assistant working on your behalf.
Tines 3B has no identity of its own, so it acts as the person who invoked it and can reach only what that person could. A service account, by contrast, is its own principal, so work it does is checked against its own grants.
The practical effect is that access is consistent from every direction. There's no side door with different permissions, because everything ultimately runs as a principal and every principal is subject to the same grants.
Groups play both roles
Groups are worth a second look, because they sit on both sides of access. A group is a principal when it holds grants on other resources, like a team granted access to a space. The same group is also a scope when the question is who belongs to it, since membership is itself a grant with the person as principal and the group as the thing granted. So a group is a principal and a target of grants at once, which is exactly what lets it gather people together and hand them access as a unit.