Assume compromise

A design principle that assumes an attacker may already be present in some part of the environment. Controls are then built to limit blast radius, detect movement, and preserve recovery options. In identity programmes, it means access and trust cannot rely on a perfectly protected internal network.

Expanded Definition

“Assume compromise” is a security design stance, not a single control. It treats any network segment, workload, credential, or agent as potentially exposed, then builds policy around containment, verification, and recovery. In NHI and agentic AI environments, that means service accounts, API keys, certificates, and tool-enabled agents are never trusted simply because they sit “inside” the enterprise.

The concept aligns closely with Zero Trust thinking and is reinforced by guidance such as NIST Zero Trust Architecture, but usage in the industry is still evolving when applied to autonomous agents and non-human identities. Some vendors frame it as detection-first, while others emphasize prevention and segmentation; in practice, both are needed. NHIMG research shows why: Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes implicit trust especially dangerous.

The most common misapplication is treating assume compromise as a slogan while leaving long-lived credentials, broad privileges, and flat network trust in place.

Examples and Use Cases

Implementing assume compromise rigorously often introduces more verification, tighter segmentation, and faster rotation requirements, requiring organisations to weigh operational convenience against reduced blast radius.

• A CI/CD pipeline is treated as potentially exposed, so build credentials are short-lived, scoped per job, and revoked immediately after use.
• A production API key is assumed to be at risk, so the service is isolated with least privilege and monitored for abnormal request patterns.
• An AI agent with tool access is placed behind explicit policy checks, so each action is evaluated rather than inherited from a trusted internal network.
• Service-account activity is compared against baseline behavior, using lessons from The 52 NHI breaches Report to prioritize detection where compromise is most likely to spread.
• Incident response plans assume stolen secrets may still be valid, so rotation, session invalidation, and rollback are prepared in advance.

That posture maps well to CISA Zero Trust Maturity Model guidance, which favors continuous verification over static trust.

Why It Matters in NHI Security

Assume compromise is central to NHI security because non-human identities often operate with broad, unattended, and persistent access. NHIMG data shows that 97% of NHIs carry excessive privileges, 71% are not rotated within recommended time frames, and only 5.7% of organisations have full visibility into their service accounts. Those conditions turn a single exposed secret into a platform-wide event. The practical consequence is that discovery of one leaked token may imply many more are at risk, especially when credentials are embedded in code, CI/CD systems, or third-party integrations. That is why the Ultimate Guide to NHIs is so strongly tied to lifecycle governance, visibility, and rotation discipline. The broader lesson is echoed in the Anthropic report on AI-orchestrated cyber espionage, which shows how automation can accelerate abuse once access is obtained.

Organisations typically encounter the full cost of assume compromise only after an identity incident, at which point containment, rotation, and forensic scoping become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do I respond to a confirmed NHI credential compromise?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• What did Shai Hulud 2.0 actually compromise?
• How do attackers turn stolen npm secrets into broader compromise?