Organisations should choose the approach that reduces duplication and keeps service data synchronized. If the API platform already knows traffic, policy enforcement, and service health, extending it can avoid a second system to secure, integrate, and maintain. A separate platform is harder to justify when the same discovery and governance outcomes can be achieved in one control plane.
Why This Matters for Security Teams
The decision is not really about platform architecture alone. It is about whether the organisation can keep discovery, policy enforcement, and service state consistent without creating another control plane that drifts over time. When teams split responsibilities between an internal developer platform and an API platform, they often duplicate identity, secret handling, and routing logic, which increases operational overhead and makes governance harder to prove.
This is especially relevant where non-human identities carry production access. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — The NHI Market, and fragmentation makes that visibility problem worse. A separate platform can be justified, but only when the API platform cannot natively express the developer workflows, guardrails, and lifecycle controls required. The governance lens from the NIST Cybersecurity Framework 2.0 still applies: know what is being exposed, who can change it, and how quickly control changes propagate.
In practice, many security teams discover duplicated policy and stale service records only after incidents, not through planned platform rationalisation.
How It Works in Practice
The practical decision starts with capability mapping. If the existing API platform already handles traffic management, authentication, authorisation, service catalog data, and runtime health, extending it often preserves a single source of truth. That reduces the chance that an internal developer platform becomes a second inventory of services, secrets, and entitlements. In that model, the API platform can expose self-service workflows for deployment, policy templating, and approved environment creation without rebuilding controls that already exist.
A separate internal developer platform becomes more defensible when the developer experience requires capabilities the API platform was never designed to provide, such as ephemeral environment scaffolding, developer portals, golden path orchestration, or opinionated software supply chain controls. Even then, the strongest pattern is usually integration, not duplication: the platform that owns the policy should stay authoritative for identity, access, and service metadata, while the other layer consumes that truth through APIs or event streams.
Security teams should evaluate three questions:
- Does the current API platform already know the service, its owner, and its runtime policy state?
- Can it enforce or publish the controls needed for developer self-service without manual sync?
- Will a second platform improve governance, or just add another place where secrets, roles, and approvals can drift?
That choice is often sharpened by secrets risk. NHIMG reports that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and undermines centralised oversight in The State of Secrets in AppSec. When a platform split introduces another secret lifecycle, the operational burden rises quickly. The best practice from current guidance is to keep the control plane closest to the authoritative policy source, then extend it only where the existing platform cannot support the required developer path. These controls tend to break down when service ownership is ambiguous and multiple teams independently mutate the same policy or identity records.
Common Variations and Edge Cases
Tighter centralisation often increases platform coupling, so organisations must balance governance consistency against delivery speed and team autonomy. There is no universal standard for this yet, and the right answer depends on how mature the existing API platform is, how many teams consume it, and whether the internal developer platform needs to support materially different workflows.
One common edge case is legacy API infrastructure that is strong on traffic routing but weak on developer ergonomics. In that situation, a separate platform may be reasonable if it can layer on top of the API platform without duplicating service ownership or policy logic. Another edge case is a rapidly growing engineering organisation where the API platform team cannot absorb self-service portal requirements quickly enough; here, a thinner developer platform can be a pragmatic bridge, provided it does not become a parallel source of truth.
A useful rule of thumb is to separate presentation from authority. The developer platform can improve usability, but the API platform should usually remain authoritative for identity, policy, and runtime state. Where that split is not possible, the organisation should avoid building two overlapping systems that both claim to know the same service data. Current guidance suggests treating every additional platform boundary as a control-risk boundary, not just an engineering convenience. In practice, that distinction matters most when teams inherit platform sprawl from acquisitions or when product and platform groups change ownership faster than records can be reconciled.
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, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access and policy consistency are central to deciding between one control plane or two. |
| NIST AI RMF | Governance and accountability apply when multiple platforms manage the same service state. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Platform sprawl increases the chance of uncontrolled non-human identities and secrets. |
| CSA MAESTRO | G1 | Agentic-style platform boundaries require shared control and lifecycle governance. |
| OWASP Agentic AI Top 10 | A2 | If automation extends into self-service or autonomous workflows, runtime guardrails become critical. |
Use a single governance model for identity, policy, and orchestration across developer and API platforms.
Related resources from NHI Mgmt Group
- How can organisations decide when an internal developer platform should become the governance layer for AI workloads?
- How do organisations decide whether to use one platform for LLM observability or separate tools for monitoring and evals?
- How should security teams decide whether JIT access is safe for non-human identities?
- How can organisations decide whether to buy a standalone red teaming tool or a broader platform?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
