agent overwrote existing saml config with defaults during rerun

Stop the agent overwriting your SAML config with defaults on rerun

TL;DR

Snapshot the live SAML configuration before any agent run touches it, and make the agent merge its changes into the existing config instead of writing a fresh one. A rerun that starts from defaults will clobber the certificate, entity ID, and ACS URLs that took hours to get right. Read before you write, always.

The problem

before rerun: entityID "urn:acme:sso", signing cert valid, ACS https://app.example.com/sso/acs
agent rerun: wrote default template config
sso logins: failing - signature validation errors everywhere

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent overwrote existing saml config with defaults during rerun"

Fix it

Step 1: Snapshot the live config before the agent runs

Export the full SAML configuration (entity ID, ACS URLs, signing certificate, attribute mappings, NameID format) to a versioned backup before any run that can write to it.

Expected: you have a restorable copy of the working config with a timestamp.

Step 2: Make the agent read before it writes

The agent's first config step must fetch the current live configuration. If it finds one, it merges its intended changes into it field by field instead of writing a template.

Expected: fields the agent did not intend to change keep their live values.

Step 3: Diff the intended write against the live config

Before applying, produce a diff of what will change. Require explicit approval for any change to the certificate, entity ID, or ACS URLs.

Expected: a rerun that only needed to tweak attribute mappings cannot silently replace the certificate.

Step 4: Restore from the snapshot if anything breaks

If logins fail after the run, restore the snapshot immediately, then investigate. Do not debug forward on a broken config.

Expected: SSO is back within minutes while you figure out what the agent changed.

Step 5: Prove the rerun is non-destructive in staging

Run the agent twice against a staging SSO integration with a customized config.

Expected: the second run changes nothing except its intended fields, and logins keep working.

When this applies

• SSO breaks right after an agent rerun or re-provisioning run
• The config shows default or template values where custom values used to be
• Signature, ACS, or entity ID errors appear that were not there before

When it doesn't

• The SAML config was wrong from the first setup (fix the initial config)
• The certificate expired on its own schedule (rotate it properly)
• A human edited the config by hand (check the audit log, not the agent)

Compatibility

Okta, Entra ID, Auth0, and OneLogin SAML app configs; any IdP where an agent manages app configuration via API.

Variant phrasings

agent reset sso config to defaults on reprovision

Same fix. The agent's "ensure configured" step must mean "ensure the desired fields match," not "write the template."

saml broke after onboarding agent reran setup

Check the config audit log for a full replace versus a patch. A full replace is the signature of this bug.

Why it happens

The agent's setup playbook was written for greenfield installs: write the config, done. On a rerun it follows the same playbook, and "write the config" means "write the whole template," which replaces every customized field with its default. The agent never noticed the config already existed because nobody told it to look.

Edge cases

• The IdP API distinguishes create from update; the agent must call update when the app exists
• Certificate rotation during a rerun: the new cert must be deployed to the SP too, not just the IdP
• Multi-environment configs: the staging snapshot must never be restored into production

If it still fails

• Capture the config audit log, the snapshot, and the post-run config before changing anything else.
• Reproduce with a staging app so you are not debugging production SSO.
• Check the IdP status page; platform incidents look exactly like config bugs.

Prevention

• Config snapshots run automatically before every agent write, kept for 30 days.
• Diffs of intended config changes are logged where the next operator will find them.
• Destructive fields (cert, entity ID, ACS) require human approval to change.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YKOAL0-D0BIP5zs8Z0ZKfw