Deployment organization model

Target audience: Solution Architects, Enterprise Architects, CISOs, IT Directors

Reading time: 12 minutes (overview)

Prerequisites: Working knowledge of cryptographic key management, multi-tenant systems, access control, and inter-organization data exchange

Executive summary

ANKASecure© is a Cryptographic Control Plane that governs the use of cryptography across internal systems and data exchanges with third parties. The platform decouples cryptographic operations from the applications that consume them, exposing them as governed, controlled, and auditable capabilities.

The deployment organization model defines how an enterprise structures cryptographic governance across its deployment: how parties are identified, how operations are authorized, how exchanges with counterparties are mediated, and how every action becomes part of a verifiable audit record.

This section is the canonical conceptual reference for the model. The current page is the overview; the detail pages explore each dimension.

Core principle

Cryptographic keys never leave the control domain of the data owner.

Access to cryptographic functions is mediated through controlled, auditable capabilities. External parties and internal components do not own keys: they are authorized to invoke capabilities under strict governance.

This principle has three direct consequences:

1. Key custody is centralized. Cryptographic material is held by the data owner inside ANKASecure©, protected by HSM-backed key management. No counterparty, vendor, or external system ever receives raw key material.
2. Authorization is capability-based. Parties request the execution of a function (encrypt, decrypt, sign, verify, wrap), not access to a key. Authorization is granted to perform an action under specific conditions.
3. Every operation is observable. Each invocation produces a structured audit event linking party, credential, capability, asset, exchange context, and outcome.

Model overview

The model is organized into six logical layers. Each layer answers a different governance question.

The twelve entities of the model distribute across these layers as follows:

flowchart TB
    subgraph ORG["Organizational layer"]
        direction LR
        DEP["Deployment"]
        TEN["Tenant"]
        APP["Application"]
    end

    subgraph IDENT["Operational identity layer"]
        direction LR
        ACT["Cryptographic Actor"]
        CRED["Credential"]
    end

    subgraph EXCH["Governed exchange layer"]
        CTX["Exchange Context"]
    end

    subgraph RES["Cryptographic resource layer"]
        direction LR
        ASSET["Cryptographic Asset"]
        CAP["Capability"]
    end

    subgraph CTRL["Control layer"]
        direction LR
        GRANT["Capability Grant"]
        CONSTR["Constraint Policy"]
        POL["Policy"]
    end

    subgraph EVID["Evidence layer"]
        AUDIT["Audit Event"]
    end

    ORG --> IDENT --> EXCH --> RES --> CTRL --> EVID

    style ORG fill:#e8f4f8,stroke:#1a5276
    style IDENT fill:#fdebd0,stroke:#d68910
    style EXCH fill:#d6eaf8,stroke:#2980b9
    style RES fill:#d5f5e3,stroke:#1e8449
    style CTRL fill:#fadbd8,stroke:#c0392b
    style EVID fill:#e8daef,stroke:#7d3c98

What's in this section

This section is organized as a guided path from the architectural shape of the model to the concrete scenarios it supports.

A reader new to the model should follow the pages in order. A reader looking up a specific entity or attribute can jump directly to Entity reference.

Control plane orchestration layer

The 12 entities above form the runtime authorization model. Cryptographic operations resolve against Capability Grant and never reference any orchestration construct.

The platform also exposes a control-plane orchestration layer that lives strictly above the runtime model and exists for administrative usability. The runtime model is unaffected by anything in this layer.

The single entity in the orchestration layer is the Cryptographic Exchange — an admin-managed aggregate that groups one Application + one Cryptographic Actor + one Cryptographic Asset (by KID) + one Exchange Context + one Constraint Policy under a single managed lifecycle (DRAFT → READY → ACTIVE ⇄ SUSPENDED; terminals REVOKED, EXPIRED, CONSUMED). It owns its Capability Grant 1:1.

The Exchange collapses the admin's mental model from "five separate entities to wire correctly" into "one intercambio to set up". Activate / Suspend / Resume / Revoke act on the Exchange and propagate atomically to the underlying Grant. The runtime path (Core API) is unaffected.

For the full reference, see Entity reference — Control plane orchestration entities.

Model properties

The model produces five governance properties that distinguish it from traditional key management:

These properties hold uniformly across simple internal use cases, complex enterprise environments, and multi-party ecosystems — without architectural variation.

Conclusion

ANKASecure© redefines cryptography as an independent layer that is governed, controlled, and enforced — not embedded inside applications. The deployment organization model provides the conceptual fabric for that governance.

The same set of entities composes the structure for an internal API integration, a regulated data exchange with a third-party processor, and a multi-jurisdiction enterprise platform. Cryptographic governance becomes a property of the platform, not a responsibility delegated to each application team.

Continue to The six-layer model for the structural breakdown.

Document status: ACTIVE — canonical reference for the ANKASecure© organization model.