Self-service intake is the process of registering an AI producer, agent, or use case through a structured onboarding flow. It captures ownership, purpose, data access needs, and control requirements early so governance starts at deployment rather than after a problem appears.
Expanded Definition
Self-service intake is the controlled entry point for registering a new AI producer, agent, workload, or use case before it receives access to production systems. In NHI governance, the term is broader than a simple form or ticket because it captures ownership, business purpose, data scope, runtime boundaries, credential needs, and required controls at the moment of onboarding.
Definitions vary across vendors, but the governance intent is consistent: make policy decisions early enough to prevent informal deployment from becoming shadow infrastructure. In practice, self-service intake sits between request orchestration and entitlement provisioning, and it should trigger review workflows aligned to NIST Cybersecurity Framework 2.0 outcomes for governance and access control. For NHI programs, it is also the mechanism that records whether the identity is human-run, agentic, ephemeral, or system-managed, which determines how secrets, certificates, and privileges are issued and later revoked.
The most common misapplication is treating intake as an HR-style onboarding request, which occurs when teams collect a name and approval but omit ownership, data constraints, and control requirements.
Examples and Use Cases
Implementing self-service intake rigorously often introduces friction at launch, requiring organisations to weigh faster experimentation against tighter governance and review discipline.
- A development team submits a new agent for code review support, and the intake flow requires purpose, repository scope, tool permissions, and an owner before any token is issued.
- A platform team registers a service account through the intake portal so certificate issuance, rotation expectations, and offboarding steps are defined before production deployment, consistent with the lifecycle focus described in the Ultimate Guide to NHIs.
- An enterprise AI assistant is proposed for finance workflows, and the intake process routes the use case through data classification checks, approval thresholds, and logging requirements before access is granted.
- A third-party automation is added to a CI/CD pipeline, and self-service intake documents external exposure, secret storage location, and revocation ownership to reduce downstream ambiguity.
- A cloud-native workload requests a short-lived credential, and the intake step confirms whether the request can be satisfied with ephemeral access rather than long-lived secrets, aligning with guidance found in the NIST Cybersecurity Framework 2.0.
Because NHI programs often discover that identities are created faster than they are governed, self-service intake becomes the control point that distinguishes approved automation from unmanaged sprawl.
Why It Matters in NHI Security
Self-service intake matters because it prevents identities from entering the environment without an accountable owner, approved purpose, and defined control set. When intake is missing or weak, teams can create agents and service accounts that outlive their intended use, accumulate access, or store secrets in places no one is monitoring. That gap is especially dangerous in NHI environments, where Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Self-service intake helps prevent those outcomes by forcing decisions about least privilege, ownership, and revocation from the start.
It also supports auditability, because security teams can trace who requested the identity, why it exists, what it can access, and which safeguards were approved. In NHI security, that traceability is often the difference between a governed workload and an undocumented dependency that cannot be safely changed. Organisations typically encounter the cost of weak intake only after a leaked secret, an orphaned agent, or an overprivileged service account is discovered, at which point self-service 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 Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Intake is the first checkpoint for registering and governing non-human identities. |
| NIST CSF 2.0 | GV.OC-01 | Capturing purpose and ownership aligns with organisational context and governance. |
| NIST Zero Trust (SP 800-207) | Self-service intake supports zero trust by gating access before trust is granted. | |
| NIST SP 800-63 | Identity proofing concepts inform assurance needed for system and delegated identities. | |
| OWASP Agentic AI Top 10 | A2 | Agent onboarding must define tool access, constraints, and operator accountability. |
Apply assurance checks proportional to the workload's access and sensitivity before onboarding.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
