A control principle that limits an agent’s effective authority to the overlap between its own configured scope and the user’s current permissions. It prevents the user’s maximum access from becoming the agent’s default power and creates a smaller, auditable permission set for each tool call.
Expanded Definition
The intersection rule is a permission reduction principle for NHI governance: an agent can act only where its configured scope and the invoking user’s current permissions overlap. That makes the agent’s effective authority smaller than either party’s maximum entitlements, which is critical when tool access, data access, and execution rights are all in play.
In practice, the rule is used to stop a user’s broad access from becoming the agent’s standing power. It is closely aligned with Zero Trust thinking and least privilege, but it is more specific because it computes a per-request ceiling rather than relying on static role assignment. NHI teams often apply it when an AI agent can call APIs, retrieve secrets, or trigger workflows on behalf of a person. The control is conceptually compatible with NIST Cybersecurity Framework 2.0, but no single standard governs this term yet, and vendor usage is still evolving.
The most common misapplication is treating the agent as if it inherits the user’s full session rights, which occurs when authorization is checked once at login instead of at each tool call.
Examples and Use Cases
Implementing the intersection rule rigorously often introduces extra authorization checks and policy complexity, requiring organisations to weigh safer delegation against tighter integration overhead.
- An internal support agent can read a ticket and draft a response, but it can only access the subset of customer records that the authenticated analyst is allowed to see.
- A deployment agent can open a release workflow, yet it cannot approve production changes unless the current user already has that specific approval right.
- A secrets retrieval agent is allowed to fetch only the credentials needed for one task, rather than inheriting the user’s broader vault visibility. This is directly relevant to the governance issues described in Ultimate Guide to NHIs.
- A finance assistant can generate a report from a restricted ledger slice, but it cannot expand into adjacent systems just because the operator has broader enterprise access.
- In Zero Trust workflows, the rule can be combined with per-request verification and scoped tokens so that each action is assessed independently, consistent with NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
The intersection rule matters because NHI compromise is usually a privilege problem, not just a credential problem. NHIMG reports that 97% of NHIs carry excessive privileges, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, as documented in Ultimate Guide to NHIs.
For security leaders, the rule turns an agent from a broad proxy into a constrained executor, which reduces blast radius, improves auditability, and makes policy decisions easier to defend during incident review. It also supports clean alignment with access governance because the effective permission set can be traced to both the user context and the agent policy. When absent, organisations often discover that an agent can perform actions no human intended, especially across API calls, data export paths, and secret-bearing workflows. The operational value is strongest when paired with service account hygiene and scoped delegation patterns discussed in Ultimate Guide to NHIs.
Organisations typically encounter the need for an intersection rule only after an agent overreaches during an incident, at which point permission narrowing 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-02 | Intersection rules prevent excessive delegated permissions in NHI operations. |
| NIST CSF 2.0 | PR.AC-4 | Access control should enforce least privilege and limit permission propagation. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust limits subject authority to verified, context-aware access decisions. |
Constrain each agent action to the overlap of user and agent scope, then audit any excess entitlements.
Related resources from NHI Mgmt Group
- What is the difference between behavioural analytics and traditional rule-based monitoring?
- Why does the 72-hour breach reporting rule matter for IAM and security teams?
- How should security teams govern bulk sensitive data transfers under the DOJ rule?
- How should crypto platforms implement Travel Rule compliance without creating excessive operational overhead?
