Secondary authorization is an added control that evaluates a request in the context of another identity or policy before access is granted. In agentic environments, it helps bind an AI agent’s permissions to the human user who triggered the action. This supports least privilege, accountability, and policy enforcement.
Expanded Definition
Secondary authorization is a decision layer that evaluates a request against a second identity, workload, or policy context before access is granted. In NHI security, that context often binds an AI agent’s action to the human user who initiated it, or to a separate approval identity with different authority. The control is closely related to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need stronger authorization decisions than a single token or session can provide.
Definitions vary across vendors because some products treat secondary authorization as policy re-check, while others treat it as delegated approval, step-up authorization, or request re-binding. In practice, the NHI meaning is narrower: the request is not trusted solely because the agent already has credentials. It must be re-evaluated in relation to who requested the action, what the agent is allowed to do, and whether the action is still valid under policy. This is especially important in autonomous workflows where tool use can outpace the original human intent.
The most common misapplication is assuming primary authentication is enough, which occurs when teams let an agent reuse standing credentials without a second policy decision at execution time.
Examples and Use Cases
Implementing secondary authorization rigorously often introduces latency and workflow friction, requiring organisations to weigh stronger accountability against faster autonomous execution.
- An AI coding agent can draft a deployment change, but a separate human approval must authorize production release before the tool executes.
- A service account may be allowed to read customer data, but a second policy check blocks export unless the triggering user has case-specific approval.
- A privilege escalation request from an agent is validated against the human operator’s role and current ticket context before the elevated action is permitted.
- For delegated operations, the system records both the agent identity and the initiating user so that the approval chain is auditable later.
- After a policy change, the agent’s cached permissions are not enough; the request must be re-authorized against the updated rule set and session context.
This pattern aligns with the governance emphasis in the Ultimate Guide to NHIs, which frames NHI control as a lifecycle problem rather than a one-time login event. It also fits broader authorization design patterns described in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Why It Matters in NHI Security
Secondary authorization reduces the chance that an agent can act beyond the intent, scope, or current authority of the user that triggered it. Without it, organisations often confuse possession of a token with permission to execute, which is dangerous when NHIs and agentic systems can chain tools, call APIs, and move data at machine speed. NHIMG reports that Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges, and that reinforces why a second authorization decision is so valuable when standing access is already too broad.
Secondary authorization is also a practical Zero Trust control because it forces continuous evaluation of context instead of trusting the original session indefinitely. Where organisations need stronger assurance for sensitive actions, this pattern complements NIST SP 800-53 Rev 5 Security and Privacy Controls and the broader guidance in the Ultimate Guide to NHIs.
Organisations typically encounter the need for secondary authorization only after an agent makes an unintended high-impact action, at which point the control becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent actions need context-aware approval before tool execution. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secondary authorization reduces misuse of overprivileged NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be enforced with least-privilege decision logic. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous, context-based authorization decisions. | |
| NIST SP 800-63 | AAL2 | Stronger assurance is needed when an action depends on user-bound authorization. |
Use step-up assurance when the initiating identity must be trusted for sensitive actions.
Related resources from NHI Mgmt Group
- What are MCP Authorization Extensions and how do they help organizations?
- Why is it necessary to address authorization challenges in AI agent deployment?
- When should organisations use runtime authorization for AI agents?
- What is the difference between prompt-based control and runtime authorization for agents?
