A sub-principal is a non-human actor that performs work on behalf of a human identity, such as an OAuth app, API token, or service account. Labeling this relationship matters because the same action can be routine automation or suspicious abuse depending on whether a person or delegated credential actually executed it.
What a sub-principal is doing in practice
A sub-principal is not the human identity itself, but a delegated actor carrying out work on that person’s behalf. In practice, that means an OAuth app, API token, or service account can inherit enough trust to trigger meaningful security outcomes.
The useful distinction is execution authority. The action may look automated, yet the security posture changes depending on whether the event came from a person, a delegated credential, or an unmanaged automation path.
Why the label matters for access and accountability
Calling something a sub-principal helps separate delegated software actors from the humans who approved or created them. That distinction matters when you are reviewing access paths, tracing approvals, or deciding whether an action should be treated as routine automation or as suspicious use of delegated trust.
Sub-principals often sit in the middle of identity and authorization flows. They may not own intent, but they can hold enough permission to create, modify, read, or forward sensitive data, which is why their behavior needs to be interpreted in context rather than as generic machine activity.
Common forms of sub-principal
The term usually covers identities or credentials that act on behalf of a person, including OAuth applications, scoped API tokens, and service accounts. These can be tightly bounded and legitimate, or they can become broad, persistent, and hard to distinguish from normal application behavior.
In mature environments, a sub-principal may represent a carefully constrained delegation chain. In weaker environments, the same pattern becomes a shadow access path that survives long after the original business need has changed.
How sub-principals change security interpretation
When a sub-principal performs an action, the investigator should ask what authority it inherited, what it can reach, and whether that access still matches the intended business purpose. That is why the same API call can be harmless automation in one case and privilege abuse in another.
For workflow design and detection, the important issue is not whether an actor is human or non-human in the abstract, but whether the delegated relationship is explicit, current, and sufficiently bounded for the task it is performing.
Risk and Threat Considerations
Sub-principals create risk when delegated access outlives its purpose, is over-scoped, or is difficult to distinguish from normal service activity. They are also attractive to attackers because a stolen token or abused service account can look like legitimate automation while still carrying real authority.
Failure mechanism: Excess privilege, weak lifecycle control, token theft, or poor attribution lets an attacker use the delegated actor as a trusted execution path instead of a visibly compromised human account.
Impact: Unauthorized data access, hidden persistence, lateral movement, and control-plane abuse can follow, especially when the sub-principal has broad API access or long-lived credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Sub-principals often hold delegated non-human access that can exceed intent. |
| NHI-07 — Long-Lived Secrets | API tokens and similar sub-principal credentials often persist beyond their intended use. | |
| Recommendation — Constrain delegated credentials to the minimum access needed and review scope regularly. Rotate or expire delegated secrets promptly and remove stale credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Sub-principal credentials require lifecycle control, rotation, and revocation. |
| AC-6 — Least Privilege | Delegated actors should not retain more access than the task requires. | |
| Recommendation — Manage delegated credentials through issuance, rotation, and revocation controls. Apply least privilege to every delegated access path and entitlement. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API tokens and service accounts can be abused when delegated authentication is weak. |
| Recommendation — Harden authentication for delegated API access and monitor for token abuse. | ||
Practitioner Guidance
Why practitioners should care: A sub-principal is useful only when the delegation is intentional, bounded, and reviewable. Treat the delegated actor as a first-class security subject in logs, approvals, and ownership records so its actions can be explained later.
Common misunderstanding: Automation does not automatically mean low risk. If a delegated credential can act broadly or persist indefinitely, it deserves the same scrutiny you would apply to any other powerful access path.
Practitioner takeaway: The more authority a sub-principal has, the more important it becomes to know exactly who created it, what it can do, and when it should be removed or re-scoped.
Related resources from NHI Mgmt Group
- What breaks when an agent delegates work to a sub-agent without carrying the original principal through the chain?
- What breaks when principal validation is weak in SSH certificate flows?
- What breaks when principal restrictions are parsed like lists?
- How should organisations govern sub-agents in agentic commerce?
