What CloudTrail-based alerting would you specifically set up for a narrowly-scoped static-key IAM user, and how would you tune it to avoid false positives?

Alert on anything outside the specific, expected pattern for this one narrow use case: API calls outside the small set of actions the user is actually supposed to perform (even though IAM already restricts what's possible, alerting on unexpected calls catches attempted misuse before it's blocked, and catches misconfiguration), source IP addresses outside the known, expected range the legitimate integration calls from, and any activity at unexpected times if the integration has a predictable schedule — tuned specifically to this one user's narrow, well-understood behavior pattern, which is exactly what makes tight tuning practical here in a way it wouldn't be for a broadly-used role.

Alert on unexpected API actions, even though IAM already blocks unauthorized ones: IAM's own permission boundary prevents actions outside the granted policy from succeeding at all, but CloudTrail still logs attempted calls, including denied ones — alerting on any attempt (successful or denied) to call an action outside the small, specific set this user is meant to perform is a useful earlier-warning signal, since a legitimate integration calling something unexpected suggests either a misconfiguration on the vendor's side or a compromised credential being probed for capability, worth investigating either way.

Alert on source IP outside the known expected range: since this is a narrowly-scoped integration (not a broad service reached from many places), the legitimate calling infrastructure's IP range is often knowable and stable — alerting on any activity from outside that expected range is a strong, low-false-positive signal specifically because the use case is narrow enough to have a genuinely predictable source.

Alert on activity outside expected timing, if the integration has a predictable schedule: if the integration only legitimately runs on a known schedule (a nightly batch sync, for instance), activity at other times is worth flagging — though this specific signal needs care, since a legitimate but irregular usage pattern would generate false positives; only apply this if the actual expected pattern is genuinely predictable.

Tuning to avoid false positives specifically leans on this being a narrow use case: this level of tight, specific alerting (exact expected actions, exact expected IP range) is practical here precisely because the user is narrowly scoped for one known integration — the same approach applied to a broadly-used role with many legitimate, varied call patterns would generate constant false positives, since there'd be no single "expected pattern" to alert against deviations from. The narrowness of the use case is what makes this level of precise alerting both possible and low-noise.

Route alerts to a specific, small audience who actually understands this integration: since the alert is specific to one narrow, well-understood use case, routing it to whoever actually owns/understands that integration (rather than a generic broad security alert channel) means whoever receives it has the context to quickly judge whether an anomaly is a real concern or an expected edge case (a legitimate one-time manual run outside the normal schedule, for instance) — reducing both response time and the risk of the alert being dismissed by someone without the context to properly evaluate it.

• Alert on API actions outside the narrow expected set, even though IAM already blocks unauthorized ones — CloudTrail's attempt logging catches probing/misconfiguration earlier.
• Source-IP-range alerting is a strong, low-false-positive signal specifically because a narrowly-scoped integration's legitimate calling infrastructure is usually knowable and stable.
• This level of tight alerting is practical precisely because the use case is narrow — the same approach would generate constant noise applied to a broadly-used role.
• Route alerts to whoever actually understands the specific integration, so anomalies get judged with the right context quickly.

• AWS: Logging IAM and AWS STS API calls with CloudTrail
• AWS: Amazon CloudWatch Alarms