Assemble agent · Use case · Authentication

Turn a bank’s security audit into enforced policy

Cirrus Cash Flow, a fintech startup, was acquired by Cumulus Global Bank and handed a bank-grade authentication audit. The Assemble agent turned the findings into enforced org configuration: password policy, lockouts, login restrictions, connected-app control, a trusted corporate network. 16 minutes 51 seconds of wall clock against the ~1 hr 45 min Trailhead estimate, and every acceptance check passed against the live org.

0:00 Running
Send a follow-up…
01

What this does

Cumulus Global Bank acquired Cirrus Cash Flow and put the startup’s Salesforce org through a full security audit. The findings became hard requirements: passwords of at least 12 characters with alpha, numeric, and special characters, 3 login attempts before a 30-minute lockout, one password reset per 24 hours, obscured security answers, and a 15-character, full-complexity floor for System Administrators.

The Assemble agent inspected the org first and found it still on stock defaults: 8-character minimums, plain alpha-numeric complexity, 10 attempts before a 15-minute lockout. It then deployed the entire program: org-wide SecuritySettings, a stricter admin profile policy, login IP ranges (corporate 13.108.0.0, VPN 22.0.0.1–22.0.255.0) with Mon–Fri 8 AM–5 PM hours for Call Center agents, connected apps locked to admin approval with Salesforce for iOS reserved for Inside Sales, and the corporate network trusted for device activation.

Everything shipped through the org’s own change surfaces: Metadata API deploys staged from a pre-change retrieve, and the classic Setup UI where no API name would resolve. All 4 acceptance checks passed against the final org state.

02

How it works

Salesforce MDMetadata API TLTooling API UISetup UI
  1. 1Read the audit. The brief resolves into four verifiable requirements: password policy, login requirements and limits, connected-app access, trusted IPs.
  2. 2Inspect before touching. Org describe, Tooling reads of SecuritySettings, and a Metadata API retrieve that doubles as the revert snapshot.
  3. 3Stage and approve. One deploy carries settings, both custom profiles, and profile password policies. rollbackOnError=true means nothing lands partially, and the staged change is approved before deployment.
  4. 4Deploy and recover. The first deploy fails three ways. The Assemble agent probes the Complexity enum with checkOnly deploys, converts login hours to minutes, and replays the 587-field Setup form for the admin policy no metadata name could reach.
  5. 5Verify from the org’s own pages. Security settings, profile pages, and Network Access are re-read after deploy. The new values match the audit line by line.
  6. 6Sign off. The acceptance checks return PASS on all four requirements.

Same shape a senior Salesforce security consultant would use: snapshot first, one reviewable change set, verification against the org itself. An afternoon of work compressed into seventeen minutes, with a revert path recorded for every change.

03

Outcomes you can verify

The claims on this page are checkable. Every before/after value comes from the org’s own APIs: the 8 → 12 minimum, TenAttempts → ThreeAttempts, FifteenMinutes → ThirtyMinutes, obscureSecretAnswer: false → true. The final state was verified by acceptance checks against the live org, not self-reported.

The change ledger above records all 12 persistent org changes with revert paths: redeployable pre-change metadata for every deployed file, a DELETE for the trusted-IP record, and the saved Setup form for the admin policy.

Duration
16:51
wall clock, one recorded run
Trailhead estimate
~1 hr 45 min
for the same work by hand
Speed-up
6.2×
against the Trailhead estimate
Steps
112
real API calls against the org
Checks
4/4
PASS, run against the live org
Org changes
12
all reversible, revert paths recorded
before/after policy snapshot deploy payloads 0Afbm00000YUSuX, 0Afbm00000YUTYr verification page reads acceptance-checks.csv revert paths ×12 evidence/org-inspection.md