q-fin.GNSep 25, 2026

Multi-Jurisdictional Legal Identity Assurance for Capability Gating: A Design-Science Proposal for Tiered, Reusable Identity Assurance of Natural, Juridical, and Machine Entities

Authors: Walter Kurz

Organizations: Swissi Institute for AI

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Identity assurance is the cost a digital system pays for dishonesty and uncertainty: it exists to make acts attributable when not everyone can be trusted at their word. A common way to pay that cost is flat maximum verification, asking each participant to meet a single high level of identification at entry, before any capability is exercised. Paid on everyone, it over-collects, excludes participants who cannot meet a bar they never needed to clear, taxes every interaction with the cost of the rarest high-risk case, and binds the strength of identification to the activity it unlocks. Existing frameworks compound this by fixing a small number of per-credential levels inside a single legal space and binding each verification to the institution that performed it, leaving cross-border reuse and the tension between data erasure and evidentiary retention unaddressed. This paper develops, as a design-science proposal, a tiered and reusable model of identity assurance for natural, juridical, and machine entities across jurisdictions. Reading the problem through systems theory, where a system changes only when an entity acts, the model holds the assurance state apart from the capability gate that consumes it, so that identity demand follows the act and the weight of its consequences rather than mere presence: a participant may take part with minimal disclosure and supply more only as an act requires. It comprises a typed entity taxonomy, a two-axis coordinate of disclosed assertion scope and source of information, jurisdiction as a time-indexed attribute of the entity, and reliance recorded as bitemporal, liability-allocated, point-in-time snapshots. Requirements are derived from anti-money-laundering, electronic-identity, and data-protection law, and the proposal is evaluated against flat maximum verification, per-credential level-of-assurance designs, and institutional reusable-KYC reliance.

Figures & tables

Figure 1: Entity taxonomy for assurance evaluation. Two accountability cuts, suability then source of behaviour, yield three entity types, natural (N), juridical (J), and machine (M); the remaining logical branch lacks both suability and behaviour and is an inert object outside the model. The text develops the type definitions, the juridical catalogue and its trustee-imputed arrangement corner, the machine descriptors, and the grid from which a tier is derived.
Req.ConstraintLegal or standards pressureDischarged by
R1Identity demand must be proportional to the requested act and its consequence weight. Low-consequence participation must be available at the lower floor.Data minimisation requires processing limited to what is necessary; NIST requires a relying party to determine whether proofing is needed before selecting an assurance level. European Parliament and Council of the European Union, 2016a , art. 5(1)(c) National Institute of Standards and Technology, 2025b , secs. 3.3.2–3.3.3Equation 1 , eq. 2 , and capability gates that request only the cells each act consumes.
R2Assurance state must remain separate from capability permission. The same state may pass one gate, fail another, and remain auditable.eIDAS and NIST define assurance baselines, while service authorization remains a relying-party decision. European Parliament and Council of the European Union,2014a ; European Commission,2015a ; National Institute of Standards and Technology,2025bThe assurance state, demand set, and gate pass relation, rather than a stored verified/unverified account flag.
R3The model must support N, J, and M without making technical action collapse into legal personhood. Consequential machine action must attach to N, J+N, J+N+M, or a legally sufficient J+M path.AI and product-liability instruments allocate duties and liability to legal actors around systems; AML beneficial-ownership rules ground juridical accountability in natural persons. European Parliament and Council of the European Union, 2024h ; European Parliament and Council of the European Union, 2024i ; European Parliament, 2020a European Parliament and Council of the European Union, 2024g , arts. 51–63The entity taxonomy, attachment rule, inheritance bound, and constellation grammar.
R4Disclosure must be granular enough that a gate can request a named assertion class without receiving a packed identity record.GDPR data minimisation and data protection by default require purpose-scoped processing; the European Digital Identity Framework supports selective disclosure through the wallet architecture. European Parliament and Council of the European Union, 2016a , arts. 5(1)(c) and 25(2) European Parliament and Council of the European Union, 2024e , arts. 5a and 5b(9)Assertion rows, optionality, cardinality, artifact multiplicity, and selective presentations.
R5The assurance state must preserve jurisdictional continuity across moves, parallel statuses, and later audits. Facts and jurisdiction-relative predicates must remain separable.Cross-border electronic-identity frameworks support reusable identity means, and credential standards support holder-presented credentials across verifier contexts, while legal evaluation remains tied to the governing frame of the act. European Parliament and Council of the European Union,2024e ; Sporny et al.,2025aJurisdictional artifacts, the active-anchor function α(E,a,t)\alpha(E,a,t) in eq. 4 , and bitemporal valid-time and record-time storage.
R6Reuse must allocate responsibility for reliance instead of erasing it. A relying party may consume prior confirmation, but its legal responsibility and the relied-on snapshot must remain visible.AMLD4 permits third-party reliance while retaining ultimate responsibility with the obliged entity; FATF Recommendation 17 and the AML Regulation preserve a risk-based due-diligence structure. European Parliament and Council of the European Union, 2015a , art. 25 Financial Action Task Force, 2025a , rec. 17 European Parliament and Council of the European Union, 2024g , arts. 19, 20, 33, and 34Confirmation events, gate-pass records, reliance snapshots, requirement versions, parties, and liability boundaries.
Table 1: Design requirements for the proposed legal identity-assurance artifact. The requirements become the criteria for the comparative evaluation.
Figure 2: The source-of-information scale, the second axis. The classes of the scale are exactly the seven grey leaves, S1–S7; the outlined nodes above them are explanatory grouping, not a taxonomy, and the dashed boxes beneath are glosses. A statement is either provided, by the subject itself, the self (S1), the floor of the scale because an entity cannot confirm itself, or verified: by machine, an automated check (S2) or a register API, the system of record for the fact queried and compared (S3), or by a natural person, where the trained-verifier tier (digital S4, in person S5) and the public or qualified confirmation tier (digital S6, in person S7) each split into a digital and an in-person class, because co-presence removes the remote-channel attack surface. Where the governing framework recognises the confirming authority, the public or qualified tier outranks a trained human verifier, so the in-person human class (S5) sits below the digital public or qualified class (S6), and the in-person public or qualified class (S7) is the strongest source class. The two sub-axes under each class are the source itself and the strength of its binding to the subject; what an individual confirmation is worth at a particular gate is derived by the relying party from the cell’s position, binding, and freshness, never stored as a score.
Class (content)OptCardSource-availability note
N0 Statusmand1civil register, population register, death register, public authority, or self-declared floor
N1 Date of birthvol1civil register, identity document, wallet confirmation, or public/qualified attestation
N2 Contact channelsvolncontrol proof, carrier or provider record, or verified contact ceremony
N3 Civil namevol1civil register, identity document, name-change record, or public/qualified attestation
N4 Addresses + jurisdiction linkvolnpopulation register, residence permit, tax record, utility or bank evidence, or public/qualified attestation
N5 Personal likenessvolnlive capture, document-photo comparison, biometric ceremony, or public/qualified witnessing
Table 2: Assertion catalogue of the natural type: eleven classes N0–N10, ordered by willingness to reveal, with optionality (mand mandatory, vol voluntary) and cardinality (1 one slot, n an open set of instances). The source-availability note states ordinary confirmers; the binary S1–S7 cells are entity-specific and are filled by confirmation events.
Class (content)OptCardSource-availability note
J0 Statusmand1register, competent authority, insolvency record, or fiduciary record
J1 Legal namevol1register, founding instrument, public-law instrument, or qualified attestation
J2 Form and governing lawvol1register parameter or legal instrument naming the form and legal system
J3 Founding instrumentvolndeed, articles, statute, trust instrument, or public-law act
J4 Register or public anchorvolncommercial register, supervisory register, LEI/vLEI, public act, or recognised non-register basis
J5 Organs and representativesvolnregister entry, mandate, role credential, board record, trustee office, or public appointment
Table 3: Assertion catalogue of the juridical type: eight classes J0–J7. The rows cross the same source scale S1–S7 as the natural catalogue; the source-availability note states the ordinary high-weight confirmer without excluding other documented confirmations.
Class (content)OptCardSource-availability note
M0 Status and attachment pathmand1artifact attestation, register or conformity record, audit, mandate, public-officer attestation, or role proof
M1 Deterministic actuatorvolncode hash, deployment attestation, reproducible build, bytecode proof, audit, or notarised mandate
M2 Model-driven mandated actuatorvolnmodel provenance, version record, risk classification, conformity assessment, oversight record, audit, or mandate
M3 Reserved goal-setting actuatorvolnfuture legal and technical confirmation only; active gates require explicit law, control, and recovery predicates
Table 4: Assertion catalogue of the machine type: four classes M0–M3. M1–M3 are capability rows; trust and control are descriptors attached to the machine row and its confirmation events.
Figure 3: The fold. Left: the assurance state as the two-axis grid of eq. 6 , each cell separately addressable, filled cells scattered as real states are. Right: the same state folded into a per-credential ladder of levels, the form shared by flat verification and level-of-assurance designs. The fold deletes cell addressability; table 5 lists what each deletion costs.
FoldWhat it deletesDemand made inexpressible
Rows merged into data blocksper-class addressability; an unrequested class travels with its blocka gate that demands the address package at register-API source and nothing else
Source columns merged into one verified bitgraded confirmation strengththe same fact accepted self-declared in one jurisdiction and required at machine strength in another, with no additional data disclosed
Corroboration merged into rankthe distinction between level and confirmation indexthree passports read as higher corroboration of the same class rather than as a level-up
Grid folded to enrolled / verifiedthe voluntary floora participant that exists, is welcome, and can do nothing that requires trust
Table 5: What each fold of the grid amputates. Every simplification of the two-axis state into fewer dimensions deletes the addressability of some cells and with it a demand the gate grammar could otherwise express; the comparative evaluation below evaluates exactly these folds as designs.
FieldMeaningMain consumer
confirmation-idStable event identifier, scoped by issuer and policy versionaudit trail; aggregation layer
subjectEntity identifier and entity type T∈{N,J,M}T\in\{N,J,M\}grid owner; gate evaluation
cellsSet of catalogue rows and source class pairs (r,s)(r,s) filled by this eventassurance grid; fold-kill preservation
confirmerIssuer, register, verifier, public officer, qualified service, auditor, or machine source that performed the checksource-scale evaluation
methodCeremony or protocol used, including remote proofing, register pull, holder-triggered connect, audit, or public attestationsource/binding interpretation
bindingEvidence that the confirmed fact belongs to this entity instance and, where relevant, to the presenting holderreplay; anti-impersonation checks
Table 6: Confirmation event fields. The event fills one or more grid cells and preserves the source, binding, timing, status, and proof context needed for later replay.
FieldMeaningMain consumer
reliance-idStable identifier for the relying-party decisionaudit trail; dispute handling
relying-partyService, obliged entity, public body, platform, or other party consuming the presentationliability allocation
actCapability request, transaction, or operation to which the presentation is attachedgate selection
constellationSubmitted actor pattern, such as N, J+N, J+N+M, N+M, J+M, or Madmissibility grammar
gate-versionPublished gate profile, including demand set D(g)D(g) , constellation family K(g)\mathcal{K}(g) , and governing law ℓ(g)\ell(g)reproducible decision test
presentationDisclosed coordinates, confirmation-event references, proof package, and selective-disclosure metadataevidence minimisation; replay
Table 7: Reliance event fields. The event records the relying-party decision over a presentation, with the legal, temporal, and responsibility context needed for audit.
RequirementFlat maximum verificationPer-credential LoAInstitutional reusable KYCProposed grid
R1 Proportional demandLow: maximal entry bar.Partial: relying party chooses a level.Partial: sectoral risk bands.High: each gate declares the cells it consumes.
R2 Assurance/capability separationLow: verification bit and admission merge.Partial: level remains credential or scheme bound.Partial: reuse serves the institution’s onboarding purpose.High: state, demand set, and pass predicate remain distinct.
R3 N/J/M imputationLow: natural-customer template dominates.Partial: natural-person credentials lead; delegation sits outside the level.Partial: juridical and beneficial-owner evidence fit AML reuse.High: N, J, M, and composites share one typed grammar.
R4 Granular disclosureLow: evidence is collected as a package.Partial: credential presentation can disclose attributes, while level still bundles assurance.Partial: document exchange remains package oriented.High: row-addressed assertions support scoped presentations.
R5 Jurisdictional continuityLow: account anchor fixed at enrolment.Partial: scheme portability exists inside trust frameworks.Partial: reuse follows participating institutions and current files.High: jurisdictional anchor and bitemporal event state are stored.
R6 Allocated relianceLow: reliance is an enrolment fact.Partial: assertion consumption is federated, liability allocation is external.Partial: third-party reliance exists with retained responsibility.High: reliance event records gate, parties, law, time, and liability boundary.
Table 8: Comparative evaluation against the six requirements. Scores report architectural support: low means the design expresses the requirement only through external policy or manual process; partial means it expresses part of the requirement; high means the requirement is native to the model.
TensionFlattened responseArtifact response
Minimisation and recoursecollect a broad package earlyaddress each assertion row and preserve reliance events
Inclusion and high-consequence controlimpose a high entry baradmit the status floor and gate later capabilities
Reuse and retained responsibilitycopy due-diligence files or trust an institutional assertionrecord the package, parties, rule version, and liability boundary at reliance
Portability and local lawbind the account to one enrolment jurisdictionstore facts once and evaluate jurisdiction-relative predicates at act time
Automation and legal imputationtreat machine output as a system event beside the actor modelroute machine capability through M0 attachment and admissible constellations
Table 9: Design tensions and artifact responses. The responses interpret the evaluated requirements rather than adding new requirements.
More in this topic

Cybersecurity

Cybersecurity develops methods to protect digital and cyber-physical systems from attacks, vulnerabilities, data loss, and misuse.

See all 355 papers

Explore similar work

CardsList
Apr 7, 2026

Who Governs the Machine? A Machine Identity Governance Taxonomy (MIGT) for AI Systems Operating Across Enterprise and Geopolitical Boundaries

The governance of artificial intelligence has a blind spot: the machine identities that AI systems use to act. AI agents, service accounts, API tokens, and automated workflows now outnumber human identities in enterprise environments by ratios exceeding 80 to 1, yet no integrated framework exists to govern them. A single ungoverned automated agent produced $5.4-10 billion in losses in the 2024 CrowdStrike outage; nation-state actors including Silk Typhoon and Salt Typhoon have operationalized ungoverned machine credentials as primary espionage vectors against critical infrastructure. This paper makes four original contributions. First, the AI-Identity Risk Taxonomy (AIRT): a comprehensive enumeration of 37 risk sub-categories across eight domains, each grounded in documented incidents, regulatory recognition, practitioner prevalence data, and threat intelligence. Second, the Machine Identity Governance Taxonomy (MIGT): an integrated six-domain governance framework simultaneously addressing the technical governance gap, the regulatory compliance gap, and the cross-jurisdictional coordination gap that existing frameworks address only in isolation. Third, a foreign state actor threat model for enterprise identity governance, establishing that Silk Typhoon, Salt Typhoon, Volt Typhoon, and North Korean AI-enhanced identity fraud operations have already operationalized AI identity vulnerabilities as active attack vectors. Fourth, a cross-jurisdictional regulatory alignment structure mapping enterprise AI identity governance obligations under EU, US, and Chinese frameworks simultaneously, identifying irreconcilable conflicts and providing a governance mechanism for managing them. A four-phase implementation roadmap translates the MIGT into actionable enterprise programs.

Andrew Kurtz, Klaudia Krawiecka

AI GovernanceCybersecurityAI Agent SecurityAI Risk Management
AskPDF
Apr 25, 2026

AI Identity: Standards, Gaps, and Research Directions for AI Agents

AI agents are now running real transactions, workflows, and sub-agent chains across organizational boundaries without continuous human supervision. This creates a problem no current infrastructure is equipped to solve: how do you identify, verify, and hold accountable an entity with no body, no persistent memory, and no legal standing? We define AI Identity as the continuous relationship between what an AI agent is declared to be and what it is observed to do, bounded by the confidence that those two things correspond at any given moment. Through a structured survey of industry trends, emerging standards, and technical literature, we conduct a gap analysis across the full agent identity lifecycle and make three contributions: (1) a structural comparison of human and AI identity across four dimensions (substrate, persistence, verifiability, and legal standing) showing that the asymmetry is fundamental and that extending human frameworks to agents without structural modification produces systematic failures; (2) an evaluation of current technical and regulatory documents against the identity requirements of autonomous agents, finding that none adequately address the challenge of governing nondeterministic, boundary-crossing entities; and (3) identification of five critical gaps (semantic intent verification, recursive delegation accountability, agent identity integrity, governance opacity and enforcement, and operational sustainability) that no current technology or regulatory instrument resolves. These gaps are structural; more engineering effort alone will not close them. Foundational research on AI identity is the central conclusion of this report.

Takumi Otsuka, Kentaroh Toyoda, Alex Leung

1AIFT, Singapore · 2Graduate School of Fundamental Science and Engineering, Department of Computer Science and Communications Engineering, Waseda University, Japan · 3Keio Global Research Institute (KGRI), Japan

AI AccountabilityAI Agent SecurityAI Agent Governance
AskPDF
May 6, 2026

Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure

The security discussion around agentic AI focuses heavily on prompt injection. This paper argues that multi-agent systems also create a distinct authorization problem: maintaining authorization invariants as non-human principals retrieve data, delegate tasks, and synthesize results across changing boundaries. We call this problem authorization propagation. It is not reducible to prompt injection and is not fully addressed by classical access-control models such as RBAC, ABAC, or ReBAC. The paper formalizes authorization propagation as a workflow-level property, identifies three sub-problems (transitive delegation, aggregation inference, and temporal validity), and derives seven structural requirements for authorization architectures in multi-agent AI systems. Recent work on invocation-bound capability tokens, task-scoped authorization envelopes, dependency-graph policy enforcement, and execution-count revocation demonstrates that the field is converging on the problem, but not yet on a complete architecture. The central claim is that identity governance must be treated as infrastructure: evaluated continuously, enforced at every interaction boundary, and designed into the system before orchestration logic is allowed to scale. Preliminary implementation evidence from a production enterprise AI platform shows that ordinary system behavior, not only adversarial action, already produces the failures this model predicts.

Krti Tallam

Kamiwaza AI

AI Agent GovernanceAccess ControlMulti-Agent System Security
AskPDF