Hardened for enterprise security review
Authentication, key material, roles, and deployment, hardened and documented for an enterprise security review in DALP 3.0.
Every platform that moves regulated assets faces four questions before it goes near production: who authenticates, where key material lives, who may do what, and how the thing deploys. In 3.0, you get documented, enforced answers to each one.
3.0 answers the four questions a security review always asks: authentication, key location, authorization, and deployment
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
- Configured storage and access
- 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 rule 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. If you are preparing a security review, examine each one separately.
The outer layer is session resolution: it 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 is authorization: it decides whether the authenticated principal may perform the requested operation. Every sensitive endpoint carries a gate that fires before the handler runs. A role mismatch returns a structured FORBIDDEN response. The API checks the declared role before running the operation.
A step-up layer checks whether the principal re-authenticated within a defined freshness window. Stale sessions cannot execute high-impact operations without a fresh credential challenge. That check runs in the same middleware pipeline, before the operation proceeds. The window is 15 minutes. Structured error responses identify which gate rejected the call and why, so automated controls receive a precise signal rather than an opaque failure. The session age check and the role check are independent: both must pass.
When your deployment configures OIDC-based wallet verification, a capability separate from OIDC sign-in with its own credentials on the identity provider entry, the platform wires multi-factor authentication into the wallet-verification path. A wallet operation then requires proof of identity beyond the session credential itself, and verification middleware resolves the MFA outcome before allowing the on-chain operation to proceed. Without that configuration, a wallet operation authenticates on the session credential alone.
Key material and secret management
The deployment's secret provider and custody configuration determine where credentials and signing keys live. External custody retains signing keys with the provider. Local signing uses platform-managed key material.
Keep provider credentials in the configured secret store and restrict access to the workloads that need them. Values and secrets explains configuration sources and rotation. Custody providers explains the signing boundary.
Role separation
The role model has two distinct planes. Examine each one separately when you conduct a security review.
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 have a single definition that every enforcement point in the platform reads from. Change a role's definition once, and it takes effect consistently everywhere that role is checked, with no separate copy a deployment might drift out of sync with.
Account-abstraction (a smart-contract wallet that submits a transaction and has a sponsor pay its gas, rather than paying from a private key directly) has its own paymaster roles, governing who may authorize that sponsorship for a given transaction. These are documented per sponsored flow in Advanced accounts. Signer access is scoped to the specific on-chain operations each signer is authorized for, as set out below.
The domains below require separate grants. A platform administration role does not itself grant an on-chain asset role. The same person can hold more than one grant, so review effective permissions when your operating policy requires separation of duties.
Controls who can access the platform, manage users, configure integrations, and alter system settings. Does not grant rights over asset or compliance operations.
Controls who can create, configure, and act on instruments. Separated from administration so a system operator cannot unilaterally issue or transfer assets.
Controls who can approve transfers, manage compliance rules, and act on identity records. Separated from both administration and asset operations.
Scoped to the specific on-chain operations each signer is authorized for. Paymaster and account-abstraction roles are separated per sponsored flow.
Deployment: image supply chain, network isolation, and self-hosting
Enterprise security reviews ask three things about deployment. Is network traffic constrained to known services? Is the image supply chain controllable? Where does the line sit between what DALP runs and what you self-host? The Helm chart layer addresses all three.
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. Review the rendered manifests and any security-context overrides before deployment.
NetworkPolicy templates ship with every service and restrict ingress and egress to declared selectors. When enabled and enforced by the cluster, these policies constrain matching traffic. 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, network and RPC configuration, the self-hosting split by topology, 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. You redirect every first-party image to your internal mirror with one Helm setting: no per-chart edits, no fork to maintain. Two further controls harden the deployment: you can restrict ingress 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.
Review the rendered security contexts, network policies, registry settings, and secret-provider access for the target deployment.
All changes in this area are additive enforcement-only. Existing sessions, keys, and role assignments carry forward. Existing grants still require review against the active endpoint policies. It adds enforcement at the API layer for operations that were previously unguarded.