Who should own the risk of custom GPT API access in IAM programmes?

IAM, application security, and platform teams should share ownership, but the decisive control belongs to the API owner. That team defines scopes, validates tokens, logs usage, and can revoke access without changing the GPT itself.

Why This Matters for Security Teams

Custom GPT API access is not just another application entitlement. It creates a live trust path between an IAM programme, a model-driven interface, and a downstream API that can expose data, trigger actions, or chain into other systems. The risk sits in the boundary between identity governance and application control, which is why ownership becomes contested so quickly. Guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both point to the same operational reality: access must be governed where it can be enforced and observed.

That is why the API owner is decisive. IAM can broker identity, but it cannot validate whether a GPT should have scope to read invoices, write tickets, or call production endpoints. Application security can define abuse cases, and platform teams can standardise the plumbing, but the team that owns the API must own the blast radius. In practice, many security teams discover this only after a custom GPT has already been granted broad scopes through a convenient pilot and those scopes are later reused outside the original business case.

How It Works in Practice

Ownership should be mapped to control points rather than organisational chart labels. The API owner defines the scopes, token audience, and allowed methods; IAM issues and tracks the identity; platform engineering provides the brokered path; and application security validates the abuse scenarios and logging requirements. This is consistent with NHIMG’s repeated emphasis on the fragility of non-human access paths, including the Ultimate Guide to NHIs and the Why NHI Security Matters Now section, where unmanaged service access is framed as a recurring source of exposure.

In operational terms, the API owner should be able to answer four questions without escalation:

• What exact scopes does the custom GPT need, and what is explicitly out of bounds?
• How are tokens minted, rotated, and revoked when the use case changes?
• What telemetry proves which user, prompt, or workflow triggered the API call?
• What exception process exists when the GPT needs broader access for a short period?

This division of labour matters because custom GPTs often inherit privilege through convenience, not design. A low-friction integration can mask broad read and write access that was never reviewed by the API owner. NHIMG research on the 52 NHI Breaches Analysis shows how quickly identity shortcuts become incident paths once credentials or scopes are reused outside their intended context. These controls tend to break down when the GPT is wired to multiple APIs with shared tokens and no single team can revoke access end to end.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance faster experimentation against clearer accountability. Current guidance suggests that the right model depends on how embedded the GPT is in business workflows, but there is no universal standard for this yet. In early pilots, IAM may temporarily coordinate approvals, especially when the API owner is not yet ready to operate the control plane. That is a transition state, not a stable governance model.

Edge cases usually appear in shared platforms. If a custom GPT is backed by a central integration layer, the platform team may run the technical controls while the API owner still owns the risk acceptance and scope definition. If the GPT calls multiple APIs, each API owner must approve its own exposure rather than allowing a single front-door approval to cover all downstream systems. For teams facing weak credential hygiene or scope sprawl, NHIMG’s Top 10 NHI Issues is a useful reminder that the recurring failure is usually not the model itself, but the identity and access path wrapped around it.

As a practical rule, IAM should own policy enforcement mechanics, but the API owner should own approval, logging expectations, and revocation authority. That is the only team positioned to measure whether access still matches the API’s actual risk.

Related resources from NHI Mgmt Group

• Why do refresh tokens create governance risk in IAM programmes?
• Why do federated login options create governance risk for IAM programmes?
• Why do SSO programmes still leave access risk after centralisation?
• When does JIT access create more risk than it reduces?