A delegated access model where the final permission at runtime is the overlap of what the agent is configured to do and what the user currently can do. It blocks privilege inflation and keeps agent behaviour within the smallest valid authority set.
Expanded Definition
Intersection-based authorisation is a runtime permission model for agentic systems in which the effective action set is the overlap between what the agent is allowed to do and what the current user is allowed to do. It is a practical way to prevent privilege inflation in delegated workflows.
In NHI security, this matters because an AI agent may have broad technical capabilities, but it should not be able to exceed the human initiator’s current authority. The model is closely related to least privilege and Zero Trust thinking, but it is narrower: it answers the question, “What may this agent do right now on behalf of this user?” rather than “What can this identity do in general?” Guidance across vendors is still evolving, so implementations vary in how they evaluate role membership, contextual policy, and per-request consent. For a broader NHI governance baseline, NHI Management Group’s Ultimate Guide to NHIs is a useful reference, and NIST frames the governing principle under NIST Cybersecurity Framework 2.0 as access control and continuous risk management.
The most common misapplication is treating the user’s historical permissions as the runtime ceiling, which occurs when systems fail to re-evaluate the user’s current role, session context, or revocation state before each agent action.
Examples and Use Cases
Implementing intersection-based authorisation rigorously often introduces extra policy checks and latency, requiring organisations to weigh stronger containment against additional orchestration complexity.
- An IT helpdesk agent can reset a password only if the requesting employee currently holds the account owner role and the agent’s tool policy explicitly allows resets.
- A finance copilot can draft a payment file, but submission is blocked unless the user has approval authority and the agent’s configured scope includes payment operations.
- A developer assistant can open a pull request, yet it cannot merge or deploy unless the user’s live entitlements permit those actions and the runtime policy confirms release access.
- A support workflow can retrieve customer records only when the customer service agent is already authorised for that tenant and the human requester remains in an active support session.
These patterns align with NHI governance guidance in the Ultimate Guide to NHIs, especially where delegated access intersects with secret usage and service account control. They also map naturally to access-control expectations in NIST Cybersecurity Framework 2.0, where authorization should be explicit, bounded, and auditable.
Why It Matters in NHI Security
Intersection-based authorisation reduces the chance that an agent turns a legitimate user request into a broader system action than intended. Without it, NHI-driven workflows can inherit stale privileges, overbroad service account scopes, or unreviewed tool access, all of which make lateral movement and data exposure easier when an agent is compromised or misrouted.
This is especially important because NHI Mgmt Group reports that Ultimate Guide to NHIs data shows 97% of NHIs carry excessive privileges, which means many environments already start from a weak baseline. In practice, intersection-based authorisation becomes a control that forces runtime restraint even when upstream identity hygiene is poor. It supports the operational intent behind NIST Cybersecurity Framework 2.0 by making authorization demonstrably narrower than nominal entitlements. Organisations typically encounter the need for this model only after an agent performs an action that a user was not actually allowed to complete, at which point the term 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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Defines NHI authorization boundaries and least-privilege expectations for delegated identities. |
| NIST CSF 2.0 | PR.AC-4 | Covers access permissions management and the need for authorized, bounded action. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, per-request authorization rather than implicit trust. |
Apply continuous authorization checks before every agent action and revoke excess access promptly.
