Behavioural Detection with Automated Agents: The Future of Managed Detection & Response

Rule-based detection has a ceiling

Most detection engineering today follows the same pattern: an analyst learns about a technique, writes a rule to detect it, deploys it, and moves on to the next one. The result is a stack of detection rules that work well for known threats and miss almost everything else.

This model has a fundamental problem. Adversaries don’t need to invent new techniques — they just need to operate within the gaps between your rules. A compromised service account making API calls that are individually legitimate but collectively abnormal won’t trigger a rule written for a specific attack signature. Lateral movement that mirrors normal administrative workflow won’t fire an alert. Data exfiltration at a rate that blends into regular traffic patterns won’t hit a threshold.

The issue isn’t that detection teams are writing bad rules. It’s that the rule-based approach requires you to anticipate what an attacker will do before they do it. That’s a race that defenders consistently lose.

Alert fatigue compounds the problem. Organisations with mature detection programs often run hundreds or thousands of rules. The volume of alerts overwhelms triage capacity, and analysts start making trade-offs — tuning rules down, ignoring low-severity alerts, or triaging based on gut feel rather than evidence. The threats that slip through are precisely the ones designed to look unremarkable.

Behavioural profiling is environment-specific

Behavioural detection starts from a different premise. Instead of defining what bad looks like and hunting for it, you define what normal looks like and flag everything that deviates from it.

This sounds simple. In practice, it requires building a detailed model of how your specific environment operates — not a generic model trained on someone else’s telemetry.

What does normal look like? It depends entirely on context:

• Identity behaviour — which users authenticate at what times, from which locations, to which systems. What roles access what resources, and how frequently. When service accounts run, what APIs they call, and in what sequence.
• Network and API patterns — typical traffic volumes between services, expected API call patterns, normal data transfer rates. Baseline east-west traffic within your environment, not just north-south perimeter traffic.
• Workload behaviour — what processes run on which systems, expected resource utilisation, normal deployment cadence. Container orchestration patterns, serverless invocation frequency, scheduled job timing.
• Data access patterns — who accesses what data stores, how much data moves between systems, typical query patterns against databases and object storage.

A behavioural profile built from these signals is unique to your environment. An action that’s perfectly normal in one organisation — a developer pulling production database snapshots for testing, for instance — would be a critical anomaly in another. Static rules can’t express this distinction. Behavioural profiles can.

The baseline isn’t static either. Environments change — teams grow, workloads shift, new services launch. A useful behavioural model adapts to drift rather than generating an ever-growing list of false positives as the environment evolves.

How automated detection agents work

An automated detection agent is a software system that continuously observes environment telemetry, builds and maintains behavioural profiles, detects anomalies against those profiles, and escalates findings that warrant human investigation.

The agent operates in a continuous loop:

Observe. The agent ingests telemetry across your environment — cloud provider logs, identity provider events, network flow data, application logs, SaaS audit trails. It normalises these into a consistent event model regardless of source.

Profile. From observed events, the agent builds and continuously updates behavioural baselines. These profiles capture patterns at multiple levels: per-user, per-service-account, per-workload, per-network-segment. The agent learns temporal patterns (this service account runs batch jobs every night at 2am), relational patterns (this user typically accesses these three systems), and volumetric patterns (this API endpoint handles 500 requests per hour during business hours).

Detect. The agent continuously compares live telemetry against established profiles. Deviations are scored based on multiple factors: how far outside the baseline the behaviour falls, how many dimensions of the profile are violated simultaneously, and how sensitive the resource being accessed is. A single anomalous API call scores differently from a cluster of unusual behaviours from the same identity within a short window.

Escalate. Findings above a confidence threshold are packaged with context — the specific anomaly, the relevant baseline, the raw events, and correlated activity — and escalated for human review. The agent provides the analyst with the evidence to make a fast decision, not just an alert that requires 30 minutes of manual investigation to understand.

This isn’t a black box. Each detection includes an explanation of why the behaviour was flagged — which baseline it violated, by how much, and what the expected behaviour was. Analysts can validate the finding, provide feedback, and the agent incorporates that feedback to improve future accuracy.

What this catches that rules miss

The value of behavioural detection is clearest in scenarios where adversaries are deliberately staying below the threshold of rule-based detection.

Compromised service account

A service account’s credentials are leaked through a misconfigured CI/CD pipeline. The attacker uses the credentials to make API calls that the account is authorised to make — listing S3 buckets, describing EC2 instances, reading SSM parameters. Each individual action is legitimate for that account’s role.

A rule-based system sees authorised API calls from a valid identity. No alert.

A behavioural agent sees that this service account normally makes 12 specific API calls in a predictable sequence during deployment windows. It’s now making broad reconnaissance calls — ListBuckets, DescribeInstances, GetParameter — outside its normal operating window, from an IP range it has never used before. The combination of timing, call pattern, and source anomaly triggers an escalation.

Slow data exfiltration

An insider or compromised account begins copying sensitive data to an external location, but does so gradually — a few hundred megabytes per day, spread across normal working hours, using legitimate access patterns to a data store they’re authorised to query.

No individual data transfer exceeds any threshold. The queries are syntactically normal. The access is within the user’s permissions.

The behavioural agent tracks this user’s historical data access volume. They typically download 50MB per week from this data store. Over the past two weeks, that figure has climbed to 200MB per day — a 28x increase — with queries that are broader than their usual patterns. The gradual escalation and query scope change are flagged as a compound anomaly.

Lateral movement via legitimate tools

An attacker gains initial access to a developer workstation and moves laterally using native tools — SSH, RDP, PowerShell remoting — that are commonly used in the environment. They access systems that the compromised user has legitimate credentials for.

Rule-based detection for lateral movement typically looks for specific tool usage or known attack frameworks. Native tools used within authorised access patterns don’t trigger these rules.

The behavioural agent knows that this user typically connects to three specific systems during business hours. They’re now connecting to systems they’ve never accessed, outside normal hours, in a pattern that suggests systematic exploration rather than task-driven work. The access pattern — breadth of systems, time between connections, sequence of exploration — deviates significantly from the user’s established profile.

Cloud privilege escalation

An attacker with limited cloud credentials attempts to escalate privileges by creating new IAM policies, assuming roles, or modifying existing permissions. They do this incrementally — small permission changes that individually look like routine administrative work.

The behavioural agent profiles IAM modification patterns across your environment. It knows which principals typically modify IAM policies, how frequently, and what types of changes they make. A developer account that has never touched IAM suddenly creating inline policies and modifying role trust relationships triggers an immediate escalation — even if each individual IAM action is syntactically valid and within the account’s permissions.

Why cloud environments are ideal for this approach

Cloud and SaaS environments generate structured, API-driven telemetry at a volume and consistency that makes behavioural profiling particularly effective.

Every action in a cloud environment is an API call. Every API call is logged with the identity that made it, the resource it targeted, the timestamp, the source IP, and the result. This structured, comprehensive audit trail is exactly what a behavioural agent needs to build accurate profiles.

On-premise environments generate heterogeneous logs across dozens of systems with inconsistent formats, variable coverage, and gaps in visibility. Cloud environments provide a unified, structured event stream that covers the entire control plane.

Cloud environments also have a higher baseline of automation. Service accounts, Lambda functions, Step Functions, scheduled tasks — these automated workloads produce highly predictable behavioural patterns that make deviations easy to spot. A Lambda function that runs every 6 hours and makes the same 4 API calls is trivial to profile. Any deviation from that pattern is immediately meaningful.

The challenge is volume. A mid-size AWS environment can generate millions of CloudTrail events per day. A behavioural agent needs to process this volume in near-real-time, maintain profiles across thousands of identities and workloads, and detect anomalies without drowning operators in false positives. This is where automation is essential — no human team can maintain behavioural baselines at this scale manually.

Operationalising behavioural detection

Deploying a behavioural detection agent isn’t a replacement for a detection engineering program — it’s a force multiplier. The most effective MDR operations combine both approaches:

Rules for known threats. When you know exactly what an attack looks like — a specific exploit, a known malware C2 pattern, a documented technique — a detection rule is the right tool. It’s deterministic, fast, and easy to validate.

Agents for unknown and emergent threats. When the threat is an adversary operating within your environment using legitimate access and native tools, behavioural detection is the only approach that scales. The agent catches what rules can’t anticipate.

Humans for judgement. Automated agents detect anomalies. Humans determine whether those anomalies are threats. The agent’s job is to surface the right findings with enough context that an analyst can make a fast, confident decision. Fully automated response without human validation creates its own risks — false positive containment actions can cause as much disruption as the threat they’re responding to.

At Opcode, automated detection agents run continuously across client environments as part of our MDR service. The agents handle the scale problem — profiling thousands of identities and workloads, processing millions of events, and maintaining baselines that adapt as environments change. Our analysts handle the judgement problem — validating escalations, conducting deeper investigation, and driving response actions.

This model means clients get the coverage of machine-speed behavioural analysis with the confidence of human-validated response. The agent surfaces the 15 findings per day that warrant investigation out of the millions of events observed. The analyst team investigates those 15 and acts on the ones that are confirmed threats.

Evaluating MDR providers

Every MDR provider now claims some form of AI or behavioural detection capability. Here’s how to evaluate whether it’s real:

Ask what data the model is trained on. If the provider builds profiles from your specific environment telemetry, that’s behavioural detection. If they apply a generic model trained on aggregated data from other customers, that’s a fancier form of signature detection — it can spot known-bad patterns but won’t catch threats that are unique to your environment.

Ask about the baseline period. A meaningful behavioural profile takes 2-4 weeks of observation to establish. If a provider claims full detection capability from day one, they’re not doing real behavioural profiling — they’re running rules and calling it AI.

Ask how the model handles drift. Environments change constantly. A model that was accurate 6 months ago generates noise today if it hasn’t adapted. Ask how the provider handles baseline updates — is it continuous, periodic, or manual?

Ask about explainability. When the system flags something, can it tell you why in terms that make operational sense? “Anomaly score 0.87” is not useful. “This service account made 14 API calls it has never made before, from a new source IP, outside its normal operating window” is useful. If the provider can’t explain their detections in plain terms, the system becomes an untrusted black box that analysts learn to ignore.

Ask about false positive rates and feedback loops. What’s the ratio of escalations to confirmed threats? How does the system learn from analyst feedback? A system without a feedback mechanism will never improve — it will generate the same false positives indefinitely.

Where this is heading

Behavioural detection with automated agents is not a future capability — it’s operational now. The organisations that adopt this approach gain a detection capability that scales with their environment, adapts to change, and catches the threats that their rule-based detection stack was never designed to find.

The adversary advantage has always been that they only need to find one gap. Behavioural detection changes that equation. Instead of defending every possible attack path with a specific rule, you’re detecting any behaviour that deviates from what’s expected — regardless of the technique used.

For security leaders evaluating their detection strategy, the question is straightforward: are you confident that your current detection capability would catch an adversary using valid credentials, legitimate tools, and authorised access patterns to move through your environment? If the answer is no, behavioural detection is how you close that gap.