Security Review Checklist for AI Workflow Tools

Password policy is the first line of defense for any platform. In DAVE, password complexity and expiration are configured at Admin, then Settings, then Access, then Passwords. All settings apply to every user on the tenant and are enforced on password creation, reset, and change.

• Password complexity is set to Strong or Enterprise. Strong requires 12 or more characters, mixed case, a number, and a symbol. Enterprise requires 16 or more characters, mixed case, a number, a symbol, and rejects common passwords. Basic (8 or more characters) and Standard (8 or more characters, mixed case, number) are available but insufficient for teams handling sensitive AI workflow data. None (no complexity requirement) is never appropriate for a production tenant.
  Where to check: Admin, then Settings, then Access, then Passwords, then Password Complexity dropdown.
• Force Change After Reset is enabled. This checkbox (default: checked) requires users to change their password immediately after an Admin resets it. Disabling it means a reset password set by an Admin could remain in use indefinitely.
  Where to check: Admin, then Settings, then Access, then Passwords, then Force Change After Reset checkbox.
• Password expiration policy is set. Options are: All passwords expire, All non-admin passwords expire, or No forced expiration. For most teams, All passwords expire with an Expiration Days value of 90 days or fewer is the appropriate setting. No forced expiration is acceptable only if MFA is mandatory for all users (see Area 2).
  Where to check: Admin, then Settings, then Access, then Passwords, then Password Expiration dropdown and Expiration Days slider (15 to 90 days).
• Rate limiting is enabled with a sensible threshold. The default is 3 failed login attempts before lockout, with a 5-minute lockout duration. Increase the lockout duration for higher-security environments. The maximum lockout duration is 60 minutes.
  Where to check: Admin, then Settings, then Access, then Login Security, then Rate Limiting section. Enable Rate Limiting toggle should be on. Max Login Attempts (1 to 20, default 3). Lockout Duration (1 to 60 minutes, default 5 minutes).
• CAPTCHA is configured if the tenant is exposed to automated login attempts. Four providers are supported: reCAPTCHA v2, reCAPTCHA v3, hCaptcha, and Cloudflare Turnstile. For reCAPTCHA v3, confirm the Minimum Score threshold is set (default 0.5; increase to 0.7 or higher for stricter filtering).
  Where to check: Admin, then Settings, then Access, then Login Security, then CAPTCHA section.

MFA is the single most effective control for preventing unauthorized account access. In DAVE, MFA is configured at Admin, then Settings, then Access, then 2FA. Eight MFA provider types are supported. The enforcement policy determines whether MFA is optional or mandatory for all users.

• MFA is enabled. The Enable MFA toggle must be on. If it is off, no MFA is enforced regardless of other settings.
  Where to check: Admin, then Settings, then Access, then 2FA, then Enable MFA toggle.
• Enforcement policy is set to Tenant-wide mandatory. Three options exist: Tenant-wide optional, Tenant-wide mandatory, and Per-user optional. Tenant-wide mandatory is the strongest posture. Per-user optional is acceptable only during a phased rollout with a defined completion date. Tenant-wide optional is not acceptable for a production tenant handling sensitive AI workflow data.
  Where to check: Admin, then Settings, then Access, then 2FA, then Enforcement Policy dropdown.
• Grace period is set to 14 days or fewer. The grace period (0 to 30 days) gives existing users time to enroll after MFA becomes mandatory. A grace period longer than 14 days leaves a significant window of unprotected access. Set it to 0 for new tenants where all users can be enrolled before launch.
  Where to check: Admin, then Settings, then Access, then 2FA, then Grace Period field.
• Trusted Device Duration is set to 30 days or fewer. The trusted device duration (0 to 90 days) controls how long a device remains trusted before re-verification is required. 90 days is too long for most security postures. 30 days is a reasonable default; 0 days requires MFA on every login.
  Where to check: Admin, then Settings, then Access, then 2FA, then Trusted Device Duration field.
• Backup Codes are enabled. Backup codes allow users to recover access if they lose their MFA device. Without backup codes, a lost MFA device requires Admin intervention to unlock the account. Enable backup codes and ensure users are instructed to store them securely.
  Where to check: Admin, then Settings, then Access, then 2FA, then Backup Codes toggle.
• At least one strong MFA provider is configured. Eight provider types are supported: Google Authenticator, Microsoft Authenticator, Authy, Duo Security, YubiKey, Email OTP, SMS OTP, and Custom. Hardware keys (YubiKey, FIDO2/WebAuthn) and TOTP apps (Google Authenticator, Microsoft Authenticator, Authy, Duo Security) are phishing-resistant. Email OTP and SMS OTP are weaker options and should be used only where stronger options are not available.
  Where to check: Admin, then Settings, then Access, then 2FA, then the provider cards.

Session controls limit the window of exposure if a session token is stolen or a user leaves a device unattended. In DAVE, session management is configured at Admin, then Settings, then Access, then Session Management. DAVE uses JWT-based authentication with refresh token rotation: each token refresh invalidates the previous refresh token, preventing replay attacks. Tokens are scoped to the tenant, so there is no cross-tenant token reuse.

• Session Expiration is enabled. The Enable Session Expiration toggle must be on. If it is off, sessions do not expire automatically.
  Where to check: Admin, then Settings, then Access, then Session Management, then Enable Session Expiration toggle.
• Session Timeout is set to 60 minutes or fewer. The default is 60 minutes. Options range from 5 to 1440 minutes. For teams handling sensitive AI workflow outputs or operating under SOC 2 or GDPR requirements, 30 minutes is a more appropriate default. 1440 minutes (24 hours) is not appropriate for a production security posture.
  Where to check: Admin, then Settings, then Access, then Session Management, then Session Timeout field.
• SSO/OIDC is configured if the organisation uses a central identity provider. Five SSO providers are supported: Google, Microsoft, GitHub, Okta, and Custom OIDC. Centralizing authentication through an SSO provider means MFA enforcement, session policy, and account deprovisioning are managed in one place. When a user is deprovisioned in the identity provider, their DAVE access is revoked at the next login attempt.
  Where to check: Admin, then Settings, then Access, then OAuth sub-tab.

The audit log is the primary evidence source for security investigations and compliance audits. In DAVE, audit log configuration is split across two locations: compliance standards are set at Admin, then Settings, then General, then System Parameters, then Audit Log, and the log itself is viewed at Admin, then Settings, then Audit Log tab. Only users with Admin role access (admin:* or audit:read permissions) can view the audit log.

• Standard audit logging is active. The Standard compliance level is always on and cannot be disabled. It captures all mutations (create, update, delete), authentication events, and system changes. Confirm by navigating to the Audit Log tab and verifying that recent events are present.
  Where to check: Admin, then Settings, then Audit Log tab. Events should be present for all recent user actions.
• SOC 2 compliance mode is enabled if the organisation operates under SOC 2 requirements. SOC 2 mode adds read-access logging for sensitive endpoints: Users, Roles, Secrets, API Clients, OAuth Providers, and Reports. It covers trust service criteria CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management). Without SOC 2 mode, reads of sensitive data are not logged.
  Where to check: Admin, then Settings, then General, then System Parameters, then Audit Log section, then SOC 2 checkbox.
• GDPR compliance mode is enabled if the organisation processes EU personal data. GDPR mode adds read-access logging for user data endpoints, covering the same sensitive endpoint list as SOC 2. It covers Articles 5, 15, 17, 30, and 33. Without GDPR mode, reads of user data are not logged.
  Where to check: Admin, then Settings, then General, then System Parameters, then Audit Log section, then GDPR checkbox.
• Compliance change events have been verified. Every change to compliance standards generates an automatic audit.compliance_changed event with a before/after snapshot. Filter the audit log for this event type to confirm the compliance standards were enabled at the expected time and by the expected actor.
  Where to check: Admin, then Settings, then Audit Log tab, then filter by event type audit.compliance_changed.
• Read-access logging is confirmed active. After enabling SOC 2 or GDPR mode, navigate to a sensitive endpoint (for example, Admin, then Settings, then Users and Roles) and check the Audit Log for a corresponding read event with complianceTriggered: true in the details.
  Where to check: Admin, then Settings, then Audit Log tab. Look for a read event with a blue SOC2 or purple GDPR compliance badge.
• Audit log export has been tested. Use the CSV export button to export a date-filtered sample of audit events and confirm the output is complete and correctly formatted for your compliance records. SOC 2 auditors typically need date-filtered exports covering the full audit observation period.
  Where to check: Admin, then Settings, then Audit Log tab, then set date range filter, then click the download button.

Retention policy controls how long workflow data, artifacts, and audit logs are kept before automatic, permanent deletion. In DAVE, retention is configured at Admin, then Settings, then General, then System Parameters, then Retention Policy. Options for each setting are: 30, 60, 90, 180, 365, or 730 days, or Forever. Cleanup runs automatically via a scheduled background task. Expired data is permanently deleted and cannot be recovered.

• Retain Audit Logs is set to at least 365 days. The default is 365 days. If SOC 2 is enabled, the recommended minimum is 2,555 days (7 years): DAVE displays a warning if retention is below this threshold. The maximum dropdown option is 730 days. For 7-year retention, set to Forever and manage archival manually, or export audit logs as CSV on a regular schedule.
  Where to check: Admin, then Settings, then General, then System Parameters, then Retention Policy, then Retain Audit Logs dropdown. If SOC 2 is enabled and retention is below 2,555 days, a warning is displayed.
• Retain Instances is set to match the team's operational review cycle. The default is 90 days. If the team reviews AI workflow outputs for quality assurance after completion, set this to at least 180 days to give reviewers a buffer beyond the review cycle.
  Where to check: Admin, then Settings, then General, then System Parameters, then Retention Policy, then Retain Instances dropdown.
• Retain Artifacts is set to match the team's compliance and quality requirements. The default is 90 days. Artifacts include files and outputs generated during workflow execution, including AI-generated content. If AI-generated outputs need to be available for compliance evidence or quality review, set this to at least 180 days.
  Where to check: Admin, then Settings, then General, then System Parameters, then Retention Policy, then Retain Artifacts dropdown.
• A retention reduction has not been made without a data export. Reducing any retention setting below its current value may cause existing data to be purged in the next cleanup cycle. Confirm that any required data has been exported before reducing retention. Cleanup is automatic and irreversible.
  Action: Before reducing any retention setting, export the relevant data (audit log CSV, workflow instance records) and store it in an external archive.

AI workflow platforms handle sensitive credentials: API keys for AI providers, OAuth client secrets, and other integration credentials. In DAVE, all credentials are stored in a per-tenant encrypted vault using AES-256-GCM authenticated encryption. Credential values are never returned through the API once stored: they are write-only from the moment of creation. This section confirms that credential handling is configured correctly and that no credentials are stored or transmitted insecurely.

• All AI provider credentials are stored in the DAVE credential vault, not in workflow definitions or agent prompts. Credentials stored in the vault are encrypted with AES-256-GCM and never returned via the API. Credentials embedded in workflow definitions or agent prompts are stored as plaintext in the workflow record and are visible to anyone with access to the workflow editor.
  Action: Review all workflow definitions and agent prompts for hardcoded API keys, tokens, or passwords. Move any found credentials to the credential vault via Admin, then API Management, then Providers.
• Credential access is limited to the minimum necessary set of users. Configuring AI providers and storing credentials requires the Admin role. Confirm that the Admin role is assigned only to users who genuinely need to configure provider credentials. Review the user list at Admin, then Settings, then Users and Roles.
  Where to check: Admin, then Settings, then Users and Roles. Review all users with the Admin role.
• MCP keys are per-user and per-assistant. MCP keys grant AI assistants (Claude Code, Claude Desktop, VS Code, JetBrains) access to the DAVE workspace. Each key should be tied to a specific user and a specific AI assistant. Shared keys make the audit trail ambiguous. Review the MCP Keys list and confirm no keys are shared across users or assistants.
  Where to check: Admin, then API Management, then MCP Keys section. Confirm each key has a descriptive name identifying the user and assistant.
• Unused or unrecognized MCP keys have been revoked. Review the MCP Keys list for keys with no recent last-used timestamp, keys with generic or unidentifiable names, and keys belonging to users who have left the team. Revoke any that cannot be attributed to an active user and active use case. Revocation takes effect within minutes.
  Where to check: Admin, then API Management, then MCP Keys section. Review the last-used timestamp and name for each key.

DAVE has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable database rows, so the six defaults may have been modified or supplemented with custom roles on your tenant. This section confirms that role assignments are current, minimal, and documented.

• The Admin role is assigned to the minimum necessary set of users. Admin is the only role that can access Settings, configure compliance standards, view the audit log, and manage users and roles. Every additional Admin is an additional attack surface. Review the Admin user list and remove the role from anyone who does not need it.
  Where to check: Admin, then Settings, then Users and Roles. Filter by Admin role.
• Every active user has the correct role for their function. Assign roles based on what each user needs to do, not on convenience. A user who only needs to complete workflow tasks needs the Use role, not the Create or Curate role. A user who only needs to view reports needs the Reporting role, not the Admin role.
  Where to check: Admin, then Settings, then Users and Roles. Review each user's role assignment against their job function.
• Departed users have been deprovisioned. Users who have left the team should have their accounts deactivated or deleted. An active account for a departed user is an uncontrolled access vector. Review the user list for accounts that have not logged in recently and confirm they belong to active team members.
  Where to check: Admin, then Settings, then Users and Roles. Sort by last login date and review inactive accounts.
• Role assignments have been reviewed in the last 90 days. Role assignments drift over time as team members change responsibilities. A quarterly review of all role assignments against current job functions is the minimum cadence for a team running AI workflows with sensitive data. Document the review date and any changes made.
  Action: Schedule a recurring calendar reminder for quarterly role review. Document the review in your internal admin log.
• Lockout events in the audit log have been reviewed. Failed login attempts and account lockout events are recorded in the audit log. A pattern of failed logins for a specific account may indicate a brute-force attempt or a compromised credential. Review the audit log for auth.login_failed events regularly.
  Where to check: Admin, then Settings, then Audit Log tab. Filter by event type auth.login_failed or similar authentication failure events.