AI agent identity needs zero trust inside the enterprise core

At a glance

What this is: This is an analysis of why AI agents running inside core infrastructure create identity and access gaps that traditional Zero Trust controls miss.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern machine-speed access, not just human sessions, or they will miss shadow AI, exposed services, and uncontrolled lateral movement.

👉 Read Appgate's analysis of AI agent security inside the enterprise core

Context

AI agent identity risk grows when autonomous workloads run inside servers, virtual machines, and Kubernetes clusters that were designed around user-centric access models. In that setting, policy statements alone do not remove exposure because the agent still has credentials, network reach, and internal service access.

The governance gap is architectural, not rhetorical. If ZTNA ends at the user boundary, then machine identities, exposed APIs, and workload-to-workload paths can remain outside enforcement even when an organisation believes it has adopted Zero Trust for the environment.

Key questions

Q: How should security teams govern AI agents that run inside core infrastructure?

A: Security teams should govern AI agents as non-human identities with named ownership, bounded entitlements, and lifecycle control. The practical test is whether each agent has a clear purpose, a known credential set, and access that is limited to the systems it actually needs. If not, the agent is operating as shadow identity, not governed automation.

Q: Why do AI agents complicate Zero Trust Architecture?

A: AI agents complicate Zero Trust Architecture because many ZTNA designs assume a human user, a device, and a session boundary. AI agents often operate headless inside servers or Kubernetes clusters, using credentials and service-to-service calls that fall outside that model. The result is a trust gap between policy intent and runtime enforcement.

Q: What breaks when machine identities are not tied to lifecycle governance?

A: When machine identities are not tied to lifecycle governance, access persists beyond the workflow, environment, or owner that justified it. That creates orphaned tokens, stale service access, and hidden lateral movement paths. The programme loses both accountability and containment, especially when agents are deployed quickly and retired slowly.

Q: Who is accountable when an AI agent accesses systems it was not meant to reach?

A: Accountability sits with the team that owns the agent, the identity controls that issued its access, and the governance process that failed to review it. In practice, security, platform, and application owners must share responsibility for the agent’s entitlement model and its revocation path.

Technical breakdown

Why ZTNA breaks down for AI agent workloads

Traditional Zero Trust Network Access is built around users, devices, and remote sessions. AI agents running headless inside servers or Kubernetes do not fit that model because they authenticate as workloads, not as browser-based users. They can expose APIs, service ports, or internal web interfaces that sit inside the trust boundary yet remain reachable by other systems. The result is a policy gap between where the access control model expects the subject to be and where the subject actually operates.

Practical implication: security teams need to map which AI workloads sit outside user-centric ZTNA enforcement and treat them as workload identity problems, not remote access problems.

Machine identity, credentials, and internal access paths

AI agents depend on credentials, tokens, and machine-to-machine communication to act inside enterprise systems. That makes them NHI subjects, even when the business labels them as automation or inference services. If those identities are not governed with lifecycle controls, privilege scope, and contextual authorisation, the agent can access internal systems faster than a human operator could approve or observe. This is where shadow AI becomes an identity issue, not just an application issue.

Practical implication: inventory AI agent credentials alongside service accounts and tokens, then bind each identity to a clear owner, scope, and expiry condition.

Infrastructure cloaking and access enforcement at the point of execution

Cloaking infrastructure until authenticated reduces reconnaissance and limits opportunistic discovery, but cloaking alone is not identity governance. The control value comes when access is enforced at the point of execution, across Linux hosts, VMs, and Kubernetes nodes, using identity-based policy rather than network openness. That aligns with Zero Trust Architecture by continuously verifying the subject before it can interact with internal services, while still acknowledging that the workload is operating autonomously inside the core.

Practical implication: extend authentication and authorisation decisions to the workload layer so exposed services are not the first line of defence.

Threat narrative

Attacker objective: The objective is to exploit unmanaged AI workload access paths to move laterally, reach sensitive systems, and operate without adequate visibility or control.

1. Entry occurs when AI agents are deployed directly into core infrastructure with exposed APIs, service ports, or web interfaces that extend beyond traditional ZTNA coverage.
2. Escalation happens when those workloads use credentials, tokens, or internal trust relationships to reach adjacent systems and establish lateral movement paths.
3. Impact follows when unmanaged machine identities and invisible services create compliance blind spots, unauthorised internal access, and higher data-exfiltration risk.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

AI agent governance is now a workload identity problem before it is an AI policy problem. Enterprises are placing agents inside core infrastructure where they act through credentials, tokens, and internal service paths. That means the control plane must treat them as NHIs first, with lifecycle ownership and access boundaries, before policy language can mean anything operational.

Policy-only guidance fails when autonomous workloads are already embedded in production systems. The article’s core point is that prohibition does not remove behaviour. In identity terms, the enterprise must govern what is actually running inside servers, VMs, and Kubernetes, because unmanaged machine identities do not disappear when policy says they should not exist.

Identity does not stop at the browser boundary. Traditional ZTNA assumptions were designed for human sessions and remote access, not for headless execution inside the enterprise core. The implication is that IAM, PAM, and NHI teams need a shared model for machine-authenticated workloads that can operate without a user present.

Shadow AI is really shadow identity with faster execution speed. The article describes decentralized experimentation and unsanctioned deployment, which creates hidden access paths that security teams cannot govern if they only track users and devices. The practitioner conclusion is that discovery, ownership, and recertification must extend to every agent identity, not just every application.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For the broader control pattern, see OWASP Agentic AI Top 10 for the governance risks created when agents can act across tools and data sources.

What this signals

Shadow AI is becoming an identity governance problem, not just a security operations problem. If organisations cannot inventory AI agents, they cannot recertify them, revoke them, or prove their access boundaries. With 92% of companies saying governing AI agents is critical yet only 44% having implemented policies, the gap is already operational.

The practical shift is toward workload-centric governance that spans IAM, PAM, and NHI management. Teams should expect AI agent controls to converge with service account governance, especially where agents run inside Kubernetes and hybrid infrastructure.

For practitioners, the immediate signal is that Zero Trust programmes must be measured by coverage at the workload layer, not by user access coverage alone. If internal services remain reachable without identity enforcement, the programme is incomplete.

For practitioners

• Map AI agents as NHIs in the identity inventory Record each agent, its credentials, its owning team, and the systems it can reach. Include servers, VMs, and Kubernetes deployments so the inventory reflects runtime reality instead of procurement labels.
• Apply least privilege to machine-to-machine paths Limit each agent to the narrowest APIs, services, and internal endpoints required for its task. Reassess access whenever the agent’s workload, data source, or deployment location changes.
• Move access enforcement to the workload layer Use identity-based policy, authentication, and authorisation controls at the point of execution rather than relying on perimeter assumptions. Cloak exposed services until the workload is authenticated.
• Add recertification for autonomous workloads Review AI agent entitlements on a scheduled basis and confirm that the operational need still exists. Remove orphaned tokens, stale service access, and any agent permissions that outlive the workflow they support.

Key takeaways

• AI agents inside enterprise infrastructure behave like governed identities, not just software features, so IAM and NHI controls have to move into the workload layer.
• The evidence is already material: most organisations report AI agents acting outside intended scope, including unauthorised system access, sensitive data sharing, and credential exposure.
• The decisive control is not policy language but lifecycle-aware, identity-based enforcement that follows the agent through deployment, execution, and revocation.

Key terms

• Agentic AI Core Protection: A control pattern for securing AI agents where they actually run, rather than only at the edge or user boundary. It combines identity-based access, continuous evaluation, and workload-layer enforcement so autonomous or semi-autonomous systems cannot bypass governance simply by operating inside core infrastructure.
• Shadow AI: AI agents or AI-enabled workflows that exist in the environment without formal ownership, policy coverage, or security visibility. In practice, shadow AI becomes a governance problem when the organisation cannot inventory the agent, understand its credentials, or prove what data and systems it can reach.
• Workload Identity: The identity assigned to a machine, service, or AI agent so it can authenticate and be authorised without relying on a human user session. For AI agents, workload identity is the control plane that determines whether machine-speed access is bounded, auditable, and revocable.
• Infrastructure Cloaking: A security technique that keeps services, ports, or workloads hidden until the requester is authenticated and authorised. It reduces reconnaissance and opportunistic access, but it only works as governance when the cloaked service is tied to identity policy and lifecycle control.

What's in the full article

Appgate's full article covers the operational detail this post intentionally leaves for the source:

• Linux Headless Client deployment detail for enforcing ZTNA on servers and virtual machines.
• Kubernetes-side enforcement patterns using sidecar and node-level controls.
• Identity-centric policy examples tied to role, posture, and context.
• Single Packet Authorization handling for cloaking infrastructure until authenticated.

👉 The full Appgate article covers workload-layer enforcement, cloaking, and AI agent access controls in more operational detail.

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 building capability across IAM, PAM, or workload identity, it is worth exploring.