AdminSecurity posture

Check stored Security posture events against current results

Copy page



Once a day, compare the attestation activities your SIEM has stored with the endpoint’s current results and decide which mismatches need a person.

The Activity Feed can deliver an activity late, and the endpoint keeps no history, so each source can show a change that the other does not. A daily comparison finds what your security information and event management (SIEM) store lacks. The feed does not record every change, so an attestation can be older than the feed’s first activity for its security control, and in rare cases a change has no activity at all. If you only report current results, you do not need the check.

You need a Compliance Access Key that covers the organization, with read:compliance_org_data for the endpoint and read:compliance_activities for the Activity Feed, or read:org_audit for both.

Run the check

Start each run after the day’s daily re-read completes, so that late activities are stored.

1. List the linked organizations with List organizations. You get the uuid of each.
2. Call the endpoint once for each organization. You get a 200, or a 404 on every run for an organization that the endpoint does not serve (see Security posture availability). A 404 means the organization is not read on this run. Keep a list of the organizations that return a 200, each with the evaluated_at of its first 200: your first run for the organization.
3. Set aside what the set-aside rules list.
4. Group the organization’s remaining stored attestation activities by security control and take the newest by created_at for each. You get one activity for each control, or none.
5. For each control that is left, find its row in the decision table. You get Match, Expected, or Look into.
6. Act on a Look into only when the next run that reads the organization shows it again; act on row 6 at once, and for rows 10 and 11 follow the placeholder rules instead. A run that did not read the organization neither counts nor restarts the wait.

Pace your calls and handle a 429 as 429 Too Many Requests describes; an organization whose calls fail after your retries is not read on this run, and a failed call is not a change.

Match the fields

Match an entry in the response to a stored activity with these fields.

Set aside what cannot be compared

Before you compare, set these aside.

Decide what each mismatch means

Each control that is left fits exactly one row.

Keep a placeholder where the two sources cannot be matched

A placeholder stands in for what one of the two sources lacks, and you keep it apart from your stored activities. For rows 10 and 11, read the feed again, and store and flag the placeholder only if nothing arrives within 15 days, the reach of the daily re-read. On your first run, store it at once, with no review.

Row 10 placeholders, keyed on the control and attested_at:

1. Read again from your newest stored activity for the control, or from attested_at inclusive if you have stored none; the 15 days count from attested_at. Build the placeholder from the entry, marked as having no activity; in the decision table, read it as an attested activity at that attested_at whose value pairs with its status, if any.
2. On each run that shows the attestation, update its status and state.
3. When an activity arrives whose created_at equals that attested_at, replace the placeholder with it.
4. When two runs in a row do not show the attestation, resolve the placeholder; flag that for review unless a newer stored activity or an unresolved row 10 mismatch for the control explains it, or both runs show descriptive.
5. A run that did not read the organization, or shows not_evaluated, neither counts toward nor restarts those two runs.
6. If the attestation shows again, reopen the same placeholder.

Row 9, 11, and 15 placeholders, keyed on the control alone:

7. For row 11, the 15 days count from the first run that shows the status. While the placeholder is unresolved, flag nothing more for that control; resolve it when a newer activity arrives, the attestation shows, or two runs in a row fit another row.
8. When a row 9 placeholder resolves because the attestation shows as failed_check_accepted_risk, flag it for review once: the risk is in effect.

Worked example

These two runs read the organization in the response sample on the Results reference; run 1 is your first run.

• Run 1, directory_sync_enabled. Stored: attested, accepted_risk, created at 2026-10-20T15:04:00.220114Z. Response: failed_check_accepted_risk, in_force, the same attested_at. Row 1: Match.
• Run 1, allowed_invite_domains. Stored: nothing. Response: descriptive, attestation null. Rule S4: set aside.
• Run 1, oauth_conditional_access. Stored: nothing. Response: an attestation with state review_due. Row 10: Look into. On your first run, store a placeholder at once, with no review.
• Run 2, oauth_conditional_access. Placeholder: the one from run 1. Response: the same. Row 5: Expected. Act once on review_due.

What the check cannot find

The daily check cannot find a missing activity for an attestation that the response leaves out on an automatic control. The response gives no sign of such an attestation, or only the status failed, which looks like the status the automatic check gives.

When an organization stops answering

An organization that has returned a 200 and then returns a 404 on several runs in a row needs a person, once. Ask someone with access to the Security posture page whether the page was turned off for the organization (see Security posture availability). If the page was not turned off, contact your Anthropic representative. The organization might have been deleted, or your access, Security posture, or the endpoint might have ended for the organization. Whatever the cause, resolve the organization’s placeholders and unresolved mismatches with no review, keep calling the organization, and reopen them if the organization returns a 200.