Keep DDF workflow credentials under customer control.
SentinelFlow provides supported credential-retrieval patterns for DDF workflows, helping keep secrets out of scripts, workflow files and ad hoc configuration.
Credentials remain managed in customer-approved stores. SentinelFlow retrieves the required secret material or token at runtime within the customer environment for use by the approved DDF connector. SentinelFlow is a supporting DDF capability, not a replacement for the customer’s existing secrets-management platform.
- ✓ Supports agreed runtime retrieval patterns for CyberArk, 1Password and Windows Credential Manager deployments
- ✓ Keeps credentials out of DDF workflow configuration where supported
- ✓ Retrieves secrets at runtime from within the customer environment
- ✓ Supports a consistent credential-handling pattern across DDF connectors
- ✓ DDF does not operate a hosted credential broker or secrets vault for workflow execution
Controlled workflows still need credentials. They should not become another unmanaged dependency.
Enterprise automation commonly needs authenticated access to platforms such as Planview, ServiceNow or Jira. The security question is not whether credentials exist, but how the workflow retrieves and uses them.
Hard-coded secrets
Passwords, tokens or client secrets embedded in scripts and configuration are difficult to govern safely.
One-off security patterns
Different workflows can end up retrieving credentials in different ways, making support and review harder.
Unnecessary credential movement
A locally executed workflow authenticates to approved target-system endpoints without sending credentials to a DDF-operated hosted credential broker.
Difficult operational support
A repeatable credential-retrieval pattern makes it easier to understand how a DDF workflow is intended to authenticate.
How SentinelFlow fits into a DDF workflow
SentinelFlow retrieves approved secret material or tokens at runtime from a customer-approved source. The relevant licensed DDF connector then authenticates directly with the target system, performs the approved operation and retains the associated run evidence.
1. Customer stores the secret
The credential remains in the approved customer-controlled credential store.
2. SentinelFlow retrieves approved material
At runtime, SentinelFlow retrieves the required secret material or token from the approved customer credential source using the supported deployment pattern.
3. The connector authenticates directly
FoliosFlow, ServiceFlow, JiraFlow or another licensed connector uses the retrieved material from within the customer environment to authenticate directly with the approved target-system endpoint.
4. The workflow runs and retains evidence
The surrounding DDF workflow performs the approved operation and retains its normal logs, outputs and failures.
Use the credential store you already operate
SentinelFlow is designed to work with supported customer-approved credential sources. It does not require DDF to become another secrets vault.
CyberArk
Supported runtime retrieval patterns for agreed DDF deployments using a customer-managed CyberArk environment and approved access model.
1Password
Supported runtime retrieval patterns for agreed DDF deployments using a customer-managed 1Password environment and approved access model.
Windows Credential Manager
A supported local credential-store pattern for agreed Windows-based DDF deployments using the approved execution identity.
The exact retrieval pattern depends on the customer environment, credential store, access model and connector workflow. Support should be confirmed against the intended deployment rather than assumed from the store name alone.
A credential-retrieval layer, not another secrets-management platform
SentinelFlow does
- Provide supported runtime credential-retrieval patterns
- Help keep secrets out of DDF workflow configuration
- Support local authentication by licensed DDF connectors
- Create a more consistent DDF credential-handling approach
SentinelFlow does not
- Replace CyberArk, 1Password or another customer secrets platform
- Require credentials to be stored in DDF infrastructure
- Remove the need for customer permissions, access policies or credential governance
- Turn unsupported target-system access into a supported DDF workflow
One security pattern across supported DDF workflows
SentinelFlow sits behind the licensed DDF connectors that need authenticated access. It is a supporting capability within the DDF platform rather than the starting point for most customer conversations.
FoliosFlow
Support FoliosFlow authentication by retrieving approved Planview credential material at runtime through the agreed SentinelFlow pattern.
ServiceFlow
Support the agreed ServiceNow authentication pattern without embedding credentials in workflow configuration.
JiraFlow and future connectors
Apply the same DDF credential-handling principle where the connector and deployment pattern support it.
Security remains a customer-controlled concern
SentinelFlow helps DDF fit into the customer’s security architecture. It does not bypass that architecture.
Customer-owned credentials
Secrets remain in customer-controlled stores and under customer access policies.
Local execution
Credential retrieval and connector execution occur from within the customer environment.
Supported deployment pattern
The retrieval method is agreed as part of the connector and customer deployment scope.
Workflow evidence
The surrounding DDF workflow retains normal run evidence. Credential values are not intended to form part of workflow configuration or run outputs.
How should your DDF workflow retrieve approved authentication material?
Talk to us about your credential store, access model and intended DDF workflow. We can confirm the supported SentinelFlow pattern as part of the deployment design.