Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority

Every action in an estate is taken by someone or something, and the security architect's first design question about any action is who that actor is, on whose behalf it acts and how the receiving system can tell. For people the question has a mature answer in the identity provider and strong authentication. For non-human actors the answer is usually weaker: credentials created for a project, copied into configuration and never retired, and an audit trail that names an account rather than a person. When an agent acts in production with such a credential, the consequence is a loss of accountability as well as a larger attack surface, because nobody can say who decided that the action should happen.

This chapter concerns three of the four shifts defined in Chapter 3. It belongs to Shift 1, from documents to code, because an identity is a versioned record that a broker reads and a policy point enforces, not a row in a spreadsheet of service accounts. It belongs to Shift 2, from gatekeeper to boundary designer, because identity is the boundary that holds whatever an actor intends: the architect designs who may be an actor, what each may do and who answers for it, rather than approving each request. And it belongs to Shift 3, from periodic to continuous, at machine speed, because credentials that live for minutes, revocation that takes effect within a minute and evidence produced at the moment of use replace the annual access review as the control that matters. Chapter 7 placed the boundaries and the containment around actors; this chapter owns who an actor is, on whose behalf it acts and how that is proved.

The chapter builds on the earlier volumes. AI Governance, Chapter 14, introduced the agent operator, who watches Mode 5 agents and may revoke their credentials, and its Chapter 19 concluded that the July 2026 OpenAI–Hugging Face incident failed through correlated controls (168, Nordqvist, 2026), the first of which, according to the incident reports, was a credential shared across many workloads (129, OpenAI, 2026) (130, Larcher et al., 2026). AI Platform and Security, Chapter 12, set out delegated authority with explicit propagation of the service identity and the person, and Chapter 19 concluded that agents hold task-scoped credentials and no ambient authority (169, Nordqvist, 2026). AI Red Team, Chapters 6 and 14, concluded that every machine identity has an owner, operators and an authority who are named people, and that approvals are confirmed by call-back rather than by appearance (170, Nordqvist, 2026). This chapter asks what the architect designs from those conclusions.

Figure 8.1: An agent's action traced through its workload identity, a delegated token and a policy decision point to a tamper-evident log, and from the log to the people named in the identity record.

Non-human actors outnumber people

A large organisation has several populations of identity, and the non-human ones are the larger and the less governed. The first is the workload, such as a container or batch job that calls another service. The second is the pipeline, which builds, signs and deploys and therefore holds some of the most powerful credentials in the estate. The third is the service account, the long-lived credential between systems. The fourth is the agent, a system in which a model directs its own sequence of tool calls towards a goal, and which authenticates without a person present.

OWASP's Non-Human Identities Top 10 lists the failures that these populations share: improper offboarding, secret leakage, overprivileged identities, long-lived secrets, and the reuse of one identity across many workloads (187, OWASP, 2025). MITRE ATT&CK treats the payoff of these weaknesses as a technique in its own right: the use of valid accounts (T1078), with unsecured credentials (T1552) and stolen application access tokens (T1528) as common ways of obtaining them (46, MITRE, n.d.). An intruder who holds a valid machine credential needs no exploit, and the logs show a legitimate account doing what that account does.

An agent differs from a service account because its actions vary with its input, and much of that input is controlled by others: ticket text, document contents, tool outputs. OWASP's list for agentic applications treats the abuse of an agent's identity and privileges as a class of risk of its own (45, OWASP, 2025). AI Governance, Chapters 19 and 25, concluded that every agent is governed as a well-meaning insider, with boundaries and not instructions setting the ceiling on its consequences (168, Nordqvist, 2026), as Chapter 7 develops. Identity is the first of those boundaries, because every other boundary, the policy point, the egress rule and the stop path, decides on the basis of who is asking.

The architect's task is therefore threefold: every non-human actor is an identity in a register, every identity is issued, scoped and retired by a mechanism that does not depend on the actor's cooperation, and every identity leads back to named people.

Workload identity

The most important design decision for workloads is to replace secrets that are distributed with identities that are attested. A static API key or password proves only that the caller holds a string. Anyone who copies the string becomes the caller, and the copy leaves no trace.

SPIFFE, the Secure Production Identity Framework for Everyone, is the open specification most organisations use to give workloads an identity of the second kind. It defines a SPIFFE ID, a URI of the form spiffe://trust-domain/path that names a workload within a trust domain, and a SPIFFE Verifiable Identity Document, which is either an X.509 certificate or a signed token that carries the ID. SPIRE, the reference implementation, issues these documents after attesting the workload: it verifies what the workload is, from properties of the platform it runs on, before it hands out an identity, and it rotates the documents frequently (55, SPIFFE Project, n.d.). Two properties follow that a distributed secret cannot offer. The identity is issued by a component outside the workload, so the workload cannot mint or widen it. And the identity is short-lived, so a copy taken today is useless tomorrow.

The architect need not choose SPIRE in particular, since cloud providers and service meshes offer equivalents. The requirements are independent of the product and follow Zero Trust Architecture, as Chapter 7 sets it out: access is granted per session, on the basis of a policy decision that considers the identity and its context, and with no implicit trust from network location (31, Rose et al., 2020). Four requirements follow.

• Attestation before issue. An identity is issued only after the platform has verified what is asking, not on the strength of a bootstrap secret that anyone could hold.
• Issuance outside the runtime. The component that issues credentials is outside the workload's runtime, and the workload can neither configure it nor reach its control plane.
• Short lifetimes. Credentials last minutes for production actions and hours at most for build work, and renew only while the task or the workload remains registered.
• One identity per workload. A workload never shares an identity with another, so that a log line names exactly one actor and a revocation stops exactly one.

The last requirement is the lesson of the July 2026 incident (Chapter 7), in which many research workloads held the same package-mirror credential (129, OpenAI, 2026). A shared credential made independent runs one communicating population, and it made attribution impossible, because the logs could not say which run had used it. Where each run held its own short-lived identity, the same convenience would have left a trace and a revocation per actor.

Agents with their own identity or with a person's

Every AI system acts with some identity, and the usage modes of the series differ chiefly in whose. In Mode 1 Conversational assistants and Mode 2 Embedded workplace assistants, the AI works inside a person's session and can read what the person can read. In Mode 3 Agentic work tools, an agent runs commands with the engineer's credentials between the instruction and the review. In Mode 4 Built AI applications, the application presents a service identity and propagates the end user's identity to the systems it calls. In Mode 5 Autonomous production agents, the AI has an identity and permissions of its own (169, Nordqvist, 2026) (170, Nordqvist, 2026).

The choice has consequences for accountability that the architect should state explicitly in the design, because the two answers move risk to different places.

When the AI acts with a person's identity, the person's access becomes the AI's access, and the person answers for what the tool does. Two weaknesses follow. An assistant that can read everything its user can read will act on more than the task needs, including content that someone else has placed where the user can see it. And the logs cannot distinguish the person's own action from the tool's. ATT&CK catalogues the theft of application access tokens (T1528) and the use of alternate authentication material such as stolen tokens (T1550) as ways of turning such a delegation against its owner (46, MITRE, n.d.).

When the AI acts with an identity of its own, the organisation can scope, monitor and revoke that identity without touching any person's access, and the logs name the agent. The price is that the organisation now owns a privileged non-human actor, a machine insider that works at machine speed and can be steered by its input. For that reason the book recommends an identity of its own for every agent that acts in production, and recommends that the architect's own Mode 3 tool, which acts with a person's credentials, be confined to a sandbox credential scoped to a branch or a workspace rather than to the engineer's full access.

The design test is this. If the action would be taken in the same way whoever asked, because the agent follows a playbook the organisation has approved, the agent needs an identity of its own. If the action is the person's own act, performed with a tool's help, it carries the person's identity. An agent that acts for a person within limits the person did not set is delegation, treated next.

Delegated authority

Delegation is the mechanism that connects the two identities. When an agent acts for a person, a unit or a legal entity, the receiving system must be able to decide on the basis of both parties, who is acting and for whom, and on the task and its limits as well. Collapsing the agent and the person into a single identity is the most common identity mistake in AI integrations, and it destroys either the agent's accountability or the person's.

OAuth 2.0 Token Exchange (RFC 8693) is the standard mechanism for the exchange. A client presents a token it holds, the subject token, to a token service and requests a new token for a specified audience and scope. The standard distinguishes impersonation, in which the new token makes the holder indistinguishable from the subject, from delegation, in which the new token identifies both the subject and the actor, and it defines the act claim that records the acting party and the may_act claim that states who is permitted to act (56, Jones et al., 2020). The architect should require delegation and prohibit impersonation for agents. An impersonating token leaves the audit trail unable to separate the agent from the person, while a delegating token keeps both visible.

The token must also carry the task and its limits. Rich Authorization Requests (RFC 9396) let a client express fine-grained authorisation as structured data, for example a type of action, the resources and the amounts, rather than as a coarse scope string (185, Lodderstedt et al., 2023). A bearer token can be replayed by anyone who obtains it, so the architect should require that tokens be bound to the holder's key, as the DPoP mechanism of RFC 9449 does (186, Fett et al., 2023). Together these give the delegated token four properties that AI Red Team, Chapter 14, asked for (170, Nordqvist, 2026):

1. The entity. The legal entity or business unit on whose behalf the agent acts, so that a token for one market cannot be used in another. Hansa Mutual's claims adapter already refuses a request whose entity and claim market differ (AI Platform and Security, Chapter 12) (169, Nordqvist, 2026).
2. The task. A task identifier, so that a token issued for one task cannot be reused for another.
3. The scope. The actions and resources permitted, each carrying the autonomy level at which it may be taken without fresh approval.
4. The actor. The agent's own workload identity, in the act claim, so that the log names the agent and the delegating party both.

The Model Context Protocol (MCP), through which many agents reach tools, includes an authorisation framework built on OAuth, and its security best practices warn against token passthrough, in which a server accepts a token that was not issued for it (57, Anthropic, 2024) (58, MCP, 2025). The architectural implication is that a tool server validates the audience of every token and exchanges tokens for downstream calls rather than forwarding them, so that a token obtained for one purpose cannot be spent for another.

The authorisation decision belongs to the system of record or the policy decision point, never to the model. A prompt cannot grant access that the identity provider has not granted, and an agent's statement of its own authority is a claim, not evidence. The Five Eyes agencies' joint guidance on the careful adoption of agentic AI makes the privileges granted to agents a central design concern for the same reason (138, Five Eyes agencies, 2026).

Owners, operators and authorities

An identity record that names only a service is incomplete. Behind every machine identity, three kinds of person stand, and the architect writes their roles into the record so that none is implied.

The owner is the person accountable for the identity existing at all: the one who requested it, who decides whether it is still needed and who answers for its purpose. For an agent the owner is normally the owner of the system or process the agent serves. The operators are the people who watch the identity in operation, who see its alerts, review its exceptions and hold the power to revoke its credentials. AI Governance, Chapter 14, named the agent operator for Mode 5 agents, and this chapter gives the role its place in the identity model (168, Nordqvist, 2026). The authority is the person with the power to approve the identity's scope and its autonomy level, and to accept the residual risk. The authority is not the agent's builder, because the person who builds an agent should not alone decide how much it may do.

NIS 2 requires the management bodies of essential and important entities to approve the risk-management measures and oversee their implementation (Article 20), and DORA places the ultimate responsibility for managing ICT risk on the management body of the financial entity (Article 5) (6, European Union, 2022) (9, European Union, 2022). Neither lets responsibility pass to a tool, and neither mentions agents. The architectural implication is that an agent's identity record must lead to a person who can carry the accountability. A team mailbox does not satisfy this, so the record names roles that resolve to named holders at any moment, in a register of holders that is versioned and reviewed.

At Level 3 Bounded, accountability concentrates rather than dilutes. The person no longer approves each action, so the approval moves to the playbook and the decision record, and the authority who signs them answers for every action taken within them (170, Nordqvist, 2026). The identity record is the place where this becomes concrete: it names the playbook, the decision record and the authority together.

Practical guide: registering an agent identity

Purpose. Ensure that no agent acts in production without an identity that is registered, scoped, time-limited, revocable and traceable to named people.

Roles. The owner of the system the agent serves requests the identity. The identity domain architect designs the record and reviews it. The agent operator accepts the duty to watch and to revoke. The authority approves the scope and level. The platform team implements the issuance.

Steps.

1. Write the purpose in one sentence and list the task classes the agent performs.
2. Choose the identity type. Use an identity of the agent's own for every action that would be the same whoever asked, and delegation for every action taken for a person or an entity. Never use a person's credentials for an agent that runs unattended.
3. List the scopes as resources and actions, each with the autonomy level at which it may proceed. Start with read-only access. Deny by name the permissions an intruder who steered the agent would want most: assigning roles, resetting credentials, writing detection rules, changing its own policy.
4. Set the token lifetime. Use 15 minutes as the default for production actions and one hour for build work, bind tokens to the task and the entity, and allow renewal only while the task is active. Adapt these to the organisation's risk appetite and to the reversibility of the actions.
5. Name the owner, at least two operators and the authority as roles, and bind each role to a holder in the register of holders. Different people hold the owner and the authority roles.
6. Define revocation. State who may revoke, by which path outside the agent's runtime, and the time within which revocation takes effect. Use 60 seconds as the target for the credentials of a Mode 5 agent, and test it.
7. Name the decision record and, for Level 3, the playbook, and state the log destination. Require the log to record every issue and every use of a token.
8. Set the review date. Review at least every six months and after every change of model, tool set or scope, and let the identity expire if the review does not happen.
9. Commit the record to the repository, run the policy checks of Chapter 5 on the pull request, and let the broker read only the merged record.

Definition of done. The identity exists only as a merged record. The broker issues credentials from it. A revocation test has taken effect within the stated time. The owner, the operators and the authority can each state what they answer for. An expired review disables the identity rather than leaving it live.

Worked example: identity record and delegated-token policy for an evidence-collection agent

Illustrative. Hansa Mutual's Mode 5 evidence-collection agent gathers evidence for control catalogue entries from platform telemetry. It has an identity of its own, read-only access, and acts at Level 3 Bounded only to refresh evidence links, an action that is reversible because a link can be restored from the previous manifest. The identity domain architect designed the record, and AIDR-0565 records the decision to grant the level.

# Illustrative: Hansa Mutual, identity record for the evidence-collection agent
identity: HM-EVC-001
decision_record: AIDR-0565
purpose: Refresh evidence links for control catalogue entries from platform telemetry
workload_identity: spiffe://hansa.group/architecture/evidence-collector
mode: 5
issuer: group-credential-broker        # outside the agent runtime
people:
  owner: head-of-security-architecture
  operators: [agent-operator-rota-hamburg, agent-operator-rota-polish-service-centre]
  authority: group-ciso
ambient_authority: none
shared_with: []
token:
  type: delegation                     # impersonation is refused
  max_lifetime_minutes: 15             # at first; 5 after the stop drill of Chapter 10
  bound_to: [task_id, entity]
  sender_constrained: true             # key-bound, DPoP style
  renew: only_while_task_active
scopes:
  - action: read
    resources: [telemetry.platform, repo.catalogue, repo.evidence-manifests]
    autonomy_level: 1
  - action: refresh_evidence_link
    resources: [repo.evidence-manifests]
    autonomy_level: 3                  # playbook EVP-REFRESH-01, reversible
    limit: {per_run: 40, restore_from: previous_manifest}
denied:
  - catalogue.control.write
  - catalogue.exception.approve
  - iam.roles.assign
  - policy.rules.write
revocation:
  stop_path_holders: [agent-operator-rota-hamburg, group-ciso]
  takes_effect_within_seconds: 60
review: {every_months: 6, on_change: [model, tools, scope], on_missed: disable}
log: {every_issue_and_use: true, destination: group-evidence-store}

The record denies the agent the permissions that would let it alter the catalogue it serves. The broker and the policy checks read the same file, so the record the authority approved is the record that is enforced.

The delegated token that the broker issues for one run carries the entity and the task, and names both parties.

{
  "iss": "https://broker.hansa.example",
  "sub": "owner:head-of-security-architecture",
  "aud": "evidence-store.hansa.example",
  "act": {"sub": "spiffe://hansa.group/architecture/evidence-collector"},
  "scope": "evidence:read evidence:refresh_link",
  "authorization_details": [
    {"type": "evidence_refresh", "entity": "HM-DE", "task_id": "EC-2026-11-0412",
     "max_links": 40, "autonomy_level": 3, "playbook": "EVP-REFRESH-01"}
  ],
  "exp": 1793000900,
  "cnf": {"jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"}
}

The subject is the accountable role on whose behalf the agent acts and the act claim names the agent, following the delegation semantics of RFC 8693. The architect states this convention once in the token policy, because a log analysis that mixes conventions produces false attributions. The policy decision point refuses a request whose entity differs from the entity of the evidence it touches, whose link count exceeds the limit or whose key does not match the confirmation claim cnf.

Approvals that resist synthetic media

The same logic governs the approvals through which people authorise changes, and AI-generated voice, video and text have weakened the oldest evidence of identity in them, that the requester looks and sounds right. In May 2024 CNN reported that the engineering firm Arup had lost about USD 25 million after an employee in Hong Kong joined a video call with people who appeared to be senior colleagues and who were synthetic (154, Magramo, 2024). The process had treated appearance as authentication, and appearance can now be generated.

AI Red Team, Chapter 14, set out three controls: call-back verification through a contact taken from a trusted register, dual control by a second approver who did not receive the request, and out-of-band confirmation in an authenticated system of record (170, Nordqvist, 2026). The architect's contribution is to place these controls in the identity model, so that they bind approvals of changes to machines as well as payments. The requests that matter to the architect are those that change who or what may act: granting privileged access, registering a new agent identity, widening a scope, raising an autonomy level, adding a supplier's staff to a portal, changing an escalation contact and approving an exception.

Two design rules follow. First, the organisation designates which channels count as authenticated for instructions, and treats every other channel as unauthenticated, whatever it appears to show. NIS 2 includes, where appropriate, secured voice, video and text communications among the minimum risk-management measures (Article 21(2)(j)) (6, European Union, 2022). Second, an approval given by an agent's proposal travels the same path as an approval requested by a person: the human who approves does so in the system of record under their own phishing-resistant authentication, not in a chat message that anyone could have written. An unattended agent never approves another agent's scope, because a chain of agents approving one another contains no accountable person.

The European Digital Identity Framework, Regulation (EU) 2024/1183, establishes European Digital Identity Wallets that member states must make available (15, European Union, 2024). Wallets are expected to give public authorities a standard way to authenticate individuals, but their adoption in approval flows is not settled, and the architect should not wait for them.

Worked example: a call-back rule for changes to the benefits-triage system

Illustrative. Nordvik Region's benefits-triage system is provided by TriageSoft under tender NR-2026-117 and run in the Region's regional data centre. A change to the system's model version, its integration credentials or its administrator list is an approval of the kind that an impersonator would target, because an official of the Region is a public figure whose voice and image are easy to obtain. The security architect proposed the rule below, and the CISO adopted it as AIDR-0508.

# Illustrative: Nordvik Region, call-back rule for benefits-triage changes
rule: CBR-NR-BEN-01
decision_record: AIDR-0508
system: benefits-triage            # tender NR-2026-117, supplier TriageSoft
applies_to:
  - model_version_change
  - integration_credential_change
  - administrator_list_change
  - supplier_contact_change
untrusted_channels: [inbound_voice, video_meeting, email, chat, sms]
contact_source: supplier-register  # contacts fixed at contract signature
require:
  call_back: registered_contact_only
  second_approver: not_request_recipient
  confirmation: change-ticket-system   # signed in with phishing-resistant key
  cooling_off_hours: 24                # shortened only by the CISO, recorded
  caseworker_lead_informed: true
on_change_of_contact_register:
  require: [dual_control, ciso_approval, waiting_period_days_5]
record:
  retain_months: 120                   # public-access and archiving rules
  fields: [request, channel, call_back_time, approvers, outcome]
emergency:
  route: ciso_and_regional_security_officer
  after_action_review_hours: 48

Three features reflect Nordvik's position. The contact register is fixed at contract signature, the one moment when the Region verified who TriageSoft's people are. The record is retained for 120 months to survive public-access requests and archiving. And the caseworker lead is informed before a model change takes effect, because caseworkers decide every case and a silent change would alter what they oversee.

The machine identity lifecycle

A machine identity has a life, and each stage has a design requirement. A single failure at any stage can undo the rest, and the shared credential does this by defeating all of them at once.

Registration. Nothing is issued without a record in the register, as in the practical guide above.

Attestation. The platform verifies what is asking before it issues: platform properties for a workload, the repository and branch for a pipeline, and for an agent its code version and registered record. An agent whose tool set has changed since approval fails attestation until the record is reviewed.

Issuance. The broker issues short-lived, task-scoped credentials from the merged record. The agent never receives a credential it can keep.

Rotation. Credentials that expire in minutes need no rotation process. The few long-lived secrets that remain, such as the broker's root material, are rotated on a calendar and after any suspected exposure.

Revocation. Revocation must be fast, must not depend on the actor and must be rehearsed. The target of 60 seconds for a Mode 5 agent is a design parameter, and the architect verifies it with a revocation test, which Chapter 10 places among the stop paths. A revocation that works only when the agent cooperates is not a revocation.

Retirement. Identities end when their purpose ends, and the register shows it. A decommissioned system whose identity persists is a standing credential with no owner, which OWASP lists as improper offboarding among the principal weaknesses of non-human identities (187, OWASP, 2025). The expiry rule of the practical guide, in which a missed review disables the identity, turns retirement from a task someone must remember into a default.

The shared credential defeats every stage: it cannot be attested to one actor, rotating or revoking it disrupts every user, and nobody owns it, so nobody retires it. The architect's rule is that a shared credential is a finding, and each exception is recorded with an owner, a reason and an expiry date.

Identity as evidence

The identity model is also the evidence model. Its purpose is that, after any action, the organisation can reconstruct who acted, on whose behalf, under what authority and by which decision. The chain has five links, and the diagram at the head of this chapter shows them: the action, the workload identity that performed it, the delegated token that authorised it, the policy decision that permitted it and the log that recorded it. From the log, the record leads to the named owner, operators and authority.

Each link must be recorded by a component the agent cannot write to. AI Platform and Security, Chapter 19, concluded that an agent's account of what it did is a claim, not evidence, and that the evidence is what the infrastructure recorded (169, Nordqvist, 2026). For identity this means that the broker logs each issue, the policy decision point logs each decision with the token claims it considered, and the system of record logs each use, all in tamper-evident storage with a retention period that matches the obligation. The AI Act requires high-risk AI systems to allow automatic recording of events over their lifetime (Article 12) and requires deployers to keep the logs under their control for at least six months (Article 26(6)) (1, European Union, 2024). Those provisions apply to a system and its deployer; the identity record is how an organisation shows that the logs it keeps can be attributed to an actor and to a decision.

The test of the model is a reconstruction exercise. Take an action from the last quarter at random, and trace it from the system of record to the person who answers for it, without asking the agent anything. If the trace stops at an account, a team mailbox or a shared credential, the finding is a design defect in the identity model. The exercise belongs among the assurance activities of Chapter 9, and it becomes continuous when the pipeline checks it: a token without an act claim, an identity without an owner or a log entry without a decision reference fails.

Across the usage modes and autonomy levels

The mode sets whose identity the AI uses, and the level sets what a delegated token may authorise without fresh human approval.

Mode or level	Identity the AI acts with	Accountable person	What the architect designs
Mode 0 Ambient AI	The supplier's service or the user's session	The supplier under contract; the user for their session	Inventory entry and a contract term on change notification
Modes 1 and 2	The person's session and delegated permissions	The person	Access reviewed before enablement; tokens that are short-lived and device-bound; logs that mark the tool's actions
Mode 3 Agentic work tools	The person's credentials, or a sandbox credential	The person; the tool's owner for its configuration	Sandbox credentials scoped to a branch or workspace; no standing access to the control plane
Mode 4 Built AI applications	A service identity plus the propagated end-user identity	The system owner	Token exchange at the gateway; the model never holds standing credentials
Mode 5 Autonomous production agents	An identity of its own	Owner, operators and authority	Registered record; broker-issued, task-scoped tokens; revocation within a set time
Level 0 Advisory and Level 1 Assisted	Read-only	The person who acts on the proposal	Read scopes only; no write scope in the token
Level 2 Supervised	Write scope, each action approved	The approver, per action	Approval in the system of record under the approver's own authentication
Level 3 Bounded	Write scope limited to a playbook	The authority who signed the playbook	Tokens naming the playbook and its limits; policy point enforces them
Level 4 Autonomous	Write scope without per-action approval	The authority and the owner	Never for irreversible actions; no token for them is issued

The last row is a rule of issuance, not of intent. The broker does not issue a Level 4 token for an action that the register classes as irreversible, whatever the agent proposes and whatever the owner requests.

Observable, expected, speculation. Workload identity and token exchange are observable, mature practice, used in production by organisations of all sizes. Standards for identifying agents and expressing their delegated authority across organisational boundaries are expected to change: the specifications for authorisation in agent protocols have been revised repeatedly since 2024 (57, Anthropic, 2024) (58, MCP, 2025), and the architect should keep the token policy in a form that can follow them. Whether agents will one day carry portable, verifiable credentials accepted between unrelated organisations is speculation, and no design in this chapter depends on it.

Nordvik Region and Hansa Mutual

Nordvik Region has no Mode 5 agents, so its identity work concerns what it already runs. The first target is the platform team's workload identities on the reserved capacity and at the AI gateway: the architect recommends replacing static service credentials between the gateway, the hosted open-weight models and the case-management API with attested, short-lived identities, each registered with an owner. The second is the identity of the architect's own Mode 3 tool under MND-NR-01, which should use a sandbox credential scoped to the architecture repository instead of the architect's own access. The third is the approval rule CBR-NR-BEN-01 above. The Region relies on a small team and on suppliers, so the architect holds the boundary through register entries and tender annexes, and the single post is a single point of failure in the lifecycle: the review that disables an unreviewed identity must name a deputy.

Hansa Mutual has Mode 5 agents in production, and its identity domain architect designs the identities of four of them: the claims-triage agent, the IT-operations agent, the SOC investigation agent and the evidence-collection agent. Each has a record of the kind shown above, with a named owner, operators and authority, and the operator rotas follow the sites at which the agents work. Their task-scoped tokens last 15 minutes at first; the first stop drill cuts them to 5 minutes (Chapter 10). The July 2026 incident led Hansa to examine its own estate for credentials shared across workloads, and its decision to retire them, with exceptions recorded and time-limited, is AIDR-0553. The difficulty is volume: seven legal regimes mean that the entity in every token must be checked, and a fortnightly review board cannot approve each identity that agents and pipelines will need, so the registration record and its policy checks become the gate.

Summary

Identity is the architect's first line of design for non-human actors. Workloads, pipelines, service accounts and agents outnumber people, and an attacker who obtains a valid machine credential needs no exploit. The design replaces distributed secrets with attested, short-lived identities issued outside the actor's runtime, gives each workload its own identity so that no credential is shared, and chooses deliberately whether an agent acts with an identity of its own or with a person's.

Delegation joins the two. OAuth 2.0 Token Exchange gives a delegating token that names both the subject and the actor, and structured authorisation details and key binding let the token carry the entity, the task, the scope and the autonomy level. The decision is made by a policy point or a system of record outside the model, and the agent's own statement of its authority is a claim, not evidence. Every machine identity leads to an owner, operators and an authority who are named people, because NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool, and the identity record, the log and the decision record together let the organisation trace an action to the decision that allowed it.

The chapter concerns Shift 1, from documents to code, because the identity is a versioned record that the broker and the policy checks read; Shift 2, from gatekeeper to boundary designer, because the architect designs who may act and what each may do, and delegates the routine issuing to a broker; and Shift 3, from periodic to continuous, at machine speed, because credentials that live for minutes and revocation that takes effect within a minute replace the annual access review. For approvals, appearance is not evidence, and call-back, dual control and confirmation in an authenticated system make an approval hold against synthetic media. Workload identity and token exchange are observable practice, while standards for expressing agents' authority across organisations are expected to change.

Chapter 9 turns to the control catalogue, evidence and assurance as the architect's artefacts, and shows how each of the commitments in this chapter becomes a control with an owner, a test and an evidence manifest.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (6, European Union, 2022)
3. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
4. European Parliament and Council of the European Union. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. (15, European Union, 2024)
5. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. NIST Special Publication 800-207, August 2020. (31, Rose et al., 2020)
6. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. (45, OWASP, 2025)
7. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (46, MITRE, n.d.)
8. SPIFFE Project. Secure Production Identity Framework for Everyone (SPIFFE) specifications and the SPIRE reference implementation. (55, SPIFFE Project, n.d.)
9. Jones, M., Nadalin, A., Campbell, B., Bradley, J. & Mortimore, C. (2020). OAuth 2.0 Token Exchange. RFC 8693. (56, Jones et al., 2020)
10. Anthropic. Model Context Protocol Specification. (57, Anthropic, 2024)
11. Model Context Protocol (2025). Security Best Practices. (58, MCP, 2025)
12. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
13. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (130, Larcher et al., 2026)
14. Five Eyes cyber security agencies (2026). Careful adoption of agentic AI services. (138, Five Eyes agencies, 2026)
15. Magramo, K. (2024). Arup revealed as victim of $25 million deepfake scam involving Hong Kong employee. CNN Business. (154, Magramo, 2024)
16. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
17. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
18. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
19. Lodderstedt, T., Richer, J. & Campbell, B. (2023). OAuth 2.0 Rich Authorization Requests. RFC 9396. (185, Lodderstedt et al., 2023)
20. Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M. & Waite, D. (2023). OAuth 2.0 Demonstrating Proof of Possession (DPoP). RFC 9449. (186, Fett et al., 2023)
21. OWASP Foundation (2025). OWASP Non-Human Identities Top 10, 2025. (187, OWASP, 2025)