Sequence-level authorisation is control over the full chain of actions an autonomous agent can take, not just the permissions on each individual request. It matters because an agent can combine several valid calls into an outcome that no single policy check would flag.
Expanded Definition
Sequence-level authorisation governs the allowed order, scope, and cumulative effect of actions taken by an autonomous agent. Rather than asking whether a single API call is permitted, it evaluates whether the entire chain of actions remains within policy, which is increasingly important in agentic systems that can plan and adapt mid-task. In practice, this sits alongside RBAC, PAM, and Zero Trust Architecture, but it is not the same thing as any one of them. RBAC answers who may act, while sequence-level authorisation asks what the agent may do next, after each step is combined with prior context. Definitions vary across vendors, and no single standard governs this yet, so implementations should be evaluated carefully against the NIST Cybersecurity Framework 2.0 and the controls around asset access, identity assurance, and continuous monitoring. For NHI teams, the core question is whether an agent can turn individually valid permissions into an unsafe outcome by chaining tool calls, secrets retrieval, and external side effects. The most common misapplication is treating each request as isolated, which occurs when policy engines do not preserve task context across the full execution sequence.
Examples and Use Cases
Implementing sequence-level authorisation rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger outcome control against slower automation and more demanding policy design.
- An AI agent can read a ticket, retrieve a secret, call a deployment API, and restart a service. Each step may be allowed, but the full sequence may violate change-control boundaries unless the chain is evaluated end to end.
- A support agent can access customer data only after approval, but sequence-level controls prevent it from exporting records, opening an external channel, and then masking the action as a benign workflow. This is especially relevant when reviewing the governance patterns described in the Ultimate Guide to NHIs.
- A build automation agent may be permitted to pull code and run tests, but not to fetch production secrets and redeploy without human confirmation. Continuous verification aligns with the intent of NIST Cybersecurity Framework 2.0.
- A procurement bot can create a vendor record and request pricing, but it should not combine those actions with bank-detail changes unless policy explicitly allows the sequence.
These examples show that the control is less about one privileged request and more about the story the agent is trying to complete across multiple tools and systems.
Why It Matters in NHI Security
Sequence-level authorisation matters because non-human identities often operate with broad privileges, and those privileges become more dangerous when an agent can stitch together valid actions into an unintended result. The issue is not just excess access at the credential level, but uncontrolled composition across workflows, secrets use, and external integrations. That is why the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. When agents are involved, a single over-permissioned identity can become an execution path for data exfiltration, unauthorised deployment, or destructive automation. This is also where Zero Trust logic becomes practical, because trust decisions must persist across the sequence, not just at the first login or API token check. In governance terms, the control supports least privilege, continuous validation, and bounded autonomy for agents, which aligns with NIST Cybersecurity Framework 2.0. Organisations typically encounter this failure only after an incident review shows that every individual call was approved, at which point sequence-level authorisation 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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AA-03 | Agentic AI guidance addresses unsafe multi-step tool use and chained actions. |
| OWASP Non-Human Identity Top 10 | NHI-04 | NHI controls cover over-privileged identities that enable harmful action sequences. |
| NIST Zero Trust (SP 800-207) | Policy Engine | Zero Trust requires continuous, context-aware authorization decisions across actions. |
Constrain agent tool chains so each step and the full sequence remain policy-approved.
Related resources from NHI Mgmt Group
- What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
- What are MCP Authorisation Extensions and why do they matter for enterprise governance?
- When does AI agent access become a board-level security concern?
- What is the difference between network trust and request-level identity trust?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
