The process of capturing a proposed AI use case before it is built or deployed. Good intake records the purpose, data involved, intended users, and risk signals, giving governance teams the information needed to classify the request, route review, and decide whether controls are sufficient.
Expanded Definition
Use case intake is the structured front door for a proposed AI or agentic workflow. It captures enough context to determine whether the request is a simple automation, a higher-risk agent, or a use case that requires additional governance before build work begins. In NHI and IAM programs, intake is not just a ticketing step. It is the point where purpose, data sensitivity, intended users, execution authority, and downstream integrations are first made visible.
Good intake helps teams distinguish between a low-risk internal assistant and an AI agent that can invoke tools, read secrets, or act on behalf of a business process. Definitions vary across vendors, but the governance requirement is consistent: the organisation needs a repeatable way to classify the request before identities, permissions, and credentials are provisioned. That aligns closely with the risk-based approach described in the NIST Cybersecurity Framework 2.0 and with NHI lifecycle discipline described in the Ultimate Guide to NHIs.
The most common misapplication is treating intake as a procurement or project-planning form, which occurs when teams collect business goals but fail to capture data access, secret use, and agent autonomy.
Examples and Use Cases
Implementing use case intake rigorously often introduces friction at the start of delivery, requiring organisations to weigh faster experimentation against the cost of early governance review.
- A product team requests an AI support assistant. Intake records whether it will answer from public content only or also query internal systems, which changes the review path.
- An engineering group proposes a deployment agent that can open pull requests and access CI/CD tokens. Intake captures tool access, credential scope, and approval requirements before implementation.
- A finance workflow wants an AI to summarize invoices and trigger actions in an ERP system. Intake identifies whether the system needs read-only access or write privileges.
- A customer-facing chatbot will use retrieval over policy documents. Intake determines whether the content is approved, whether logs contain sensitive data, and whether human review is needed.
- An operations team proposes a service account for an autonomous remediation agent. Intake records the blast radius, fallback steps, and whether privileged access can be time-bound.
These examples mirror the broader NHI governance pattern in the Ultimate Guide to NHIs, where early visibility into purpose and access is what prevents later privilege sprawl. For classification and assurance language, many organisations also map intake questions to the control logic in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Use case intake matters because NHI risk is often created before the first deployment. If a request is approved without understanding what data it touches, what identity it will use, or which systems it can act on, the organisation may create standing privilege, untracked secrets, or an autonomous path into critical infrastructure. The governance failure is not only technical. It is documentary and procedural: there is no defensible record of why access was granted or what safeguards were required.
That is especially important in light of NHIMG research showing that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. Intake is where teams can decide whether a proposed use case should ever receive credentials, and if so, whether it needs JIT access, scoped tokens, or a non-production sandbox first.
Organisations typically encounter uncontrolled agent access only after a deployment incident, at which point use case intake 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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Use case intake captures agent authority, tool access, and risky autonomy before build. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Intake identifies the identity, secrets, and access patterns a proposed NHI will require. |
| NIST CSF 2.0 | GV.RM-01 | Governance risk management depends on intake that records purpose, data, and exposure. |
| NIST Zero Trust (SP 800-207) | AC-4 | Intake should define least-privilege access needs before dynamic authorization is issued. |
| NIST AI RMF | AI risk management starts with describing the intended use, users, and potential impacts. |
Record agent capabilities and approval boundaries before any tool access or execution is granted.
Related resources from NHI Mgmt Group
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
- How do organisations decide whether encrypted computation is enough for a use case?
- How do security teams decide whether biometrics are appropriate for a use case?
- How should organisations centralise AI use case and model inventories?
