AI agent zero trust controls are becoming an identity problem

At a glance

What this is: Appgate argues that AI agents become an identity governance problem when inherited permissions, unmanaged access paths, and weak auditability let them operate beyond intended scope across enterprise environments.

Why it matters: IAM and NHI teams need to treat AI agents as runtime actors with their own access boundaries, because human-centric controls do not contain agent activity once it starts invoking systems and data paths independently.

Context

AI agent runtime access is now an identity governance issue, not just a network routing problem. When an agent inherits the same entitlements as a human user, the control plane has to decide what the agent can reach, when it can reach it, and how that access is observed.

Appgate frames the risk across local devices, virtual machines, Kubernetes pods, and SaaS integrations because each runtime creates a different trust boundary. The practical challenge is that agent-initiated activity can look like normal user activity unless identity, device posture, and policy are bound together.

The article's core point is that zero trust for AI agents only works when the agent is treated as a distinct runtime actor. That is typical of modern AI adoption, where capability arrives faster than governance.

Key questions

Q: What breaks when AI agents inherit access from users and service accounts?

A: The main failure is that inherited access can be broader than the agent’s actual task, so privilege becomes easier to reuse than to govern. Once an agent can chain tool calls across systems, the original approval no longer describes the full blast radius. Security teams need to treat inherited access as a live identity surface, not a one-time provisioning artifact.

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

A: AI agents increase non-human identity risk because they can execute many actions quickly once they inherit a credential or tool permission. That speed expands blast radius, shortens attacker dwell time, and makes weak delegation more dangerous. The remedy is tighter scoping, continuous verification, and strict separation between observation and execution privileges.

Q: How can organisations tell whether AI agent governance is actually working?

A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level. If the organisation cannot show which runtime acted, what it touched, and which endpoint or command it used, then governance is still too coarse. Effective control produces auditable decisions, not just authentication events.

Q: What should organisations do first when shadow AI appears in the environment?

A: Organisations should treat the tool as an unmanaged identity, then decide whether it is allowed to handle business data at all. The first 24 to 72 hours should focus on discovery, containment, and policy enforcement at the access boundary. If the tool cannot be governed inline, it should be denied by default.

Technical breakdown

Why inherited user permissions create over-privileged AI agents

Many AI agents start by borrowing the access rights of the user who enabled them. That creates a simple but dangerous shortcut: the agent can reach every system the user can, even when its task only needs a fraction of that scope. In NHI terms, the agent is functioning like a delegated non-human identity, but without the tighter entitlement boundaries normally expected for machine access. The result is privilege inflation at the moment of enablement, not after compromise. That is why access design must separate user convenience from agent authorisation.

Practical implication: define agent-specific entitlements instead of inheriting full user access by default.

How shadow AI and traffic ambiguity break auditability

Shadow AI appears when users install or connect unsanctioned agents outside central governance. Traffic ambiguity then makes it hard to tell whether a request, file transfer, or API call came from a person or an embedded agent inside a developer tool or workflow. Once those two conditions combine, the access path becomes difficult to inventory and even harder to attest after the fact. The issue is not just missing logs. It is the loss of a clear identity-to-action mapping, which is what audit and response processes depend on.

Practical implication: inventory agent entry points and bind each session to a traceable identity and policy context.

Why Kubernetes and SaaS integrations need per-runtime access boundaries

AI agents deployed in Kubernetes or connected to SaaS APIs are often ephemeral and highly distributed, which makes coarse network controls too blunt. A pod can be created, used, and removed faster than a manual review cycle can react, while SaaS integrations may expose API paths that never appear in a traditional access review. Runtime access therefore has to be controlled at the pod, workflow, or integration layer, not only at the perimeter. This is where zero trust becomes an identity and entitlement problem rather than a transport problem.

Practical implication: enforce pod-level identity and API entitlements for agent workloads before they can reach external services.

Threat narrative

Attacker objective: The objective is to use the agent's delegated access to move data, trigger internal abuse, or create unmanaged access paths without obvious human intervention.

1. Entry occurs when a user installs or enables an AI agent that inherits existing access rights and begins operating inside normal business workflows.
2. Escalation follows when the agent uses that inherited scope to reach internal systems, SaaS integrations, or sensitive data paths beyond the task's real need.
3. Impact appears when the agent leaks data, sends information to third-party LLMs, or performs actions that create unmonitored exposure and audit gaps.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent access is now an identity design problem, not a connectivity problem. The article is really describing runtime authority, not network reach. Once an agent can act inside the same workflows as a human, zero trust has to decide whether that runtime is entitled to the same access shape as the person who enabled it. Practitioners should stop treating agent connectivity as a transport issue and start treating it as delegated identity scope.

Inherited user access is the wrong default for AI agents. That model assumes the agent's task scope is identical to the user's operational scope, which is rarely true and often too broad. When an agent can automate research, communications, or code actions, the entitlement set must be narrower than the user profile or the blast radius expands immediately. The practical conclusion is that agent authorisation must be separate from human authorisation.

Shadow AI creates an inventory problem before it becomes a security problem. If the organisation cannot see which agents exist, where they run, and which identities they use, policy enforcement becomes partial by definition. That makes lifecycle governance, recertification, and offboarding the real control boundary for AI agents. Security teams should treat discovery and classification as the first governance step, not an administrative afterthought.

Runtime auditability must be attached to the agent session, not the user session. The article shows that visibility breaks when AI activity blends into normal employee traffic. That means audit, logging, and policy enforcement need to record agent intent, destination, and entitlement context at the moment of execution. For practitioners, traceability is only meaningful if the agent's action chain can be reconstructed without guessing.

Identity blast radius: AI agents expand the impact of a single delegated account because the same entitlement can now be exercised repeatedly, at machine speed, and across multiple environments. This is the governance concept the article sharpens. A human user may only intermittently reach sensitive systems, but an agent can do so continuously through IDEs, pods, and SaaS APIs. The implication is that access reviews alone are no longer enough; runtime scope control becomes the decisive safeguard.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Runtime access is the control boundary. AI agents do not fit neatly into human session models because they can act repeatedly, across tools, and without the same cognitive or operational limits as a person. Programme owners should shift governance from user-centric access reviews toward per-runtime authorisation, logging, and revocation.

Shadow AI will outpace manual governance unless discovery is automated. If teams cannot see which agents exist and where they connect, they cannot certify or offboard them reliably. That makes inventory, ownership, and runtime traceability the practical minimum for any AI identity programme.

Identity blast radius: once an agent inherits a broad user profile, every downstream integration becomes part of the same exposure surface. Security teams should expect the access model to matter more than the model's intelligence when determining whether an agent is safe to deploy.

For practitioners

• Define agent-specific entitlements Separate AI agent access from the human account that deployed or approved it. Give the agent only the systems, APIs, and data paths required for the current task, not the full user profile.
• Inventory shadow AI entry points Map where agents are being introduced through IDE plugins, local tools, pods, and SaaS integrations. Treat any unmanaged path as an identity exposure until it is assigned an owner and policy.
• Bind runtime logs to agent identity Ensure session logging records the agent identity, destination, and policy decision so investigators can distinguish human activity from agent-initiated actions.
• Apply pod-level and API-level controls Use per-pod identity and explicit API entitlements for Kubernetes and SaaS-connected agents so ephemeral workloads cannot widen scope mid-execution.

Key takeaways

• AI agents create an identity governance gap when they inherit broad user permissions and then operate across multiple runtime environments.
• The article highlights the visibility problem clearly: shadow AI, audit gaps, and ambiguous traffic make agent activity hard to govern after the fact.
• Practitioners need separate agent identity, tighter entitlements, and session-level traceability if they want zero trust to extend beyond human users.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.