AI security is an identity problem, not a model problem

At a glance

What this is: This is an analysis of why AI security should be governed through identity, with builders, users, and agents treated as distinct access subjects.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams will need one governance model that spans human users, machine identities, and AI agents instead of managing AI as a separate security silo.

👉 Read Permiso Security's analysis of why AI security is an identity problem

Context

AI security becomes unmanageable when organisations treat it as a pure model-safety problem instead of an identity governance problem. The article argues that the real control surface is the set of identities that build, train, consume, and act through AI systems, which makes access, privilege, and accountability the first-order issues.

That matters for IAM and NHI programmes because AI usage now appears across developer workflows, business applications, and automated agents. For teams already managing workload identity and secrets exposure, the next step is to classify AI subjects by role, privilege, and lifecycle rather than by the technology stack alone.

Key questions

Q: How should security teams govern AI systems that can access data and tools?

A: They should govern them as identity subjects, not as isolated applications. That means assigning owners, bounding access by role and task, logging every material action, and reviewing connected credentials on the same lifecycle cadence used for other privileged identities. The goal is to make AI access visible, attributable, and revocable.

Q: Why do AI systems create identity risk beyond model security?

A: Because the main exposure often comes from who can build, prompt, connect, or delegate through the system. If those identities are over-privileged or poorly governed, the model becomes a channel for data exposure and unauthorised action. Model hardening helps, but it does not replace access control.

Q: What breaks when organisations treat builders, users, and agents the same?

A: They create a single policy that fits none of the real risk profiles. Builders need controls around training data and pipelines, users need limits on exposure and action, and agents need task-scoped permissions with tighter logging. Collapsing these into one policy usually produces either excess access or unusable restrictions.

Q: How can organisations tell whether AI governance is actually working?

A: Look for evidence that every AI-connected identity is discoverable, owned, and revocable. If teams cannot say who approved access, what data the identity can reach, and how it is retired, governance is incomplete. Effective programmes show consistent inventory, review, and decommissioning records.

Technical breakdown

Why AI security collapses into identity and access management

AI systems are not secured by one control plane. They inherit risk from every identity that touches them, including the builder who trains the model, the end user who prompts it, and the agent that triggers downstream actions. Once AI is framed this way, prompt injection and data leakage are no longer isolated model issues. They become questions of whether an identity is authorised to see, send, or modify the data and services involved. That is why discovery and privilege mapping matter before any hardening programme can work.

Practical implication: inventory AI-touching identities first, then assign access boundaries and owners before expanding deployment.

Builders, users, and agents require different access models

The article distinguishes three AI identity types. Builders need controlled access to training data, pipelines, and model artefacts. Users need policy-based limits on what the AI can reveal or invoke on their behalf. Agents need task-scoped permissions because they may execute actions outside a conversational interface. Treating all three as the same class of subject creates overreach or blind spots. The security model changes because the risk changes: training access, prompt-time access, and delegated execution are not interchangeable identity events.

Practical implication: separate policy, logging, and approval paths for builder, user, and agent identities instead of reusing one generic AI access model.

Shadow AI discovery is the prerequisite for governance

The article’s implementation advice starts with discovery because organisations cannot govern what they cannot see. AI use often spreads through unofficial tooling, unapproved model access, and departmental experimentation before security teams are aware of it. That creates a governance gap similar to shadow IT, but with more direct access to data and automation. Visibility is therefore not a reporting exercise. It is the control that decides whether AI remains a managed capability or becomes an unmanaged access path into sensitive systems.

Practical implication: build discovery around AI usage, connected accounts, and data flows so shadow deployments surface before policy is enforced.

NHI Mgmt Group analysis

AI security is now an identity governance problem before it is a model security problem. The article is right to shift attention away from abstract AI risk language and toward the identities that build, use, and operationalise AI systems. That framing matters because identity is where authority, data access, and accountability intersect. The implication is that IAM and NHI programmes should treat AI as a new access domain, not a separate security exception.

Builders, users, and agents are not one governance class. A builder has training and pipeline access, a user has prompt-time and output exposure, and an agent can initiate downstream action. Those are materially different trust relationships and cannot be governed with one generic policy set. The practitioner conclusion is that AI governance must be segmented by subject type, not collapsed into a single control template.

Discovery is the control that makes AI governance possible. Without visibility into who is using AI, which accounts are connected, and where data is flowing, policy becomes aspirational. This is the same failure mode seen in other identity programmes: unmanaged access precedes unmanaged risk. The field should therefore treat AI discovery as a prerequisite for governance maturity, not a reporting nicety.

Identity-centric AI security extends the same lifecycle discipline used for humans and NHIs. The article’s model is strongest when it ties AI access to approval, decommissioning, and bounded use. That is the same lifecycle question IAM teams already know, but now applied to AI actors and their delegated permissions. Practitioners should recognise that the programme problem is continuity of governance across identity types, not a new category of controls.

Prompt injection is often a governance failure expressed through an interface. When an AI system is allowed to expose or act beyond the subject’s authority, the user interface becomes the point where policy breaks. That makes access modelling and output restriction more important than trying to classify every prompt as malicious. The practical conclusion is to enforce least privilege around the AI subject, not just around the model endpoint.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, which leaves identity retirement far behind deployment velocity.
• That is why Top 10 NHI Issues is the right next resource for teams translating discovery into lifecycle controls.

What this signals

AI governance programmes are likely to converge on the same operational model as NHI governance: discovery first, then ownership, then revocation. The organisations that succeed will not be the ones with the most AI policy language. They will be the ones that can prove every AI-connected identity is visible and accountable.

Identity blast radius: the real metric for AI risk is not how advanced the model is, but how far its connected identities can reach into data and execution paths. Once that blast radius is understood, IAM teams can set priority around the systems that combine sensitive data, broad permissions, and delegated action.

The immediate planning signal is that AI security will keep pushing identity teams into shared ownership with platform and data teams. That makes lifecycle governance, secrets hygiene, and access review the control stack to mature first, especially where AI is embedded in developer tooling and internal business automation.

For practitioners

• Map AI-touching identities and owners Create an inventory of builders, business users, service accounts, and agents that can reach AI systems. Tie each identity to a business owner, data scope, and approval path so governance does not depend on informal knowledge.
• Separate policy for builders, users, and agents Apply different controls for training access, prompt-time access, and delegated execution. A builder may need pipeline restrictions, a user may need output filtering, and an agent may need task-scoped permissions and event logging.
• Start with AI discovery before tightening controls Detect where employees, teams, and automated workflows are already using AI, including shadow deployments and unsanctioned integrations. Use that baseline to prioritise the systems with the highest data exposure and the least oversight.
• Align decommissioning to AI lifecycle events Define what happens when an AI project, model, or agent is retired. Revoke credentials, remove connected accounts, and close data pathways as part of the offboarding process rather than treating shutdown as an informal project task.

Key takeaways

• AI security becomes governable only when organisations treat models as part of an identity and access problem.
• The main risk sits in the identities around AI systems, including builders, users, and agents with the wrong level of authority.
• Discovery, ownership, and revocation are the practical controls that turn AI from an uncontrolled capability into a managed one.

Key terms

• AI-connected identity: An AI-connected identity is any user, service account, bot, or agent that can reach an AI system or act through it. The governance question is not whether the AI is clever, but who can access it, what it can touch, and whether those permissions are owned and revocable.
• Delegated execution: Delegated execution is when an identity is allowed to take actions on behalf of a person or organisation without a human approving each step. In AI security, it raises the stakes because permissions can be exercised faster and more broadly than a manual workflow would allow.
• Shadow AI: Shadow AI is AI use that exists outside approved governance, monitoring, or ownership. It often appears through unsanctioned tools, ad hoc integrations, or team-led experimentation, creating access paths that security teams cannot easily review or revoke.
• Identity blast radius: Identity blast radius is the amount of data, systems, and actions an identity can reach if it is misused or compromised. In AI environments, it helps teams judge whether a builder, user, or agent has more authority than the business risk justifies.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Permiso Security: Rethinking AI Security: Every Interaction Is About Identity. Read the original.