Notifications
Clear all
Topic starter
11/07/2026 8:24 pm
TL;DR: Enterprises are deploying AI agents directly into servers, VMs, and Kubernetes clusters, creating exposed APIs, machine identities, and lateral movement paths that traditional ZTNA was not built to secure, according to Appgate. The governing assumption is collapsing because policy-only guardrails do not stop autonomous workloads that run inside core infrastructure and outside browser-centric access models.
NHIMG editorial — based on content published by Appgate: AI agent security inside the enterprise core
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map AI agents as NHIs in the identity inventory Record each agent, its credentials, its owning team, and the systems it can reach.
- Apply least privilege to machine-to-machine paths Limit each agent to the narrowest APIs, services, and internal endpoints required for its task.
- 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.
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.
👉 Read Appgate's analysis of AI agent security inside the enterprise core →
AI agents inside the enterprise core: are your controls keeping up?
Explore further
11/07/2026 8:54 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity needs zero trust inside the enterprise core
