Entity reference

Target audience: Solution Architects, Enterprise Architects, Platform Implementers

Reading time: 25 minutes (full read), or jump to a specific entity

Prerequisites: The six-layer model

Introduction

This page is the canonical reference for the twelve entities of the deployment organization model. Each entity definition includes its purpose, key attributes, lifecycle considerations, and concrete examples.

For the layered structure that groups these entities, see The six-layer model. For their relationships and runtime composition, see Relationships and runtime flow.

Organizational entities

Deployment

A Deployment is a complete installation of ANKASecure©. It defines:

• The infrastructure footprint (compute, network, storage)
• The global compliance baseline (regulatory region, certification posture)
• HSM and KMS integrations (vendor, slots, partitions)
• Default cryptographic policies inherited by tenants

A Deployment maps to a productive environment, a regulatory region, or a logical infrastructure boundary. Organizations operating under conflicting regulatory regimes — for example, jurisdictions with incompatible cryptographic mandates — typically run separate deployments.

Key attributes:

When to define a separate deployment: when the regulatory or jurisdictional context differs in ways that require independent governance. A single multinational organization may run multiple deployments — one per major regulatory region — to satisfy data residency and sovereign cryptography requirements.

Tenant

A Tenant is an isolated cryptographic domain within a Deployment. It provides:

• Boundaries of key ownership
• Independent policy scope (within deployment baseline)
• Administrative separation
• Audit isolation

Each tenant owns its cryptographic assets and defines its own governance rules within the constraints imposed by the deployment. A compromise within one tenant cannot reach assets in another tenant, even when both run on the same infrastructure.

Key attributes:

Multi-tenancy scope: a Tenant is the unit of cryptographic isolation. It is also the natural unit of administrative delegation — different tenants can be administered independently. For details on the technical isolation mechanisms, see Multi-Tenant Isolation Model.

Application

An Application is a business system or functional domain. It defines:

• Business ownership
• Risk classification
• Regulatory scope
• Operational context

Examples: Core Banking, Card Issuance, CRM, Collections, Regulatory Reporting.

Key attributes:

Important distinction: Applications are not technical identities. They do not authenticate, do not hold credentials, and do not invoke operations directly. They are the business container under which technical actors operate. The technical identity is the Cryptographic Actor.

Operational identity entities

Cryptographic Actor

A Cryptographic Actor is the operational subject that executes or requests cryptographic operations. It represents:

• An internal API service
• A batch processing job
• An integration channel
• A third party (for example, a card embossing vendor)
• A BPO processing system

Each Cryptographic Actor belongs to an Application, operates under defined constraints, and is the primary subject of authorization. Authorization decisions, audit events, and rate-limit enforcement are anchored on the actor.

Actors are the unit of trust at runtime. The model treats internal services and external parties uniformly: both are actors with clearly delimited capabilities.

Key attributes:

Actor lifecycle: an actor is created when an integration is established, suspended when it is paused (without losing its authorizations), and revoked when the integration is terminated. Suspending the actor immediately blocks all of its grants without deleting them; reactivation restores the previous state.

Credential

A Credential is the authentication mechanism associated with a Cryptographic Actor. Examples:

• client_id + secret
• Asymmetric client authentication
• mTLS identity (X.509 client certificate)
• Federated identity (OIDC, SAML)

A Cryptographic Actor may hold multiple credentials simultaneously (for credential rotation), and credentials have independent lifecycle management. The separation between actor and credential allows secret rotation without altering authorization grants.

Key attributes:

Credential rotation pattern: an actor can hold two ACTIVE credentials simultaneously during a rotation window. The new credential is issued and tested in parallel with the old one; once the new credential is verified, the old one is revoked. No grant changes are required.

Governed exchange entity

Exchange Context

An Exchange Context is a governed interaction scenario involving cryptographic operations. It models:

• The relationship between parties
• The purpose of the exchange
• The direction of data flow
• The trust model

Examples:

• Card Embossing — VISA
• Card Embossing — AMEX
• Collections Processing — BPO Alpha
• Regulatory Reporting — Central Bank
• Internal Analytics Pipeline

Key attributes:

Why this entity exists: the Exchange Context distinguishes ANKASecure© from a traditional KMS. By modeling the business interaction explicitly, authorization decisions can reflect not only who is acting and what they are doing, but the governed business relationship in which the action takes place.

Lifecycle implication: when a third-party relationship is renegotiated or terminated, the cryptographic implications propagate through the affected Exchange Context. Suspending or terminating a context affects every grant scoped to it — without requiring per-grant inspection.

Cryptographic resource entities

Cryptographic Asset

A Cryptographic Asset is managed cryptographic material. Types include:

Each asset belongs to a Tenant, follows a defined lifecycle (ACTIVE, PENDING_ROTATION, ROTATED, EXPIRED, REVOKED, ARCHIVED), and is governed by policy.

Key attributes:

Asset identification: assets are referenced by stable KID. The runtime resolves the appropriate version based on policy, lifecycle state, and operation type. This is the foundation of the KID system.

Capability

A Capability is a cryptographic function that can be executed. Capabilities abstract the use of cryptographic material into controlled operations.

Standard capabilities:

Why capabilities matter: a consumer never receives a key; it requests the execution of a capability and receives the operational result. This abstraction enables crypto-agility — the underlying algorithm or key version can change without affecting consumers.

For the broader principles behind this design, see Policy-Driven Crypto-Agility.

Control entities

Capability Grant

A Capability Grant is the authorization given to a Cryptographic Actor to invoke a specific capability under specific conditions. It binds:

• An Actor
• A Capability
• One or more Cryptographic Assets
• An Exchange Context (optional or required, depending on the use case)
• Constraints

A Capability Grant answers four questions in a single record:

1. Who can act? — the Actor
2. What can they do? — the Capability
3. On what assets? — the Cryptographic Assets
4. Under what conditions? — the Constraints, scoped to an Exchange Context

Key attributes:

Why this is the unit of authorization: revoking a grant immediately removes the actor's ability to invoke the capability, without affecting other grants or other actors. The grant is the smallest unit of fine-grained governance.

Constraint Policy

A Constraint Policy expresses restrictions on how a capability can be used. Examples:

Key attributes:

Composability: a single Capability Grant can have multiple Constraint Policies attached. They compose by conjunction — all must be satisfied for the grant to be active. For example, a grant might be simultaneously time-windowed (valid Mon-Fri, 8 AM to 6 PM), batch-scoped (only batch #2847), and rate-limited (max 50,000 ops/hour).

Policy

A Policy is a global or scoped rule that governs platform behavior. Policies exist at multiple levels:

• Deployment — regulatory region, allowed algorithms, FIPS posture
• Tenant — tenant-specific algorithm catalog, lifecycle defaults
• Exchange Context — rules specific to a business interaction
• Cryptographic Asset — rotation cadence, usage limits, exportability
• Capability — invocation rules, audit requirements

What policies define:

Key attributes:

Policy versus Constraint Policy: Policies govern platform behavior at architectural levels and apply to many grants. Constraint Policies govern individual grants. The two are complementary: a Policy may say "ML-DSA-87 is the required signature algorithm for the Treasury tenant"; a Constraint Policy may say "this specific grant is single-use and expires in 4 hours."

For the broader policy framework, see Policy-Driven Crypto-Agility.

Evidence entity

Audit Event

An Audit Event records every cryptographic operation and every authorization decision. Each event captures the full context of what happened.

Captured fields:

Integrity: audit events are HMAC-signed at production time using a 9-field canonical format and stored in an isolated audit data store. Tampering is detectable; events are immutable once produced.

Both allow and deny: the evidence layer captures the full decision context, not only successful operations. A denied invocation produces an audit record with the reason for denial, supporting forensic analysis and continuous monitoring.

What audit events enable: compliance reporting (DORA, PCI-DSS, SOX, GDPR), incident response, forensic reconstruction, continuous posture monitoring, and detection of anomalous patterns.

Control plane orchestration entities

The 12 entities above form the runtime authorization model. Core API runtime authorization resolves against Capability Grant and never references the orchestration layer described here.

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

Cryptographic Exchange

A Cryptographic Exchange is 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. It owns its Capability Grant 1:1.

Where the runtime model asks "is this Actor authorized to invoke this Capability on this Asset?", the orchestration model answers a different question for the admin: "what is this whole intercambio I am setting up, and where is it in its lifecycle?". The 7-step manual onboarding sidebar (Applications → Actors → Contexts → Constraint Policies → Capability Grants) is replaced by a single tabbed wizard that materializes one Exchange.

Lifecycle states:

Key attributes:

Composition vs reference (key invariant):

• Composes (1:1, owned): the Capability Grant. The 1:1 invariant is enforced at the database layer via a UNIQUE constraint on grant_id. Two Exchanges cannot share a Grant.
• References (N:1): Application, Actor, Asset (by KID), Exchange Context, Constraint Policy. These remain reusable across multiple Exchanges. The same Actor can participate in many intercambios.

Why this entity exists: the orchestration layer collapses the admin's mental model from "5 separate entities I have to wire correctly" into "one Exchange I am setting up". Activate / Suspend / Resume / Revoke act on the Exchange and propagate atomically to the underlying Grant. The runtime authorization path (Core API) does not change — it still resolves against the Grant. The orchestration is purely an admin usability layer.

API: the Cryptographic Exchange is exposed by ankasecure-admin-api under /api/v3/admin/exchanges. See the admin-api endpoints documentation for the full surface (list, detail, create, PATCH, validate, activate, suspend, resume, revoke, clone, audit-trail).

Greenfield posture: ANKASecure has no live data to migrate. The schema lands empty at first deployment via the 02e_cryptographic_exchange.sql init-sql script. Demo data alignment is operational tooling in the provision-demo workspace project, which wraps any seed Capability Grants in an owning Exchange to maintain the 1:1 invariant.

Quick reference table

Next steps

• For relationships between these entities and the runtime decision flow, see Relationships and runtime flow.
• For worked examples that show these entities composed in real scenarios, see Reference scenarios.
• For the broader architectural context, return to Deployment organization model — Overview.