The governance model breaks because the GPT may carry files, credentials, and action permissions that extend far beyond the user's own role. If teams only review the human account, they miss the delegated access path that actually performs the work. That creates shared, identity-bearing access without a clear lifecycle owner.
Why the Surface View Fails
A custom gpt is not just a conversational front end. It can embed instructions, connect to tools, read uploaded content, and act through permissions that the person using the chat does not personally hold. When teams treat it as a simple UI, they review the wrong thing and miss the delegated capability that actually shapes exposure, control, and accountability.
The practical break is in ownership and scope. A chat account may look low risk, but the GPT can operate with reused files, persistent instructions, connected services, and output that depends on access granted elsewhere. That means the security question is not only who typed the prompt, but what authority the configured assistant can exercise and under whose governance it runs.
That distinction is especially important when the assistant can reach data, systems, or workflows on behalf of a user or team. The surface can look ordinary while the underlying behaviour is closer to an access-bearing automation asset than a passive interface.
What Actually Changes in Governance
Once a GPT can carry files, invoke actions, or rely on connected services, the control model shifts from conversation review to delegated-access review. The key questions become who approved the capability, what data it can reach, what conditions trigger the action, and how long that access remains valid.
That is why identity, privilege, and lifecycle controls matter here. A GPT may inherit more authority than the human account suggests, so the relevant review is about permissions, retained secrets, and revocation paths rather than only prompt content. For a control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls gives the clearest access-control and accountability anchor, while NIST Cybersecurity Framework 2.0 helps frame governance, identification, protection, detection, response, and recovery as one operating model.
For environments where the GPT behaves like a delegated non-human access path, the relevant controls are the same ones you would use for other identity-bearing automation. The difference is that the user experience looks conversational, which makes it easier for teams to forget that the assistant may have standing permissions, persistent context, and a separate audit trail.
Why the Risk Scales Fast
The risk grows when people reuse the GPT across teams, connect it to sensitive sources, or allow it to take actions that affect systems of record. In that situation, a single weak review can create broad exposure because the assistant becomes a shared execution layer with unclear ownership, unclear revocation, and unclear blast radius.
That is also why the access path itself matters more than the prompt transcript. If an attacker, careless user, or overbroad configuration can influence the assistant, the impact is not limited to a misleading answer. It can extend to file access, downstream actions, and any standing permissions attached to the GPT. The governance failure is therefore a control-plane issue, not just a content-safety issue.
For teams that need a concrete identity lens, OWASP Non-Human Identity Top 10 is a useful way to think about overprivilege, secret handling, and lifecycle mistakes, and OWASP Agentic AI Top 10 captures the added exposure that appears when an assistant can use tools or act with delegated privilege.
Risk and Threat Considerations
The main security failure is assuming the chat surface is the control surface. That hides the delegated access path, which may carry secrets, persistent permissions, or connected-system reach that can be abused, reused, or left active after the original business need ends.
Failure mechanism: Teams review the human account, not the configured assistant, so overbroad permissions, stale secrets, and unmanaged tool access survive normal account governance.
Impact: Unauthorized data access, unintended actions, weak attribution, and delayed revocation can follow, especially when the GPT is shared or reused across workflows.
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Custom GPTs can hold delegated permissions beyond the user role. |
| IA-5 — Authenticator Management | GPTs may rely on stored tokens, keys, or other secrets for action access. | |
| AU-2 — Event Logging | Delegated actions need audit evidence separate from the chat transcript. | |
| Recommendation — Limit GPT-connected permissions to the minimum required for each approved action. Rotate and revoke GPT-related credentials on a defined lifecycle schedule. Log GPT actions, connector use, and permission changes in an auditable trail. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The issue is governance over delegated access paths and their blast radius. |
| Recommendation — Classify GPT capabilities as governed access assets in your risk model. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A GPT with broad delegated access is a classic overprivilege problem. |
| Recommendation — Remove any GPT permission that exceeds the assistant’s business need. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The assistant can act with authority that differs from the human user. |
| Recommendation — Separate user identity from agent authority when approving tool-enabled GPTs. | ||
Practitioner Guidance
What to verify: Confirm whether the GPT has its own files, tokens, connectors, or action permissions, and treat those as separate from the user’s chat session. If you cannot show who owns the capability and how it is revoked, the control is incomplete.
Decision rule: If the GPT can touch sensitive data or trigger external actions, review it as a delegated access asset, not as a prompt layer. If it cannot be independently inventoried, monitored, and deprovisioned, do not rely on the human account review as your approval gate.
Practitioner takeaway: The right security question is not “what did the user ask?” but “what authority did the GPT retain, and how do we govern that authority over time?”
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What breaks when a custom GPT is shared too broadly?
- What breaks when agent memory is not treated as a governed control surface?
- What breaks when agent access is treated as a developer convenience instead of a control surface?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org