AI agent visibility fails when governance waits for perfect discovery

At a glance

What this is: This is an independent analysis of why AI agent discovery alone does not secure agent use, and why governance must start before inventory is perfect.

Why it matters: It matters because IAM, PAM, and lifecycle controls built for humans or static service accounts do not reliably govern AI agents that act at runtime and expand blast radius through overpermissioned access.

👉 Read Defakto Security's analysis of AI agent discovery and governance

Context

AI agent governance is the problem of controlling software entities that can decide, select tools, and act without a person approving each step. The primary issue in this article is not whether AI agents exist, but that many are already live with more access than they should have, while teams keep waiting for perfect discovery before applying control. That is a visibility problem only on the surface. At the governance level, it is a delay problem.

For IAM, PAM, and NHI programmes, the key issue is that legacy environments were built for human users and static machine identities, not agents that can operate across SaaS, CI/CD, and API layers. The article argues for starting with the agents you already know about, then using identity to improve visibility over time. That is the practical starting point, and it is the typical position for enterprises in early AI governance maturity.

Key questions

Q: How should security teams govern AI agents that already have production access?

A: Start with the agents already in production, then rank them by data sensitivity, privilege breadth, and secret reuse. Replace static API keys with identities that can be authenticated at runtime, bind access to the tools and data they actually use, and revoke anything that cannot be attributed cleanly. Governance has to begin with what is already live.

Q: Why do AI agents create more governance risk than traditional automation?

A: AI agents can choose actions at runtime, which means their access needs, tool use, and data paths can change during execution. Traditional automation follows a fixed script, but agents can wander across systems if permissions are broad. That makes access reviews, secret handling, and blast-radius control materially harder than with ordinary workflows.

Q: What do security teams get wrong about AI agent discovery?

A: They treat discovery as a prerequisite for action instead of a starting point for control. In practice, network logs, provider portals, code scans, and secret inventories already reveal enough to begin governing high-risk agents. Waiting for perfect inventory just leaves long-lived credentials and excessive access in place longer.

Q: Who is accountable when an AI agent overreaches or exposes data?

A: Accountability sits with the team that assigned the identity, approved the access, and failed to constrain runtime behaviour. For AI agents, that usually spans IAM, security engineering, platform teams, and the application owner. If the access model cannot explain who approved what, the governance model is already failing.

Technical breakdown

Why AI agent discovery becomes a governance trap

Discovery tools can show outbound calls, API key usage, repo references, and model-provider traffic, but none of that is the same as governance. Governance requires knowing which identity is allowed to act, what it can touch, and how its behaviour is constrained at runtime. In AI agent environments, perfect inventory is a moving target because agents can be embedded in SaaS platforms, pipelines, scripts, and developer workflows. The result is that discovery can create the illusion of progress while the real control gap remains open.

Practical implication: use discovery as an input to control placement, not as a prerequisite for enforcement.

Static API keys and secrets sprawl in AI agent workflows

Most AI agents still authenticate with static API keys, which behave like long-lived secrets rather than governed identities. That creates an exposure pattern familiar to NHI teams: broad credential reuse, weak attribution, and slow containment when keys leak. The difference is scale and speed. Agents can generate far more calls, touch more services, and create more ambient risk than a simple script. Without identity-backed runtime checks, a copied key can become both an access path and an audit gap.

Practical implication: replace static keys with verifiable workload identities where runtime authorisation can be logged and bounded.

Fine-grained access control for autonomous agent behaviour

The article correctly points to the need for distributed access control, but the deeper issue is that agent behaviour cannot be governed well with coarse permissions alone. If an agent can reach a model endpoint, a CI/CD system, and downstream data stores, then each step in that path needs identity-aware policy enforcement. This is where NHI governance and agentic AI governance converge. The control objective is not to trust the agent less in theory, but to make every action dependent on explicit authorization at runtime.

Practical implication: scope policy to the agent's actual execution path, not to the application label attached to it.

Threat narrative

Attacker objective: The attacker objective is to exploit overpermitted AI agent identities to reach data and systems beyond the intended task boundary while staying hard to attribute or contain.

1. Entry occurs through already-deployed AI agents that authenticate with static API keys embedded in SaaS integrations, scripts, CI/CD pipelines, or copied secrets.
2. Escalation happens when those long-lived credentials grant broader access than the task requires, allowing the agent to read data, call tools, or reach systems outside intended scope.
3. Impact follows as excessive access, weak attribution, and delayed containment expand the blast radius, exposing sensitive data, intellectual property, and compliance boundaries.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Perfect discovery is the wrong control objective for AI agents. Security teams do need visibility, but visibility is not the same as governance and it never has been. The article exposes a common programme failure: teams treat incomplete inventory as a reason to delay control, even though the agent population is already known enough to govern in part. The practitioner implication is to stop using discovery as the gate to action and start using it as a prioritisation input.

Static API key dependence is the real AI agent identity problem. AI agents that authenticate with long-lived secrets inherit all the weaknesses of unmanaged NHI, then add faster runtime behaviour and broader blast radius. That means secret leakage is no longer only a credentials issue, it is an operating model issue. The practitioner implication is to treat key sprawl as a governance defect, not a tooling inconvenience.

Runtime authorisation must replace trust-by-provisioning for agent access. Legacy environments were built around the assumption that access granted at setup time remains acceptable during execution, but autonomous and semi-autonomous agents can move across systems faster than review cycles can observe. This is a control-design failure, not just a missing policy. The practitioner implication is to redesign access models around action-by-action accountability.

Identity fabric is becoming the boundary between AI adoption and AI control. The article points toward a useful pattern: use identity to create auditability, then use that auditability to refine discovery. That is the right direction for programmes that need to deploy AI without surrendering oversight. The practitioner implication is to make identity the control plane for agent access, rather than bolting security on after rollout.

AI agent governance now sits inside the same lifecycle discipline as NHI governance. The article's focus on ranking, containing, and progressively governing known agents aligns with lifecycle thinking: identify, assign, constrain, observe, and offboard. The difference is that agent behaviour changes the tempo of that lifecycle. The practitioner implication is to bring AI agents into the same governance model used for high-risk machine identities, with more runtime scrutiny.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• That gap is why teams should pair agent identity controls with the OWASP Agentic AI Top 10 and move from discovery-first thinking to runtime governance.

What this signals

AI agent governance will increasingly be judged by runtime control, not inventory size. Security teams that can only count agents but cannot constrain them will struggle to defend their position as adoption rises. With 48% of companies unable to track and audit the data their AI agents access, governance is already behind the deployment curve, and that gap will widen unless identity becomes the control point.

Ephemeral access is becoming the new baseline for agent security. The more agents are embedded into business workflows, the less useful long-lived secrets and static access reviews become. Teams that want a stable operating model should align agent policy with the NIST AI Risk Management Framework and treat every agent as an identity with a lifecycle, not a script with credentials.

Identity fabric is the right named concept for this phase of AI adoption. It means using workload identity, audit trails, and policy enforcement as the foundation for discovery, containment, and ongoing oversight. That approach scales better than trying to discover every agent before allowing any of them to move.

For practitioners

• Prioritise the agents you already know about Rank known AI agents by data access, production reach, and key reuse. Start with anything touching customer data, production workflows, or shared secrets stores, because those are the fastest routes to material exposure.
• Replace static API keys with workload identities Move high-risk agent interactions away from copied secrets and toward identities that can be authenticated and authorised at runtime. This gives you attribution, revocation leverage, and a cleaner audit trail when behaviour changes.
• Bind policy to the agent execution path Set access rules around the actual tools, endpoints, and data stores the agent uses, not just the application it belongs to. Apply least privilege to each hop so one overbroad entitlement does not become a full-path compromise.
• Use identity data to sharpen discovery Once agents are governed by identity, review access logs and token activity to find the missed agents, forgotten experiments, and duplicated keys. Discovery should become a feedback loop, not a waiting period.

Key takeaways

• AI agents are not hidden in most enterprises, but they are still under-governed because teams are waiting for perfect discovery before enforcing control.
• Static API keys, excessive access, and weak auditability combine to make AI agents a broad identity risk, not just an automation risk.
• The practical answer is to govern known agents first, move them to verifiable identities, and use runtime policy to shrink blast radius as discovery improves.

Key terms

• AI Agent: A software entity that can decide what to do next, choose tools, and execute actions without a person approving each step. In identity governance, that behaviour turns the agent into a subject that needs runtime controls, attribution, and lifecycle handling, not just a credential and a policy.
• Workload Identity: A machine identity used to authenticate software, services, or agents without relying on shared long-lived secrets. It provides a clearer basis for authorization and audit because each action can be tied back to a specific workload rather than a copied API key or opaque token.
• Identity Fabric: A governance pattern that connects discovery, authentication, authorization, and auditing around the same digital entity. For AI agents, it becomes the layer that turns visibility into control by making access decisions traceable and enforceable at runtime.
• Secrets Sprawl: The accumulation of duplicated, long-lived, and poorly tracked credentials across repositories, pipelines, and platforms. In AI agent environments, secrets sprawl expands the attack surface because one leaked key can represent many identities, many systems, and little accountability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Defakto Security: AI Your AI Agents Aren’t Hidden. They’re Ungoverned. It’s time to Act. Read the original.