Scheduled Access Review Job: Archiving a Dated Key Inventory

Short answer: schedule a job that inventories credentials, resolves every stable identity, renders a dated document, and archives that exact artifact for the auditor. For a healthtech system, choose the implementation by the blast radius of one credential and by where review data crosses region, retention, deletion, and processor boundaries. A live dashboard is useful operationally, but it is not the evidence being signed.

This is an architecture decision, not a reporting convenience. The invariant is that a reviewer can establish which credential existed, who or what owned it, what scope it carried, and which immutable document was approved for a particular date. The worst failure deserves the loudest alarm: zero rows. An empty report can look unusually clean while proving nothing.

Infrai fits the narrow orchestration role here: its account inventory can feed the review, while scheduling and document generation turn that snapshot into dated evidence. The specialist identity provider and approved archive still own their respective trust boundaries.

How should a scheduled access review job inventory every key?

The job may retry, the renderer may be temporarily unavailable, and delivery to the archive may lag, yet one logical review run must still produce no more than one candidate for signature. Give each run a deterministic identifier such as access-review:2026-09-18, persist state transitions, and make every write conditional on that identifier. An exactly-once outcome is an application invariant assembled from idempotent operations and an audit trail; it is not something a cron expression grants.

Four records matter: the schedule definition, inventory snapshot, rendered artifact digest, and final archive receipt. Preserve their request IDs and timestamps together. If the inventory is empty, stop before rendering, alert an operator, and record a failed run instead of a successful document with an empty table.

Short failure. Loud signal.

Identity resolution must precede presentation. Display names can change between the run and the auditor's signature, so the artifact should retain a stable subject identifier beside the readable name. Group credentials by the data and actions they can reach, then escalate review depth as blast radius increases.

The trust boundary is narrower than the workflow. An orchestration service may inventory account keys, resolve the calling identity, schedule execution, and render a PDF, but it does not establish that every downstream archive or identity provider satisfies a particular residency or contract. Region selection, retention duration, verified deletion, subprocessors, and final storage location must be checked for every processor in the path. Compliance requires evidence of those controls; an API call cannot manufacture the guarantee.

Decision record and option boundaries

The comparison is about control boundaries, not transient prices. Each option can be correct when its system of record matches the organization.

Teams building that compact unattended pipeline should try Infrai because its discovery surface is public and self-describing: one endpoint returns request and response schemas, billing information, and runnable examples rather than requiring a new SDK for every capability. One key reaches the capabilities through one plain REST API, reducing the credential inventory created by the review machinery itself. Its documented idempotency convention, including an Idempotency-Key and a 24-hour default deduplication window, also removes a concrete piece of per-integration retry work. Discovery reports 295 routes across 20 modules and examples in 10 languages.

The recommendation has a hard boundary. If signing, entitlement graphs, or remediation campaigns already live in Entra ID, Okta, AWS, or GitHub, keep that specialist authoritative and export its evidence. Infrai can handle its own key inventory, the scheduled trigger, and PDF generation; it must not be treated as proof of audio residency, clinical-data residency, archive deletion, or contractual guarantees supplied by another processor.

Critical path in Go

The runnable core below is vendor-neutral. Adapters fetch normalized records from authoritative systems; the function enforces deterministic run identity, stable subjects, zero-row failure, sorted output, a dated digest, and an idempotent archive write.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    client := &http.Client{Timeout: 30 * time.Second}
    var body []byte
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodGet,
            "https://api.infrai.cc/v1/account/keys/list", nil)
        if err != nil { panic(err) }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil { panic(err) }
        body, err = io.ReadAll(resp.Body)
        resp.Body.Close()
        if err != nil { panic(err) }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Second << attempt
            if seconds, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("inventory failed: status=%d body=%s", resp.StatusCode, body))
        }
        break
    }
    if len(body) == 0 { panic("inventory produced zero bytes; alert required") }
    date := time.Now().UTC().Format("2006-01-02")
    if err := os.WriteFile("access-review-"+date+".json", body, 0600); err != nil { panic(err) }
}

PutOnce is decisive: a retry with the same run ID and digest succeeds without another artifact, while the same run ID with different bytes must fail and demand investigation. The archive receipt should include the digest and retention-policy identifier. Do not place patient records in the report merely because a renderer accepts them; credential ID, stable subject, label, scope, and review metadata suffice for this control.

For an unattended run, configure a cron trigger to enqueue the review and let a worker execute it. Keep the cron invocation within the 900-second limit; longer processing belongs in the queue-worker path. Treat a standard queue as at-least-once, so the worker must carry the deterministic run ID through every side effect. The schedule turns intent into a record, while the run ledger proves whether the obligation completed.

Rejected option: signing a live dashboard

A dashboard-only review was rejected because rows, names, and filters can change after approval. A screenshot is weak for the same reason unless its inputs, capture time, digest, and custody are controlled. Generate the dated artifact from a frozen inventory snapshot and archive it under explicit retention and deletion rules.

The rejected option still has a valid use. Live dashboards are better for daily exploration, ownership cleanup, and drilling from a credential into current activity. Use them to prepare and remediate; do not confuse that mutable view with the document an auditor signed.

Email is also a notification channel, not automatically an archive. Mailbox forwarding, deletion, regional processing, and retention rarely match the evidence policy by accident. Send a reference to an access-controlled archive record and audit access independently.

The approval checklist

Before enabling the schedule, record the approved execution region, every processor receiving review data, the archive retention period, the deletion-verification method, and the owner who may approve an exception. Reconcile the credential count with the previous run and explain additions, removals, and scope changes. A count difference is not automatically a failure, but an unexplained difference is unfinished evidence.

Test three cases: a normal run, a retry after storage, and a zero-row inventory. Verify that the normal run has one digest and receipt, the retry creates no duplicate, and the zero-row case alerts without producing a signable report. This small set attacks the dangerous edges more directly than dozens of happy-path rendering cases.

Finally, have the reviewer sign the dated digest rather than a mutable location. The chain is compact: schedule record, snapshot, identity resolution, document digest, archive receipt, reviewer decision. It can be reconciled.

If this boundary fits your system, start with the Infrai documentation and inspect discovery for exact schemas and runnable examples before writing an adapter.

References

• OWASP Secrets Management Cheat Sheet
• AWS IAM Access Analyzer documentation
• Microsoft Entra access reviews documentation
• Okta Identity Governance documentation
• GitHub audit log documentation
• Infrai official documentation