AI as an identity shifts control from policy to runtime enforcement

At a glance

What this is: This is an analysis of how TaskUs governed employee AI use by treating AI as an identity and enforcing controls at the browser boundary, with visibility and policy enforcement replacing policy-only governance.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams are now being pushed to govern AI behaviour at runtime, not just approve software and hope users comply.

👉 Read Island's analysis of how TaskUs governed AI as an identity

Context

AI governance breaks down when policy says one thing and users actually do another. In this case, the primary IAM question is not whether AI is allowed, but how to govern AI as an identity when employees can create workflows, use personal credentials, and connect models to business data.

TaskUs started with a written policy, but the gap was visibility. The article shows the shift from paper controls to runtime enforcement at the browser layer, which is where the user meets the tool. That is a useful pattern for both NHI governance and emerging AI identity controls, because it moves enforcement closer to actual access.

The starting position is typical for organisations trying to approve AI without understanding how it is already being used. What makes this case notable is that TaskUs tied enablement to measurement, then used those findings to narrow and control access rather than block AI outright.

Key questions

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. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do AI workflows make traditional IAM controls less effective?

A: Traditional IAM controls assume slower change, clear ownership, and periodic review. AI workflows break those assumptions because they can move data quickly, act inside trusted platforms, and rely on service accounts or agents that outlive the task they were created for. That creates standing exposure that manual governance usually misses.

Q: What breaks when organisations approve AI in policy but do not measure usage?

A: Policy-only governance creates a false sense of control. Without usage data, teams cannot see shadow AI, cannot tell whether employees are using approved instances, and cannot distinguish between corporate and personal access paths. That leaves enforcement reactive and makes later standardisation much harder.

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.

Technical breakdown

Why browser-level governance matters for AI identity

When AI use happens in browser sessions, the browser becomes the enforcement point for identity, access, and data movement. That matters because many employee AI interactions bypass traditional backend controls entirely: a model may be external, embedded in SaaS, or accessed through a personal account. Browser telemetry can reveal which tools were used, whether corporate or personal credentials authenticated the session, and when files moved into an AI workflow. In identity terms, the control surface is the session, not the application catalogue. That is why visibility at the browser layer can support governance where application-centric reviews cannot.

Practical implication: put session-level visibility in place before trying to standardise AI use.

Treating AI as an identity changes the access model

Calling AI an identity is more than terminology. It means the system has access, tools, and behaviour that must be governed like any other actor with privileges. In practice, that shifts the security question from “is the app approved?” to “what can this AI actor see, do, and delegate?” Least privilege and just-in-time access become relevant because AI workflows often expand or contract around tasks rather than fixed job roles. The article also highlights that AI can be embedded into workflows outside engineering teams, which makes static application controls too blunt for actual use patterns.

Practical implication: define AI entitlements by task and data scope, not by broad application approval.

Why DLP alone no longer matches the attack surface

DLP was built for a world where the prompt or document was the main boundary. AI changes that boundary by adding extensions, linked accounts, file uploads, model switching, and workflow chaining. That means risk is no longer just about text entering a chat box. It includes what the AI can inherit from the browser session, what files it can touch, and whether the user is operating through corporate or personal identity. The article’s control model reflects this shift by enforcing policy where content, credentials, and extensions intersect.

Practical implication: align DLP with identity controls, browser policy, and extension governance instead of using it alone.

Threat narrative

Attacker objective: The objective is not a single intrusion event but uncontrolled AI-mediated access to data and workflows that bypass governance and create blind spots.

1. entry: Employees gain access to AI tools through browser sessions that may use either corporate or personal credentials, creating a mixed-trust entry point.
2. escalation: AI workflows expand beyond chat into digital workers, extensions, and embedded SaaS use cases, widening the effective privilege surface.
3. impact: Uncontrolled AI use can expose sensitive data, create unaudited workflows, and make governance dependent on user behaviour rather than enforced policy.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

AI as an identity is the right model because it collapses application-only thinking. Once employees can create workflows, connect tools, and reuse personal or corporate credentials across AI experiences, the old boundary between software approval and identity governance disappears. That makes least privilege, task scoping, and session enforcement relevant to AI actors in the same way they are to human and machine identities. Practitioners should redesign access models around actor behaviour, not software labels.

Measurement before enforcement is the only credible path to safe AI enablement. Organisations cannot govern what they cannot see, and shadow AI becomes inevitable when users can reach AI tools from the browser, SaaS, and personal accounts. The practical lesson is that discovery must come before standardisation, because enforcement without visibility simply pushes usage into unmanaged channels. Practitioners should measure usage first, then formalise the allowed path.

Browser-mediated AI creates an identity blast radius that traditional DLP does not capture. The browser now carries credential context, file movement, extensions, and access to embedded AI workflows. That means compromise is no longer confined to a chat prompt or one tool. The implication is that identity, endpoint, and browser controls are converging on the same enforcement point, and governance teams need to treat that as a single operational problem.

From our research:

• 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.
• That visibility gap is exactly why OWASP NHI Top 10 and related agentic controls now matter to IAM and security teams.

What this signals

Measurement-first AI governance will become the default for identity teams. Once AI usage spreads through browsers, SaaS, and personal accounts, approval workflows alone stop working. Teams will need discovery, entitlement scoping, and enforcement in the same operational loop, especially where human and non-human access paths overlap.

AI identity and NHI governance are converging faster than most programmes are structured to handle. With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, access reviews and policy updates will not keep pace unless they are tied to runtime telemetry.

Browser policy will become an identity control, not just an endpoint setting. As AI use shifts into the same place employees authenticate, upload, and delegate, the browser becomes part of the access plane. Security leaders should expect identity governance, endpoint policy, and data controls to be managed as one programme rather than three.

For practitioners

• 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.
• Treat personal and corporate credentials as separate risk paths Track whether AI sessions authenticate with corporate identities or consumer accounts, then apply different control and review paths to each.

Key takeaways

• AI governance fails when organisations rely on written policy without seeing how employees actually use tools.
• Treating AI as an identity shifts the control problem to session-level access, data movement, and task-scoped privilege.
• The practical path is measure first, then enforce in the browser where user behaviour becomes visible and governable.

Key terms

• AI Identity Scope: The set of resources, tools, and credentials an AI system can access in order to complete a task. Proper scope is narrower than generic user access because autonomous systems can chain actions quickly, making overbroad permissions far more damaging than in human-only workflows.
• Browser-Mediated Governance: Browser-mediated governance is the use of the browser as a control point for identity, access, and data movement. It is especially relevant when users reach AI tools through SaaS, personal accounts, or embedded workflows, because traditional backend controls may never see the session.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.

👉 Island's full post covers the browser controls, visibility methods, and AI workflow governance details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.