Skip to main content
Wildo.ai Coming soon

Audit trail

Record when deployed sign-in rules change

Authentication rules authored in configuration deserve the same visibility as settings changed through a screen. Wildo records the baseline and changes to the deployed authentication posture, including affected user types and before-and-after values. Changes to the application audit-reading policy are recorded too.

A deployed authentication-policy change from optional to required MFA produces a policy record.

Record when deployed access rules change

Authentication rules authored in configuration deserve the same visibility as settings changed through a screen. Wildo records the baseline and changes to the deployed authentication posture, including affected user types and before-and-after values. Changes to the application audit-reading policy are recorded too.

Example — Record when authentication rules change

A deployment starts requiring a second factor for a user type. Its policy-change event puts that transition on the same timeline as sign-ins and administrative activity.

For engineers

Keep authentication methods, password policy, MFA, session and step-up settings in the user-type configuration. The authentication-serving startup path calls emitApplicationAuthPolicyChangeIfChanged; ordinary restarts with the same recorded posture do not create a new change.

The decisive portion compares the normalized snapshot with the latest policy event:

Selected source from audit-logs.backend.service.ts:

const currentSnapshot = buildApplicationAuthPolicySnapshot(data.userTypes);
const currentDigest = computeApplicationAuthPolicySnapshotDigest(currentSnapshot);
const prior = await this._readMostRecentApplicationAuthPolicyEvent();

const effectiveAuditReadAccess = data.auditApplicationReadAccess ?? AuditApplicationReadAccess.ROLE_BASED;
const previousAuditReadAccess = prior?.auditApplicationReadAccess?.after ?? null;
if (prior && prior.snapshotDigest === currentDigest && previousAuditReadAccess === effectiveAuditReadAccess) {
  // Unchanged since the last recorded snapshot — the trail already reflects it. Emit nothing.
  return;
}

const before = prior?.after ?? null;
const changedUserTypes = diffChangedApplicationAuthPolicyUserTypes(before, currentSnapshot);

await this.logApplicationAuthPolicyChanged({
  changedUserTypes,
  snapshotDigest: currentDigest,
  before,
  after: currentSnapshot,
  auditApplicationReadAccess: { before: previousAuditReadAccess, after: effectiveAuditReadAccess },
});

This selected implementation segment is inside the startup reconciliation method. A first observation records a baseline with no prior posture. A changed snapshot records before, after and changedUserTypes; the trail itself supplies the previous state. auditApplicationReadAccess separately records the effective audit-reader policy. An older event without that field is treated as an unknown baseline; omitted and explicit role-based configuration are equivalent.

Attribute a deployment honestly

The event is system-attributed because no signed-in person changed it through the product. Connect it to deployment and source history when reviewing who authored and released the change. Background hosts that do not serve authentication do not independently report the same boot policy.

This contract covers the normalized authentication posture, not every setting in the application. A resource-managed security setting follows its own change event; adding a new authored policy dimension should include it in the snapshot and its meaningful comparison.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.