Who is accountable when a custom GPT performs an unintended action?

Accountability should sit with the team that owns the GPT, its configuration, and the credential it uses. Audit logs often show the token owner or service identity, not the person who typed the prompt, so governance must include ownership, logging, and revocation paths. Otherwise, responsibility becomes ambiguous after the fact.

Why This Matters for Security Teams

A custom GPT that acts on tools, files, or connected APIs is not just a chat interface. It is an operational identity with delegated power, and unintended actions can create the same blast radius as a compromised service account. Accountability becomes difficult when logs record the token, service identity, or workspace owner rather than the person who prompted the action. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that the credential path matters as much as the prompt path.

Security teams often get this wrong by treating the GPT like a human user with a human-style approval trail. That fails because the model can chain tools, persist context, and execute actions after the original intent has shifted. Current guidance from the NIST Cybersecurity Framework 2.0 pushes organisations toward clearer governance and accountability, but it does not remove the need to define who owns the model, who approves its scope, and who can revoke its access. In practice, many security teams encounter the accountability gap only after a GPT has already sent the email, changed the record, or called the API, rather than through intentional control design.

How It Works in Practice

The practical answer is to assign accountability to the team that owns the GPT configuration, the connected workflow, and the credential used at execution time. That means separating prompt authorship from operational authority. A user may initiate a task, but the organisation should treat the GPT owner, system administrator, or service custodian as the accountable party for access design, guardrails, and revocation paths. For AI-connected systems, this is consistent with emerging agentic governance guidance in the Ultimate Guide to NHIs, especially where secrets, tokens, and service identities drive execution.

• Bind every GPT instance to a named business owner and technical owner.
• Use workload identity and short-lived credentials rather than shared static secrets.
• Log the prompt, tool call, identity used, and approval context together.
• Define escalation and revocation paths before the GPT is connected to production systems.
• Limit tool scope so the model can only act within a narrow, reviewable task boundary.

That control model aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance, access control, and recovery, but the implementation detail is important: the record of who launched the prompt is not enough. The organisation also needs to know which identity the GPT used, what permission set was active, and whether the action was reversible. These controls tend to break down when a custom GPT is embedded in a shared workspace with inherited permissions because ownership and execution authority are no longer aligned.

Common Variations and Edge Cases

Tighter accountability controls often increase operational overhead, requiring organisations to balance auditability against developer speed and user convenience. There is no universal standard for this yet, so the right model depends on whether the GPT is answering questions, executing transactions, or chaining multiple tool calls.

One common edge case is a human-triggered GPT that makes a harmful decision based on ambiguous instructions. In that scenario, the prompt author may share some responsibility, but the greater governance failure usually sits with the team that allowed excessive privilege, weak logging, or no approval gate. Another edge case is delegated automation in a regulated workflow, where the GPT acts on behalf of a department but the service identity is managed centrally. In those environments, accountability should be explicitly split between business ownership, security oversight, and platform administration. NHI Mgmt Group’s research shows only 20% of organisations have formal processes for offboarding and revoking API keys, which makes post-incident blame assignment especially unreliable if revocation paths are not preplanned.

Best practice is evolving toward intent-aware authorisation, JIT credentialing, and clear ownership of every autonomous component, but organisations should not assume the model itself can be the accountable party. It cannot accept policy, remediate its own access, or answer for the business impact after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent performs an unauthorized action after injection?
• Who is accountable when an AI agent performs an unauthorized action in a SaaS product?
• Who is accountable when an AI assistant performs a sensitive action after DOM manipulation?
• Who is accountable when an agent performs a sensitive action without adequate approval?