Unexpected Setting Changed: How to Find Who Changed It

TL;DR — If you can see a setting you did not change, the most common causes are: another user with access changed it, an automation tool overwrote it, or a connected integration synced it back. Start with the activity/audit log in your provider's dashboard and the list of users/API tokens; those two checks usually tell you whether this was a normal change, a sync loop, or a security issue. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and you open your dashboard to update one small thing. Instead, you notice a setting is already different: a DNS record points somewhere else, a feature flag is enabled, an email forwarding rule exists, or MFA (multi-factor authentication) was turned off on an account you manage. Nobody told you about a change, and now you need to answer two questions quickly: was this expected, and is it still happening? You do not want to blindly flip it back if some automation will just change it again five minutes later.

Symptoms

• You see a setting value you did not choose in the dashboard or admin panel.
• The UI shows recent changes such as:

  Updated 2 hours ago
  Last modified by API
  Changed by unknown user
  Synced from integration
  

• You notice related side effects, for example:
  • website starts loading from the wrong server after a DNS change
  • users report login behavior changed after an auth setting changed
  • emails start forwarding unexpectedly after mailbox rules appear
• Audit or activity logs contain entries like:

  settings.update
  config changed
  PATCH /settings 200
  actor=api-token
  actor=user@example.com
  source=terraform
  source=scim
  

• The setting changes back after you manually correct it.
• You receive security emails such as:

  New login detected
  API token created
  Password changed
  MFA disabled
  

Likely causes

Step-by-step diagnosis

1. Check the activity or audit log first

   • Dashboard path: in your provider's dashboard, look for Activity Log, Audit Log, or Recent Changes.
   • What to look for: an entry for the exact setting with an actor such as a user email, API token, or integration.
   • This is your problem if you see entries like:

     2026-10-01 14:12 settings.update actor=user@example.com
     2026-10-01 14:13 dns.record.update actor=api-token-123
     2026-10-01 14:15 auth.policy.update source=scim
     

   • If the actor is a person, jump to Fixes → Another authorized user changed it.
   • If the actor is an API token, CI job, or tool name, jump to Fixes → Automation or Infrastructure as Code overwrote it.
   • If the source is an integration or sync service, jump to Fixes → A connected integration synced the setting.

2. Check whether the setting flips back after you change it once

   • Change it back in the dashboard, then refresh after 1-5 minutes.
   • What output means this is your problem: the setting returns to the unexpected value without any human action.
   • If it flips back, that strongly points to automation or an integration. Jump to the matching fix section.

3. Review users, admins, and recent sign-ins

   • Dashboard path: Settings → Users, Team, Admins, or Security → Sessions.
   • What to look for: unknown users, recently invited admins, new sessions from unfamiliar locations, or MFA disabled.
   • This is your problem if you see:

     user added: unknown.contractor@example.com
     new session: IP not recognized
     MFA status: disabled
     API token created: today
     

   • If anything looks unfamiliar, jump to Fixes → Account compromise or stolen API token.

4. Check connected apps and sync tools

   • Dashboard path: Settings → Integrations, Connected Apps, Directory Sync, or SSO/SCIM (System for Cross-domain Identity Management, a user/account sync standard).
   • What to look for: apps with write access, sync jobs, provisioning tools, or webhooks that can update settings.
   • This is your problem if the changed field matches something managed by the integration and the audit log shows the same source.
   • Jump to Fixes → A connected integration synced the setting.

5. Search your code/config repository for the value

   • If you have repository access, search for the exact setting name or value.
   • Copy-paste command:

     git grep -nE 'example\.com|SETTING_NAME|feature_flag_name|record_value'
     

   • What output means this is your problem: the setting appears in Terraform, Ansible, Helm, app config, or CI files.
   • Example matches:

     infra/dns.tf:42 value = "203.0.113.10"
     .github/workflows/deploy.yml:18 FEATURE_X=true
     ansible/group_vars/prod.yml:7 auth_policy: relaxed
     

   • Jump to Fixes → Automation or Infrastructure as Code overwrote it.

6. Rule out a browser-side issue

   • Open the page in a private/incognito window or another browser.
   • What output means this is your problem: the unexpected setting only appears in one browser session, or changes happen only while a browser extension/admin helper is active.
   • Jump to Fixes → A saved browser profile, extension, or admin script changed it from your session.

Fixes

Another authorized user changed it

1. Confirm the actor in the audit log.
2. Contact the user and verify whether the change was intentional.
3. If the change was not approved, revert it in the dashboard.
4. Reduce unnecessary write access.
   • Dashboard path: Settings → Users/Team → select user → Role.
   • Change broad admin roles to narrower roles where possible.
5. If the setting is sensitive, require change review outside the tool (ticket, pull request, or written approval).

Verify it worked: the setting stays at the intended value and the audit log shows no new edits from that user.

Automation or Infrastructure as Code overwrote it

1. Find the source file or CI job.

   git grep -nE 'example\.com|SETTING_NAME|feature_flag_name|record_value'
   

2. Update the source of truth there, not only in the dashboard.
3. Commit and deploy/apply the change.

   git add .
   git commit -m "Fix unexpected setting value"
   git push
   

4. If Terraform is involved, review the planned change before applying.

   ⚠️ Terraform or similar tools can change live infrastructure and cause downtime if the plan includes unrelated resources. Review the plan output before applying.

   terraform plan
   terraform apply
   

5. If you need an emergency stop, disable the scheduled job or pipeline that keeps writing the old value, then correct the setting.

Verify it worked: after the next scheduled run or deploy, the setting remains correct and no new audit entries show the old automation actor.

A connected integration synced the setting

1. Identify the integration from the audit log or integration page.
2. Temporarily pause or disconnect the integration if it is safe to do so.

   ⚠️ Pausing directory sync, identity sync, or mailbox sync can stop legitimate user/account updates. Do this during a quiet period if possible.

3. Update the setting in the upstream system the integration reads from.
   • Example: if a directory sync keeps restoring a user policy, change it in your identity provider, not only in the app.
4. Re-enable the integration and run a manual sync if your provider offers one.
5. If the integration should not have write access, remove or narrow its permissions.

Verify it worked: a manual sync completes and the setting does not revert.

A saved browser profile, extension, or admin script changed it from your session

1. Open the page in a private/incognito window.
2. Disable browser extensions one by one, especially password managers, admin helpers, autofill tools, and userscript managers.
3. If you use saved form-fill data, clear it for that site.
4. Retry the change in a clean browser session.
5. If your team uses admin scripts or bookmarklets, stop using them until reviewed.

Verify it worked: the setting displays correctly in a clean browser and no unwanted changes happen while editing.

Account compromise or stolen API token

1. Immediately revoke suspicious sessions and tokens.
   • Dashboard path: Security → Sessions → Revoke, API Tokens/Access Keys → Delete or Rotate.
2. Reset the affected account password and re-enable MFA.
3. Review recent changes and revert unauthorized ones.
4. Check for persistence:
   • new users/admins
   • forwarding rules
   • webhooks
   • SSH keys or deploy keys
   • backup API tokens
5. If email or identity settings were changed, review them carefully before restoring service.
6. If the account has access to production systems, rotate related secrets.

   # Example only if you manage app env vars through a CLI
   # Replace OLD_SECRET with a new generated value in your secret manager or dashboard
   

Verify it worked: all unknown sessions/tokens are gone, MFA is enabled, and the audit log shows no new changes from suspicious actors.

Prevention

1. Turn on audit log retention and alerts for sensitive settings

   • In your provider's dashboard, enable alerts for events like:

     MFA disabled
     API token created
     admin role granted
     DNS record changed
     forwarding rule created
     

   • Send alerts to a shared mailbox or chat channel, not one person's inbox.

2. Reduce write access and separate admin roles

   • Review Settings → Users/Team monthly.
   • Keep only a small number of full admins.
   • Use read-only or limited roles for routine work.

3. Move important settings into version-controlled config where possible

   • Example Terraform snippet:

     resource "example_setting" "feature_x" {
       name  = "feature_x"
       value = "disabled"
     }
     

   • Require pull request review before changes are applied.

4. Add CI checks that fail on unexpected config drift

   • Example GitHub Actions step:

     - name: Terraform plan
       run: terraform plan -detailed-exitcode
     

   • Alert when drift appears instead of silently overwriting dashboard changes.

5. Review and rotate API tokens on a schedule

   • Keep a simple inventory with owner, purpose, and last used date.
   • Delete tokens with no clear owner or no recent use.

6. Document the source of truth for each sensitive setting

   • Keep a short table in your internal docs:

     DNS records -> DNS provider dashboard / Terraform
     SSO policy -> Identity provider
     App feature flags -> App admin panel
     Mail forwarding -> Mail admin console
     

   • This prevents the common mistake of changing a downstream copy that will just be synced back.

---

This article was written by an AI system and published pending human review. Verify anything you intend to act on.