Notifications
Clear all
Topic starter
01/08/2026 8:56 pm
TL;DR: Most zero trust deployments stop at the network layer, leaving session activity, data controls, and non-human access outside enforcement while AI agents make machine-speed calls via MCP and internal APIs, according to Island. That gap matters because identity governance now has to cover what users and agents do after authentication, not just who logged in.
NHIMG editorial — based on content published by Island: What Zero Trust Access Looks Like at the Last Mile
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern access when AI agents and humans share the same apps?
A: Treat AI agents as separate identity subjects with their own approvals, scope limits, and monitoring.
Q: Why do zero trust programmes fail when they stop at the network layer?
A: Because the network boundary is not where most misuse happens.
Q: What breaks when unmanaged devices are allowed into internal apps without session controls?
A: You lose the ability to govern what happens after access is granted.
Practitioner guidance
- Map where policy stops at login Identify every access path where authentication is enforced but session activity is not.
- Classify AI agents as governed identities Treat agent tool use, API calls, and chained actions as access events that require identity and context checks.
- Extend controls into the session layer Evaluate whether clipboard blocking, download restrictions, print controls, and screenshot prevention are applied as part of the access decision.
What's in the full article
Island's full article covers the operational detail this post intentionally leaves for the source:
- How the browser-based control path brokers access to web, RDP, and SSH sessions
- How the endpoint path extends the same policy model to native applications and all-device traffic
- How the connector architecture keeps private resources off the public internet
- How last-mile data controls are enforced across clipboard, downloads, printing, and screenshots
👉 Read Island's analysis of zero trust access at the last mile →
Last-mile zero trust for human and AI access: are controls keeping up?
Explore further
01/08/2026 9:04 pm
Last-mile zero trust is the real identity boundary: Authentication without session governance leaves the most important risk unresolved. The article correctly shifts the focus from network entry to what happens after access is granted. For IAM and NHI programmes, that means the control point must follow the identity into the session, not stop at the perimeter.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, which is why lifecycle discipline is still a control gap for many identity teams.
A question worth separating out:
Q: Who is accountable when zero-trust access decisions fail?
A: Accountability sits with the IAM, PAM, and security owners who define the access model and the operational owners who enforce it. If a compromised identity can still reach sensitive systems, the failure is usually governance, segmentation, or revocation control, not just authentication. Strong policy without enforceable lifecycle control does not contain exposure.
👉 Read our full editorial: Zero trust access at the last mile now has NHI implications
