5 Min Read
AI security is an identity problem before it is a model problem. Every AI agent, copilot, and automated workflow acts through credentials, tokens, keys, and service accounts that grant it access to data and systems. Control that identity layer and you control what AI can read, act on, and expose. Neglect it and you have handed an autonomous process a set of standing permissions with no one watching.
This is the shift security leaders need to internalise: the perimeter for AI is not the prompt or the firewall, it is identity. Non-human identities (NHIs) are now the operating system on which AI security runs.
Why identity is the control plane for AI
Human security has spent two decades maturing: MFA, conditional access, joiner-mover-leaver processes, privileged access management. Machine identity has not kept pace, and AI is widening that gap fast.
An AI agent does not log in the way a person does. It authenticates with an API key, an OAuth token, a certificate, or a service account, and it does so continuously, at machine speed, often across multiple systems. Each of those credentials is an identity. In most estates, machine identities already outnumber human ones by a wide margin, and AI adoption accelerates that ratio.
The practical consequence: the blast radius of a compromised AI workflow is defined entirely by the permissions attached to its identity. If a retrieval agent holds a token that can read every SharePoint site, a single prompt-injection or leaked key becomes a full data exposure event.
What makes AI identities harder to govern
Machine identities were already difficult. AI raises the difficulty on four fronts:
- Scale and churn.Agents spin up, call tools, and spawn sub-processes. Credentials multiply faster than any manual inventory can track.
- Standing privilege.Service accounts and API keys tend to be long-lived and over-permissioned because rotating them breaks automation. That is exactly the wrong posture for an autonomous actor.
- Delegation and chaining.An agent often acts on behalf of a user, then calls another service on behalf of itself. The identity that finally touches the data may be several hops from the human who triggered the action.
- Opacity.Many AI tools abstract away which credential is used for which call, so audit trails answer "the agent did it" rather than "this identity, with this scope, accessed this record."
The five controls that matter most
Securing the AI identity layer is not a new discipline invented from scratch. It is disciplined machine-identity governance applied to a faster, hungrier consumer. Prioritise in this order.
- Build an inventory of non-human identities.You cannot govern what you cannot see. Enumerate service accounts, API keys, OAuth grants, tokens, and certificates tied to AI systems, and map each to an owner, a purpose, and a scope. Treat an ownerless credential as a finding, not a footnote.
- Enforce least privilege per agent.Scope every AI identity to the minimum data and actions its task requires. Prefer narrow, purpose-built credentials over shared, broad ones. If an agent only needs to read three data sources, it should not hold write access to the estate.
- Make credentials short-lived and rotated.Replace static, long-lived secrets with short-lived tokens issued just in time. Where static keys are unavoidable, automate rotation and store them in a managed secrets vault, never in code or config files.
- Log identity-level actions, not just agent actions.Instrument the estate so you can answer which identity accessed what, when, and with what scope. This is the evidence trail you will need for incident response and for compliance.
- Govern the full lifecycle.Apply joiner-mover-leaver logic to machines. When an agent is decommissioned or a workflow changes, revoke its credentials. Orphaned AI identities are standing risk that no one owns.
Where this meets EU and Nordic regulation
The identity layer is where several regulatory obligations converge, and treating it well answers multiple requirements at once.
- NIS2:requires risk management measures and access control across essential and important entities. Non-human identities that touch critical systems fall squarely inside that scope, and "we did not know the agent had that access" is not a defensible position.
- DORA:expects financial entities to manage ICT risk end to end, including the identities their AI and automation rely on. Access control, logging, and lifecycle governance for machine identities are part of demonstrating operational resilience.
- GDPR:ties directly to scope. An over-permissioned AI identity that can reach personal data it does not need is a data minimisation and access control problem before it is ever an incident.
- ISO 27001:access control expectations (Annex A) apply to machine identities as much as human ones. Auditors increasingly ask how service accounts and tokens are governed, not just how staff log in.
- EU AI Act:obligations around record-keeping and human oversight for higher-risk systems depend on the identity-level logging described above. You cannot oversee what you cannot attribute.
How to start this quarter
You do not need a full AI governance programme before you act. You need to reduce standing privilege on the identities your AI already uses.
- Find the credentials.Pull every API key, token, and service account tied to AI or automation tooling into a single list with named owners.
- Cut the obvious excess.Identify the most over-permissioned and longest-lived credentials and scope them down or rotate them first.
- Turn on identity-level logging.Make sure post-incident you can trace an action to a specific identity and scope, not just to "the assistant."
- Assign ownership.Every AI identity gets a human owner accountable for its scope and lifecycle.
The organisations that get AI security right will not be the ones with the cleverest model controls. They will be the ones that treated identity as the operating system it is, and governed the machine layer with the same rigour they apply to their people.
If you want a structured review of the non-human identities in your estate, our team can help you build the inventory and prioritise the controls that reduce risk fastest.
Frequently asked questions
- What is a non-human identity in AI security?A non-human identity (NHI) is any credential used by software rather than a person: API keys, OAuth tokens, certificates, and service accounts. AI agents authenticate and act through these identities, so the permissions attached to them define exactly what the AI can access and do.
- Why is identity more important than the model in AI security?An AI model only causes harm through the systems and data it can reach, and that access is granted by its identity's permissions. A compromised prompt or leaked key is only as damaging as the scope of the credential behind it. Governing identity limits the blast radius regardless of how the model behaves.
- How do NIS2 and DORA apply to AI machine identities?Both frameworks require access control, logging, and ICT risk management. Non-human identities that touch critical or essential systems fall within scope, so organisations must inventory them, enforce least privilege, and maintain an evidence trail of identity-level actions to demonstrate compliance.
- What is the fastest way to reduce AI identity risk?Start by inventorying every API key, token, and service account tied to AI tooling, assign each a named owner, and scope down the most over-permissioned and longest-lived credentials first. Then enable identity-level logging so actions can be traced to a specific credential and scope.
- Why are AI identities harder to govern than human ones?AI identities churn at machine speed, tend to hold long-lived and over-broad permissions, chain across services through delegation, and are often abstracted so audit trails show only that the agent acted, not which credential and scope were used.
Thank you!
