AI as an identity shifts control from policy to runtime enforcement

At a glance

What this is: This is a governance analysis of treating AI as an identity rather than an application, with runtime enforcement replacing policy-only control.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern AI access, tools, and behaviour at the point of use, not just in a policy document.

Context

AI governance fails when teams assume a written policy is enough to control how people actually use tools in the browser. That gap gets wider when employees adopt AI through third-party SaaS, personal credentials, or embedded workflows that central policy never sees.

The article's primary identity question is how to govern AI as an identity with access, tools, and behaviour. In that model, control has to move to runtime enforcement at the moment the user interacts with the AI service, because the old application-centric model does not capture what is really happening.

TaskUs is presented as an example of a default-deny environment adapting to AI adoption at scale. The useful lesson is not the vendor stack, but the control shift from written rules to observed use and then to enforced access boundaries.

Key questions

Q: What breaks when AI systems are trusted without runtime policy enforcement?

A: The model can take actions that look valid but violate business rules, expose restricted information, or trigger unsafe downstream processes. Without runtime enforcement, design-time intentions do not survive contact with live prompts, changing context, or tool integrations. The failure is governance drift.

Q: How does non-human identity governance apply to AI-powered applications?

A: AI-powered applications frequently act through service accounts, API keys, and delegated tokens, so identity governance becomes part of the control model. Teams should know which AI workflow owns each credential, what it can reach, and how it is revoked when the workflow changes or is retired. That closes the gap between application behaviour and access accountability.

Q: How do security teams know if shadow AI is actually under control?

A: Security teams know shadow AI is under control when they can inventory every agent, model workflow, and tool connection, then map each one to an owner and access scope. If they cannot explain who owns it, what it can access, and when it was last reviewed, it is not controlled.

Q: What is the difference between controlling AI with DLP and controlling it as an identity?

A: DLP focuses on the content moving in and out of a session, which works best when the prompt is the main attack surface. Identity-based control also governs who or what is acting, which tools are available, and whether the session itself is allowed to proceed. That broader model is needed once AI can behave like a digital worker.

Technical breakdown

Why policy-based AI governance breaks at runtime

Traditional policy controls assume the organisation can define acceptable AI use in advance and that users will stay inside that boundary. In practice, employees adopt AI through browser sessions, SaaS embeds, personal credentials, and extensions, which makes the real control point the session where the user meets the tool. That turns governance into a runtime problem: visibility first, enforcement second, and user acknowledgement at the point of access. When the tool is already embedded in work, a static policy is only a declaration of intent, not an operating control.

Practical implication: move AI governance from policy publication to point-of-use enforcement in the browser or session layer.

AI identity control versus application control

Treating AI as an application assumes the tool is the object being secured. Treating AI as an identity assumes the system must govern what that AI can access, what data it can see, and which actions it can perform. That distinction matters because the article describes AI systems that can behave like digital workers, not passive chat interfaces. Once behaviour, access, and tools are part of the model, least privilege and just-in-time provisioning become identity controls, not application hardening controls.

Practical implication: map AI controls to identity privileges, not to application features or menus.

Browser-level enforcement as the new control plane

Browser telemetry becomes the enforcement layer when the browser is the place where users log in, paste prompts, upload files, and install extensions. That gives security teams a way to observe which AI tools are used, which credentials are involved, and how data flows into and out of the session. The architectural point is simple: governance can be applied without owning the AI service itself if the browser mediates the interaction. This is runtime enforcement, not backend integration, and it is especially relevant where shadow AI is a discovery problem before it is a blocking problem.

Practical implication: instrument the browser or equivalent session layer to control prompts, uploads, downloads, and extensions.

Threat narrative

Attacker objective: The objective is to exploit unmanaged AI usage paths to move sensitive data, credentials, or work activity outside the organisation's intended control boundary.

1. Entry occurs when employees adopt AI through browser sessions, embedded SaaS workflows, or personal credentials that sit outside the original policy boundary.
2. Credential and data exposure follow when the browser reveals whether users logged in with corporate or personal credentials and when files were uploaded into AI tools.
3. Impact emerges when unmanaged AI use becomes embedded in business workflows, making the organisation dependent on tools and personas it has not formally governed.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI governance has crossed from policy management into identity enforcement. The central shift in this article is that AI can no longer be treated as a static application with a documented allowed-use policy. When employees can adopt tools, credentials, extensions, and embedded workflows in the browser, the actual control surface becomes runtime behaviour. Practitioners should read this as a governance redesign problem, not a tooling preference.

AI as an identity is the right model because access, tools, and behaviour now move together. That model aligns AI governance with the same disciplines used for human and non-human identities: least privilege, just-in-time access, and lifecycle control. The important change is that the identity is not a person, but the system still needs boundaries on what it can touch and when it can act. Practitioners should stop asking whether AI is a tool and start asking what identity it is operating under.

Runtime enforcement is now the decisive control point for shadow AI. Shadow AI is no longer only a discovery issue, because the business is already building AI workflows and personas that it depends on. The useful concept here is runtime identity enforcement: control applied at the moment the user or AI session reaches the tool, rather than after a policy review. Practitioners should expect this to reshape browser security, session control, and access governance.

Least privilege and just-in-time provisioning remain valid, but only if they are applied to AI behaviour. The article shows that the same control logic used for people can extend to AI identities when the system has its own access and tools. That does not mean the controls are unchanged in practice. The governance task is to define the AI's permitted scope in terms of runtime action, data exposure, and session duration. Practitioners should treat AI access as a governed identity lifecycle, not a one-time enablement choice.

Programme teams will have to measure adoption before they can control it. The article's operating lesson is that enforcement without visibility leaves the organisation guessing, while visibility without enforcement leaves it exposed. That is a familiar identity pattern, but it is newly urgent when the subject is AI because usage spreads through self-service behaviour. Practitioners should assume the first successful AI governance programme will be the one that can observe actual use and then constrain it at the point of interaction.

What this signals

Runtime identity enforcement: AI control is moving to the browser and session layer, where the user meets the tool. That shift matters because visibility and policy acknowledgement must happen before the AI interaction becomes a workflow dependency.

AI governance will increasingly sit inside IAM, PAM, and NHI programme design because the same control questions apply: who can act, what can they access, and for how long. The distinction is that the actor is now an AI identity with its own runtime behaviour, so static application controls are no longer sufficient.

For practitioners

• Measure actual AI usage before writing controls Inventory which AI tools, models, modalities, credentials, and extensions employees are already using, including embedded use inside third-party SaaS and browser sessions.
• Enforce controls where the user meets the tool Apply policy prompts, acknowledgement, and access limits at the browser or session layer so controls appear when an employee opens an AI page or workflow.
• Limit AI to company-managed instances Constrain approved use to managed AI services where prompts, uploads, downloads, and extension installation can be governed consistently.
• Treat AI access like identity governance Apply least privilege and just-in-time provisioning to AI identities so access scope, session duration, and allowed actions are explicitly bounded.
• Start with one dataset or workflow Begin with a narrow, well-understood use case and only expose data that the AI truly needs, then expand after proving the control model.

Key takeaways

• AI governance fails when organisations assume a written policy can control browser-era AI adoption across embedded workflows and personal usage patterns.
• The operational shift is from discovery to runtime enforcement, with control applied where prompts, files, credentials, and extensions are actually used.
• Treating AI as an identity brings least privilege and just-in-time provisioning into the AI control model, which is the right lens for governing action, not just access.

Key terms

• Runtime Identity Security: Runtime Identity Security is the practice of protecting identities while they are actively being used by software, services, devices, or agents. It focuses on controlling authentication, authorization, secrets, and session behavior at execution time, so compromised credentials, excessive privileges, or abnormal identity actions can be detected and contained quickly.
• 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.
• 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.
• Point-of-Use Control: Point-of-use control is enforcement applied at the moment data is entered into, processed by, or returned from a system. In AI security, this matters because after-the-fact review is often too late to prevent exposure, and it may not create the evidence needed for compliance.

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 IAM programme, it is worth exploring.