Notifications
Clear all
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.
NHIMG editorial — based on content published by Appgate: Securing AI Agents with AppGate ZTNA, Zero Trust for Every Runtime
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Separate agent entitlements from user entitlements Do not let agents inherit full user rights by default.
- Bind policy to execution context Use device posture, pod identity, workload labels, and session metadata to decide whether an agent can connect outward.
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.
👉 Read Appgate's analysis of AI agent zero trust controls and runtime access →
AI agent runtime access: what IAM teams need to control now?
Explore further
11/07/2026 8:55 pm
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.
A few things that frame the scale:
- 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.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
A question worth separating out:
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.
👉 Read our full editorial: AI agent zero trust controls are becoming an identity problem
