Hardened for enterprise security review

Every platform that moves regulated assets gets asked four questions before it goes near production: who authenticates, where key material lives, who may do what, and how the thing deploys. We stopped leaving those questions to convention.

Security & deployment

Documented, enforced answers: not assurances

Every security review of a platform that touches money asks the same four questions: who can authenticate, where private keys live, who may do what, and how the thing deploys. 3.0 has documented, enforced answers to each one.

Access domains

Four, least-privilege

Secrets on disk

Zero

High-risk actions

Step-up auth

Deployment

Air-gap ready

A platform moving assets through regulated workflows earns trust through documentation an auditor can follow and enforcement the platform itself applies. Enterprise security reviewers and external auditors are not looking for assurances. They want evidence: a behavior they can trace, a boundary they can verify, a control that does not depend on a caller getting it right. These four questions now have answers in the enforced API layer.

Authentication and admin authorization

The authentication model has two distinct layers a security reviewer should examine separately.

The outer layer, session resolution, decides whether the caller has authenticated at all. The platform resolves identity from either an interactive session cookie or an API key. It enforces read-only scopes on API-key sessions issued without write permission and rejects API keys entirely on endpoints that require interactive authentication. Neither path is guessable. Middleware checks the resolved principal against the declared endpoint policy before any handler logic runs.

The inner layer, authorization, decides whether the authenticated principal may perform the requested operation. Every endpoint touching user management, role assignment, or platform configuration carries a gate that fires before the handler runs. If the principal's role does not match, the platform returns a structured FORBIDDEN response. Reaching those endpoints without the gate is not possible.

A step-up layer checks whether the principal re-authenticated within a defined freshness window. A session authenticated hours ago and since gone stale cannot execute high-impact operations without a fresh credential challenge. That check runs in the same middleware pipeline; the pipeline offers no bypass. The window is 15 minutes. Structured error responses identify which gate rejected the call and why, giving automated controls a precise signal rather than an opaque failure.

The platform wires multi-factor authentication into the wallet-verification path through an OIDC-backed MFA flow. Wallet operations require proof of identity beyond the session credential itself. Verification middleware resolves the MFA outcome before allowing the on-chain operation to proceed.

Key material and secret management

Key material is where most platforms are loudest in marketing copy and quietest in documentation. In 3.0 we reversed that. Every key and credential the platform uses, including custody API keys, paymaster credentials, and signer material, carries documented scope, permitted operations, and the boundary it must not cross. We do not assert properties. The admin operating model reference names each one explicitly so an operator or external auditor can verify them without reading source code.

The zero-on-disk guarantee works through a secrets middleware layer that runs once per request context and never earlier. At service startup, a lazy singleton loader initializes the first time a request context needs it and talks to whichever secrets backend the deployment configures: a cloud key management service, a self-hosted vault, or a local provider for non-production environments. The loader defers initialization until first access, so a service starting with a missing or misconfigured secrets backend fails immediately on first use rather than silently continuing with an empty credential set. Once resolved, the provider is injected into the request context via middleware and consumed there. Raw values never travel through environment variables, do not persist across deployments, and do not appear in log output. A SecretsDestroyedError is raised if a consumer attempts to reach a provider that has been torn down, making lifecycle errors auditable rather than silent.

Custody API-key credentials are documented per sponsored flow. The scope of each key, the operations it authorizes, and the boundary it must not cross are stated explicitly. A key issued for paymaster operations cannot authorize custody withdrawals, and vice versa. Scope boundaries are enforced before any outbound call is made. Key rotation propagates on the next service startup cycle: update the value in your secrets manager, restart the service, and the new value resolves without any change to the deployment artifact.

Role boundaries

The role model has two distinct planes a security reviewer should examine separately.

The first is the platform access plane. A principal is either a platform administrator or they are not. Platform administration covers user management, role assignment, integration configuration, and system settings. It grants no rights over assets, transfers, or compliance decisions. Those belong entirely to the second plane.

The second plane is the on-chain authorization model: asset-scoped and fine-grained. Roles here, covering supply management, token management, compliance management, identity management, custody, funds management, auditing, governance, and several others, resolve per executor wallet against the access-control state of the specific instrument being acted on. A wallet holding the token-manager role on one instrument does not automatically hold it on another. Promoting a wallet to compliance-manager does not grant supply-management rights. These are independent grants, not labels on a shared permission set.

Token permissions live in a single source of truth in the API contract package and every middleware and route consumer imports from there. A role definition changed in one place propagates consistently across every enforcement point, with no separate definition a deployment might diverge from.

Account-abstraction paymaster role boundaries are documented per sponsored flow. Signer access is scoped to the specific on-chain operations each signer is authorized for, and the boundaries are described in the admin operating model reference.

The four domains below are mutually exclusive by design. Collapsing them, for example letting a single principal span administration and asset operations, is a common gap DALP explicitly closes. Each boundary is enforced at the API layer, not negotiated at deploy time.

Deployment: image supply chain, network isolation, and self-hosting

Enterprise security reviews ask three things about deployment: whether the network traffic is constrained to known services, whether the image supply chain is controllable, and where the self-hosting boundary sits. All three are addressed at the Helm chart layer.

Each service pod runs under a security context that prohibits privilege escalation and drops capabilities not required for operation. The chart templates declare those constraints rather than relying on cluster-level defaults. A deployment override does not silently remove controls because the chart itself carries the hardened baseline.

NetworkPolicy templates ship with every service and restrict ingress and egress to declared selectors. A compromised service cannot freely reach other services in the cluster. The health port on the Workflow Engine, for example, accepts connections only from the designated cleanup job, not from arbitrary in-cluster pods. Policies default to disabled to preserve compatibility with clusters that do not enforce NetworkPolicy, but they are documented, tested against the expected traffic shape, and recommended for any production deployment.

The image pull surface gates through a single global registry override. Setting one Helm value, global.imageRegistry, redirects all first-party image pulls to an internal mirror, so air-gapped or private-registry deployments require no per-chart edits and no forked values tree. Ingress supports restriction to a CIDR allowlist at the load-balancer layer. Durable workflow snapshot-store credentials read from the secrets manager rather than from plaintext values.

Helm chart composition, RPC routing, the self-hosting boundary, and what DALP manages versus what your infrastructure team owns are documented so a deployment review does not need to infer topology from configuration values.

Deploy into air-gapped and private-registry environments

A regulated institution rarely pulls container images from the public internet. DALP 3.0 routes its entire image-pull surface through a single global registry override. An air-gapped or private-registry deployment redirects every first-party image to an internal mirror with one Helm setting: no per-chart edits, no fork to maintain. Two further controls tighten the boundary: ingress can be restricted to a source-CIDR allowlist at the load balancer, and the durable-workflow snapshot store reads object-storage credentials from the secrets manager instead of from plaintext values.

Together, these changes mean an auditor reviewing a DALP 3.0 deployment can work from documentation rather than source exploration. Every load-bearing property name is documented and every required secret path is named in the operating model reference.

---

All changes in this area are additive enforcement-only. Existing sessions, keys, and role assignments carry forward. The new role boundaries do not remove previously granted access. They add enforcement at the API layer for operations that were previously unguarded.

Set up admin operating model →