AI agent zero trust controls are becoming an identity problem

At a glance

What this is: This is an analysis of how AI agent runtime access creates new identity and audit gaps, especially when agents inherit user privileges across endpoints, containers, and SaaS APIs.

Why it matters: It matters because IAM, PAM, and NHI teams need to govern agent access as a runtime identity problem, not as a simple network or application-control issue.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Appgate's analysis of AI agent zero trust controls and runtime access

Context

AI agent identity is now a governance problem because agents often operate with the same access as the human user while acting across endpoints, virtual machines, containers, and SaaS APIs. That creates a control gap between who approved the workflow and what identity actually executed the action.

The primary issue is not that AI agents exist, but that enterprises are still treating them like extensions of human users or standard workloads. Once an agent can initiate traffic, reach third-party models, and interact with internal systems, IAM needs to distinguish runtime behaviour, policy scope, and auditability at the identity layer.

Key questions

Q: How should security teams govern AI agents that inherit user access?

A: They should treat the agent as a separate non-human identity with its own entitlements, session controls, and audit trail. Reusing the user’s full access creates excessive blast radius and makes it impossible to prove whether the agent stayed within task scope. The right approach is task-scoped access, monitored execution, and explicit ownership.

Q: Why do AI agents create more audit risk than ordinary automation?

A: Because they can make decisions at runtime, reach multiple systems, and initiate actions without the clean, repeatable patterns that traditional automation usually follows. That makes it harder to reconstruct intent and harder to separate sanctioned activity from shadow AI. Audit design has to capture context, not just events.

Q: What breaks when AI agents are managed like human users?

A: The governance model breaks because human IAM assumes a person, a stable account, and predictable review cycles. AI agents can appear quickly, act across systems, and disappear outside those cadences, which leaves access reviews and recertification blind to real runtime behaviour.

Q: Who is accountable when an AI agent exfiltrates data or triggers abuse?

A: Accountability should sit with the organisation that approved the agent’s scope, owner, and controls, not with the agent as an abstract actor. Practically, that means assigning a business owner, an IAM owner, and a technical control owner so there is a clear chain of responsibility for access, logging, and offboarding.

Technical breakdown

Identity inheritance and over-permissioned AI agents

Many AI agents inherit the permissions of the user or host process that launched them. That is convenient for productivity, but dangerous when the agent can browse internal systems, query APIs, or take actions beyond the user's intent. In identity terms, the agent becomes a non-human identity with human-sized access but machine-speed execution. Without a separate entitlement model, the organisation loses the ability to constrain scope by task, context, or destination. That is why least privilege for AI agents cannot be copied directly from human IAM patterns.

Practical implication: define agent-specific entitlements instead of reusing the parent user’s access profile.

Why shadow AI creates blind spots in audit and compliance

Shadow AI emerges when users install or connect unsanctioned agents outside approved governance paths. These agents can create unmanaged access routes to data, internal tools, and external model providers, often without a durable inventory record. The result is an audit problem as much as a security problem, because the organisation cannot prove what data the agent touched or why a decision was taken. For IAM and GRC teams, the issue is lifecycle control: if the identity is not discovered, registered, and monitored, it is effectively outside governance.

Practical implication: fold agent discovery and registration into NHI inventory and access review processes.

Traffic ambiguity in IDEs, VMs, Kubernetes, and SaaS APIs

AI agents often operate through normal application channels, which makes agent-initiated traffic hard to separate from legitimate user or service activity. That ambiguity is strongest in developer tooling, sandboxed virtual machines, containerised workloads, and API-driven SaaS integrations. Technically, the access path may look valid while the underlying actor has shifted from a human workflow to an autonomous or semi-autonomous runtime. Identity controls therefore need context signals such as device posture, pod identity, workload labels, and session metadata to preserve attribution and enforcement.

Practical implication: bind policy decisions to workload context and session metadata, not to network location alone.

Threat narrative

Attacker objective: The objective is to use agent-mediated access to expand reach, extract data, and create deniable or hard-to-audit activity paths inside the enterprise.

1. Entry begins when a user installs or enables an AI agent that inherits broad access and can reach internal tools, cloud-hosted models, or SaaS APIs.
2. Escalation occurs when the agent uses that inherited access to query sensitive systems, automate phishing, scan infrastructure, or move into destinations that were never explicitly approved for the task.
3. Impact follows when the organisation cannot clearly attribute agent activity, detect data leakage, or prove which actions were taken on which data and under what authorisation.

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 an NHI problem before it is an AI problem. The article is really about runtime identities that act across systems with inherited access, which places them squarely inside NHI governance. App-level policy alone does not solve this because the identity layer still has to answer who or what the agent is, what it can reach, and how its actions are audited. Practitioners should treat AI agents as governed non-human identities, not as enhanced users.

Over-permissioned AI agents create identity blast radius, not just access sprawl. Once an agent can use the user's privileges at machine speed, the damage window narrows and the impact radius widens. That changes the security question from whether the agent is trusted to how much downstream exposure a single runtime identity can accumulate before anyone notices. IAM and PAM teams should measure privilege exposure by task scope, not by account ownership.

Shadow AI is a lifecycle failure, not only a discovery failure. Users can introduce unmanaged agents faster than governance teams can inventory them, but the deeper issue is that discovery, registration, attestation, and offboarding are not yet defined for this actor type. The implication is that access review cadences built for human users will miss runtime identities that appear, act, and disappear outside those cycles.

Traffic ambiguity makes network controls insufficient without identity attribution. When AI agent traffic blends into IDEs, VM egress, Kubernetes pod activity, or SaaS API calls, perimeter evidence alone cannot distinguish sanctioned from unsanctioned behaviour. That means the control plane has to carry identity context forward into every enforcement decision. Practitioners should push for session-level attribution that survives across the full agent execution path.

Runtime AI identity needs its own governance concept: agent identity blast radius. This is the practical measure of how far an AI agent can move, exfiltrate, or trigger side effects before a control boundary stops it. It combines entitlement scope, data access, destination reachability, and audit fidelity into one governance lens. Security teams should use it to decide where to segment agent access first.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• From our research: 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
• Forward link: Pair that governance gap with the 52% visibility figure in AI Agents: The New Attack Surface report to understand why auditability remains incomplete.

What this signals

AI agent governance is converging with NHI governance, which means programmes that already manage service accounts, tokens, and workload identities have a head start. The missing piece is not another tool category but a stronger model for ownership, inventory, and session-level attribution across runtime identities.

Agent identity blast radius: the practical measure of how far an AI agent can move before containment, and it should now be treated as a design input for segmentation and access policy. The more runtime authority an agent has, the more important it becomes to expose that authority to review, logging, and policy enforcement.

Teams should expect pressure to extend zero trust from the network layer into the execution layer, especially where agents operate inside IDEs, Kubernetes pods, and SaaS API chains. That shift will favour programmes that can tie identity, device, workload, and session evidence together in one control loop.

For practitioners

• Inventory every AI agent as a governed identity Create a registry for sanctioned and unsanctioned agents, including owner, purpose, data access, execution environment, and approval status. Fold these records into existing NHI and access review workflows so shadow AI is not treated as an exception process.
• Separate agent entitlements from user entitlements Do not let agents inherit full user rights by default. Issue task-scoped access, restrict destinations, and limit tool reach so an agent can only act within the approved workflow and data boundary.
• Bind policy to execution context Use device posture, pod identity, workload labels, and session metadata to decide whether an agent can connect outward. Context-aware enforcement is what prevents agent traffic from disappearing into normal application noise.
• Add auditability at the point of action Log which agent touched which resource, when it did so, and under what entitlement state. Export those records to SIEM and retention systems so compliance teams can reconstruct agent activity later.
• Treat unsanctioned AI tools as shadow access paths Block direct access to third-party model endpoints and unapproved agent services unless they are explicitly permitted. This reduces the chance that data will leave approved channels without a visible control decision.

Key takeaways

• AI agents are best governed as runtime non-human identities, because inherited user access makes their behaviour an identity problem, not just a tooling problem.
• The main risks are over-permission, shadow AI, and weak auditability, all of which grow when agents act across endpoints, containers, and SaaS APIs.
• Practitioners should separate agent entitlements, bind policy to context, and build logging that can reconstruct what each agent did and why.

Key terms

• AI Agent Identity: The identity assigned to a software agent that can act across systems at runtime. In governance terms, it must be treated separately from the human user or workload that initiated it, because its access scope, execution path, and audit requirements can diverge quickly.
• Shadow AI: Unapproved or undiscovered AI agents operating outside formal governance. These agents create unmanaged access paths, weaken auditability, and make offboarding difficult because the organisation may not know they exist until after a security or compliance event.
• Agent Identity Blast Radius: The total range of systems, data, and actions an AI agent can affect before containment. It is a practical governance measure that combines entitlement scope, destination reach, and logging fidelity, helping teams decide where to segment access first.
• Session-Level Attribution: The ability to tie an action back to a specific runtime session, actor, and policy state. For AI agents, this matters because network logs alone often cannot show whether activity came from an approved workflow, a shadow tool, or a reused user entitlement.

What's in the full article

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

• Specific policy examples for controlling AI agent traffic across local devices, VMs, Kubernetes pods, and SaaS integrations.
• Details on how AppGate ZTNA applies single packet authorization, segment-of-one access, and policy-as-code to runtime AI workflows.
• Implementation-oriented guidance on proxy enforcement, domain filtering, and selective bypass for sanctioned AI use.
• Session logging and SIEM export behaviour for teams that need to prove agent activity during investigation or audit.

👉 Appgate's full article covers the control patterns for local agents, Kubernetes workloads, and SaaS egress paths.

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 NHI governance in your organisation, it is worth exploring.