Who is accountable when attackers exploit behaviour that blends into normal operations?

Why This Matters for Security Teams

When attacker activity blends into normal operations, the hardest failure is not just detection coverage. It is ownership. Security teams often assume that if an alert did not fire, the event was invisible, but in many cases the telemetry existed and the interpretation layer was weak. That creates a gap between access context, identity signals, and response decisions. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties monitoring, accountability, and control operation together rather than treating them as separate disciplines.

This matters even more with behaviour-based attacks, where adversaries use legitimate tools, valid accounts, and low-and-slow activity to avoid easy signatures. The question is not only whether the SOC can see the event, but whether identity owners have supplied enough context to tell normal from suspicious. That includes service accounts, delegated privileges, machine identities, and automation paths that are often outside classic user-centric monitoring. In practice, many security teams encounter accountability only after a suspicious session has already blended into routine admin work, rather than through intentional detection design.

How It Works in Practice

Accountability should be split by function, not blurred across a general security umbrella. The SOC owns detection logic, tuning, escalation criteria, and incident triage. Identity and access teams own the context that makes telemetry meaningful: which identities exist, what they are allowed to do, which credentials are active, and which paths are normal for a given account or workload. This is where the control relationship becomes operational, especially when the activity resembles techniques tracked in the MITRE ATT&CK Enterprise Matrix.

• Detection engineering should map alert logic to actual attacker behaviours, not just broad anomalies.
• IAM and PAM teams should maintain authoritative identity, privilege, and session context for humans and non-human identities.
• Control owners should verify that logs, baselines, and approval trails are usable by the SOC during investigation.
• Incident responders should know which team can validate whether an action was expected, delegated, or abused.

For behaviour that mimics administration, current guidance suggests combining identity telemetry with endpoint, SaaS, cloud, and application signals to reduce false confidence. If the organisation uses automation, AI assistants, or agentic workflows, then ownership also extends to tool permissions and action boundaries. Where relevant, threat intelligence from sources such as CISA cyber threat advisories can help validate whether the pattern is part of a known campaign or a local anomaly. These controls tend to break down when privileged activity is run from shared automation accounts with weak logging because attribution becomes ambiguous before analysts can reconstruct the session.

Common Variations and Edge Cases

Tighter behavioural controls often increase operational overhead, requiring organisations to balance detection confidence against analyst workload and business agility. That tradeoff becomes sharper in environments with cloud automation, delegated admin, or AI-driven workflows, where legitimate actions can look suspicious without context. There is no universal standard for this yet, but best practice is evolving toward explicit ownership of identity context, tool access, and detection tuning.

One edge case is when the “attacker” is actually abusing a trusted integration rather than a user session. In those cases, the accountable party may be the team that approved the integration, the team that manages the secret or token, and the team that monitors its use. Another edge case is AI-enabled operations, where adversarial behaviour can intersect with agentic tool use. The MITRE ATLAS adversarial AI threat matrix is relevant when model-driven or agent-driven actions are part of the attack path, while the Anthropic report on AI-orchestrated cyber espionage shows why AI-assisted abuse can collapse old assumptions about clear operator boundaries. In practice, accountability becomes hardest to assign in shared-service platforms where logs are incomplete, identities are recycled, and business owners treat service accounts as infrastructure rather than governed identities.

Related resources from NHI Mgmt Group

• Who should be accountable when attackers exploit chained weaknesses across software and identity?
• Who is accountable when a machine-speed exploit outruns normal remediation?
• Who is accountable when AI-assisted attackers exploit supplier environments?
• How should security teams build assume-breach operations when attackers can scale exploit generation?