A per-document policy decision evaluates each retrieved item separately instead of treating a whole source or repository as uniformly accessible. That approach is essential for AI systems because sensitive and non-sensitive content often coexist in the same document set, requiring field-level controls and verifiable outcomes.
Expanded Definition
Per-document policy decision means evaluating access, sensitivity, and allowed actions on each retrieved item individually, rather than applying one permission model to an entire repository or source. In NHI and agentic AI systems, this matters because one document can contain public references, internal operational detail, and secrets-adjacent content side by side.
This concept is closely related to NIST Cybersecurity Framework 2.0 concepts for governance and access control, but no single standard governs per-document policy decisions yet. Usage in the industry is still evolving, especially where retrieval-augmented generation, document search, and tool-using agents all consume the same corpus. Strong implementations pair document-level evaluation with metadata, classification, and traceable enforcement so that the system can explain why one item was returned and another was withheld.
The most common misapplication is treating folder-level or source-level permissions as sufficient, which occurs when organisations assume every item in a shared repository has the same sensitivity.
Examples and Use Cases
Implementing per-document policy decision rigorously often introduces latency and metadata-management overhead, requiring organisations to weigh finer-grained control against retrieval speed and operational complexity.
- An AI assistant retrieves policy PDFs from a shared knowledge base, but only exposes pages or sections cleared for the requesting role.
- A code search agent scans engineering documents and blocks documents containing embedded secrets or deployment details unless the requester has explicit need-to-know.
- An internal support bot uses Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs to align retrieval access with NHI lifecycle governance, then applies per-item filtering before answering.
- A compliance workflow reviews each evidence file independently so that audit artifacts can be shared while privileged incident notes remain withheld.
- Security teams map the control design to NIST SP 800-53 Rev 5 Security and Privacy Controls when document access must reflect least privilege and data minimisation.
In practice, per-document decisions are most valuable where a single corpus contains mixed sensitivity levels and a single request could surface both safe and restricted material.
Why It Matters in NHI Security
Per-document policy decision reduces overexposure of credentials, runbooks, incident notes, and operational records that frequently travel together in shared systems. That matters for NHI security because service accounts, API keys, certificates, and automation instructions are often documented in the same places as ordinary business content. NHIMG research shows 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes document-aware controls especially important. The same risk pattern appears in Top 10 NHI Issues and in Ultimate Guide to NHIs — Regulatory and Audit Perspectives, where governance failures often trace back to overly broad access assumptions.
Without per-document decisioning, an NHI or agent may retrieve a document that is generally permitted but operationally unsafe in a specific context, such as during external support, incident response, or automated summarisation. Organisations typically encounter the impact only after a sensitive artifact is exposed through search, at which point per-document policy decision 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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Per-document access decisions reduce overbroad retrieval exposure for NHI-driven systems. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access decisions at the point of data retrieval. |
| NIST SP 800-63 | IAL2 | Identity assurance supports reliable policy enforcement for requesting principals. |
| NIST Zero Trust (SP 800-207) | Section 3 | Zero trust requires continuous, context-aware authorization for each access attempt. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege control aligns with restricting access to only needed documents. |
Enforce item-level authorization before an AI agent can retrieve or summarize any document.
Related resources from NHI Mgmt Group
- What breaks when AI actions cannot be traced to a user or policy decision?
- Who is accountable when an AI system in finance makes a policy-relevant decision?
- What breaks when session policy is global instead of per application?
- Why do embedded policy decision points change the risk model for authorization?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
