Notifications
Clear all
Topic starter
14/08/2026 6:35 pm
TL;DR: TaskUs says it safely enabled AI for 40,000 employees by measuring actual usage first, then enforcing controls where the user meets the tool, including browser-level visibility into tools, credentials, uploads, and extensions. That shift matters because AI is increasingly behaving like an identity with its own access and tools, not just another application.
NHIMG editorial — based on content published by Island: Updated: TaskUs Runs on Default Deny. It Still Said "Yes" to AI
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do AI workflows make traditional IAM controls less effective?
A: Traditional IAM controls assume slower change, clear ownership, and periodic review.
Q: What breaks when organisations approve AI in policy but do not measure usage?
A: Policy-only governance creates a false sense of control.
Practitioner guidance
- Measure actual AI usage before enforcing policy Instrument browser and SaaS activity to see which AI tools, models, credentials, uploads, and extensions employees really use before you narrow approved access.
- Define AI entitlements by task and data scope Grant access to the minimum data, model, and workflow required for the use case, and avoid broad approvals that assume all AI use is equivalent.
- Move enforcement to the browser boundary Apply controls where the user meets the tool so you can govern prompts, file movement, and extension use without relying on backend ownership of every AI service.
What's in the full article
Island's full blog post covers the operational detail this post intentionally leaves for the source:
- How TaskUs used browser telemetry to distinguish AI tools, modalities, and credential types across the workforce.
- How the company rendered policy on screen at the moment users hit an AI page and required acknowledgement before proceeding.
- How the team moved users to a company-managed Gemini instance and controlled prompts, uploads, downloads, and extensions.
- How TaskUs is applying browser telemetry and SIEM data to agentic threat-intelligence workflows.
👉 Read Island's analysis of how TaskUs governed AI as an identity →
AI as an identity: what changes when control moves to runtime?
Explore further
14/08/2026 6:42 pm
AI governance fails when organisations manage policy instead of runtime identity. A written approval list does not tell you what employees are actually doing, which tools they are reaching, or what data they are moving. The control problem is not intent, it is observable behaviour at the point of access. The practitioner conclusion is simple: governance must follow the session, not the policy document.
A few things that frame the scale:
- While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility, according to AI Agents: The New Attack Surface report.
- Only 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.
A question worth separating out:
Q: Should organisations treat AI as an application or as an identity?
A: Treat it as an identity when the AI can access data, invoke tools, or participate in workflows that affect business systems. That framing makes least privilege, just-in-time access, and lifecycle governance relevant. If you keep treating it only as an application, you will miss the access and delegation behaviours that actually create risk.
👉 Read our full editorial: AI as an identity shifts control from policy to runtime enforcement
