The separation between identity controls that govern access to an AI platform and those that govern access to the application built on top of it. The split matters because each layer has different subjects, different lifecycle owners, and different audit expectations, even when they appear similar at a glance.
Expanded Definition
The AI identity stack split describes a governance boundary between the identity controls that authorize access to the AI platform itself and the controls that authorize access to the application, agent, or workflow built on top of it. In practice, those layers often involve different subjects, such as platform operators, app developers, agent runtimes, and downstream service identities, so a single login or API key rarely tells the full story.
This distinction matters because the trust decision at the platform layer is not the same as the trust decision at the application layer. Platform access may govern model configuration, data connectors, logging, or deployment settings, while application access governs end-user functions, task execution, and tool calls. Industry usage is still evolving, and no single standard governs this term yet, so practitioners should treat it as an operating model rather than a formal control category. For broader identity governance context, NHI Management Group’s Ultimate Guide to NHIs is the baseline reference, while the NIST Cyber AI Profile (IR 8596) helps frame AI-specific risk management.
The most common misapplication is collapsing both layers into one access policy, which occurs when teams reuse the same service account, token, or role for platform administration and application execution.
Examples and Use Cases
Implementing the AI identity stack split rigorously often introduces extra policy design and audit overhead, requiring organisations to weigh clearer accountability against added integration complexity.
- A platform team uses one privileged identity to manage model hosting, secrets injection, and connector configuration, while a separate application identity governs chatbot actions for business users.
- An internal AI agent can call a ticketing API through an application-scoped credential, but only a limited platform operator role can modify the agent’s tool inventory or system prompts.
- A compliance review maps platform identities to infrastructure and model administration, then maps application identities to customer workflows and delegated action approvals.
- A breach investigation uses the split to determine whether misuse came from an exposed platform token or from a compromised application session, a distinction highlighted in NHIMG research such as the LLMjacking analysis and the JetBrains GitHub plugin token exposure.
- Security engineers separate CI/CD access for deploying the AI app from runtime access used by the app to retrieve secrets or invoke model endpoints, aligning those responsibilities with NIST Cyber AI Profile (IR 8596) guidance on AI risk boundaries.
Why It Matters in NHI Security
The AI identity stack split is critical because misaligned identity boundaries create hidden privilege paths. If the platform layer is overtrusted, a compromised admin token can expose model settings, data connections, and downstream secrets. If the application layer is overtrusted, an agent or end-user flow may gain access to tools it should never reach. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which makes layered identity separation essential rather than optional. The same guide also reports that only 5.7% of organisations have full visibility into their service accounts, a visibility gap that becomes even more dangerous when AI platforms and AI applications share credentials.
For governance, the split supports cleaner ownership, narrower blast radius, and more defensible audits. It also helps security teams detect whether a failure is in platform administration, agent execution, or delegated application access. That distinction matters in incidents involving secret leakage, tool abuse, or unauthorized model changes, where response depends on which identity actually crossed the boundary. Operationally, the concept links closely to the Ultimate Guide to NHIs and the compromise patterns documented in 52 NHI Breaches Analysis.
Organisations typically encounter the consequences only after an exposed token, lateral movement event, or unauthorized agent action reveals that platform access and application access were never separated, at which point the AI identity stack split 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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Layered identity boundaries reduce overprivileged non-human access. |
| OWASP Agentic AI Top 10 | A2 | Agent tool and execution permissions must not mirror platform admin rights. |
| NIST AI RMF | AI risk management requires clear role boundaries across the stack. |
Document which identity controls the model platform versus the AI application and review both separately.
