Who should be accountable for maintaining deception controls in an assumed-compromise model?

Why This Matters for Security Teams

Deception controls only work in an assumed-compromise model when someone is clearly accountable for keeping them believable, reachable, and instrumented. That responsibility usually lands with the security team that owns detection engineering and incident readiness, because deception is not a one-time deployment. It has to evolve alongside attacker behavior, identity paths, and cloud change. NHI Management Group’s 52 NHI Breaches Analysis shows how often identity misuse becomes the real breach path, not the initial lure.

In practice, the same control can fail if cloud, identity, and endpoint owners treat it as someone else’s problem. Deception nodes, honey credentials, canary tokens, and trap services must be validated against live telemetry, access paths, and attacker tradecraft. That is why mature programs align deception with guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls while also watching real-world abuse patterns such as the DeepSeek breach. In practice, many security teams discover weak deception ownership only after an attacker has already mapped the control plane and ignored the traps.

How It Works in Practice

Accountability should be operational, not symbolic. The security function usually owns the deception strategy, alert logic, and validation cadence. Cloud teams maintain the environment where decoys live, identity teams ensure the trap assets have realistic entitlements, and endpoint or platform teams verify that sensors, logging, and response paths work. The goal is not to scatter fake assets everywhere. It is to make deception a managed part of detection engineering and incident readiness.

A practical operating model usually includes:

• Named control owners for each deception type, such as honey secrets, decoy accounts, fake API endpoints, and canary data.
• Regular refresh cycles so indicators, labels, and access paths stay believable as infrastructure changes.
• Validation tests that confirm alerts fire, tickets route correctly, and responders know what to do.
• Rules for coordination with IAM, PAM, cloud, and endpoint teams when decoys need realistic permissions or telemetry.

Current guidance from the Anthropic report on AI-orchestrated cyber espionage and NIST’s control framework suggests deception should be measured like any other defensive capability: alert quality, dwell time impact, and response speed matter more than the number of traps deployed. That aligns with NHIMG’s broader NHI research, including the Ultimate Guide to NHIs — Why NHI Security Matters Now, which frames identity as an active attack surface rather than a static inventory item. These controls tend to break down when deception assets are not maintained in step with cloud automation, because stale traps become obvious to adversaries and stop generating trustworthy signals.

Common Variations and Edge Cases

Tighter deception governance often increases coordination overhead, requiring organisations to balance realism against operational burden. That tradeoff becomes more visible in fast-changing cloud environments, where a decoy that looks convincing today may be obviously stale next week. Best practice is evolving here: there is no universal standard for how many deception controls are enough, or which team must own each one in every operating model.

In smaller organisations, the security team may own almost everything, with cloud and identity teams acting as approvers. In larger programs, the ownership model often shifts toward shared service management, where platform teams manage the plumbing and security owns test criteria. For AI-enabled environments, deception may need to account for autonomous agents that enumerate, chain, and retry faster than human operators expect, which makes refresh cadence and telemetry quality more important than static placement. If the organization also runs high-volume secrets workflows, the concern documented in The State of Secrets in AppSec becomes relevant because exposed secrets can undermine deception credibility and create competing incidents at the same time.

The practical rule is simple: if nobody owns validation, deception becomes decoration. If nobody owns refresh, it becomes predictable. In mature programs, accountability stays with security, but operational reality is shared with the teams that control identity, cloud, and endpoints.

Related resources from NHI Mgmt Group

• Who should be accountable for access governance when enterprises use a partner to implement identity controls?
• Who is accountable when GenAI traffic is allowed to bypass policy controls and exposes sensitive data?
• Who should be accountable for secrets governance when developer productivity and security controls conflict?
• Who is accountable when AI security controls fail during a live event or proof of concept?