Trace an access decision

The auditors ask: „On October 14 at 21:10, Max Vermittler read contract data. From where, with which access, and which setting allowed it?“—or the other way round: „Why was Erika denied this morning?“

Four sources, linked through the person, the key, and the correlation ID:

1. Find the sign-in: SignInEvents with $filter=Person eq 'Max Vermittler' and At ge 2026-10-14T19:00:00Z and At lt 2026-10-14T20:00:00Z. The event names Method, KeyId, Origin, Country, NetName, Outcome, and for a denial Reason (for example deniedByCountry, outsideKeyNetworks, revoked). Rules names the rules the decision was based on, with identifier and version, including a rule an exception lifted (spared, with the exception's note); Signals names country and second factor (see Grounds of the decision).
2. Find the access: AuditEntries with the same person and time; Resource, Verb, and Status show what was read, Target the record (…/Vertraege(17) or …/Vertraege?$filter=Nr eq 'V-2026-17'), CorrelationId links to the sign-in event.
3. Access at the time: PersonalKeys('k…') shows the key's restrictions and term; ChangeLog with $filter=Entity eq 'PersonalKeys' and EntityKey eq 'k…' shows whether they changed since.

4. The rule today and then: explain-sign-in with the origin from step 1 names the rules with their version today. If it matches the version in the event, the rule still stands as it did at the sign-in. If it differs, ChangeLog shows who changed it since, when, and how: with Entity equal to save-sign-in-rule and the rule's identifier as EntityKey when it was saved with that command, otherwise with Entity in SignInRules, SignInRuleItems, and SignInRuleExceptions. The request to explain-sign-in:

   { "person": "Max Vermittler", "scope": "Data",
     "origins": [ { "name": "Oct 14 21:10", "address": "203.0.113.7" } ] }

5. The access rule today and then: AccessRule in the entry from step 2 names the rule that allowed the access, with its version (vertrieb-lesen@3f2a8c41d07b9e65). ClientRules shows the version today in RuleVersion; if it matches, the rule still stands as it did. Otherwise ChangeLog with Entity in ClientRules and ClientRuleItems shows who changed it since, when, and how. PersonRules, WindowsAccounts, and SqlLogins show who has the rule.

Result: Time, origin, access, record read, and the rules the decision was based on, with proof of who set these rules and when.

• Version, not content. The event keeps the rule's version, not its whole content; the content of an earlier version comes from the „before“ values in the change log.
• Older events from before the service kept the grounds have empty Rules and Signals; for them, the rule follows from the change log alone.
• AuditEntries reaches back as far as its retention. With an administration store, that is Gateway:AuditLog:Days (default 90 days); without one, the last 10,000 entries since start. For older access, read the audit stream in the service's logs, by CorrelationId or person.
• Entries from before the extension of the access log have Target and AccessRule empty; for them, the record and the rule follow only from the change log and the person's rules.
• Personal data. Target can contain key and filter values that relate to a person (see `Gateway:AuditLog`). Single events with address and person are visible only with the right sign-in-events; grant it deliberately, for example to the auditors (see check sign-in patterns).

• HTTP: administration—sign-in log
• Check sign-in patterns and origins
• Zero Trust and private devices