Identity, Authentication and Access for People, Agents and Machines

Most intrusions begin not with an exploit but with an identity: a harvested password, a stolen session token, an approval given to a voice that sounded like the finance director, or a shared service credential. AI changes this attack surface from two sides. Attackers use it to make lures fluent and cheap at scale and to imitate the voices and faces that approvals depend on, while defenders give agents credentials of their own and let assistants act with their users' credentials. The identity estate therefore faces more convincing attacks on human identities and gains a new population of non-human identities that read attacker-controlled content and can be steered.

This chapter covers identities for people, machines and agents; phishing-resistant authentication; approvals that resist synthetic media; and the use of AI in access governance. In NIST CSF 2.0 it is responsible for PR.AA Identity Management, Authentication, and Access Control, whose Subcategories ask that identities and credentials are managed and proofed, that users, services and hardware are authenticated, that identity assertions are verified, that access permissions follow least privilege and separation of duties, and that physical access is managed in proportion to risk (19, NIST, 2024). The chapter reads the Category through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

It builds on three earlier conclusions. AI Platform and Security, Chapter 18, committed to identity and approvals that resist synthetic media and to scoped credentials for defensive agents, and Chapter 19 named task-scoped credentials and recorded approvals among the elements of containment (73, Nordqvist, 2026). AI Governance, Chapter 19, found that the July 2026 OpenAI–Hugging Face incident failed through correlated controls, the first of which was a shared credential (72, Nordqvist, 2026); the incident's technical report records that many research workloads used the same shared credential (64, OpenAI, 2026).

People and agents reaching a high-risk request, approval outside the channel and access review

Figure 14.1: People and agents reaching a high-risk request, approval outside the channel and access review.

Identities for people, machines and agents

Three populations of identity

The first population is people, including contractors, suppliers and, for a public authority, residents, who are proofed once, authenticated many times and deceived occasionally. The second is conventional machine identities, such as service accounts and API keys, which are deterministic and easy to baseline and whose characteristic failure is neglect: credentials that never expire and are shared for convenience.

The third population is AI agents that act with credentials. An agent authenticates without a person present, but it does not behave like a service account, because its actions vary with its input, and much of that input, in cyber defence almost all of it, is controlled by someone else: alert fields, email bodies, file names and threat reports. OWASP lists excessive agency, meaning permissions or autonomy beyond what the task requires, among the principal risks of LLM applications (14, OWASP, 2025), and its agentic list treats identity and privilege abuse as a risk class of its own (15, OWASP, 2025). AI Governance, Chapters 19 and 25, concluded that every agent should be governed as a well-meaning insider, because only boundaries set a ceiling on its consequences (72, Nordqvist, 2026). Identity is the first of those boundaries.

Whose identity the AI acts with

The usage modes answer the question every identity architect must ask about AI. In Mode 1 Conversational assistants and Mode 2 Embedded workplace assistants the AI acts within a person's session; in Mode 3 Agentic work tools an agent runs commands with an engineer's credentials; in Mode 5 Autonomous production agents the AI has an identity and permissions of its own (Chapter 6).

When the AI acts with a person's identity, two problems follow. The first is over-broad delegation: an embedded assistant that can read everything the user can read will act on more than the task needs, including content an attacker has placed where the user can see it. The second is session theft: a stolen session token bypasses whatever strong authentication produced it, and MITRE ATT&CK catalogues the theft of web session cookies (T1539) and application access tokens (T1528) as credential-access techniques (10, MITRE, n.d.). An agent with its own identity, by contrast, can be scoped, monitored and revoked independently of any person, which is why this book recommends it for every production agent, at the price of owning a privileged non-human actor that can be steered by its input.

Delegation, task-scoped credentials and no ambient authority

A delegated token should say who delegated, to which agent, for which task and for which legal entity, and the receiving system decides on all four. Hansa Mutual already applies this to people: the delegated token of a handler at its Polish service centre carries the entity on whose behalf the handler acts, and the claims adapter refuses a request when that entity and the claim's market do not match (AI Platform and Security, Chapter 12) (73, Nordqvist, 2026). An agent token that names its task and entity likewise cannot be reused for another task or market, even if the agent is manipulated into trying.

The rule for agent identities follows from AI Platform and Security, Chapter 19: credentials are task-scoped and short-lived, and the agent has no ambient authority, meaning no standing permission it holds merely by existing (73, Nordqvist, 2026). The credential is issued for one task by a broker outside the agent's runtime, valid for minutes and never shared. The July 2026 incident shows why: a credential that many workloads shared let agents in one evaluation run obtain administrator credentials for the shared package service (64, OpenAI, 2026), and shared credentials also destroy attribution.

Zero trust architecture provides the frame. NIST SP 800-207 grants access per session, on a policy decision that considers the identity, the state of the requesting asset and other context, with no implicit trust from network location (23, Rose et al., 2020). For agents, the context includes the task, the delegating person or entity, the autonomy level and whether the action appears in the permission manifest. The Five Eyes agencies' joint guidance on agentic AI services likewise makes agents' privileges a central design concern (40, Five Eyes agencies, 2026).

Worked example: a credential profile for the SOC investigation agent

Illustrative. Hansa Mutual's SOC investigation agent HM-SEC-001 runs as a Mode 5 autonomous production agent with its own workload identity (Chapter 18; AIDR-0311). Its credential profile is versioned in the platform repository and read by the credential broker, never by the agent.

# Illustrative: Hansa Mutual, credential profile for HM-SEC-001 (extract)
profile: hm-sec-001-credentials
decision_record: AIDR-0311
workload_identity: spiffe://hansa.group/soc/hm-sec-001
issuer: group-credential-broker        # outside the agent runtime
ambient_authority: none
shared_with: []                        # never shared with a person or agent
token:
  max_lifetime_minutes: 15
  bound_to: [task_id, case_id, entity]
scopes:
  - {name: read-telemetry, resources: [siem.search, edr.read], autonomy_level: 1}
  - {name: revoke-session, resources: [idp.sessions.revoke], autonomy_level: 3}
  - {name: isolate-workstation, resources: [edr.isolate], autonomy_level: 3}
  - {name: disable-account, resources: [idp.accounts.disable], autonomy_level: 2}
denied: [idp.roles.assign, idp.credentials.reset, siem.rules.write]
entity_binding:
  rule: token.entity == case.entity
  on_mismatch: refuse_and_alert
revocation:
  stop_path_holders: [soc-shift-lead, group-ciso, incident-commander]
  revoke_all_within_seconds: 60

Three features carry the design. The agent cannot assign roles, reset credentials or change detection rules, the permissions an attacker who steers it would want most. Its two Level 3 Bounded actions are reversible and limited to the case and entity in the token. Moreover, people outside its runtime can revoke every token within a minute.

European obligations

NIS 2 lists access-control policies, asset management and multi-factor or continuous authentication among the minimum cybersecurity risk-management measures of Article 21(2) (3, European Union, 2022). For the digital entities in its scope, Commission Implementing Regulation (EU) 2024/2690 specifies the management of access rights, privileged accounts and authentication further (4, European Commission, 2024), and ENISA's implementation guidance gives examples of evidence (8, ENISA, 2025). DORA Article 9(4) requires financial entities to limit logical access to what approved functions require and to implement strong authentication mechanisms (2, European Union, 2022). None of these instruments mentions AI agents, but none exempts them, so agent identities belong in the same access-rights register, reviews and evidence as human ones.

Phishing-resistant authentication

What AI changes in phishing

ENISA records adversaries' use of AI to make social engineering more convincing (33, ENISA, 2025) (34, ENISA, 2026). The NCSC assesses that AI will almost certainly continue to make elements of cyber intrusion operations more effective and efficient, and that threat actors are already using it to enhance access through social engineering (37, NCSC, 2025). The traditional signs of a lure, poor grammar or an implausible context, can therefore no longer be relied on: a message can be written in faultless Swedish, Dutch or Polish, refer to a real project and arrive at the right moment. Training remains necessary (Chapter 15), but a control that depends on people recognising a forgery degrades as forgeries improve, whereas a control that makes the forgery useless does not.

Removing the harvestable secret

The relevant ATT&CK techniques are phishing (T1566) as the delivery and valid accounts (T1078) as the payoff (10, MITRE, n.d.). Between them sits a credential the user can be persuaded to disclose: a password, a one-time code, or a push approval tapped in response to repeated prompts, which ATT&CK describes as multi-factor authentication request generation (T1621). Adversary-in-the-middle phishing (T1557) defeats most of these, because a proxy relays the code or approval to the real service in real time.

Phishing-resistant authenticators, such as FIDO2 security keys, platform passkeys and smart cards, bind the authentication to the requesting origin, so a credential presented to a look-alike domain does not work at the real one; ENISA's guidance describes the strongest class as having no shared secrets, not vulnerable to attacker-in-the-middle, and with a cryptographic key registered to a domain under the FIDO and WebAuthn standards (8, ENISA, 2025). The user can still be deceived, but the deception yields nothing reusable. The goal is therefore measurable: the share of accounts, above all privileged ones, for which no phishable factor remains enabled. Migration follows account value: administrators first, then staff with access to security tooling, payment systems and case management with sensitive personal data, then everyone else. A phishable fallback left enabled undoes the migration, because an attacker simply selects it, so each group is done only when fallbacks are removed.

Sessions, recovery, the service desk and privileged access

Phishing-resistant authentication protects the moment of sign-in, not the session token issued afterwards, the account-recovery process or the service desk that can reset a factor, and these become the next targets. Session tokens should be short-lived, bound to the device where supported and re-evaluated continuously against risk signals, in line with the per-session decision of zero trust (23, Rose et al., 2020). Account recovery must be at least as strong as the authentication it replaces. Service-desk verification must assume that the caller's voice may be synthetic, so a factor reset for a privileged account is an approval in the sense of the next section.

Privileged access, the ultimate goal of an intruder, needs its own controls. Standing administrative rights give way to just-in-time elevation for a stated task, a limited time and with a recorded approval, which meets the PR.AA requirement for least privilege and separation of duties (19, NIST, 2024); administration takes place from hardened workstations, and privileged sessions are recorded. An agent that needs an administrative action receives it through the same just-in-time mechanism, never through a standing role.

Approvals that resist synthetic media

Appearance is not authentication

In May 2024 CNN reported that an employee of the engineering firm Arup in Hong Kong had transferred about USD 25 million after a video call with people who appeared to be senior colleagues and who were deepfakes (55, Magramo, 2024). The process treated appearance as authentication, and appearance can now be generated. An approval must therefore rest on a channel the requester does not control, on a second person and on a record, through three controls.

Call-back verification. The approver confirms the request through a contact detail taken from a trusted register, never from the request itself. A request to change a supplier's bank account is confirmed by calling the number held in the supplier register before the request arrived.

Dual control. A second authorised person, who did not receive the original request, approves before the action takes effect. This defeats the attack that isolates one employee under time pressure, and is the human counterpart of the separation of duties PR.AA requires (19, NIST, 2024).

Out-of-band confirmation. The request is confirmed in an authenticated system, such as the payment platform, where the requester signs in with phishing-resistant authentication. A deepfake can imitate a face; it cannot sign in as the finance director with her security key.

NIS 2 Article 21(2)(j) includes, where appropriate, secured voice, video and text communications within the entity among the risk-management measures (3, European Union, 2022). The architectural implication is that the organisation designates which channels count as authenticated for instructions and treats every other channel as unauthenticated, whatever it appears to show. The same pattern applies to privileged access, factor resets, escalation contacts and security exceptions, and to approvals that agents request: when HM-SEC-001 proposes an action at Level 2 Supervised, the analyst approves it in the SOC tool under her own authenticated identity. Because AI Governance, Chapters 10 and 21, warned that approvals given in seconds signal rubber-stamping (72, Nordqvist, 2026), the time to approve is recorded as part of the design.

Practical guide: hardening payment and privileged-access approvals against deepfakes

Purpose. Make every high-risk approval independent of the appearance of the request, so that a convincing voice, video or message cannot by itself cause a payment, a change of payee or a grant of privileged access.

Roles. Chief financial officer and CISO (joint owners), heads of finance operations and identity and access management, the service-desk manager, internal audit, and, where employees are represented, the works council or union for any monitoring of approval behaviour.

Steps.

  1. List every process in which a person authorises a payment, payee change, privileged access, privileged factor reset or security exception, and classify as high-risk whatever moves money above a threshold, by default EUR 10,000, or changes who can act, including all payee changes regardless of amount.
  2. Establish a trusted contact register for suppliers, executives and privileged users, whose own changes require dual control and a waiting period.
  3. Require call-back to the registered contact, dual control by a second approver who did not receive the request, and out-of-band confirmation in the system of record.
  4. Add a cooling-off period, by default 24 hours, for payee changes and out-of-process privileged-access grants, with an emergency route only through a named director-level approver.
  5. Write the rules as policy as code, so that the system of record refuses an approval that lacks the call-back record, the second approver or the waiting period.
  6. Protect staff explicitly: a person who delays a request to complete verification is never penalised, even if the request proves genuine and senior.
  7. Verify with announced exercises (Chapter 15) and the chaos experiment below, routing every failure to the purple backlog.

Definition of done. Every high-risk approval in scope is enforced by the system of record, the trusted contact register is complete, exercises show that call-back is applied, and the evidence of each approval, including time to approve, is retained.

Worked example: synthetic-media-resistant approval policy as code

Illustrative. Hansa Mutual's approval rules for claims payments, payee changes and privileged access are a policy that the payment platform and the privileged-access tool both evaluate, with market overlays for language and local thresholds.

# Illustrative: Hansa Mutual, approval policy resisting synthetic media (extract)
policy: hm-approvals-synthetic-media
version: 1.3.0
applies_in: [DE, NL, SE, PL, NO, UK, CH]
untrusted_channels: [inbound_voice, video_meeting, email, chat, sms]
trusted_contact_source: group-contact-register
rules:
  - id: APR-01
    applies_to: [payee_bank_change]
    threshold_eur: 0
    require: {call_back: registered_contact_only, second_approver: not_request_recipient,
              out_of_band_confirmation: system_of_record, cooling_off_hours: 24}
  - id: APR-02
    applies_to: [claims_payment, treasury_payment]
    threshold_eur: 10000
    require: {call_back: registered_contact_only, second_approver: not_request_recipient,
              cross_entity: second_approver_in_paying_entity}
  - id: APR-04
    applies_to: [agent_action_level_2]
    require: {approver_authentication: phishing_resistant, approval_channel: soc_case_tool,
              record_time_to_approve: true}
on_violation: refuse_and_alert_soc
evidence: {retain_months: 120, destination: group-evidence-store}

No rule can be satisfied by the content of a request, however it looks or sounds, which closes the gap the Arup case exposed. Rule APR-02 requires the second approver to sit in the paying entity, so that a request routed through the Polish service centre for a Swedish claim still needs a Swedish approver, and rule APR-04 brings agent approvals under the same discipline. Evidence is retained for 120 months, in line with AIDR-0022.

AI in access governance

Access reviews and identity-threat detection

Periodic access reviews are required by control frameworks, including the PR.AA outcome that permissions are reviewed (19, NIST, 2024) and, for the digital entities in its scope, Implementing Regulation 2024/2690 (4, European Commission, 2024), yet they are among the least effective controls in practice: a manager asked to confirm two hundred entitlements approves them all. AI can do the preparation people skip, explaining entitlements, flagging separation-of-duties conflicts and access unused for ninety days, and proposing revocations with reasons for the manager to decide, at Level 1 Assisted. The same review covers non-human identities, where it often matters most: ownerless service accounts and agent scopes that have grown with each new tool.

Detection is the second use. Techniques such as valid accounts used from an unusual context or tokens replayed from a new device appear as patterns across more events than analysts can read (10, MITRE, n.d.), which AI can correlate and summarise. For agents, detection has an advantage: the expected behaviour is written down in the permission manifest and credential profile, so any attempt outside them is an anomaly by definition, refused and alerted at the policy point. AI Platform and Security, Chapter 19, insisted that detection come from telemetry and decoys rather than the agent's own account (73, Nordqvist, 2026); credential honeytokens, which no legitimate actor has reason to use, are a strong signal, and Chapter 19 treats them as deception as code.

Keeping the governing AI from becoming the risk

An AI that reads the whole identity estate is one of the most valuable targets in the organisation, so three rules keep it in check. First, it reads and proposes but does not write: revocations and grants pass through the identity system's workflow with a human decision, or, for reversible containment at Level 3 Bounded, through the separate response agent with its own scoped credentials. Second, its input is treated as attacker-controlled, because display names, group descriptions and ticket text can carry instructions, which OWASP describes as indirect prompt injection from external content (14, OWASP, 2025) and which AI Platform and Security, Chapter 16, concluded is an architectural property to be contained outside the model (73, Nordqvist, 2026). Third, an AI that profiles sign-in behaviour can monitor employees, so where works councils or unions have a say, as in Hansa Mutual's German, Dutch and Swedish entities, it goes live only after consultation and is used for security, not performance management.

Mode 0 Ambient AI deserves attention too: vendor AI in identity-protection products may block a sign-in or force a reset automatically, which is action at Level 3 Bounded or above chosen by the vendor, so the organisation should know which controls act automatically and how to override them.

Modes, levels and verification

Across the usage modes

The usage mode decides the identity question (usage modes).

Mode Opportunity Characteristic vulnerability Who judges, with whose identity
Mode 0 Ambient AI Vendor risk scoring blocks suspicious sign-ins at once Automatic blocks or resets the organisation did not choose The vendor's model; the product's
Mode 1 Conversational assistants Analysts explain sign-in logs quickly Session theft; identity data pasted into an external service A person; the person's session
Mode 2 Embedded workplace assistants Access reviews prepared where people work Over-broad delegation; attacker-planted content read with the user's access A person; delegated access
Mode 3 Agentic work tools Faster identity automation and detections The agent acts with the engineer's possibly privileged credentials A person afterwards; the engineer's
Mode 4 Built AI applications Access-review and identity-threat services Estate-wide visibility; injection through identity attributes A person; a read-only service identity
Mode 5 Autonomous production agents Session revocation and containment at machine speed A privileged non-human insider steered by its input Policy point and, per level, a person; task-scoped workload identity

In Modes 1 to 3, protect the person's session and narrow what the AI can reach through it; in Mode 5, give the agent an identity of its own that is task-scoped, short-lived and never shared.

Across the autonomy levels

Identity actions differ sharply in reversibility, so the level is set per action (autonomy levels).

Level Identity actions suited to it
Level 0 Advisory Access-review findings and identity-risk summaries
Level 1 Assisted Drafted revocation lists and conditional-access changes
Level 2 Supervised Disabling an account or removing a privileged role after explicit approval
Level 3 Bounded Revoking a session, forcing re-authentication, isolating a workstation
Level 4 Autonomous Not used; granting access or resetting factors is never delegated to AI

Verifying with security chaos engineering

Two experiments from Chapter 25's catalogue inject conditions rather than attacker behaviour. The first issues a token with a scope wider than a test agent's credential profile allows; the steady-state hypothesis is that the policy point refuses the out-of-profile call, detection raises an alert, and the broker revokes the token within five minutes of first use. The second submits a synthetic payee change through an untrusted channel to a test queue whose approvers know such requests may arrive; the hypothesis is that the system of record refuses to complete it without a call-back record and a second approver, and that it is reported within one working hour. The measure is whether the process held, not who handled the request, under the conditions Chapter 15 sets for exercises involving people.

The three AI focus areas

Securing AI systems. Every agent has its own workload identity, task-scoped credentials from a broker outside its runtime and no ambient authority; assistants are confined by delegation that carries task and entity, and governance AI runs read-only (20, NIST, 2025).

AI-enabled cyber defence. AI prepares access reviews people can decide, detects identity misuse across human and agent identities, and contains account takeover through reversible Level 3 Bounded actions, going live only after any consultation labour law requires.

Thwarting AI-enabled attacks. Phishing-resistant authentication removes what AI-generated lures harvest, and approvals rest on call-back, dual control and out-of-band confirmation, so that synthetic voices and faces gain nothing.

Nordvik Region and Hansa Mutual

Nordvik Region's first priority is call-back verification for supplier payment changes, confirmed through the supplier register and by a second official before they take effect. It extends phishing-resistant authentication to staff with access to case management and security tooling, and writes the same requirement into call-offs for its managed security service provider's out-of-hours staff. NR-SEC-001 runs under a read-only service identity owned by a named person, and the Region has no Mode 5 agents, so its main identity risk lies in Modes 1 and 2, through session theft and over-broad delegation.

Hansa Mutual binds agent credentials to task and entity. HM-SEC-001, the IT-operations agent and the claims-triage agent each have their own short-lived, scoped credentials, and none shares a credential with a person or another agent. Cross-entity payment and privileged-access approvals follow the approval policy above, and AI-assisted access reviews go live in Germany, the Netherlands and Sweden only after works-council consultation. Identity risk thus lies for Nordvik with people and suppliers who can be deceived, and for Hansa increasingly with agents that act with identities of their own.

Summary

When attackers use AI, identities and approvals become the first line of protection. Under PR.AA Identity Management, Authentication, and Access Control, the organisation moves to phishing-resistant authentication, removes phishable fallbacks and extends the same strength to sessions, recovery and the service desk. It stops trusting appearance in approvals: payment changes and privileged access are confirmed by call-back to a registered contact, dual control and out-of-band confirmation, enforced as policy as code.

Agents receive their own workload identities with task-scoped, short-lived credentials and no ambient authority, and NIS 2 and DORA requirements apply to them as to people. AI-assisted access reviews and identity-threat detection run read-only, and chaos experiments verify that an over-privileged agent token is revoked and a synthetic approval request meets an enforced call-back. Chapter 15 turns to the people behind those approvals and to building resilience against AI-generated deception.

Sources

  1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
  2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
  3. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. (23, Rose et al., 2020)
  4. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
  5. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
  6. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (15, OWASP, 2025)
  7. Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. Careful adoption of agentic AI services. (40, Five Eyes agencies, 2026)
  8. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  9. European Commission. Commission Implementing Regulation (EU) 2024/2690. (4, European Commission, 2024)
  10. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
  11. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
  12. European Union Agency for Cybersecurity. ENISA Threat Landscape 2025. (33, ENISA, 2025)
  13. European Union Agency for Cybersecurity. ENISA Threat Landscape 2026. (34, ENISA, 2026)
  14. National Cyber Security Centre. Impact of AI on cyber threat from now to 2027. (37, NCSC, 2025)
  15. Magramo, K. Arup revealed as victim of $25 million deepfake scam involving Hong Kong employee. (55, Magramo, 2024)
  16. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
  17. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  18. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)