Use Case: Identity
Service account abuse detection
The CI pipeline service account authenticated from a residential IP in Romania at 3 AM and called iam:ListUsers for the first time in its 2-year history. ManySignal had the triage package ready before the pipeline ran again.
The credential nobody was watching
Service accounts are systematically under-monitored. They don't have human owners, they don't get offboarded when people leave, and they often accumulate permissions well beyond what their original automation task requires. An attacker who obtains a service account credential — from a leaked secret, a compromised build environment, or a misconfigured CI/CD pipeline — can operate in the environment using that account for months without triggering a single alert, because nobody built detection logic for accounts that weren't supposed to be used by humans.
rule: service_account_interactive_use
type: behavioral_baseline
sources:
- aws_cloudtrail
- gcp_admin_activity
- okta_system_log (service_app_tokens)
trigger:
- condition: |
account.type == "service_account"
AND (
auth_source.ip NOT IN account.known_server_ips
OR api_calls.contains(human_recon_patterns)
OR auth_method == "interactive" OR auth_method == "console"
OR api_call NOT IN account.historical_api_calls(90d)
)
enrichments:
- account_catalog: service_account_inventory
- permission_delta: actual_vs_granted_permissions
- owner_contact: hr_system, cmdb
mitre: T1078.004 (Valid Accounts: Cloud Accounts)MITRE ATT&CK mapping
Service account abuse FAQ
What makes service account abuse hard to detect with traditional tools?
Service accounts are designed to be non-interactive, so there's no behavioral baseline for 'normal human activity' to compare against. Traditional UEBA tools are human-user focused. ManySignal builds separate behavioral models for service accounts based on their API call patterns, IP addresses, and call timing — detecting deviations from their automation baseline rather than a human baseline.
Does ManySignal catalog service accounts automatically?
Yes. ManySignal discovers service accounts by analyzing authentication patterns in IdP and cloud audit logs. Accounts that authenticate only programmatically, on regular schedules, from known server IPs are classified as service accounts. This catalog is continuously updated and exposed in the identity graph.
What's the highest risk service account behavior?
Interactive login (a service account used from a browser or CLI by a human), unexpected IP origin (service account authenticating from a residential IP rather than its server range), and permission creep (service account accessing resources it has never accessed before). Any of these fires a high-confidence alert.
Can ManySignal help right-size service account permissions?
Yes. ManySignal tracks the actual API calls made by each service account against its granted permissions. Unused permissions — those granted but never called in 90 days — appear in the identity posture report with a recommendation to revoke. This is the foundation for least-privilege enforcement.
Build behavioral baselines for every non-human identity
Service account catalog, behavioral deviation detection, and least-privilege recommendations — all connected.