The common mistake is assuming that platform access controls automatically cover the customer-facing application. They do not. A system can have strong developer SSO, MFA, and API controls while still lacking the identity infrastructure needed for customer onboarding, offboarding, and role separation inside the product.
Why This Matters for Security Teams
Platform-level AI security is often treated as a control-plane problem, but the risk usually appears inside the product boundary. Developer SSO, MFA, and API gateways can be strong while the application still lacks customer onboarding, tenant separation, and in-product role governance. That gap matters because AI features inherit whatever identity model the application actually enforces, not the one the platform team assumes. NHIMG’s Ultimate Guide to NHIs is clear that non-human identity controls must match operational context, not just infrastructure trust. The same pattern shows up in AI systems that consume secrets, tool access, and delegated permissions through the product layer.
Security teams also underestimate how quickly identity flaws become data exposure problems. When secrets, tokens, or service credentials are mismanaged inside an AI-enabled product, the blast radius is defined by application roles and tenant boundaries, not by the security posture of the admin console. This is why vendor research such as the State of Secrets in AppSec remains relevant: it shows how fragmented secrets handling and weak developer practice can persist even in mature environments. In practice, many security teams encounter customer-facing identity failures only after a rollout has already exposed cross-tenant access or privileged tool use.
How It Works in Practice
Effective platform-level AI security starts by separating infrastructure trust from application identity. The platform may authenticate administrators, but the application still needs its own identity model for users, tenants, service accounts, and AI agents that act on behalf of those users. For AI-enabled products, that means defining who can create prompts, invoke tools, approve actions, export outputs, and delegate privileges inside the product itself. Current guidance suggests treating these as runtime authorisation decisions, not fixed developer entitlements.
In practice, the most durable pattern combines workload identity, short-lived credentials, and policy evaluation at request time. Standards like Anthropic Project Glasswing and the CSA MAESTRO agentic AI threat modeling framework both reinforce the need to model tool use, delegation, and autonomous execution separately from classic access management. For customer-facing applications, that usually means:
- Issuing tenant-scoped identities for users and services, rather than sharing platform-wide credentials.
- Using JIT, ephemeral secrets for AI actions that expire when the task completes.
- Applying policy-as-code so authorisation can evaluate tenant, role, action, and data sensitivity together.
- Separating human admin access from in-product operational roles, including support and automation paths.
- Logging every tool invocation and identity transition so delegated AI activity can be traced later.
NHIMG’s research on the DeepSeek breach is a reminder that exposed secrets and overbroad access are rarely isolated failures; they become systemic once product identity is weak. These controls tend to break down when a platform assumes one identity layer can safely govern both internal operators and external customers, because the application’s authorization context is then too coarse to stop lateral access.
Common Variations and Edge Cases
Tighter platform controls often increase operational overhead, requiring organisations to balance faster delivery against stronger in-product identity design. That tradeoff becomes most visible in multi-tenant SaaS, embedded AI copilots, and products that let customers connect their own tools or data sources. Best practice is evolving here, and there is no universal standard for how much identity logic should live in the platform versus the application.
One common edge case is a product that uses the platform IAM for developers and operators, while customers authenticate through a separate identity store. That split is fine only if the product enforces strict tenancy, role separation, and AI action boundaries internally. Another edge case is agentic AI that can chain tools across accounts or datasets. In those environments, static RBAC often becomes too blunt, because the agent’s behaviour changes by task, context, and user intent. Security teams should expect to use different controls for admin access, customer access, and autonomous AI execution rather than forcing all three into one model.
The practical lesson is that platform security is necessary but not sufficient. If the application cannot express onboarding, offboarding, delegation, and tenant isolation inside its own identity model, the result is a trust gap that platform IAM will never close.
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 CSA MAESTRO 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 | Identity scope and lifecycle are central to fixing app-level AI access gaps. |
| CSA MAESTRO | M1 | MAESTRO covers agent tool access, delegation, and runtime control boundaries. |
| NIST AI RMF | AI RMF addresses governance of AI system behaviour beyond platform controls. |
Use AI RMF governance to assign accountability for customer-facing AI identity decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
