GPT-5 makes AI agent NHI sprawl faster and harder to govern

At a glance

What this is: GPT-5 makes custom AI agent creation easier, which can accelerate NHI sprawl and leave corporate access poorly governed.

Why it matters: IAM teams now have to govern AI agents as non-human identities, not just as tools, because faster adoption can outpace inventory, approval, and access review processes.

By the numbers:

• In a case study, a global brand used Astrix to uncover 250+ GPTs in ChatGPT Enterprise, some with admin-level access, PII exposure, and privilege escalation risks.

👉 Read Astrix Security's analysis of GPT-5, AI agent risk, and NHI sprawl

Context

GPT-5 has made it much easier for employees to create customized AI agents that connect to business systems and act through non-human identities. That changes the governance problem: the challenge is no longer whether teams can build an agent, but whether they can inventory its privileges, ownership, and access pathways before it becomes operational.

For IAM and security teams, this is an NHI problem first and an AI problem second. When agents can be created quickly by non-specialists, service accounts, API keys, and tokens can proliferate faster than approval workflows, recertification, or ownership mapping can keep up.

Key questions

Q: How should security teams govern AI agents that use NHI credentials?

A: Security teams should govern AI agents as non-human identities with explicit ownership, constrained tool access, and auditable lifecycle controls. Every agent should be tied to a named owner, a documented credential source, and a clearly bounded set of systems. If the access path cannot be inventoried and reviewed, the agent should not be allowed to operate against production data.

Q: Why do AI agents increase non-human identity risk so quickly?

A: AI agents increase non-human identity risk because they make it easy for employees to create new access paths faster than governance teams can inventory them. Each agent may introduce service accounts, tokens, and API keys that expand the attack surface. The result is often over-permissioned, orphaned, or forgotten access that outlives the original business need.

Q: What breaks when AI agents are granted broad tool access?

A: Broad tool access breaks least-privilege assumptions because one agent identity can reach multiple systems from a single credential context. If that identity is misconfigured or abused, the impact is no longer limited to one application. The practical failure is an expanded blast radius that turns a small governance error into a cross-platform exposure.

Q: How do organisations know if AI agent governance is working?

A: AI agent governance is working when teams can prove ownership, access scope, and auditability before the agent goes live and again during periodic review. The strongest signal is that every agent is linked to a human owner, a valid credential set, and a current business purpose. Missing lineage or stale access means the control model is already failing.

Technical breakdown

Why faster agent creation increases NHI sprawl

When AI agents are simple to create, the identity footprint expands even if the number of formal applications does not. Each agent may carry its own service account, token, certificate, or delegated API connection, and those credentials become durable access paths unless they are discovered and governed. The operational risk is not the model itself but the hidden identity chain behind it. As agent creation becomes frictionless, unmanaged access tends to appear in parallel with normal business experimentation, which makes oversight harder than in traditional application onboarding.

Practical implication: inventory every agent-to-system connection as an identity object, not just as a software asset.

How integrated tool use changes privilege boundaries

Integrated tool use lets an agent reach email, code repositories, databases, and SaaS applications through explicit permissions. That creates a wider privilege boundary than a traditional assistant because the agent can act across several systems from one identity context. If the underlying permissions are too broad, the agent can expose data or trigger actions well beyond the original use case. In practice, the boundary to manage is not a single app permission, but the combination of all tools reachable through the agent’s NHI credentials.

Practical implication: treat each tool connection as a separate authorization decision and remove any default broad access.

What identity governance must prove before agents go live

Governance for AI agents needs evidence of ownership, least privilege, and auditability before the agent is allowed to interact with production systems. That means mapping the human owner, the non-human identity, the connected platforms, and the data scope in one lineage view. Without that lineage, teams can approve an agent without understanding which credentials it uses or which systems it can reach. The result is not just weak control, but an incomplete security record that complicates investigation and compliance.

Practical implication: require lineage mapping and access approval before enabling any agent against corporate data.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NHI sprawl is the real scaling problem behind fast AI agent adoption: When employees can create agents in minutes, the governance burden shifts from creation control to identity containment. The article shows how service accounts, API keys, and tokens can multiply faster than oversight can normalize them. That is an OWASP-NHI and ZT-NIST-207 problem at the same time. Practitioners should treat every new agent as an identity event, not a productivity event.

Agentic behaviour does not remove NHI governance, it amplifies it: The more an agent can choose tools and operate across systems, the more its permissions matter. Astrix’s examples of overexposed agents, orphaned agents, and privilege escalation paths point to a governance model that loses track of who owns access and where it is valid. The practitioner conclusion is straightforward: access scope must be explicit, reviewable, and tied to a human owner from the start.

Identity blast radius is the right concept for this problem: A single agent identity can connect to many systems, and each extra connection expands the damage radius of one misconfiguration. That means the governance question is not whether the agent exists, but how far its credentials can reach if they are abused or over-granted. The implication for IAM teams is to measure blast radius across every connected workload, not within one application boundary.

AI agents sit inside the same lifecycle discipline as other non-human identities: Ownership mapping, approval workflows, credential rotation, and audit trails are lifecycle controls, not optional add-ons. The article’s orphaned and dormant NHI examples show that agent identities fail in the same places as other machine identities when lifecycle ownership is weak. Practitioners should align agent governance to the same lifecycle standards used for other privileged machine identities.

Visibility without enforcement is only partial governance: The article emphasizes discovery and monitoring, but discovery alone does not resolve access risk if permissions remain broad or stale. The broader lesson is that inventory is necessary, yet it becomes meaningful only when paired with approval, least privilege, and continuous review. Teams should judge their programme by whether they can act on what they find, not just observe it.

From our research:

• In a case study, a global brand used Astrix to uncover 250+ GPTs in ChatGPT Enterprise, some with admin-level access, PII exposure, and privilege escalation risks, according to Moltbook AI agent keys breach.
• Another finding from our breach research shows that attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
• For a broader control model, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding patterns.

What this signals

Identity blast radius: the governance challenge is no longer just discovery, but controlling how far one agent credential can reach across business systems. With 250+ GPTs already found in one enterprise deployment, the scaling question becomes whether ownership and access reviews can keep pace with low-friction creation. Teams should expect shadow agents to surface wherever employee experimentation outruns formal approval.

The programme signal is clear: agent governance must sit inside the same lifecycle discipline used for other privileged non-human identities. That means lineage, ownership, and retirement need to be tracked as operational controls, not documentation tasks. If a team cannot answer who owns an agent, what it can touch, and when it should be removed, it does not yet have governance, only visibility.

For practitioners

• Inventory every AI agent as an identity object Map each custom or third-party agent to its human owner, service account, API key, and connected systems before allowing production use. Include shadow agents created outside formal IT processes so that the inventory reflects real access rather than only approved access.
• Constrain tool access to the minimum reachable scope Review every email, code, database, and SaaS connection exposed through an agent and remove any permission that is not necessary for the specific business task. Separate authorisation decisions by tool instead of assuming one broad agent grant is acceptable.
• Require lifecycle ownership for agent credentials Assign a named business and technical owner to every agent credential, then rotate or retire credentials when the owner changes, the use case ends, or the agent becomes inactive. Unowned and dormant identities should be treated as governance defects, not housekeeping issues.
• Block agent go-live without lineage and audit evidence Use a lineage graph or equivalent record to show which agent connects to which systems, what data it can reach, and which approvals exist. If the record cannot answer those questions clearly, the agent is not ready for production.

Key takeaways

• AI agents are becoming non-human identities that can accumulate privileges faster than IAM teams can review them.
• A single enterprise case already surfaced 250+ GPTs with admin exposure, PII exposure, and privilege escalation risk, showing that the problem is not hypothetical.
• The control that matters most is lifecycle governance tied to ownership, lineage, and least privilege across every connected system.

Key terms

• Non-Human Identity: A non-human identity is any credentialed digital actor that accesses systems without being a person, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. Its security problem is not login convenience, but ownership, scope, lifecycle control, and the blast radius of misused credentials.
• Agent Lineage: Agent lineage is the record of how an AI agent is connected to its owner, credentials, tools, data sources, and downstream systems. It matters because governance fails when teams can see an agent but cannot explain what it can touch, who approved it, or which identity path it uses.
• Identity Blast Radius: Identity blast radius is the amount of damage that can follow from one credential, identity, or permission set being misconfigured or abused. For AI agents, the blast radius expands quickly because one identity may span multiple tools, systems, and data sets across a single operating context.
• Shadow AI: Shadow AI is the presence of AI agents or AI-connected workflows that exist outside formal governance, inventory, or approval processes. In practice, it is an identity management problem as much as a data problem, because unmanaged agents often bring hidden credentials and unreviewed access paths.

What's in the full article

Astrix Security's full analysis covers the operational detail this post intentionally leaves for the source:

• The specific discovery workflow used to inventory custom and shadow GPTs across enterprise environments
• The permission and lineage mapping details that connect each agent to its human owner and reachable systems
• The case study breakdown showing where admin-level access, PII exposure, and privilege escalation surfaced
• The monitoring and governance controls used to keep AI adoption visible as access expanded

👉 Astrix Security's full post covers agent discovery, lineage mapping, and the field examples behind the risk patterns.

Deepen your knowledge

AI agent and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring agent identity sprawl under control, it is worth exploring.