Topic starter
11/07/2026 8:25 pm
TL;DR: AI agents often inherit user permissions, create shadow access paths, blur audit trails, and can leak data or trigger internal abuse across endpoints, VMs, Kubernetes, and SaaS integrations, according to Appgate. The core issue is not connectivity alone; identity-centric governance fails when agent activity is treated like human activity instead of a distinct runtime actor.
Editorial analysis by NHI Mgmt Group, based on content published by Appgate: “How AppGate ZTNA Secures AI Agents Across Devices, VMs, and Kubernetes with Zero Trust”.
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.
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.
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.
Practitioner guidance
- Define agent-specific entitlements Separate AI agent access from the human account that deployed or approved it.
- Inventory shadow AI entry points Map where agents are being introduced through IDE plugins, local tools, pods, and SaaS integrations.
- 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.
Bottom line: AI agents create an identity governance gap when they inherit broad user permissions and then operate across multiple runtime environments.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 8:55 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent zero trust controls are becoming an identity problem