Inforcer Audit Events — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Inforcer Audit Events (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Inforcer records an audit trail of activity and changes it observes. This skill covers searching that trail (auditEvents) and enumerating the event-type catalog you filter against. It is a read-only history surface — it tells you what happened and when, which is the evidence layer behind a drift or posture report.
Read api-patterns first for the gateway headers, the region requirement, the {success, message, errors, data} envelope, and continuationToken pagination. Audit searches commonly span many pages — paging to completion matters more here than almost anywhere else, because a partial page silently drops events from the window you think you searched.
record of what it observed, a much narrower feed than M365's. For sign-ins, inbox-rule creation, app consents, or admin operations in the tenant, use cipp-alerts (cipp_list_audit_logs).
history, not a finding. Use blumira-findings, huntress-incidents, or cipp-alerts.
whom*; the state itself is inforcer-baseline-alignment.
inforcer_audit_event_typesList the event-type catalog — the set of event types Inforcer can record. Returns the type identifiers/labels you use to filter a search.
inforcer_audit_event_types()Pull this first when you need to filter auditEvents by type: it tells you the valid type values rather than guessing. The catalog is also a useful map of what kinds of activity Inforcer tracks at all.
inforcer_audit_searchSearch the audit event history. Every filter is optional, and they are: event_types (an array of values from the catalog), date_from / date_to, page_size, and continuation_token.
inforcer_audit_search(
event_types=["<from the event-type catalog>"],
date_from="2024-02-01",
date_to="2024-02-29"
)Returns event objects describing what occurred, when, and (where the API exposes it) the actor and target, plus a continuation token for the next page.
There is no tenant filter. The search is account-wide across every managed tenant — the tool takes no tenant argument, unlike the rest of this plugin's surface. To answer "what changed on this tenant", filter by type and window, then attribute each returned event to a tenant from its own payload and discard the rest. Budget for that: a narrow per-tenant question still pulls the whole portfolio's events for the window, so keep windows tight and page to completion before you filter.
| Pattern | Why it matters |
|---|---|
| Change events that line up with a drift finding | Connects "the tenant drifted" to "here is the change that caused it" |
| Privileged-role or policy changes | Highest blast radius; worth corroborating against identity review |
| A burst of activity around an incident window | Helps reconstruct a timeline for post-incident review |
| No events where you expected some | May indicate a filter mismatch (wrong type or window) rather than genuine quiet |
types = inforcer_audit_event_types() # discover valid types
events = inforcer_audit_search(
event_types=[types[...]], # values from the catalog
date_from="2024-02-01", date_to="2024-02-29")
mine = [e for e in events if tenant_of(e) == "Acme"] # filter client-sideDiscover the event types first so your filter uses real values; an invalid type quietly returns nothing and looks like "no activity." Page continuation_token to completion before concluding the window is empty — and before filtering to a tenant, since the tenant you want may only appear on a later page.
When baseline-alignment shows a tenant has drifted, search the audit trail around the drift window and pick out the events belonging to that tenant to find the change(s) that produced it. Audit gives the narrative behind the alignment delta — useful in a report and in client conversations.
but you cannot create, edit, or delete audit events, and audit events are history — they don't let you undo or remediate anything.
auditEvents shape, the event-type catalog values, and the exact filter parameter names are illustrative and credited to royklo/InforcerCommunity. Confirm filter field names against the catalog on first use.
too-narrow window) than genuine silence — widen and re-check before reporting "no activity." The same goes for a tenant that vanishes from a client-side filter: confirm you paged the whole window first.
under-report a change window.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.