For decades, security teams built walls. Firewalls, VPNs, network segmentation, DMZs. The logic was simple: keep the bad actors outside the perimeter, and everything inside stays safe.
That model worked when your servers lived in a data center, your employees sat in an office, and your applications ran on machines you could physically touch. It does not work anymore.
The perimeter dissolved the moment organizations moved workloads to the cloud, distributed teams across continents, and started granting API access to third-party services. The question is no longer "are you inside the network?" It is "who are you, and what are you doing?"
The network boundary is an illusion
Consider a typical AWS environment. Your applications run across multiple VPCs, possibly across multiple accounts. Lambda functions execute in ephemeral containers. ECS tasks spin up and terminate in seconds. S3 buckets serve data to clients worldwide.
None of these resources sit behind a traditional firewall in any meaningful sense. Access is controlled through IAM policies, resource policies, and service control policies. The "perimeter" is the identity layer itself.
- VPNs create a false sense of security. Once an attacker is on the VPN, they move laterally with ease.
- Network segmentation helps, but cloud-native architectures are too dynamic for static network rules to keep pace.
- API-driven infrastructure means every service-to-service call is an identity decision, not a network decision.
- Zero trust architectures explicitly reject the notion that network location equals trust. Identity is the only consistent control plane.
The explosion of non-human identities
When security teams think about identity, they typically think about people. User accounts, SSO, MFA, access reviews. These are important, but they represent a shrinking fraction of the identity surface.
In most AWS environments, non-human identities outnumber human users by a factor of 10 or more. Every Lambda function has an execution role. Every ECS task assumes a role. Every CI/CD pipeline authenticates with service credentials.
These non-human identities operate continuously, often with broad permissions, and rarely receive the same scrutiny as human accounts. They do not use MFA. They do not go through annual access reviews. Many of them were created months or years ago and have never been audited.
- Service accounts for monitoring tools that have read access across every resource in the account.
- CI/CD pipeline roles with administrative privileges because "it was easier to set up that way."
- Lambda execution roles that can assume other roles, creating chains of privilege escalation.
- Third-party integrations using cross-account roles with overly broad trust policies.
AI agents are a new class of identity
The emergence of AI coding agents, autonomous workflow systems, and LLM-powered tools introduces a category of identity that did not exist two years ago. These are not traditional service accounts. They are autonomous actors making decisions about which API calls to make, which resources to access, and which roles to assume.
An AI agent running Claude Code might create IAM roles, modify security groups, or deploy infrastructure. A LangChain-based automation might read from databases, write to S3, and invoke other services. A Bedrock agent might access sensitive data as part of its reasoning process.
Existing security tools were not designed for this. IAM analyzers check permissions statically. They can tell you what an identity is allowed to do. They cannot tell you what it actually does, whether that behavior is normal, or whether it changed suddenly.
- AI agents make decisions at runtime, meaning their behavior is non-deterministic and cannot be predicted from permissions alone.
- They often operate under human user sessions or shared service roles, making them invisible to identity-level monitoring.
- The volume and velocity of their API calls can dwarf human activity, creating noise that masks anomalies.
- No standard exists for identifying AI agent activity in CloudTrail logs, though user-agent strings offer partial visibility.
What ITDR means and why it matters now
Identity Threat Detection and Response (ITDR) is the practice of monitoring identity behavior at runtime, detecting anomalies, and responding to threats in real time. It sits between IAM (which defines what identities can do) and SIEM (which aggregates logs after the fact).
ITDR is not about permissions. It is about behavior. A service account with read-only access to a database is not a risk based on its permissions. But if that account suddenly starts querying tables it has never touched before, at 3 AM, from an IP address in a country where your organization does not operate, that is a threat signal.
- Behavioral baselines establish what "normal" looks like for each identity, whether human, service account, or AI agent.
- Anomaly detection catches deviations from those baselines, such as unusual API calls, unexpected role assumptions, or access to new resource types.
- Progressive response means the system can alert, recommend actions, or take automated action depending on the severity and confidence of the detection.
- Context enrichment connects raw CloudTrail events to meaningful narratives: not just "AssumeRole was called" but "this Lambda function assumed a role it has never used before, accessing a production database."
The gap in current tooling
Most organizations have invested in IAM hygiene tools, CSPM platforms, and SIEM solutions. These solve real problems, but they leave a critical gap.
IAM tools focus on posture: are permissions configured correctly? CSPM tools check configuration compliance. SIEMs ingest logs and run queries. None of them build behavioral models for each identity and detect runtime anomalies with the context needed for fast response.
This gap becomes dangerous as the identity surface expands. More non-human identities, more AI agents, more cross-account access patterns. Without behavioral monitoring, the attack surface grows faster than security teams can manually review.
Identity is the control plane
The shift from network security to identity security is not a trend. It is a structural change driven by how modern infrastructure works. Cloud APIs are identity-authenticated. Service-to-service communication is role-based. Even network controls in AWS (security groups, NACLs) are configured through IAM-authorized API calls.
When identity is the control plane for everything, monitoring identity behavior becomes the single highest-value security investment. Not just who has access, but who is using that access, how, when, and whether it matches what you expect.
The organizations that recognize this shift and invest in runtime identity monitoring will have a structural advantage in detecting breaches early, containing lateral movement, and maintaining operational trust in an increasingly automated world.