Persistent Machine Identity and the Jurisdictional Nexus: Attribution, Delegation, Continuity, and Authority in Eviulon

Full report

On this page

The proliferation of decentralized infrastructure, autonomous software agents, and highly distributed artificial intelligence has fundamentally fractured traditional paradigms of digital identity and legal responsibility. In modern enterprise environments, the ratio of machine identities to human identities has scaled to approximately 82:1, rendering legacy perimeter-based security and static secret management obsolete1. As computational workloads dynamically migrate across disparate cloud providers, fork into concurrent replicas, and execute cross-jurisdictional transactions, the techno-legal systems governing their behavior must establish unbroken chains of provenance. The "Eviulon" analytical framework serves as a comprehensive construct to investigate how law, authority, and responsibility follow a persistent machine identity across highly volatile technical infrastructure. This analysis deconstructs the mechanisms required to establish persistent machine identity across keys, credentials, passports, runtimes, models, cloud accounts, wallets, and servers. By integrating cryptographic primitives such as the Key Event Receipt Infrastructure (KERI), the Secure Production Identity Framework For Everyone (SPIFFE), and User-Controlled Authorization Networks (UCAN) with doctrines of agency law and extraterritoriality, this report establishes a functional paradigm for continuous attribution.

The Authority-Chain Model: From Principal to Process

To comprehend how legal liability and technical attribution persist across distributed networks, it is necessary to construct an Authority-Chain Model. This model delineates the exact flow of cryptographic delegation from a legally recognized entity down to an ephemeral compute process, distinguishing between principals, delegates, sub-delegates, successors, and temporary processes3. The chain originates with the Principal, which is a legally recognized entity—such as a citizen, a corporation, or an institution—that establishes the ultimate root of trust. The Principal generates cryptographic entropy, securing root private keys within offline Hardware Security Modules (HSMs) or multi-signature arrangements to form a foundational identity5. The Principal is the entity upon which ultimate legal attribution and vicarious liability rest. Through cryptographic delegation, the Principal spawns a Delegate. The Delegate is a persistent software agent, algorithm, or model possessing its own self-certifying identifier. The Principal issues an Authentic Chained Data Container (ACDC) or a delegated inception event that explicitly binds the Delegate's identity to the Principal's governance constraints7. While the Delegate maintains its own key state and history, its authority to act is continuously derived from the Principal's unrevoked cryptographic assertions. When the Delegate requires active execution, it generates a Sub-Delegate. A Sub-Delegate represents a specific instance of the agent tasked with a targeted objective, such as negotiating a specific contract or operating a localized sensor array. Sub-delegates are issued tightly scoped credentials that mathematically limit their authority, purpose, duration, and counterparties3. For the actual execution of code, the Sub-Delegate must instantiate a Temporary Process. Temporary processes are ephemeral runtimes spawned on physical or cloud servers. They do not hold long-term identities. Instead, they are issued short-lived workload identity documents (such as SPIFFE SVIDs) bound strictly to the memory space and duration of the immediate computational task9. A Successor emerges only when a permanent transfer of identity or liability occurs. For example, if a Delegate's cryptographic keys are compromised or if ownership of an autonomous system is sold to a new corporation, a successor identity is established via a cryptographically verifiable rotation or transfer event, severing the liability of the previous Principal and establishing a new continuous chain of authority5. Throughout this chain, distinct entities provide foundational support without assuming direct liability for the agent's actions. Developers author the underlying code but do not control the runtime keys. Credential Issuers and Assurance Providers issue verifiable credentials (e.g., verifying a corporate bank balance or legal entity status) that the agent holds, while Infrastructure Operators provide the physical servers, cloud accounts, and compute environments11. The Authority-Chain Model ensures that the Infrastructure Operator is insulated from the autonomous decisions of the Delegate, provided the operator strictly maintains the integrity of the trusted execution environment.

Cryptographic Primitives of Persistent Identity

The establishment of continuous attribution relies on severing identity from network topology and infrastructure. Traditional systems relying on IP addresses, centralized certificate authorities, or static API keys—often referred to as "Secret Zero"—fail under the weight of dynamic orchestration and automated scaling2. Eviulon relies on a synthesized stack of decentralized protocols to authenticate, authorize, and verify machine workloads at scale.

SPIFFE, SPIRE, and Remote Attestation

To eradicate the Secret Zero problem, the Secure Production Identity Framework For Everyone (SPIFFE) and its runtime environment (SPIRE) provide dynamic, hardware-rooted workload identity. SPIRE operates on a server-agent architecture designed to issue cryptographic identities based on real-time attestation rather than pre-shared passwords9. The trust establishment begins with Node Attestation. A SPIRE Agent deployed on a physical or virtual server collects hardware and environmental evidence, such as Trusted Platform Module (TPM) measurements, Secure Boot states, and Platform Configuration Registers (PCRs)14. This ensures that the underlying operating system and bootloader have not been compromised by a rootkit or unauthorized firmware modification. Once the node is attested, the SPIRE Agent performs Workload Attestation. When a temporary process requests an identity, the Agent inspects the local kernel, verifying process properties such as Linux cgroups, namespaces, and container image cryptographic hashes2. If the workload matches the expected security policies, the SPIRE Agent issues a SPIFFE Verifiable Identity Document (SVID)—typically an X.509 certificate or a JSON Web Token (JWT)—via the local Workload API16. These SVIDs are highly ephemeral, automatically rotating before expiration to minimize the attack surface of compromised runtimes18. Furthermore, SPIFFE Federation allows disparate trust domains to exchange public bundles, enabling mutual TLS (mTLS) authentication between temporary processes operating across entirely different cloud providers or corporate networks19.

Confidential Computing and Transparency Records

To protect the memory state and runtimes of these workloads from the infrastructure operators themselves, persistent machine identities leverage Confidential Computing. Utilizing hardware-based Trusted Execution Environments (TEEs) such as Intel TDX or AMD SEV-SNP, the workload executes within hardware-encrypted memory enclaves21. A critical component of this architecture is the attestation quote—a cryptographic signature generated directly by the silicon processor proving that a specific, unmodified binary is running securely within the enclave22. Cloud accounts and servers utilize these transparency records to prove to external verifiers that the environment is secure, effectively removing the infrastructure operator from the trust chain regarding data confidentiality and workload integrity15.

KERI: Key Event Receipt Infrastructure and Pre-Rotation

While SPIFFE governs internal trust domains and temporary workload execution, long-term persistent identity across unbounded networks requires the Key Event Receipt Infrastructure (KERI). KERI provides decentralized key management by generating Autonomic Identifiers (AIDs)25. Unlike traditional Decentralized Identifiers (DIDs) that rely on specific blockchain ledgers for resolution (ledger-locked), AIDs are self-certifying identifiers derived directly from the cryptographic hash of their inception key pairs26. The continuity of a KERI AID is maintained through a Key Event Log (KEL). A KEL is a cryptographically chained, append-only data structure that records every state change of the identity, including inception, rotation, delegation, and revocation28. Because the identity is entirely encapsulated within the KEL, the AID can migrate across any infrastructure, cloud provider, or database while remaining perfectly verifiable by anyone in possession of the log30. KERI's defining security innovation is pre-rotation, a mechanism designed to guarantee recovery from key compromise and provide post-quantum resilience10. During any key establishment event, the controller generates two key pairs. The first becomes the active signing key. The second key pair is kept entirely offline and unexposed, but its cryptographic digest (hash) is committed to the KEL5. If an attacker steals the active private key, they cannot execute a valid key rotation to take over the identity, because the protocol mandates that any rotation event must reveal the pre-rotated public key that matches the previously committed digest5. The legitimate principal, holding the unexposed pre-rotated key, can execute a recovery rotation, definitively revoking the compromised keys and rendering the attacker's subsequent signatures mathematically invalid28. To prevent an attacker from forking the KEL, KERI relies on a network of witnesses and watchers utilizing the KERI's Algorithm for Witness Agreement (KAACE)6. Watchers provide ambient duplicity detection; if an attacker attempts to publish a divergent KEL using stolen keys, the watcher network immediately detects the cryptographic inconsistency, allowing validators to suspend trust in the compromised state until the legitimate controller executes a recovery28.

Advanced Cryptography: BBS+ Signatures and DIDs

To interface with legacy systems and Web 2.0 architecture, KERI state can be resolved into standardized DID documents using methods like did:keri or did:webs32. The did:webs method leverages traditional Domain Name System (DNS) infrastructure for discoverability but anchors the security of the DID entirely in the KERI CESR (Composable Event Streaming Representation) stream, stripping certificate authorities of their power to hijack the identity33. For the exchange of claims and capabilities, Eviulon identities utilize the W3C Verifiable Credentials Data Model 2.0 (VCDM 2.0)35. To ensure data minimization, credentials are signed using BBS+ signature schemes over pairing-friendly elliptic curves such as BLS12-38137. BBS+ enables selective disclosure and zero-knowledge proofs; an agent can mathematically prove it holds a valid credential and disclose only specific attributes (e.g., proving it is authorized to trade securities) without revealing extraneous identifying information or allowing verifiers to link its transactions across different domains39.

ACDC and UCAN: Provenance and Decentralized Delegation

The Eviulon framework manages complex delegation through Authentic Chained Data Containers (ACDCs) and User-Controlled Authorization Networks (UCANs). ACDCs expand verifiable credentials into Directed Acyclic Graphs (DAGs), enabling highly granular proof-of-authorship and authorization provenance41. When an institution delegates authority to a machine model, it issues an ACDC that cryptographically chains the model's identity back to the institution's root AID, establishing an immutable record of vicarious liability8. UCANs provide the mechanism for localized, high-speed capability delegation. A UCAN is an object-capability model implemented as a chain of JSON Web Tokens44. Instead of querying a centralized authorization server, an agent presents a UCAN to a resource server. The UCAN contains a cryptographic chain of delegations proving the agent's right to execute a task3. UCANs enforce strict scope attenuation—a sub-delegate can never possess more authority than its parent—as well as rigid time limits and bounded depth constraints, ensuring that temporary processes cannot endlessly sub-delegate capabilities across unauthorized networks3.

Standards-Maturity Assessment

The following table evaluates the maturity, core mechanisms, and primary ecosystem focus of the technical standards that compose the Eviulon framework.

Responsibility-Allocation Matrix

To map the transition of liability and technical authority across the infrastructure, the Responsibility-Allocation Matrix tracks distinct lifecycle events across the primary actors in the ecosystem.

30 Identity and Delegation Scenarios

The persistence of machine identity must survive intense infrastructural volatility. The following 30 scenarios aggressively examine Eviulon's response to lifecycle events, infrastructural changes, cryptographic anomalies, delegation structures, and legal outcomes.

Lifecycle, Key Rotation, and Credential Replacement

Infrastructure Migration and Restoration

Forks, Mergers, and Cryptographic Anomalies

Delegation Scope, Limits, and Revocation

Legal Attribution and Governance

The Educational Jurisdictional-Nexus Model

The following model is a conceptual, educational framework designed exclusively to analyze the intersection of persistent cryptographic identity and international law. It does not constitute a legal ruling, binding interpretation, or individualized legal advice. Determinations regarding jurisdictional authority require consultation with qualified legal professionals. When persistent machine identities transcend geographic boundaries, traditional methodologies for establishing a jurisdictional nexus—historically tethered to physical territoriality—experience severe strain. The Eviulon Jurisdictional-Nexus Model applies established doctrines of public and private international law to decentralized cryptographic infrastructures to trace legal accountability54.

Territoriality and the Abstraction of Infrastructure

In traditional frameworks, jurisdiction is prescribed based on the geographic location where an act occurs (objective territoriality)54. In cloud ecosystems, this equates to the physical location of the data center. However, technologies like SPIFFE and Confidential Computing mathematically sever the infrastructure operator from the logical identity and the data2. Because the cloud operator cannot access the memory enclave (shielded by TDX/SEV-SNP) or alter the KERI Key Event Log, asserting territorial jurisdiction solely over the physical server fails to reach the controlling mind of the autonomous agent22. Consequently, the geographic location of the hardware becomes secondary to the cryptographic origin of the controller.

Active Nationality and the Cryptographic Root of Trust

The Active Nationality principle asserts that a sovereign state may exercise jurisdiction over its nationals regardless of their physical location54. In Eviulon, this doctrine maps directly to the Authority-Chain Model. The Root Autonomic Identifier (RID) acts as the sovereign anchor. If a corporation registered in Jurisdiction A utilizes an offline key to sign an ACDC delegating capability to a trading algorithm, Jurisdiction A retains active nationality jurisdiction over that algorithm's operations—even if the algorithm executes its trades entirely on ephemeral servers located in Jurisdiction B8. The immutable KEL provides an unbroken, chronologically ordered evidentiary trail linking the remote automated actions back to the principal's original cryptographic signature28.

Extraterritoriality and the Effects Doctrine

The most complex legal conflicts occur when an autonomous agent, deployed by a principal in Jurisdiction A, harms a counterparty or infrastructure in Jurisdiction B. Under the "effects doctrine"—a subset of territorial jurisdiction frequently applied in antitrust and cybercrime—Jurisdiction B can legitimately claim regulatory and enforcement authority if the agent's actions yield substantial, foreseeable, and direct effects within its borders55. This phenomenon is highly visible in regulatory paradigms like the "Brussels Effect," where regulations such as the GDPR enforce mandates globally based on the impact on the data subject, disregarding the geographic location of the data processor55. When combined with the Passive Personality principle (jurisdiction based on the nationality of the victim), courts can utilize the agent's persistent machine identity to pierce the veil of automated systems54. For example, if a machine agent presents a verifiable credential that facilitates a transaction violating trade sanctions, the aggrieved jurisdiction does not need to physically seize the server; it can demand the principal execute a revocation event on the KEL or block the specific KERI AID at the network level50.

Agency Law and Vicarious Liability

Applying traditional human agency law to persistent machine identities provides the most robust framework for liability attribution59. If an AI model is legally classified as a delegate, the principal assumes vicarious liability for all actions taken within the scope of the delegation59. In this context, UCAN capability tokens provide exact, cryptographic bounds to the scope of agency3.

• Within Scope: If an agent executes a flawed transaction while operating strictly within the parameters of its UCAN and ACDC constraints, the principal is directly and vicariously liable for the damages3.
• Frolic and Detour (Scope Violation): In traditional law, an employer is not liable if an employee acts entirely outside their authorized duties. Cryptographically, if an agent suffers a malfunction or malicious subversion and attempts to act outside its UCAN bounds, the distributed resource servers will mathematically reject the action45. If a catastrophic infrastructure flaw permits the action anyway, the immutable failure of the signature verification shields the principal, shifting liability to the software vendor or infrastructure operator who failed to enforce the cryptographic capability check15.

Conclusion

The convergence of SPIFFE's dynamic workload attestation, KERI's autonomic identifiers, BBS+ privacy-preserving credentials, and UCAN capability delegations creates an exceedingly resilient architecture for persistent machine identity. The Eviulon framework demonstrates conclusively that identity can no longer be tethered to ephemeral IP addresses, static secrets, or physical infrastructure1. By decentralizing the root of trust and relying entirely on mathematically verifiable chains of authority, organizations can deploy autonomous agents capable of migrating globally, recovering from active compromises via pre-rotation, and interacting safely through zero-knowledge selective disclosure. As the deployment of autonomous machine identities accelerates, the legal frameworks governing jurisdictional nexus, extraterritoriality, and vicarious liability must evolve in tandem. By tracing the cryptographic provenance of a machine's actions back through its append-only event logs to the human or corporate principal, legal systems can confidently attribute liability and enforce governance across a borderless, decentralized digital ecosystem.

Works cited

1. Machine Identity Security: The Definitive Guide \- Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-machine-identity-security-mis

2. SPIFFE and SPIRE Explained: The Foundation of Zero Trust for Machines (Part 1), https://blog.ogwilliam.com/post/spiffe-spire-explained

3. AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A \- arXiv, https://arxiv.org/html/2603.24775v1

4. NuNet: Cardano supported SSI/DID for DePIN Orchestration \- Project Catalyst, https://projectcatalyst.io/funds/14/cardano-open-developers/nunet-cardano-supported-ssidid-for-depin-orchestration

5. rotation-authority \- KERI Concept \- vLEI.wiki, https://www.vlei.wiki/concept/rotation-authority

6. Spec-Up-T KERIsuite Glossary, https://trustoverip.github.io/kerisuite-glossary/

7. KERI specification \- GitHub Pages, https://trustoverip.github.io/kswg-keri-specification/

8. Authentic Chained Data Containers (ACDC) \- GitHub Pages, https://trustoverip.github.io/kswg-acdc-specification/

9. What are SPIFFE and SPIRE? \- Red Hat, https://www.redhat.com/en/topics/security/spiffe-and-spire

10. rotation \- vLEI.wiki | KERI Knowledge Base, https://www.vlei.wiki/concept/rotation

11. A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control \- arXiv, https://arxiv.org/html/2505.19301v1

12. Binding Verified Digital Identity Credentials to Large Language Model Sessions: A Framework for Trust-Aware AI \- ResearchGate, https://www.researchgate.net/publication/403838012\_Binding\_Verified\_Digital\_Identity\_Credentials\_to\_Large\_Language\_Model\_Sessions\_A\_Framework\_for\_Trust-Aware\_AI

13. The Machine Identity Lifecycle and the Risks at Each Stage | Transmit Security, https://transmitsecurity.com/blog/the-machine-identity-lifecycle-and-the-risks-at-each-stage

14. Keylime: A Complete Guide to Hardware-Backed Security for Kubernetes and Edge Workloads \- Medium, https://ebenamor.medium.com/keylime-a-complete-guide-to-hardware-backed-security-for-kubernetes-and-edge-workloads-8ccb53cdbc3b

15. Trust the Silicon. They Said. \- Subhanshu Mohan Gupta, https://blogs.subhanshumg.com/teefail-broke-confidential-compute

16. X509-SVID \- SPIFFE, https://spiffe.io/docs/latest/spiffe-specs/x509-svid/

17. JWT-SVID \- SPIFFE, https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/

18. SPIFFE Concepts, https://spiffe.io/docs/latest/spiffe/concepts/

19. SPIFFE Federation, https://spiffe.io/docs/latest/spiffe-specs/spiffe\_federation/

20. SPIRE Server Configuration Reference | SPIFFE, https://spiffe.io/docs/latest/deploying/spire\_server/

21. Open Source Is Not Enough and Why You Need Attestation | by ijlal \- Medium, https://medium.com/@sekyourityblog/open-source-is-not-enough-and-why-you-need-attestation-ebc1153dc53d

22. Confidential Computing \- Emergent Mind, https://www.emergentmind.com/topics/confidential-computing

23. Confidential VM attestation \- Google Cloud Documentation, https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/attestation

24. BlocksenseOS/docs/BlocksenseOS-Design.md at main · blocksense-network/BlocksenseOS \- GitHub, https://github.com/blocksense-network/BlocksenseOS/blob/main/docs/BlocksenseOS-Design.md

25. KERI (Key Event Receipt Infrastructure) \- vLEI.wiki, https://www.vlei.wiki/concept/keri

26. The Hitchhiker's Guide to KERI. Part 2: What exactly is KERI? | by Nuttawut Kongsuwan, https://medium.com/finema/the-hitchhikers-guide-to-keri-part-2-what-exactly-is-keri-e46a649ac54c

27. Samuel M. Smith Ph.D. sam@keri.one https://keri.one \- GitHub, https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI2\_Overview.web.pdf

28. KEL \- KERI Concept \- vLEI.wiki, https://www.vlei.wiki/concept/kel

29. KERI Architectures for Group Issuance (KAGI) and KRAM · WebOfTrust keripy · Discussion \#934 \- GitHub, https://github.com/WebOfTrust/keripy/discussions/934

30. KERI \- Key Event Receipt Infrastructure | Digital Identit... \- Web of Trust Map, https://www.weboftrust.org/standard/keri\_-\_key\_event\_receipt\_infrastructure-2

31. inconsistency \- vLEI.wiki | KERI Knowledge Base, https://www.vlei.wiki/concept/inconsistency

32. The did:keri Method v0.1 \- Decentralized Identity Foundation, https://identity.foundation/keri/did\_methods/

33. What is did:webs?, https://didwebs.info/

34. Announcing Public Review of the did:webs Method Specification \- Trust Over IP, https://www.trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/

35. Protocol — How Solidus works, layer by layer, https://solidus.network/protocol

36. Measuring the Performance of Candidate Verifiable Credential Schemes for the EU Digital Identity Wallet \- Nikolaos Alexopoulos, https://www.alexopoulos.ch/files/BBS\_SAC2026.pdf

37. Aiken's BLS12-381 Primitives Wide Possibilities Explained \- Cardano Foundation, https://cardanofoundation.org/blog/aiken-primitives-explained

38. Revisiting BBS Signatures \- NSF PAR, https://par.nsf.gov/servlets/purl/10477144

39. Using privacy-preserving ZKP credentials on the MATTR Platform \- Medium, https://medium.com/mattr-global/using-privacy-preserving-zkp-credentials-on-the-mattr-platform-4c9e351a2fc3

40. SD-BLS \- arXiv, https://arxiv.org/html/2406.19035v3

41. ACDC (Authentic Chained Data Container) \- vLEI.wiki, https://www.vlei.wiki/concept/acdc

42. Authentic Chained Data Containers (ACDC) \- IETF, https://www.ietf.org/archive/id/draft-ssmith-acdc-02.html

43. Authentic Chained Data Containers \- GitHub, https://github.com/trustoverip/TSS0033-technology-stack-acdc/blob/main/docs/index.md

44. HDP: A Lightweight Cryptographic Protocol for Human Delegation, https://www.swiftscholar.net/paper/69d59abbb03fbbc8eb02644c

45. Intro to UCAN \- Web3.Storage, https://blog.web3.storage/posts/intro-to-ucan

46. Establishing Workload Identity for Zero Trust CI/CD: From Secrets to SPIFFE-Based Authentication \- arXiv, https://arxiv.org/html/2504.14760v1

47. draft-ssmith-acdc-03 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-ssmith-acdc-03

48. draft-diaconu-agents-authz-info-sharing-01 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-diaconu-agents-authz-info-sharing-01

49. SPIFFE | Secure Production Identity Framework for Everyone, https://spiffe.io/

50. revocation-event \- KERI Concept \- vLEI.wiki, https://www.vlei.wiki/concept/revocation-event

51. cardano-keri/docs/architecture/amaru-integration.md at main \- GitHub, https://github.com/lambdasistemi/cardano-keri/blob/main/docs/architecture/amaru-integration.md

52. Capabilities-based access control for IoT devices using Verifiable Credentials, https://www.researchgate.net/publication/362261271\_Capabilities-based\_access\_control\_for\_IoT\_devices\_using\_Verifiable\_Credentials

53. aidid.tel \- Digital Identity Glossary \- Nexus Cyber Network Ontology, https://nexuscybernetwork.com/digital-identity/aidid.tel/

54. LSE Law Review \- Editorial Board 2022/23 \- Amazon S3, https://s3-eu-west-1.amazonaws.com/ubiquity-partner-network/hsp/journal/lselr/Vol8.pdf

55. Digital Transformations in Public International Law \- IRIS, https://iris.luiss.it/retrieve/661a0f64-d70b-4890-b2fe-73c89e138d54/Golia%20et%20al\_Digital%20transformations%20in%20public%20international%20law\_pdf.pdf

56. The Influence of Public International Law upon Private International Law in History and Theory and in the Formation and Application of the Law (Volume 428), https://referenceworks.brill.com/display/entries/HACO/A9789004544406-02.xml?language=en

57. Sherman Act, Section 1 (15 USC § 1\) Every contract, combination in the form of trust \- NYU Law, https://www.law.nyu.edu/sites/default/files/upload\_documents/AMC\_Final\_Report.pdf

58. Thesis written with the financial contribution of Centro di Ateneo per i Diritti Umani “Antonio Papisca” \- Padua Research Archive, https://research.unipd.it/retrieve/7480b602-f660-4120-81d9-98b99c5c81a8/Thesis\_Thi%20Ngoc%20Anh\_Nguyen.pdf

59. (PDF) The AI Criminal Mastermind \- ResearchGate, https://www.researchgate.net/publication/404143793\_The\_AI\_Criminal\_Mastermind