Human vs. non-human identity: access and ownership

A human identity represents a person signing in to a system. A non-human identity represents a workload, service, application or automation that acts as a principal. An API key, certificate or access token is a credential used to authenticate; it is not necessarily the identity itself. One principal may have several credentials, and a copied credential can appear in many places.

Who or what is the principal?

For a person, start with the account in the workforce identity provider, their current access and the team that approves it. For a workload, start with the service account, IAM role or federated subject, the application or job that uses it, and the resources it can reach. A repository author who committed a key is evidence about one copy; that author is not automatically the workload owner or the current responder.

How is access issued?

AWS recommends federated temporary access for people and temporary role credentials for workloads. Google Cloud recommends workload identity federation or attached service accounts where applicable instead of exporting long-lived service account keys. These are preferred designs, not traits every existing account already has. Both people and workloads can have temporary sessions; both can be exposed by overbroad permissions or a stolen credential.

When reviewing a finding, record the issuer, principal, credential type, issue or expiry time if available, granted permissions and observed source location. Do not infer that a token is safe merely because it is short-lived. For a long-lived key, find every dependent workload before replacement so rotation does not unexpectedly break production.

Who owns offboarding?

A person leaving or changing roles gives you a directory and access-review event. A service has no employment record. Its owner must know when the application, deployment or integration is retired, then remove grants, disable unused accounts and replace or revoke remaining keys. Google Cloud recommends documenting the application and contact for a service account; its audit log may identify the service account without identifying which application used a shared account.

A practical review record names the principal, using workload, source of any exposed credential, available issuer status and access, service owner, decision and issuer-side action. If the owner is unknown, mark it unknown rather than assigning the person who last edited the file. OWASP lists improper offboarding and secret leakage as separate non-human identity risks; closing one does not prove the other is closed.

Where Cremit fits

Cremit finds credential patterns in supported connected sources and checks issuer status for supported types. It brings available AWS/GCP access context and owner clues into a finding. A source author can be a clue, not a confirmed owner. Cremit does not enumerate every live workload, replace a workforce directory, prove key misuse or automatically revoke credentials. The responsible person still confirms the principal and service owner and acts at the issuer.